Re: consistency (or lack thereof)

[Calum Benson <Calum Benson Sun COM>]

On 22 Jul 2006, at 07:13, Ryan Paul wrote:

> There seems to be some confusion about what the first top-level menu
> should be called in cases where the contents of that menu do not  
> relate
> to operations that are performed on files. In some cases, particularly
> in the terminal, using the name "File" seems a little absurd.

As it turns out, "Terminal" is just a bit of a problematic case, if  
you follow the HIG guideline about not using File as the primary menu  
name.

The trouble is that "terminal" refers both to the type of application  
(like "Calculator" or "Game" etc.), and to the type of objects you  
use it to create (which would be "documents" in gedit).  So whereas  
in gedit you have a File menu and a Documents menu, in gnome- 
terminal, if you were to follow the HIG guidelines to the letter,  
you'd have a Terminal menu and, er... another Terminal menu.  Not to  
mention the fact that there's _already_ a Terminal menu anyway, which  
is for something else entirely :)

"Just have one combined Terminal menu" then, you might say... which  
makes some sense up to a point, assuming it wouldn't be too long.   
But it disrupts the positional consistency of some items-- for  
example, in a tabbed application, users generally expect a menu  
immediately to the left of "Help" for switching between open tabs  
etc. (which is in fact currently called the "Tabs" menu, in gnome- 
terminal).

There have been a few discussions about the terminal menus over the  
years:
http://bugzilla.gnome.org/show_bug.cgi?id=76800
http://bugzilla.gnome.org/show_bug.cgi?id=88318
http://bugzilla.gnome.org/show_bug.cgi?id=95350

I'd agree that there's probably considerable room for improvement  
though.  My first go at re-arranging would probably be something like:

- s/File/Terminal
- s/Tabs/Window (HIG actually says "Windows", but I think it really  
only makes sense for it to apply to tabs in the current window)
- Move everything from the current Terminal menu onto the View menu,  
as they're all things that affect the appearance of the current tab,  
rather than its content (except perhaps "Change Profile")

and see how things looked after that.

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

That one we could probably have a HIG guideline for; in general, the  
menu name shouldn't be repeated in the menu items, except where it's  
necessary to disambiguate anything.  (That kind of works in English,  
anyway; I don't know if it would be more troublesome in other  
languages.)

> I also occasionally notice places where there is no access key for  
> menu
> items (a violation of the HIG). A few perpetrators that come  
> immediately
> to mind: "Tools -> Scale Images" in GThumb, "Server -> Join  
> Channel" in
> XChat, "File -> Close All Files" in Anjuta.

Please just file bugs for those, where possible, with the 'keynav'  
keyword set (if they're in bugzilla.gnome.org).

> There are also some naming inconsistencies within individual programs.
> "Image -> Scale" and "Tools -> Resize Images" in GThumb, for instance,
> is a good example.

This sort of thing is probably best covered by the Documentation  
Style Guide's terminology list... I know there are plans to revamp  
that.  I don't know if those guys prefer bugs to be filed in  
bugzilla, or have a wiki page or something... but it would certainly  
be good to record this and any other terminology inconsistencies you  
find.

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

It's certainly worth trying IMHO; it can only benefit everyone in the  
long run.  However, there are likely some maintainers of non-core  
apps out there who will just close your bugs because they're not  
interested in HIG compliance for one reason or another, which is  
unfortunate.  (But they're perfectly entitled to do so, of course.)

Cheeri,
Calum.

--
CALUM BENSON, Usability Engineer       Sun Microsystems Ireland
mailto:calum benson sun com            Java Desktop System Team
http://blogs.sun.com/calum             +353 1 819 9771

Any opinions are personal and not necessarily those of Sun Microsystems