[mythtv] A need for advanced player settings

[Michael T. Dean]

On 05/31/2011 03:23 PM, freedenizen wrote:
> On Tue, May 31, 2011 at 11:48 AM, E. Westbrook wrote:
> <snip>
>> 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:

http://www.codinghorror.com/blog/2005/09/the-problem-with-configurability.html

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 
configurable*:

   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
      software

---

and, from the book he's quoting:

http://www.joelonsoftware.com/uibook/chapters/fog0000000059.html

*"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:

http://en.wikipedia.org/wiki/The_Paradox_of_Choice:_Why_More_Is_Less

When Choice is Demotivating: Can One Desire Too Much of a Good Thing? ( 
http://www.columbia.edu/~ss957/articles/Choice_is_Demotivating.pdf ) 
Iyengar, S. S., & Lepper, M. /Journal of Personality and Social 
Psychology,/ 79, 995-1006. (2000)

(and a /lot/ of her research, see 
http://www.columbia.edu/~ss957/publications.shtml )

and for those who don't want to read PDFs, here are some articles/blog 
posts/etc that mention some of the above:

http://sivers.org/jam
http://www.nytimes.com/2010/02/27/your-money/27shortcuts.html
http://www.apa.org/monitor/jun04/toomany.aspx

and a very-opinionated, probably NSFW, article at:

http://flyosity.com/iphone/kill-the-settings-build-opinionated-software.php

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."

Mike

*** 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 
the setting:

Confirm exit
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 
name NoPromptOnExit

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 ...)