[mythtv] MythTV Usability Report

f-myth-users at media.mit.edu f-myth-users at media.mit.edu
Mon Jan 9 04:56:45 UTC 2006


If MythTV had fewer usability issues, it would probably decrease mail
volume on the -users list at least, and also lead to a lot less wasted
time by newbies trying to set it up and/or use it, and less time by
more-experienced users trying to help them.

But improving MythTV usability is currently a giant Catch-22.  Why?

(a) The reaction to usability reports is more hostile than not, when
    viewed socially.  [For an example, see the list of examples below;
    each of them is keyed to the items here by letter.]
(b) The reaction to usability reports is more hostile than not, when
    viewed technically.  [Again, see examples below, etc etc.]
(c) Usability analysis and writing code are typically different skill
    sets, but people who complain about usability in MythTV are often
    told, "Just code it yourself."
(d) New users are most likely to notice usability problems, but are
    least likely to be able to write -any- code, no matter how simple,
    because they're still trying to figure out the product---not
    diving into a large codebase.   
(e) Some developers assume that they're the best-qualified to evaluate
    usability, including for brand-new users, but they're the ones
    most familiar with the interface and least likely to see where
    it's confusing.
(f) New users are typically the ones most likely to find things
    confusing, but also most likely to be unable to clearly figure out
    where the actual problem is; in many cases they don't even know
    the right vocabulary yet.  [NOTE!  This also means that they are
    least likely to be able to search list archives for solutions,
    because they don't even know what terms to use.]
(g) New users are most likely to use a stable version (e.g., 18.1),
    but because it's been so long since a stable version has been
    released, are typically ignored because SVN has moved on so much.
(h) Since usability problems are most likely to be noticed and
    reported by new users, they're most likely to be in the form of a
    feature request, not a patch---after all new users by definition
    aren't familiar with the code base (if they ever are; most new
    users aren't coders, judging by the list traffic).
(i) Unfortunately, there isn't any way to submit feature requests
    unless they -are- accompanied by code.  Some developers will
    nonetheless accept them (e.g., see my recent conversation with
    Chris Petersen about Mythweb), whereas others will simply close
    any such Trac ticket with, "feature request without patch attached."
(j) If a long list of usability issues is discussed in one message,
    one is told, "Nobody wants to read a long message; break it up."
(k) If the list is broken up into one topic per message, one is told,
    "Stop opening so many new threads on the same idea."
(l) If Trac is used to separate each feature request into a trackable
    item, they'll all be closed in the guise of, "feature request
    without patch attached."
(m) Because of all of the above, people who've offered to help out
    with usability issues are typically turned away.
(n) Because those most likely to view usability as a priority are
    discouraged from speaking out, and can't make contributions in
    trackable fashion, MythTV usability doesn't improve very much.

How can we fix this?

(0) Stop jumping on people who complain about usability.
(1) No, -really-.  Stop jumping on people who complain about usability.
    Just because they're new is no reason to engage in a hazing ritual.
    Just because they're interested in consistency of interface, or
    in up-to-date, easy-to-find documentation all in a single place,
    or not already hip-deep in code, is no reason to look down on them.
(2) I'm very glad that Daniel Kristjansson has said he's willing to
    host usability reports.  I will contribute to that project, if I
    think that the resulting effort I spend won't simply be thrown
    away, ignored, or jeered at.  Given my past experience with the
    sociology of this project, I will wait for someone -else- to make
    the first move, however, and see whether they're time is wasted.
(3) It would be really, really nice if there was a documented way to
    submit feature requests.  There's been recent list traffic about
    this problem (see braedric-mythuser at yahoo.com's thread starter,
    over on the -user list just this evening) in which it's
    acknowledged that there's currently no way to do this.  I'm not
    saying "developers must work on any feature request submitted";
    who would?  I -am- saying that it would be nice for a developer
    with time on his or her hands to be able to say, "Is there
    anything people are clamoring for that I might be able to knock
    off in an afternoon?"  I'd suggest some sort of segregated Trac
    in which it was stated very prominently, "things here are not
    milestones and might never be fixed or closed", but at least it
    would let people see if others had suggested the idea, chime in
    with ways to do it, etc.  Many projects work this way, closing
    such features with either "implemented", "can't figure out any
    way this could work", or just leaving the request open forever.
    MythTV is the -only- project I've seen where one developer will
    say, "this doesn't have code with it, so I'm closing it so no
    other developers will even consider spending any time on it."
    No project I've ever worked on has handled feature requests in
    this way, except this one.
(4) Make self-documentation a priority.  Note David Abrahams's message
    just this evening (over on the -users list) complaining about
    inconsistency and opaqueness of keybindings; this is exactly what
    I was complaining about in early November---in fact, that very
    inconsistency over whether keystrokes were totally ignored or not
    cost me a week of work, but I was shouted down (and -at-) for
    suggesting that it could be improved.  I made the suggestion then
    (and I'll make it again now, and to Daniel's website once he sets
    it up) that there should be a single key, also bindable to a
    remote key, which pops up a list of -every- valid action and
    keystroke that can be taken in the current screen.  (Yes, the
    indirection through LIRC etc is a problem, but I had some ideas
    about that in my earlier posts, and I'd be more than happy to lay
    out a more-complete design if I thought it wouldn't be a waste of
    my time.  And it'd be pretty easy for the keyboard case.)  Note
    that this even screws experienced users!  Witness my recent
    conversation with Chris Pinkham on Friday (continuing an old
    thread) on how to delete things from the job queue, in which
    nobody could figure out if the mystery item was even present or
    not.  (Turns out not; it's in SVN but not 18.1.)  So how much of
    several people's time was wasted?  Compared to the case if I could
    have hit "?" and said, "Ah, there's no menu item for deletion here
    at all, hence nothing to bind to."

Examples of some of the above points:

(a) The reaction to the most recent report by the original poster, and
    to the ones I tried to submit back in early November.  The vast
    majority of reactions were negative, just by counting positive vs
    negative numbers of messages.  And whatever you think of -my- tone
    when I was submitting such reports, you have to admit that Jono
    Bacon's tone (the original poster in -this- thread) was positive
    and enthusiastic---but he still got slammed repeatedly.  So it's
    not (just) the tone, and it's not (just) me.
(b) The reaction to my report that at least one installer would create
    a ringbuffer partition too small to hold the ringbuffer, causing
    the machine to explode and die (in a hard-to-fix way) if it was
    left in LiveTV too long.  I had to argue, repeatedly, that we not
    punish the user for innocently leaving the UI in a common,
    documented, expected mode for too long, against others who claimed
    that "nobody should do that anyway" and "that's not what MythTv is
    for" (then why's it a major piece of functionality?) and so forth.
    All this, for something a couple lines of code could have fixed.
    (It's now moot in SVN, since LiveTV works differently, but the
    pattern of behavior is consistent across several other issues.)
(c) This sort of macho posturing is all over the place in free and
    open-source development, but it's worse in some places than
    others.
(e) There's lots of literature in the usability field about this.
    It's pretty much taken for granted as dogmatic truth there.
    For an example here, note all the resistance when I suggested
    that mythtv-setup, by default but overrideable by experts,
    automatically assign sequential and unique device numbers,
    instead of letting new users shoot themselves in the foot.
(g) What new user is going to run SVN?  For one thing, it takes a
    large committment to do so having not even tried the product at
    all, and for another, it requires monitoring both -dev and -commit
    (and maybe -users), all incredibly high-volume, before even
    starting to compile anything, much less use it.


More information about the mythtv-dev mailing list