A proposed global naming schema for menu items

Last week the GNOME project released a second Human Interface Guidelines (HIG 2.0) document. The HIG is an effort to push a more consistent look and feel on the GNOME desktop, and it’s worthwhile reading for other projects as well. The first version of HIG was the target of massive debate. The new, 168-page-thick version still leaves plenty of room for improvement. Here’s one proposal.

GNOME’s desktop menu was, and still is, one of the main targets of criticism, despite a user-friendly descriptive schema used in GNOME since version 2.4. The HIG defines that menu item names should be a combination of both an application name and a description. However, the descriptive part is discussed only in general and left mainly to the creative powers of application developers.

The HIG, on page 7, discusses an example menu in which the GIMP is called an editor and Evolution an email application. Who makes these choices? Is the GIMP an editor or an image editor? Doesn’t Evolution do a lot more than email?

Shouldn’t there be some agreement on more understandable terms, clearly explaining the function or use of the respective application?

Maybe application developers shouldn’t define menu item names at all, but instead rely on a global classification schema that’s part of the HIG.

Such a global naming schema would define four attributes: product name, product type, product class, and an optional prefix, along with a list of default types and classes. The correct type and class would be provided by the desktop meta-file of the application.

Let’s look at an example to see how this would work. Given the BatallaNaval server, the type is Server and the class is Game, having the prefix MultiPlayer. The result is:

BatallaNaval Multiplayer Game Server

How would we classify a word processing application like Abiword? The type is Editor and the class is Document. The result looks like:

Abiword Document Editor

With a publishing tool like Inkscape, the type is Editor and the class is Publishing. The result looks like:

Inkscape Publishing Editor

In cases where no type or class fits — or just to prevent trouble with some sensible developer teams — both the type and the class attribute can be user-defined. For example, suppose the WINE developers would rather ignore the type Emulator for their Windows implementation (taken from their Web site), and the class Windows may not be provided by the desktop for copyright reasons. The WINE developers would provide own terms, like:

WINE Windows Compatibility Layer

The naming schema could even support lists of attributes for products that have more than one main use, like:

CD/DVD Editor/Writer

Another interesting enhancement would be a more descriptive overall menu layout, skipping the mostly uninformative tooltips and instead providing a selection of helpful information right below each menu item, as shown at right.