Re: [Usability] desktop entry names, generic?

[Bryan Clark <bclark redhat com>]

Right, so this response has been long overdue, my bad dude.

On Mon, 2004-06-21 at 03:38 -0500, Shaun McCance wrote:
> On Wed, 2004-06-16 at 18:14 -0400, Bryan Clark wrote:
> > Hi ~
> > 
> > doing both lists just to get the idea stated, but lets please keep any
> > discussion on the usability list only please.
> > 
> > We're updated the HIG recommendation for menu item names.  Currently we
> > are requiring a GenericName and Name for .desktop entries, where a
> > generic name is purely the applications functionality ("Web Browser")
> > with out it's application name and the name is the proper name which has
> > the applications name and its functionality together (App Name +
> > GenericName, "Epiphany Web Browser")
> 
> I've found the naming situation to be rather annoying so far with
> respect to documentation.  Currently, I select Games->Lines, but the
> documentation is called "Glines Manual V2.6" and discussions some
> "Glines" program.  I'm certain I don't have that in my menus.

I would call this a bug against the GLines program.  If GLines menu
entry is called Lines then the application should follow that naming
scheme throughout.  A similar situation to this is a glib function
proposed to retrieve application name from the .desktop for use in the
Title and other places.

> On a complete reversal, Rhythmbox's documentation refers to "Music
> Player" all the way through.  While that's consistent with its menu
> entry (for now), I can't help but wonder if this just causes more harm
> than good.  People who know it's called Rhythmbox are going to have a
> tough time picking out the correct document in a line-up.

I'm not really sure what people you're talking about here.  People who
know it's called Rhythmbox and are searching through the documentation
on how to use it?  I see your point, it seems far off, but I'm sure it
exists; I feel that you're bringing up an edge case here.

> And now what happens when we have three players that all want to be
> "Music Player"?  Sure, we can do magical menu shifting in the menu.
> (Aside: Shifting interfaces are hard to document well.)  But if the
> applications menu shifts, the documentation menu should shift as well.
> That's probably manageable, but there's little hope of shifting all
> occurances of the application name in the document itself.  And that
> just creates inconsistency and confusion.

Our goal is to control how the GNOME Desktop applications interact with
the users.  We can do our best to help other applications providing
recommendations and guidelines, however we can't be expected to control
what everyone else is going to do.  Applications outside of the core
desktop should brand themselves as they are, however the core desktop
applications should be branded as GNOME and that brand is simply not
having one.  If Rhythmbox were the GNOME music player and then were
replaced later by another application, we would continue to call
whichever application Music Player (i would assume Rhythmbox would
change to being Rhythmbox music player, but that's up to them).  The
actual application underneath isn't part of the GNOME interaction we're
trying to provide.  Developers should be proud of the fact that their
application is in the GNOME desktop, however I don't think that having a
menu entry that doesn't include their application name needs to take
away that pride.

> My vote is in favor of "Rhythmbox Music Player" and "Epiphany Web
> Browser".  In an ideal world, maybe we could completely hide the
> existence of applications.  But in this world, I think this naming
> convention is the least confusing overall.

I don't think this kind of branding is helping people, while we are
proud of the applications that make up the GNOME Desktop, each
application that's included in the desktop becomes part of GNOME as it
is integrated.  I view us kind of like the Borg, resistance is futile
and you will be assimilated.

~ Bryan

-- 
Bryan Clark <bclark redhat com>
Red Hat Desktop Design Ninja