Whatchamacallit

One of the things Jeremy Perry and I have been working on in the GNOME Shell design is a way to make application launching work better.  You can see some of this in the following mockup:

Activities Overview Concept (drawn by Jeremy)

As you can see there.  We need short “brand” names for the Favorite apps.

So, in preparation for GNOME Shell, a few of us have been looking into how we should handle application names in GNOME 2.28 – since GNOME 2.28 is primarily a prepatory release for GNOME 3.0.  We need to make a decision on this soon.

First, some background.

What is a name?

Applications, like many things, have a few different names associated with them.  Such as:

• Unique Identifier — rhythmbox.desktop
• Generic name — Media Library
• Brand Name — Rhythmbox

This is analogous to what we find in the consumer pharmaceutical world:

• Chemical Name — 7-chloro-1,3-dihydro-1- methyl-5-phenyl-2H-1,4-benzodiazepin-2-one
• Generic Name* — diazepam
• Brand Name — Valium

Note: I’m ignoring differences between INN, BAN, USAN for this.  And also ignoring the fact that generic drugs are usually exact copies of the same chemical substance.
Also see:  this and this.
For both drugs and applications, generic names are meant to be a substitute for a brand name.  They are not classifications, categories, or descriptions.  For example, an alternate for Tylenol may be called acetaminophen / paracetamol but it belongs to the categories of analgesic and antipyretic.

In the open source world, our application naming system is described in a nearly universally adopted freedesktop.org specification.  However, the specification does not address how these names can and should be used.  Nor does it address how a name should relate to an application icon.  These are things that we (GNOME) must decide.

How are names used?

Let’s go back to our drug example again to think about how these names are used.  At least in the US, Tylenol is like Firefox (ha, Mozilla.com wishes!) in that it is a very widely recognized brand among consumers.  So, for our purposes let’s suppose a new relatively unknown brand of orally administered analgesic: Livernol.  There are a few different ways this name is used:

1. Local Pharmacy

   Kelly goes to the store with the intention of finding something to ease her headache.  She probably won’t know the name Livernol, she may ask the pharmacists if they can recommend something like Tylenol or that can help with headaches.  They may hand her Livernol and she can confirm from the descriptions on the label that it is will help with headaches and may be compared with Tylenol.

2. Medicine Cabinet

   Kelly has another headache (she is a designer who works with open source software).  She staggers to the bathroom and grabs the bottle of Livernol on the shelf.  No need to read the descriptions since she knows what it is.  However, she may consult the documentation if she has forgotten how to use it.

3. Talking to Experts

   Gosh darn headaches won’t stop.  Kelly goes to the doctor.  She tells the doctor that she gets headaches frequently and the analgesic she takes doesn’t seem to help.  The doctor asks her what analgesic and then looks looks up the chemical name and then details about it.  He informs her that this isn’t the best choice for her since it doesn’t treat her specific problem and it has a number of unwanted side effects.

4. Online Pharmacy

   Now she is looking for something else on an online store since she didn’t find it in the local one (or didn’t trust the recommendations).  The doctor scribbled on a note “napro…” something.  Oh here it is, the store generic Naproxen Sodium.  Label descriptions and reviews confirm it is good for severe headaches.

[Public service announcement: consult your doctor to make sure Tylenol is right for you]

So what does this have to do with software?

In GNOME Shell we want to handle the above scenarios separately.

1. When looking for something new you can either browse or search through a rich set of information
2. When you already know something you want to optimize for easy access
3. When you need help or just want to share information you need to be able to talk about it unambiguously
4. When you don’t find what you need on your computer, it should be simple to find and access more online.

Matthew Paul Thomas has discussed some specifics of naming on the GNOME development mailing list before.  I agree with what he says there.

So what rules govern the use of Name and GenericName?

Proposed guidelines:

• When Name is the same as GenericName, the GenericName should be removed
• The desktop entry Name value, application menu (for GNOME shell), window titlebar (for GNOME 2.x), documentation, and about dialog should all use the same name
• The desktop entry Name value should be the brand name unless the application is a simple (single purpose), core GNOME built-in and does not have an established external brand identity (web site, online help, etc)
• Brand names should be considered carefully but can’t be relied on to indicate functionality in many languages
• Application icons should supplement names of all kinds and are critical to recognizing already known applications

Examples:

• It doesn’t make sense for Dictionary or Calculator (GNOME is implied) to be separately branded.
• It is fairly clear that something like Firefox or Rhythmbox is branded.
• Totem which actually do bit more than the generic name implies (It is a little strange that Movie Player plays songs and youtube – according to the description) but the name isn’t known outside of GNOME for the most part.
• gedit is tough because the name doesn’t “read” well and it is a pretty core component. However, it does have an external presence and the authors feel it should be called gedit.

That’s nice but how do we handle this in the current panel?

Frederic Peters made a nice proposal to XDG list to add another entry to the spec to over the case where the two names are used in menus.  The primary reason for this was to try to avoid problem translating the combined use of Name and GenericName.  I was initially in favor of this approach.  However, the proposal was not well received.  After discussing the proposal with Owen Taylor, Matthias Clasen, and others I don’t think we can rely on this solution for a few reasons.

• We will only need this solution in GNOME for a single release.  It isn’t required for the GNOME Shell.
• It will take a significant amount of time for all desktop files in existence to be updated to use the new key.
• We will need to create a fallback solution for desktop files that don’t have FullName.
• It isn’t clear that translations should fundamentally alter the design of the menu entry layout.
• It isn’t clear how you can do much better with a translated key than we can with a programmatic layout (given the constraints of a menu and that we don’t want to combine the strings).
• We aren’t trying to concatenate the names.  The names are substitutes for one another – so articles and grammatical combinations are not needed.
• There seems to be tepid support for programmatically adding both Name and GenericName to the GNOME menu items using a translated format string i18n(“%1$s – %2$s”) or similar
• Using a separator isn’t ideal but then the menus are just terrible interfaces for launching anyway
• After actually trying out the approach in the menus – it doesn’t look that bad

So, concretely, what do we need for 2.28?

1. We need to patch the panel to support showing both Name and Generic Name to workaround the fact that menus are very poor ways to discover new things.
2. We need to fix a lot of our desktop files to use Name and GenericName correctly:  GNOME Goal,  tracker bug, Fedora wiki page.
3. Consider renaming applications that have really poor names.
4. Ensure that application names perform well in GNOME Shell

I will bring this up on the GNOME desktop development list.  Discussion should happen there.