Menu consistency [was Re: consistency (or lack thereof)]

[Alan Horkan <horkana maths tcd ie>]

(This should maybe be moved to the usability list but rather than CC'ing
and making the discussion too hard to follow I'll respond here.)

On Fri, 21 Jul 2006, Ryan Paul wrote:

> Date: Fri, 21 Jul 2006 23:13:08 -0700
> From: Ryan Paul <segphault sbcglobal net>
> To: desktop-devel-list gnome org
> Cc: Matthias Clasen <mclasen redhat com>
> Subject: Re: consistency (or lack thereof)
>
> As long as we are talking about interface consistency, I'd like to bring
> up another issue I have noticed while working on documentation. There
> seem to be a lot of inconsistencies in menu nomenclature. I'll start by
> looking at the first top-level menu in various applications:

> * In the dictionary, terminal, and character map utilities it is "File"
> * In the Calculator utility it is "Calculator"
> * In XChat it's "XChat"
> * Beagle-Search uses "Search"

I must be looking at the wrong thing because I dont see any menus
http://beagle-project.org/Image:Best-shot-thumb.png
(Further googling suggests that page may be out of date.)

> * GNOME games all seem to use "Game"
> * Totem uses "Movie"        [1]
> * Rhythmbox uses "Music"    [1]
> * Glade uses "Project"

Also File roller uses the a menu labelled "Archive", unlike Stuffit,
Winzip, Winrar and others popular archiving applications. To better
organise things into two shorter menus I suggested using a standard File
menu for the basic file operations and an archive menu for Archive
specific operations (Add, Remove, etc).
http://bugzilla.gnome.org/show_bug.cgi?id=164505

There are also a few multimedia applications which use the menu "Disc"
consistently.   If I recall correctly Gnomemeeting/Ekiga uses Call and
various Chat applications use either Chat or connect.

Generally speaking I think there is room for an additional top level menu
and it is better to group things out rather than having an overly long
first menu.  Microsoft office had a fairly consistent menu layout:  File,
Edit, View, Insert, Format, Tools, %VARIABLE%, Window, Help.  The menu
that varied was the most application/document specific: Table in Word,
Data for Excel, and "Slide show" in Powerpoint (ugly use of two words for
a top level menu).  Similarly most applications could have a standard File
menu and another menu for more application specific items, like how EoG
has both a File menu and an Image menu.

Part of the problem is there is a truck sized hole in the HIG which
developers have happily been driving through.  Developers do great work
and like to think they are exceptional, which for them trumps consistency.
The HIG doesn't strongly advise against not using a File menu, so it isn't
like other cases where we might argue they should push for changes in the
HIG first before making their application inconsistent.

http://developer.gnome.org/projects/gup/hig/1.0/menus.html#standard-menus
"If your application does not operate on documents, name this item for the
type of object it displays. For example, many games should have a Game
instead of a File menu."

A file menu makes little sense in a calculator.  It doesn't make much
sense in a Game either but if a game did save games which could be saved
out and loaded in then in that case I would say it should have a File
menu.

http://bugzilla.gnome.org/show_bug.cgi?id=172297

The general idea is that in a task based program there are none of the
basic file operations like Open, Close or even Save sometimes, in which
case there is less of a strong reason for a File menu.  However in
document based applications there are these file operations but rather
than simply having a File menu and there was some suggestion that it might
be better to replace the file menu with a document specific menu.

Another part of the problem is the lack of stock top level menus which I
believe would make things easier and encourage developers to follow the
path of least resistance.

> I have also noticed some inconsistencies in GNOME game applications (for
> which I'm currently engaged in doc revisions). Users start a new game
> with either "Game -> New" or "Game -> New Game" depending on the
> application.

Gnome games has its own stock items and I'd expect them all to be using
"Game, New Game" although I did suggest they avoid the redundant
repitition.  Other games are probably using the stock new item.

> GThumb [...] (rather than just using one and having it behave
> differently depending on whether or not multiple items are selected)

There are several cases where gthumb has two menu items for the one
file and multiple file versions of very similar tasks.  I think this may
have been improved in relation to some of the keybinding requests I made
but I'm not sure.

> issues at all (I worry that this is just my OCD making an ass out of
> me ;-). I apologize in advance if it is inappropriate for me to bring
> this up here. Should I be filing bug reports, or attempting to submit
> patches to resolve these issues myself?

Submitting patches will get things part of the way but in cases where
developers disagree with the suggestion you would need to build up some
kind of consensus on this list and maybe the usability list which might be
enough to convince them.

> I also apologize in advance for including in my list of issues
> applications that are not "officially" part of GNOME.

These kinds of inconsistencies often occur before an application is
officlally part of Gnome which can make things a little more difficult to
change so I dont think there is any harm in mentioning the wider
community.

> included by my distribution. Is that relevant for usability issues? At
> what point is an application expected to adhere to the HIG, and should I
> try to address HIG violations in applications that aren't officially
> part of GNOME but use the GNOME libraries?

I prefer not to think of it as "violation" but try to suggest to
developers there wouldn't be any harm in being more consistent with
Gnome.

> Thanks for your patience with my n00b questions!

We were all neophytes once.  My apologies for not being more succint but I
was trying to be thorough.

-- 
Alan H.

[1] I filed requests for both Totem and Rhythmbox to use to use a standard
file menu.