Re: HIG and Escape

On Tue, 11 Mar 2003, Alan Horkan wrote:

On Tue, 11 Mar 2003, James K. Lowden wrote:

Let me update my last attempt, cf. (Lars, the .glade

Nice but a bit heavy with the Frames.
I should make reference to the Gnome HIG as
this is a prototype but (Lars) i would
really appreciate time thoroughly nit pick before any substantial
changes get made.

How does it look French, Spanish, German or with larger font sizes?
German particularly takes up more space.

Before we nitpick the particular little design decisions, there are some
more important things we must consider (see below).  Pixel-twiddling is
only a small part of UI design.

I don't agree that the GUI needs "room to grow" unless those needs are

I disagree, quite a lot.  Software that does not plan for change is
software planning to die.  (a genuine computer science quote would come
in handy right about now.)

Indeed.  But there are many ways to allow change.  And crippling the
current program just to allow for some uncertain change is also bad.

While restraint is needed when adding options, i would rather have too
many options than too few.  As an UML tool aimed at Developers Dia can
get away with a little bit more complexity (even if people like me are
using Dia instead of Sketch/Xfig/Sodipodi/gFig/etc).

I'm occasionally using Dia instead of Word:)  

I really shouldn't try to list various the things we might need space for
but I will anyway.  I would at some point like to hook up modules like
Gnome-Spell or something similar.  This bug which seems to roughly
correspond to AutoSave and would presumably need space in Preferences.

That'd be a plugin thing, wouldn't it?

If we start having such plugins, we may need to allow for plugins adding to
preferences.  Now that'll be interesting. Just look at how many
options Visio and Rational Rose have, it seems inevitable to me that Dia
will become more feature rich.

Feature rich != option rich.  

immediate and obvious.  The supporting data structures, yes, but if a
dialog needs rearrangement over time, that's OK.  Some options will

Dont presume that developers will have the time or desire to redesign the
dialog over and over again.  It is great that you are here now and
willing doing this work but in the future someone less
talented/interested or just plain busier will very likely want to add
options without needing to move things around and risk undoing lots of
usability work.

Changing the Dialogs will be confusing for users too,

Yes, whether it's changing around the tabs/tree or frames.  

why go to all the effort of cramming into a single window if it is
inevitable that it wont fit in a single window for long.

We don't know how 'for long' this will be.  If it can fit well in a window,
that's great.

If there are options we think should be added but aren't ready to
implement, we can include them in the dialog as grayed out.

Hmm, teasing the user ... i would feel a bit guilty about this, having
been dissapointed before, tooltips saying "TODO: volunteer to help and
stuff or something" might help.

Teasing the user is bad.  The option should either work or not be there.

The disadvantage to tabbed dialogs (or tree views) is they turn into a
video game: the user winds up clicking on every tab, sometimes more than

tabs and trees are not great but i think we should accept that at some
point they will be necessary and plan for that now.

The current system is great for the programmer.  Want a new option?  Just
add a few lines in preferences.c and it's there.  It's nasty for the user,
though, simply because the interface is horrendous.  It's up to us coders
to make it easier for the users, we shouldn't have our own ease as the
primary concern.

One thing I wonder about is why we don't use the properties API to generate
the preferences dialog.  The properties are much more flexible than the
current prefs system, allowing frames and stuff.  Question is whether the
interface itself really allows it.  It'd be one way to allow better

Hmmm... even looking at the current preferences, much seems to be
misplaced.  Why for instance is all the New Window stuff not under View

Anyway, comparing the current prefs and James' mockup, I find about half
the options missing from the mockup.  Adding those would surely strain the
untabbed setup.  The 'New Diagram' part of the mockup contains 2 1/2 tabs
worth of the current prefs.  There's five general options that are not
included (though some of those may go away).  The actual new diagram
options (paper size, portrait/landscape) are not included.  The whole
diagram tree part is not there (though the options seem somewhat unuseful
if we but had the window be persistent, like Gimp).

Any-anyway, I'm fiddling around with Glade to see what is needed.  Can't
get it to make a functioning treeview, though:(


Lars Clausen (| HÃrdgrim of Numenor
"I do not agree with a word that you say, but I   |----------------------------
will defend to the death your right to say it."   | Where are we going, and
    --Evelyn Beatrice Hall paraphrasing Voltaire  | what's with the handbasket?

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]