[mythtv] A need for advanced player settings
Michael T. Dean
mtdean at thirdcontact.com
Tue May 31 20:16:14 UTC 2011
On 05/31/2011 03:23 PM, freedenizen wrote:
> On Tue, May 31, 2011 at 11:48 AM, E. Westbrook wrote:
>> If we fear that the entrepid newb will STILL adjust it, to her peril, it's
>> easy enough to document a stern warning alongside with the setting's
>> authoritative reference entry, where presumably she will have gone to find
>> the value anyway.
> In my heart I'd love to agree, I always want there to just be a simple
> db table somewhere to do my tweaking, nicely documented, etc.
> The problem is that well people share information. Experience savvy
> user A adjusts a setting by reading all the associated documentation.
> Somewhat technical user B posts a problem to the mailing list, user A
> shares their fix, maybe even with the link to the documentation and
> user B implements it.
> So far that isn't so bad, the problem is that users C, D, and E who
> have no idea what they are doing just search google and find the
> commands to run in the mailing list archive without reading the
> documentation, 6 month later one of they runs into a different problem
> which is actually caused by the setting they changed in the table when
> they really had no idea what they are doing. They come onto the
> mailing list and everyone struggles to help them out, not realizing
> that they actually adjusted something which caused the fault in the
> first place.
Well said. In addition:
My favorite quote from which is (where the entry is specifically about
UI design, but applies to any other "configurable"), "This example leads
me to consider an excuse some developers have for not providing a
satisfactory visual interface to their products: 'the user can just
customize the design to his or her individual taste!' *Leaving the
design to the users is the ultimate abdication of the designer's
responsibility to provide a quality product*..." And, the summary at
the end is well worth reading:
You might come out ahead by *intentionally choosing to make things not
1. It forces you to carefully select good default values
2. It forces you to pick a strategy and run with it rather than
hedging your bets and trying to satisfy everyone
3. It's one less thing for the user to think about when using your
and, from the book he's quoting:
*"Every time you provide an option, you're asking the user to make a
decision.* ... Asking the user to make a decision isn't /in itself/ a
bad thing. Freedom of choice can be wonderful. ... The problem comes
when you ask them to make a choice that /they don't care about/."
In this situation, the user doesn't care about the buffer size--they
just want playback to work. Therefore, we just need to fix the
underlying bug, choose the appropriate buffer size, and make playback work.
And, yes, I did also read the end of that one, where it says, "This
doesn't mean eliminate /all/ choice." However, that's /not/ our goal.
We're simply trying to eliminate the choices that users don't care about.
Not to mention:
When Choice is Demotivating: Can One Desire Too Much of a Good Thing? (
Iyengar, S. S., & Lepper, M. /Journal of Personality and Social
Psychology,/ 79, 995-1006. (2000)
(and a /lot/ of her research, see
and for those who don't want to read PDFs, here are some articles/blog
posts/etc that mention some of the above:
and a very-opinionated, probably NSFW, article at:
So, IMHO, Stuart M was exactly right. Settings that are as low-level as
these are far too technical for most users (and, really, most
developers--me included) to figure out on their own. Therefore, I agree
that the best approach is to let users who feel they need changing
actually modify the code. Our goal for MythTV is to do the right thing
when we can, without forcing the user to understand details that
shouldn't be their concern.
A user-configurable setting is often just evidence that the developer(s)
either didn't know what the software should actually do or chose an easy
out rather than writing the code to just "do the right thing."
*** Also, for a fun exercise showing why writing raw settings values
directly into the DB (and failing to do validation and boundary checking
and type checking and ...) is just plain wrong, try to set a value for
If enabled, MythTV will prompt for confirmation when you press the
System Exit key.
without using the GUI. It's a boolean value that only has 2
alternatives (so it's easy to test). Use a -O override with the setting
mythfrontend -O NoPromptOnExit=1
or use the value 0. Then, think about what you just saw. Now try to
figure out how you would document this or teach a user to set it without
a GUI--and when you remember this is a simple 2-state setting, you
realize how dangerous it is to poke values into other settings that are
critical to proper operation of the application, and (more importantly)
how difficult it would be to teach users--who just want to record and
play video--how to choose the right value. (And, now start thinking
about how much more complex the code is when you not only have settings
for all sorts of critical values, but also have to do validation and
boundary checking on /every/ use of the value because the user may have
written a string that can't be converted to an int or ...)
More information about the mythtv-dev