Re: HIG and Escape

[Lars Clausen <lrclause cs uiuc edu>]

On Tue, 11 Mar 2003, Alan Horkan wrote:
> On Tue, 11 Mar 2003, James K. Lowden wrote:
>
> > Let me update my last attempt, cf.
> > www.SchemaMania.org/dia/noodle/dia_preferences.png. (Lars, the .glade
> > file
>
> 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.

> http://bugzilla.gnome.org/show_bug.cgi?id=61443 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
layout. 

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

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

-- 
Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| 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?