[mythtv-users] manual scheduling -> "no upcoming recordings"

[f-myth-users at media.mit.edu]

    Date: Fri, 4 Nov 2005 17:01:42 -0500
    From: Isaac Richards <ijr at case.edu>

I will repeat:  You, sir, are way, WAY too close to the problem.
You have no conception of what it's like to be a first-time user.
Therefore, your opinions on what's "obvious" or "easy" are not to
be trusted.

    Have you ever used _anything_ with a remote control before?  I guarantee that 
    there's not a "Press the 'Guide' button to bring up the program guide" 
    message burned in to your TV from it being displayed all the time.

I'm not -using- a remote control right now; I'm using a keyboard,
because I'm trying to get the box set up.  Because mythtv-setup is
often used when (surprise!) setting up the box, you can't assume
that everyone's using a remote.  They might not even have installed
LIRC yet.  Burying functionality is a bad idea.

    Did you even bother to read the mythtv howto?  It lists all the commands: 
    http://www.mythtv.org/docs/mythtv-HOWTO-11.html

Of course.  Did I commit every turn of phrase to memory?  No.

The whole -point- of big pretty UI's is to -avoid- forcing users to
read manuals.  And let's face it, Myth requires plenty of reading of
random manpages, web pages, and everything else already.  The less we
must force people to crawl through the doc to find buried features,
the better.

There's just no excuse for hiding this functionality.  The "Capture
Cards" screen should mention what keyboard accelerators it takes and
not hide a crucial bit of functionality behind one.  (And how come M
only brings up TWO choices?  "Delete" or "Edit".  Are you telling me
that it was -so- important to separate these choices at all, instead
of rolling them into each other?  Or was it just easier to implement
Delete if the configuration menu wasn't already onscreen?  Right now,
the -only- point of even -having- M in the interface (as opposed to
Return, which calls up the menu even if you've never heard of M) is
to enable one single option---Delete, since the only option is "Edit",
which is where you wind up if you hit Return.  You might as well have
just added a D option and left off the M, frankly.)

[And you can't argue that M is usable everywhere.  I just tried it in
a very similar-looking list, namely the "Input connections" screen,
where it does NOTHING.  Yet typing Return there -does- get me the
menu.  Why the inconsistency?  Clearly, Return works everywhere, but
M doesn't---which is the user more likely to figure out by accident,
and which is he more likely to remember?]

By the way, each individual screen for the card should probably have a
Delete button somewhere on it, too.  It's safer if the user can look
directly at the -complete- configuration of the card before deleting
it; otherwise, if you've got multiple tuners (without which you're
probably not going to be deleting a card in the first place), you have
to COMMIT TO MEMORY the correct DEVICE NUMBERS before deleting one.
It's another way to go wrong.  And, given my other complaints about
assigning new devnums causing the entries to rearrange their order in
that listing, I don't even have any faith that I'd be deleting the
right -card-, since their order kept changing.

Lacking both of those, it just looked like someone had forgotten to
even add this to the interface.  Given all the other usability issues,
can you blame me for making this assumption?

    Seriously, this is just getting laughable.

Yes, and apparently not in the way you think.

Currently, MythTV's configuration system looks like the "Bad Example"
section of any book on user interface design.  Class, let's review:

(a) No automated setup for the most common actions.
(b) No error-checking in critical data-entry fields.
    [Not even the -simplest- check for "duplicate entry"!]
(c) Changes in some fields are thrown away without warning.
(d) Any error in those fields---quite likely because of the above
    problems---causes problems that look like hardware failures.
(e) Fixing those errors (apparently) breaks other functionality
    in ways that no non-developer user is likely to know how to fix.
    [For example, I'm still in the situation where my BE has
    mysteriously lost the ability to schedule recordings manually---
    it just swallows the input.  If I don't get a solution soon, I'm
    going to have to reinstall the entire backend.  Good excuse to try
    Ubuntu, I guess.]
(f) Old information is cached in hard-to-find places.
    [I deleted the fifth card---why is ivtv still bitching about it?]
(g) Confusing, poorly-laid-out menu trees, with some options
    (e.g., several "General" menus) named identically but in
    different places and with quite different functionality.
(h) Partially-overlapping configuration shared across two different
    programs, which no obvious division into which program is
    responsible for what.

I must admit, I'm baffled by some of the apparent hostility here
towards improving the user interface.  Sure, call me abrasive, call me
demanding, but don't carry that over to insisting that the fundamental
-ideas- are invalid.  I'd rather that you weren't hostile to me, but
I'd -really- rather you weren't hostile to the very idea of improving
life for -users-.

Or are you angry at the users?  Do you -want- them to have a bad time?
To give up in disgust?  To assume they must be stupid because it takes
them ages to get anything working?

You can't be expected to know this, because you don't read my mail,
but I've had a steady stream of lurkers writing to me all day, saying
things like "Oh, thank -god- somebody is finally bitching about this!"
and "Oh! I thought it was just me!" and "No -wonder- this got all
screwed up!" and similar sorts of things.  I'd say there's a problem
here, whether it's generally known or not.

[And I'm not even mentioning, e.g., the recent thread about "how come
Every Day isn't really every day?  It matters -what day I start on-
whether it includes weekends?  WTF??" as opposed to having "Every
Weekday", "Every Weekend", and "Every Day", like any sane interface.
It's not as if we're designing a remote and don't have room for the
damned buttons.  See the pattern here?  Obscure, random behavior that
confuses users, is trivially fixable, but generates big massive
flaming arguments about whether it even -should- be fixed!]

The really sad part about this is that -all- of the bugs I've reported
in the last few days are probably fixable in under 100 lines of code,
total.  Most of the really bad ones are probably 10-line or 1-line
fixes.  A lot of them are fixable simply by adding a single English
sentence to something.

I can understand why the developers might want to divert the majority
of their efforts to actually making sure the hardware works.  But if
just 1% that effort went to making the UI easier, it would help an
enormous number of people.  And even better, -that- sort of work is
the sort of work that more people can help with, because they need
neither specialized bits of hardware, nor kernel-level knowledge of
the system.  But in order to get the help, it's first necessary to
publicize the problems.  And it's -not- helpful to belittle any
mention of UI issues.  It's a repeat of the classic attitude that
almost did in Unix as a desktop OS in the first place---the macho
kernel-hacker posturing that said, "If you're not a kernel developer,
you're a nobody, and not worth my time."  So all the desktop users,
who just wanted to be able to send mail and write memos, went
elsewhere.  It's taken years to get them back.  We have good examples
of how to do it right in other software packages and even certain
distributions.  But all of those started from listening to problems
people had with the UI, not simply calling them stupid for daring to
speak up.

Furthermore, if you expect contributions from other users to help fix
the problems, you're not going to -get- them by yelling at them and
dismissing their problems.  Why the hell should I or anyone else waste
our time coding up a solution to any of these problems if we think
that the response will be, "That's not a problem.  You're stupid.
I'm not committing this code."  But that's the attitude I've been
seeing.