Subject: Re: Options dialog stable?
From: Paul Rohr (paul@abisource.com)
Date: Tue Feb 22 2000 - 19:22:30 CST
At 01:54 PM 2/18/00 -0700, Logan Hall wrote:
>Robert Sievers wrote:
>> At 11:18 AM 2/18/00 -0500, Thomas Fletcher wrote:
>> >Hey all,
>> >
>> > I was just wondering just how stable the options
>> >dialog is right now. Are there going to be significant
>> >changes that are going to happen any time soon? I'm
>> >about to do the dialogs for Photon and if things are
>> >going to change then I'll hold off on doing that.
>>
>> The options dialog has to be the least stable of the bunch. Worse yet, it
>> is different on Linux than it is on Windows. There hasn't been any real
>> design strategy for it, and there will need to be as AbiWord approaches
1.0.
>
>I will start digging around in the option's dialog code again, now that i
have
>debian up and running. I am alittle shaky on it because i bairly know
C++ and
>i don't realy know gtk, but i figgure i will learn from digging:-).
Cool. Digging into a concrete problem like that is always a *great* way to
learn. :-)
>Also are
>there pics of the window's options dialog in the tree? any idea on which one
>is more inteligent so i can see if i can make them closer to each other?
Don't
>know how much i will get done but we will see.
Actually, I think you're asking the wrong question. The problem here isn't
that one of the dialogs is right and the other wrong. They both need help.
1. Options dialogs suck, by definition.
----------------------------------------
The *worst* dialog in any UI is always the Options dialog (or Preferences,
or whatever you call it). The natural temptation for any developer who's
not quite sure how a feature should work is to punt -- code it both ways and
let the user decide. The more features (and developers) you have the worse
it gets.
This may be perverse, but think of every entry in the Options dialog as
dirty laundry related to an unfinished feature which needs a workaround. If
you don't believe me, take a look at some other piece of software and ask
yourself why each option is there.
This is a case where more is definitely not better.
2. Options dialogs get cluttered.
----------------------------------
See #1. Think about it. Each option you add needs a clear explanation, and
you need to be able to find it easily when you want to change it.
As you add more options, you have to find some way to keep it all organized.
Tabs and overview panes are the usual solutions here, but they're very easy
to abuse:
http://www.iarchitect.com/tabs.htm
3. The scope of changes isn't easy to decide.
----------------------------------------------
There all sorts of questions which have less than obvious answers when you
really start paying attention. For example:
- Should options apply to all existing windows? To all new ones? Just the
current one? How does the user tell?
- Does it really help to have multiple simultaneous preference schemes?
Who'd use this feature? When? How? Should it be featured prominently
in the UI (Mom's settings vs. Dad's) or buried?
Trust me. It can take weeks to sort this stuff out, only to find out that
you're still confusing more users than you're helping.
4. Not all options belong in the UI.
-------------------------------------
Options give flexibility, which is a Good Thing.
Putting things in the UI makes them easy to tweak, which is also a Good
Thing.
However, combining the two is not additive. For example, imagine a
power-user feature which mapped to "rm -r *". It might be worth having some
way to do this, but putting it on a clickable button in your UI is just
asking for trouble.
For a more concrete example, see the following bug:
http://www.abisource.com/bugzilla/show_bug.cgi?id=613
Anyone who thinks this isn't a bug shouldn't be designing the Options UI. :-)
bottom line
-----------
There's been a lot of good implementation work done on the Options dialog to
date, particularly on the GTK side.
However, there's a more serious UI design effort needed, which has nothing
to do with code. Instead, it'd be worth having someone troll through
existing Options dialogs for other word processors, asking the following
questions:
- Which options does *everyone* support? Why?
- How do they organize their options?
- Does anyone have a particularly good set we could use as a model?
Once we've got some consensus on which Options are desirable, then we can
check to see whether it makes sense to try to implement them all for the 1.0
release. Given the remaining subset, then we can start mocking up dialogs
in your favorite platform-specific tool, so we can discuss screenshots and
how they'd work.
Does that make sense?
Paul
This archive was generated by hypermail 2b25 : Tue Feb 22 2000 - 19:17:01 CST