Preferences dialog suggestions

[Conrad Canterford]

On Sun, 2002-10-20 at 08:39, Chris Lyttle wrote:
> However it was
> pointed out that having too many options actually makes the dialog
> confusing not only to new users, but also to expert users
<...>
> The guideline suggested by the usability folks that
> I know in designing preferences is if you feel you need an option for
> something, you should look at how that piece functions and ask yourself
> if the option is really needed or if its only needed to fix a design
> flaw. Is the option is really giving the user a choice that is useful?

The point I'm trying to make is that some decisions are being made on
whether an option is "useful" based on our (not just my) experiences,
and not necessarily on what the users out there are wanting. You're
right, we do agree on lots of things:
- The preferences dialog as it now stands could be better organised, and
the wording of some of the preferences could be done better.
- If the option is really covering a design flaw, then the better option
is to redesign to get around that flaw (however, does this excuse us
getting rid of the option when the work to get around the flaw is not
going to happen for perhaps several releases and the option makes sense
in the meantime).
- Preferences *should* be easily understood, and *should* default to the
functionality that the majority of users are going to want. The majority
of users should never need to touch the preferences.
- Where a preference does nothing, it is confusing and should be
removed.
I think we agree on all those points.

However, I don't think this justifies removing (or not adding) an option
just because what it does is obscure and only likely to be used by a
tiny percentage of the gnucash users  That option should be put
somewhere where it makes sense and is sufficiently explained, but where
the average user will just glance at it (or better yet, never get there
because they (correctly) looked at a higher level category description)
and say to themselves "That's not relevant to me". If we do things this
way, we increase the appeal of gnucash to those extra users. If done
properly, it won't make the matter more confusing to the average user.
I don't have a solution to how to achieve this, and the more I think
about it, the more I wonder if our current preferences dialog is up to
the task. However, and "advanced" setting will alleviate some of this
for now. We can rethink the whole prefs thing later.

> > > 3) Advanced Preferences button - Add this to General, when checked shows
> > > extra tab with more complicated prefs settings called 'Advanced'.
> > Well, I'm hardly going to object to this, although I think you're
> > planning on using it for more than just advanced options, and that I do
> > think would be confusing.
> Not really, my suggesting this was a compromise to you when we discussed
> your wanting to implement a checkbox for getting rid of dialogs. I dont
> regard it as a dumping ground.

My apologies. It felt that way to me. 

> > > 5) Make Register Colors a tab that only shows when advanced is selected
> Well to be honest I wasn't sure about this one. Actually now that I
> think about it more the problem I have with this dialog is really more
> one of _how_ it is implemented not what it is. I would much prefer
> something like a 'theme' selector which shows a little picture of
> certain register themes and allows the user to pick one they like. Its
> difficult with the way this is to visualize the change.

That is an example of what I feel is the solution to this whole problem.
The problem isn't that we offer too many prefs, its how they're
presented. BTW, I like the theme idea although I'm not sure how it will
work in practice.

> > > 	Show All Transactions - Why wouldn't we want to show them all?
> Well, I can see the need for limiting the number of transactions in the
> register. That isn't necessarily an advanced option too. My take on it
> was that you could do this through date range, but I guess that's
> limited by needing to open the account first.

Yes, and that was the issue this was designed to avoid.

> If we did use this it
> should probably also have some way of saying 'I want to only show the
> past 2 month's (changeable) transactions' The above doesn't really tell
> you how to do that.

I don't know that we can do that (make the period editable) just at the
moment, but I think its a great idea. Raise it as an RFE  :-).

> Conrad please understand I'm not trying to be arbitrary in suggesting
> changes. I'm actually trying to both refer to and use what I've learned
> from the GNOME usability project and people a lot more experienced in UI
> design than I am.

I'm sorry, that was probably worded a little too harshly. I do know that
you are trying to make things better, and I do appreciate that you have
taken a lot of time and effort to look at these issues in this and other
areas and have done an awful lot to improve our usability through your
work. I guess I overreacted at your suggestion of removing two features
because you didn't know what they did which are or have been important
to my way of working in the past. In your defence, you did ask for an
explanation of what they were, and I apologise for my reaction.

> I dont fundamentally agree that having every option
> you can think of is giving users choice or flexibility though. At best
> most users just want to get on with using an app and having to wade
> through a whole bunch of prefs in order to do that really doesn't help
> that goal.

But here is my point - if the default value for the preference is set
properly, most users *won't* need to change it, whether its there or
not. The default behaviour should always be the one that satisfies most
users. However, if a couple of users suggest an option that is
relatively easy to implement, this suggests to me that we are not
providing those people with quite the application they want and that an
option is therefore appropriate. It is then our job to add that option
in such a way that those people can find it without confusing people
looking for other things. And once we add the option, other people will
look at it and say "Oh, we can do that... COOL!".

> I refer again to my above argument, using a preference for
> something, the same as when you are actually designing an app, should be
> looked at as a tradeoff. Starting out with the principle that you ask
> 'can I design this better so I dont need a preference for this' and then
> only implementing a preference if its really useful is a far better
> design choice than 'oh if you can't do this we'll just make a preference
> to turn it on'. I understand that you think I'm on the opposite side of
> this issue to you, but really that isn't the case.

I really do disagree with this... (sorry). Preferences are not
trade-offs. They are ways of offering users an ability to customise the
behaviour of the application to suit their individual needs and tastes.
That is what the name "preferences" means, surely?
We cannot write an application that is perfect and suits every single
person without having to set a single preference. People vary too much 
Some people like their application to warn them when they're being
stupid, others just want the computer to do what its told and hang the
consequeces. Some people like to control the amount of information
presented to them, other people want everything presented to them so
they can choose what to look at. What gives us the right to say which
lot of people are "right"? Our job is to provide both groups with the
best application we can, and that means being able to customise the
application to suit their desires.

Conrad.
-- 
Conrad Canterford  (conrad@mail.watersprite.com.au)
Water Sprite Pty Ltd   |  url - http://www.watersprite.com.au/
GPO Box 355,           |  - Australian Tour and Event Management (ATEM)
Canberra, ACT 2601     |  - Ticketing Division.
Mobile: +61 402 697054 |  - Catering Services Division.