Re: Question about menus in GNOME 2.x releases

[Seth Nickell <snickell stanford edu>]

On Wed, 2002-05-15 at 11:13, Chema Celorio wrote:
> On Wed, 2002-05-15 at 12:51, Aaron Weber wrote:
> ..
> > duplicate entries that confuse the heck out of me.   I know Anna sent a
> > list around of proposals, but that mostly degenerated into a thread
> > about whether preferences were good or bad (the "Violent realization"
> > thread).
> 
> This reminds me of a problem that i think is important to address, and
> that we can fix easily. The problem is that we can't have a committee
> decide on the menu structure, we need a community trusted individual to
> maintain the menus and take decisions over it, just like we do for every
> other important GNOME decision.
> 
> If we have a group of people deciding the menu structure we can all bet
> that the discussions are going to end up in 30+ mail threads because of
> the artistic nature of this. The main problem i see is that we need
> people to work on GNOME, not invest huge amounts of time, typing and
> sanity points in discussing this stuff. I am not lobbying for not having
> public discussions about this, we need them, but having someone who can
> decide Yes/No about any decision (or should it be No/Yes? I always
> forget) would be great.
> 
> So I'd like to propose that we come up with a maintainer that has the
> power to take the decision about the menu structure. I am sure that
> anybody who takes over this task is going to come up with anything
> better than what we currently have. I don't have any preference on or
> ideas about candidates.

Nils & I are effectively the maintainers of the GNOME menus. I'll
explain our design decisions below, but first a brief technical brief on
the GNOME2 menus:

George designed the GNOME2 menu system with central maintenance in mind.
GNOME2 .desktop files should be setting a "Categories=" list which
defines various attributes of the .desktop file. The menus are presented
through a VFS module, applications:/// (and preferences:///, though
we're not using that in the menus yet). The association between
categories & the actual menu structure is defined by an XML file,
applications.vfolder. The advantages of this are twofold:

  1) Menus can be centrally maintained (before the menu structure was
defined by ad-hoc custom: to change a category you'd have to change
dozens of desktop file install locations, and of course 3rd party apps
would be screwed up)
  2) Distros can easily make customizations if they need them (I'm
trying to work with distros to minimize the need for changes, but
inevitably distros will want to change some things)

The downside was backward compatibility. George set up the vfolder
system so it can look at the old GNOME .desktop files and create virtual
Categories (in memory) based on their install location. *BUT*, because
the old system only had a small number of categories, which corresponded
exactly to their menus, it meant if we wanted decent backward compat we
couldn't diverge too much from this basic structure.

So an early design decision was to keep a close enough structure to
maintain backward compat. As more .desktop files add a Categories= field
(BTW, GNOME1 apps can add this too, andjust install into their normal
location, I need to send out a public announcement encouraging
maintainers of GNOME1 apps to do releases with this, it'll clean up a
lot of mess) we'll eventually have more freedom to use an "ideal"
structure [1].

Nils did a series of menu structures with a study of the GNOME 1.4
menus, and the Ximian 1.4 menus (and I think KDE too). He refined them
based on input from the usability list. This was like 8 mo. ago.
Essentially these constituted only a rennaming, e.g. "Internet" vs.
"Network", but it went a long way. He was also focusing on the *naming*
of specific items. Most of these changes, with refinements as we
actually used the menus, have happened for Applications actually in the
GNOME release. I still need to work with most 3rd party Applications
(but most of them have not ported to GNOME2 yet).

One critical change was the absence of a "dumping ground" category,
"Applications". Because we had to support backward compat, we added an
"Other" category that appears only when you have uncategorized menu
items. On a pure GNOME2 system this category will not exist.

Unfortunately I used a pure GNOME2 system, which was silly because I
knew such a thing would not exist in the wild at release time. I
actually had no mixed system, which is why the "merging" problems [2]
only became apparent to me near release time when I tried actually mixed
systems. This was a *major* oversight on my part, and one I've been
working to rectify.

I conducted a number of card sorts on the items that would be in the
GNOME menus. Card sorts are a mechanism that is useful in trying to
determine how users expect items to be categorized. It essentially
consists of giving subjects a deck of cards with an item (in this case
an application) per card. I also included a short description of what
each item did. You then ask the subjects to sort the cards into piles of
cards that they think go together. Its also useful to ask subjects for a
couple word description of each pile (and of course a longer explanation
of the rationale behind the piles). 

The results corresponded suprisingly well with our existing structure.
One important distinction that appeared was between "stuff you use to
fix / change the computer" and "things that relate to the outside
world". These became "System Tools" and "Accessories" respectively. They
don't correspond exactly to Utilities vs. System (Utilities contains
some stuff better put in System Tools), but it was close enough to
maintain semi-reasonable backward compat.

Based on the card sorts, I added a new category, currently called
"Office". Thus far I think only Gnumeric actually sets Categories flags
that put it there, but a number of apps that in GNOME1 installed into
Applications should go there. I may add specific rules for important
apps like AbiWord to the menu vfolder until they get categories. I also
rennamed "Development" to "Programming", because almost to a person
subjects used "programming" to describe the category(s) that roughly
corresponded to this idea. "Development" is a fancier word, but it
didn't seem to be what people were actually using (or expecting).

I'll address the problem of duplicate menu entries later in a response
to Aaron's message...

-Seth

[1] Actually, based on the card sort what we have now, even with
backward compat constraints, is pretty close to how people naturally
categorized things.
[2] Pretty much all the "duplicate entry" and "item is in a stupid
place" problems are based on merging GNOME 1.4 menu items in