Re: HIG and Escape

[Alan Horkan <horkana maths tcd ie>]

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.

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

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

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

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

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

> too, making it hard to digest.   Good layout and the rule of seven will

[TANGENT
"Rule of Seven" ... "Seven Rings for Elven Kings" ... (probably
nothing to
the do with the card game of Bridge either, or puppies)

i heard this recently and did not know what it meant so this time i looked
it up.  In marketing it means you will usually need at  5-7 attempts
to get the desired effect.

Hmm should have searched with "Rule of Seven" + "Usability", which turns
up the old nugget that people tend to be able to remember 5 things plus or
minus two, thus groups of more than seven are a really bad idea.

END TANGENT]

> > I think the whole design needs serious looking at.
>
> Quite.  :-)
>
> > I've wondered just how much memory undo steps take.  It could be
> > interesting to turn the limit off and see what happens.  Emacs, for
> > instance, has infinite undo, and I have it running for months sometimes
> > without the undo stack overrunning the system.

There is something about how and when selections are lost on undo that
bothers me.  A very short undo history is quite annoying when you are
doing lost of small movements, colour/selection changes, i cant think what
operations in Dia would be particularly hard to undo (unlike some of the
advanced filters and special effects in the Gimp).

Sincerely

Alan Horkan
http://advogato.org/person/AlanHorkan/