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 [EMAIL PROTECTED]'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.
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
