Subject: Re: Options dialog stable?
From: Logan Hall (warrior514@worldnet.att.net)
Date: Tue Feb 22 2000 - 22:50:24 CST
Paul Rohr wrote:
> 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?
Yep it does. I did a little write up about this previously see:
http://www.abisource.com/mailinglists/abiword-dev/99/December/0322.html
In the mean time i am going to see if i can find the time to invest a serious
effort in getting the Unix dialog cleaned up some. Here are some of the things i
am thinking about doing:
a) Moving the save button to the Prefrence schemes tab, or
b) Getting rid of the tab all together, as I think it should be hidden in
some way.
Also i have been thinking of some way to rearange the View options tab, because
we need to bring the "Units:" text and its drop down menu closer together. Im
not sure what i am going to do at this point.
Any thoughts on any of this?
>
>
> Paul
This archive was generated by hypermail 2b25 : Tue Feb 22 2000 - 22:50:15 CST