[mythtv-users] Is there still a global padding option?

[Michael T. Dean]

On 09/28/2012 05:03 PM, Michael Watson wrote:
> On 29/09/2012 3:02 AM, Craig Treleaven wrote:
>> At 5:20 PM +0100 9/28/12, Mike Perkins wrote:
>>> On 28/09/12 13:25, Michael T. Dean wrote:
>>>> On 09/27/2012 09:22 PM, Michael Watson wrote:
>>>>> On 27/09/2012 10:40 PM, Michael T. Dean wrote:
>>>>>>
>>>>>> But thanks for the additional proof that we have too many 
>>>>>> settings to be
>>>>>> useful and that it's too hard to find the settings, even when you 
>>>>>> know they
>>>>>> exist, and that "just add a setting" isn't a good choice for 
>>>>>> solving future
>>>>>> problems.  :)
>>>>>>
>>>>>
>>>>> Frontend > Setup > Video > Recording Priorities >
>>>>> Set Recording Priorities > Page  1 is Scheduler Options,
>>>>> followed by Pages 2 and 3.
>>>>>
>>>>> Or more intuitive locations for existing/future options. Seems (to 
>>>>> me) odd,
>>>>> to look in Video for options to do with recording/scheduling.
>>>>
>>>> Well, ignoring the fact that a lot of settings have been 
>>>> moved/renamed to try to
>>>> make them more "intuitive" and easier to find (and, yet, they still 
>>>> aren't),
>>>> that still doesn't help the other problem--that we have too many 
>>>> settings for
>>>> users to know what settings are available (not to mention the 
>>>> effects of the
>>>> interaction of different settings).
>>>>
>>>> I'm still a big believer that a setting is just a shortcut for when 
>>>> the
>>>> developer doesn't know (or doesn't feel like writing code for 
>>>> figuring out) The
>>>> Right Thing to do.  (And Apple seems to be proving that people are 
>>>> happier with
>>>> limited settings and "It Just Works".)
> Maybe "it just works", but very frustrating to use.
>>>>
>>> That works for Apple because they only have a fixed, limited variety 
>>> of hardware to program for and the hardware is all under Apple's 
>>> control.
>>
>> No, Apple focused on simplicity because it was a key mantra of Steve 
>> Jobs:
>>
>> http://www.socialnomics.net/2011/10/05/steve-jobs---10-lessons-in-life-leadership/ 
>>
>> Steve Jobs demanded that the iPod not have any buttons on it; 
>> including an on/off switch. This seemed implausible for the engineers 
>> working on the project, but Jobs wouldn't bend. The engineers were 
>> pushed to their limits and as a result the scroll wheel was inspired. 
>> Jobs indicates "that's been one of my mantras - focus and simplicity. 
>> Simple can be harder than complex: You have to work hard to get your 
>> thinking clean to make it simple. But it's worth it in the end 
>> because once you get there, you can move mountains."
>>
>> Myth, currently, is very much the opposite.  The pages and pages of 
>> settings in Myth verge on incomprehensible.  Even stuff that I need 
>> and use, I sometimes forget if the knob is in mythfrontend Settings 
>> or in mythtv-setup--and I've been using Myth for over 6 years.  If we 
>> took a sample of 1,000 active Myth installations, what percentage of 
>> Myth's settings on each system are still at the delivered default? 
>> I'd guess on each individual install, less than 15% of the available 
>> settings are changed.  Of course, each individual knob is somebody's 
>> sacred cow that can't possibly be eliminated.
>>
>> Fewer settings is a good thing--both for Myth and other consumer 
>> gadgets.  Even if some resist.
>
> Just because you never change the radio station on you car radio, 
> should that option be removed?
> Just because you dont know where the toe-in adjustment on your car is 
> (or what it does), should that be removed?
> Should the Temperature setting be removed from your 
> heater/airconditioner? (and just set to what the manufacturer wants it 
> to be?)
>
> If you took a sample of 1000 Windows Users, or KDE Users, or Gnome 
> Users, MythTV Users, the results would be fairly similar.  This is not 
> a good argument to rip out the "least popular" options.   Most of 
> options/settings are there for a reason, some may be obscure (or 
> forgotten), no reason to remove them, unless they are no longer 
> required.  Remove all the options, and you have a system that works 
> only the way the developers want (akin to an Apple Device), which is 
> fine if that works for you, but frustrating if you want to change the 
> behavior slightly to work with your hardware/timezone/channel 
> listing/media/etc/etc/etc.

I typed up a long response showing why the common arguments are 
completely invalid.

In the interest of avoiding a big argument, here's the short version:

a) Nearly all of our "true" settings--including those "most loved" by 
users--are settings that users only know how to set by trial and error.  
Rather than force users to try, see that it doesn't work, change, test 
again, and repeat until they find the working setting, we should be 
doing that testing automatically in the code and just use the right 
setting.  These we're removing (so you don't have to know whether or not 
your video hardware and drivers properly support multi-texturing, vertex 
arrays, ...).

b) The "radio stations on the car radio" is primary functionality of the 
radio device, just like recording TV is primary functionality of 
MythTV.  We give you all the "settings" you need for that in terms of 
channels (and their "settings" like channel numbers, channel names, call 
signs, ...), recording rules (and all their "settings"), storage groups, 
...  We won't be taking those out /because/ they're primary 
functionality of MythTV and need to be adjusted for the myriad of 
locales/broadcasts/hardware/system configurations used by our users.  
These we're keeping.

c) Where user-preference is involved, we also provide choices--such as 
key bindings and UI and menu themes (and all of the "settings" exposed 
through theming).  We just won't be providing a setting in the settings 
screen to allow you to change your key bindings (you'll do that through, 
er, changing your key bindings) or to allow you to second-guess/break 
the well-tested theme design (you'll do that through switching themes, 
changing the theme design, or creating your own theme).  These we're 
keeping--but only in the place they belong.

d) The remaining "true" settings not covered by a, b, and c, above, are 
actually just placebos--like the completely broken "one preview pixmap 
offset will work fine for all channels by all broadcasters from all 
sources showing all types of content" setting that was removed (and 
replaced by code that actually attempts to figure out a usable in-show 
frame by taking into account things like start early/end late, program 
start time, recording start time, commercial skip lists, and cut lists 
actually gives much better results than blindly choosing a single 
location to be used for all recordings (and, yes, I actually did testing 
with many thousands of recordings to find we'd need settings to allow 
control based on recording rule (type of program and commercial-break 
timing--which actually even changes between seasons of programs), 
channel (different ones use different formats for breaks), video source 
(as there can be quite noticeable delays between OTA and cable/satellite 
rebroadcasts), and more).  These we're removing and replacing with code 
that does what we've since learned the setting couldn't do (uses more 
information to get a better answer).

And I won't even mention the fact that blaming the layout of our 
settings pages for users being unable to know about/find/determine 
effect of all of our existing settings doesn't help.  If you really feel 
that's the problem, come up with a design that would mean I'm not 
constantly quoting/pointing out/explaining settings on the list.  
(However, since that's impossible, I plan to proceed with my current 
replace the "I'll just make a setting and force the user to figure out 
the right thing so I don't have to write so much code" with the /much 
more/ code required to just Do The Right Thing plan.)

Mike