Re: ANNOUNCE: Style Guide available for review.

[Tom Tromey <tromey creche cygnus com>]

Paul> Actually, for reasons such as the consistent File|Exit and
Paul> Help|About (and other help), it is probably best if ALL apps
Paul> have the menubar, even "utility" apps.  Of course, the user can
Paul> choose to unpin the menubar, making it accessible as a pop-up
Paul> menu instead.

I think consistency is only a secondary goal when building a user
interface.  That is, consistency is a tool we use to achieve the real
goal, which is "ease of use" (as opposed to "ease of learning" --
which is a distinctly different goal).

So it makes sense to sacrifice consistency when the ease of use test
is met through other means.  For instance, we might sacrifice
consistency if we believe that historical practice requires us not to
make a certain change (that's pretty vague).  (Perhaps the calculator
example fits in here.)

There are probably other reasons to ditch consistency, too.


I think that, in practice, requiring a menubar everywhere is going to
look silly.  In particular it's probably bad to have a menubar where
the menus have very few items.

E.g., in the case of the `mouse-properties' program, we'd be talking
about a menubar with File->Exit, Help->About, and Help->Reference.
That's hardly worth it.

And nobody is going to be deeply confused if Help is on a button and
not on a menu.


I also think that the first menubar item should not be required to be
"File".  Let me note that other existing style guides (the Motif style
guide, and the MS style guide) also don't require this.  From the
Motif guide:

   If the label File is not appropriate to the context of your
   application, you can choose a different, more appropriate, label.

(MS merely says that the items are not required, which amounts to the
same thing.  Anyway, I don't think we should really reference the MS
style guide.  It isn't very good.)


I think in the long term we should consider something a little more
radical, say along the lines of what Cooper proposes in About Face.
This will have to wait for real document-oriented programs, though.
(And I'm a firm believer in writing something we know will work and
then transforming it into something better, as opposed to trying to
write something radical from the start with the risk of total
failure.)


I notice the guide doesn't mention internationalization.

For instance, when the local writing system is right-to-left, we might
want to reverse the menubar.  Perhaps the best way to handle this is
in Gtk.  (E.g., you could have most windows automatically mirror-image
themselves, but provide a special kind of window that doesn't, for
those times that you need direct control.)

Tom