Preferences dialog suggestions

[Chris Lyttle]

On Sat, 2002-10-19 at 08:53, Conrad Canterford wrote:
> On Sat, 2002-10-19 at 20:41, Chris Lyttle wrote:
> > This doc is an outline of proposed changes to the preferences dialog.
> 
> Chris,
> 
> > 2) Remove QIF Import tab - The single item on this is really something
> > that should be moved into the General tab.
> 
> We should get feedback from Benoit and Christian concerning what options
> may be applicable for the new import stuff, and change this to an
> "import" options tab.
> Personally, I don't think QIF options are a "general" thing at all - I'd
> never used QIF import for real until this month, and I've been using
> gnucash for over 3 years. Beware of confusing things by
> oversimplification....  :-)
> 

Well I agree with you about QIF specific options not being a general
thing, but this dialog is _just_ for turning off extra text screens in
the QIF import. This is why I suggested it go into general (its possibly
something that could be generalized for all our druids). Now having said
that I agree that if there are other preferences needed by the new code
(even just a couple more) changing it to 'Import' and leaving this there
would also work. BTW my reasoning in saying this is _not_
oversimplification. I know you find it difficult to understand where I'm
coming from by my objective isn't to limit choices but to limit clutter
and confusion for users. Just because of the fact that you have been
working on GnuCash code and using it for years means you're used to the
way things are but this isn't necessarily an argument for leaving things
as is.
>From what I learned watching this discussion go on when GNOME2 was being
developed, a lot of developers thought, like you suggest, that the aim
was to limit flexibility and choice by removing options. 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 as there is a
limited amount of information the brain can take in at once. This means
that even expert users would have to spend some time with lots of
preferences to get things setup (reading and figuring out what things do
then applying them). 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?

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

> Certainly agree to the above two. I'm not sure I agree about the next
> three (although I'm uncertain about double line mode). What's so
> "advanced" about them?? Surely screen layout is not an "advanced option"
> at all.
> 
> > 	Double Line Mode (Register)
> > 	Show Vertical Borders (Register)
> > 	Show Horizontal borders (Register)
> 
> The same thought applies to this one. In what way is it "advanced"????
> Changing register colours has to be one of the most basic and easily
> understood preferences a user could use.
> 
> > 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. This is also the
criticism I have for the other three above this, its difficult to say
exactly what they will do without picking them, closing the prefs and
going to look. However I know its too late now to effect this sort of
change, so I'm willing to leave them as is. We can always look more
closely at what we are trying to accomplish with the prefs and how we
can make it easier for a user to just look and go 'yeah that's what I
really want'.

> > 6) Suggest Preferences dialog be made 30% smaller
> > 7) Suggest max number of items on any one prefs tab be 6 - Will make
> > those with few items not look like such a waste of space
> 
> Not a criticism, but a question. Why? We're not talking dead-tree
> production here, in what way does the size matter that much? If reducing
> the size means crowding options together more, or forcing them to be
> broken down into more obscure sub-groupings, surely that is a bad thing?
> 

Well, again this is just to try to reduce clutter, but as Derek said in
his post the size is dynamic so these are probably irrelevant.

> > 8) Ok if someone can explain the usefulness of these items we could
> > possibly put them in advanced, however I vote for just getting rid of
> > them (all in Register);
> > 	Auto-Raise Lists - I've no idea what this does
> 
> This option is what causes the account list to pop open when you type
> stuff into the account field in the register (amongst other things). I
> like it turned on. I'm not sure if other people also feel that way or
> not. If you're going to make this advanced, at least make it default to
> "on".

Hmm, I see. I think it should be advanced and turned on by default. I
also think it should be renamed to something more descriptive like
'Bring up account list when typing'.

> 
> > 	Show All Transactions - Why wouldn't we want to show them all?
> 
> Because some people with slower machines (like me) and very large
> account files (like me) have found in the past that turning this off can
> drastically improve the speed of opening registers. I'll admit that I'm
> currently running with show all on, but in time this may become
> necessary again. I agree that it should be an advanced option.

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

> 
> > That's it folks! This removes a lot of what I think is clutter in the
> > prefs and also reduces the number of prefs a user sees (and so reduces
> > the complexity/confusion of it).
> 
> We've sort-of hedged around this before, but I must say I'm opposed to a
> fairly arbitrary removal of options (or refusing to add options) in the
> name of "usability". Its not enhancing usability to remove flexibility -
> quite the opposite. If an option isn't clear, then it needs to be
> explained better. We should not just kill it because it doesn't conform
> to how a few people on the current development team think it ought to be
> done. Please don't take offence at this, I realise you're trying to make
> the best application for everybody, we just disagree on the best way of
> achieving that.
> Also, please don't misunderstand me here - I think we should make the
> *default* behaviour conform to what we think most people would prefer
> (or which is safest), but allowing the user to modify the behaviour to
> suit their individual needs and preferences is surely what preferences
> are all about. If they are confusing, we need to explain them better,
> not remove them (except, of course, where the option doesn't do
> anything).
> 
> 
> Code for implementing tabs only visible when "advanced" is turned on is
> underway.
> 
Thanks

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

Chris

-- 
RedHat Certified Engineer #807302549405490.
--------------------------------------------
	|^|
	| |   |^|
	| |^| | |  Life out here is raw 
	| | |^| |  But we will never stop
	| |_|_| |  We will never quit 
	| / __> |  cause we are Metallica
	|/ /    |
	\       /
	 |     |
--------------------------------------------