menu application naming

[Patrick Goetz]

 > Date: Tue, 9 Jun 2009 17:45:56 +0200
 > From: Soren Hansen <soren at ubuntu.com>
 > Subject: Re: Properly identifying applications
 > To: ubuntu-devel-discuss at lists.ubuntu.com
 >
 > If you put yourself in the place of someone who is not used to
 > Linux: You have a document you want to open (and for some reason
 > you don't  just click on it in Nautilus, but let's ignore that
 > for a little bit).  How are you supposed to know to look
 > for something called "Evince"? How is
 > having that name in the menu going to be helpful?

Sorry, I guess I didn't make my point clearly; I'm not advocating that 
the menu entry just be "Evince" but rather something like

    "PDF Document Viewer (Evince)"

See the KDE4/Kubuntu menus for an example of how this can elegantly be 
accomplished.

I still object to the specific designation "Document Viewer" as it's 
simply false:

   evince foo.doc
     and
   evince foo.odt

do not work, so this is most definitely NOT a document viewer.  You're 
confusing users by calling it that.  (For the technical users who view 
ps/dvi files, there can be another menu entry called "Postscript/DVI 
Viewer (Evince)".)


 > I couldn't disagree more. The no-brainer choice it exactly to NOT show
 > which application is being invoked. What's important is the task it
 > performs, not what it's called. If the user needs to know the name of
 > the application he's using to do something, we're doing something
 > wrong. To view documents, you use a document viewer.
 > If we change the default document viewer at some point,
 > the user's experience shouldn't change. They shouldn't have
 > to know that we've replaced Evince with FooPDFViewer.
 > They should just keep using "Document Viewer" and have the
 > best possible experience.


While this philosophy makes sense when dealing with relatively naive 
home users, it falls a bit short for power users and institutional 
(large network) installations.  Let's take the case of power users 
first.  All programs have bugs, otherwise your point would be better 
received.  Working in an environment where people are frequently pushing 
certain kinds of applications to the limit, we're aware of dozens of 
specific issues in different programs.  For example, depending on 
precisely what a user is trying to do, I will recommend that they use 
acroread, evince, or xpdf (usually after one or the other has failed at 
fill out forms, or printing, or properly rendering certain kinds of 
documents -- in extreme cases, we have to invoke pdftk).  Changing the 
underlying program without letting anyone know is an excellent way to 
completely annoy power users.

The situation with institutional users is even worse.  With >300 linux 
machines, we use an automated installation system to install packages on 
machines and keep them up to date.  Every time we upgrade to a new 
ubuntu system, we have to first install 1 or 2 machines using the 
Desktop CD in order to try and figure out what Canonical has decided to 
change, particularly in the user interface, about which ordinary users 
are most apt to complain.  Forcing me to put on my Sherlock Holmes hat 
in order to deduce that, say, evince is no longer part of the default 
distro, is not the way to make new friends.

So to repeat:  The ideal is a system which is sufficiently friendly for 
naive users while not unnecessarily impeding the work of power users and 
administrators.  Yes, this is a challenging task, but Microsoft Bob 
should provide some indication of what happens when you only cater to 
the former group.  <:)