Last week the GNOME project released the second edition of their Human Interface Guidelines (HIG 2.0). 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.However, not everything’s thought out well in this 168 pages thick document. For example, the HIG defines that menu item names should be a combination of both an application name and a description. The descriptive part is discussed only in general and left mainly to the creative powers of application developers, though.
On page 7 the HIG discusses an example menu including Abiword, The GIMP, Evolution and other popular applications. The used naming schema looks very inconsistent. The item name for Galeon is appropriately including the description Web Browser. Evolution instead is just called an Email (no typo). I think this is a synonym for everything about email. However, Evolution is quite more than about email and the item name Evolution Personal Information Manager would be more in line with that for Galeon.
The other item names, like GIMP Image Editor or Abiword Word Processor, are acceptable. At least they follow the same schema like the item name for Galeon. They just made me think about how I usually call them. To me Abiword is a Typewriter (some call it a Publisher either), and The GIMP is a Manipulation Program. Don’t get me wrong, this article is not about taste. However, because developers have different views of their applications the desktop menu will definetly become more inconsistent rather than consistent over time.
Shouldn’t there be some agreement on terms, possibly at FreeDesktop.org, 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:
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 in the design study.
There is more similar reading on the subject, by a Gnome developer.
About the Author:
The author, Dennis Heuer, is a 34-years old german social scientist concentrating on human-computer-interaction (HCI) and e-learning.
If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.