Preferences

Chris Lyttle chris at wilddev.net
Mon May 12 19:26:15 CDT 2003


On Mon, 2003-05-12 at 14:05, Terry Boldt wrote:
> I reread Derek Atkins' reply to my email and another statement stood out for 
> me:
> 
> >In general, preferences are bad.  The fact remains that there is
> >already a way to do what you want; the fact you don't like it is
> >reegrettable.
> 
> I had always considered it exactly the opposite, that "preferences" are highly 
> desirable. Without preferences, the user is "stuck" with doing everything 
> exactly the way that the developer says things should be done. Now that 
> assumes that the developer knows absolutely the best way to do things for 
> absolutely every user. Kind of like Levi saying that we will manufacture only 
> one style of Levi's and only one size. Everybody with a waist over 36" should 
> lose weight and everybody under 36" should excercise and beefup.
> 
This is not only a bad analogy, it also characterizes the cost of
preferences wrong. More preferences in software don't equal more sizes
of jeans, jeans are a clothing item that everyone knows how to put on
and how to button up. Software is not clothes, is vastly more complex in
both design and in usage cost and every feature and preference added to
software has a cost and a benefit. Software is a trade off between
functionality (lots of preferences for everything possible) and
usability (the enormous expense in time involved in tweaking and
learning how to use the software). Sure you may have the time to spend
looking into every last detail of how your software works but most
people just want it to work and tweak maybe one or two things then get
on with using it.

> Is the gnucash developer community really working to eliminate the 
> 'preferences' dialog?
> 
> Again, I would have thought exactly the opposite to be true, that is, make the 
> s/w as customizable as possible by the user. That means that the 
> "preferences" dialog would have to expand to accomodate the desire to 
> customize to suit the users "preferences" and style of working rather than 
> the user having to change to meet the style of working enforced by the s/w.
> 
<snip - another bad analogy>

See above, expanding preferences doesn't equal more satisfaction among
users, making preferences reflect the needs of the majority of users and
designing the software so its useful right away for most users is the
best trade off. You can never satisfy everyone, but you need to be
mindful that most people who use computers just want to get on with
using it not spend all their lives tweaking preferences.

Chris (sick of stupid preferences arguments already)



More information about the gnucash-devel mailing list