release criteria revisions

[Matthias Clasen]

James has asked me to write something about the desktop-related release
criteria in the light of bug
https://bugzilla.redhat.com/show_bug.cgi?id=697834

Starting with the bug itself, I'll state that I don't think it is a
blocker that we should fix for F15. It has made it to the blocker list
because it seems to violate the release criterion that there shall be no
'Other' menu in the panel menus. 

Why did we put this in the release criteria ? Selecting from a long menu
is difficult, you can't actually see the content hidden behind the
menuitem until you perform a reasonably hard fine-motor-control task,
and it is hard to back out of submenu should it not contain what you are
looking for. 

In fact, these difficulties with hierarchical menus were one of the main
underlying motivations for the design of the shell overview. Not
surprisingly, the shell overview does not have these problems, mostly.
The primary mode of interaction with the overview is search; you just
start typing. 

The presence of the unsorted 'Other' grab-bag category is still an
annoyance, but since categories are much less prominent, it is just a
minor annoyance. 

Looking at the rest of the 'Menu sanity' bullet points in
https://fedoraproject.org/wiki/Fedora_15_Final_Release_Criteria some of
these codify the GNOME2 user experience and are not really adequate for
GNOME3:

> All Applications listed in the desktop menus must have icons which
> have a consistent appearance and sufficiently high resolution to avoid
> appearing blurry

No problem with this one, although it should really be a bit more
concrete: the shell overview works best if the application icon is
available as a 256x256 png.

> All applications listed under the Applications menu or category must start
> successfully

No doubt still relevant.

> All applications listed under the Applications menu or category must withstand 
> a basic functionality test and not crash after a few minutes of normal use.

Of course.

> They must also have working Help and Help -> About menu items

This one needs revision or clarification, I think. First of all, talking
about menu items only makes sense if one assumes a classical
menubar-toolbar-content-statusbar application layout. The developing
GNOME3 HIG will de-emphasize this pattern in favor of menubar-less
designs. And even if an application does have a menubar, maybe it does
not need help because it is very obvious ? 

Wrt. to 'About', one thing we are aiming for in GNOME3 is to have
'unbranded utilities' which are part of the core desktop. 'About'
dialogs mostly make sense for applications which have a 'personality'
and are not just part of the desktop. In short: applications can have an
about dialog, but the shell overview also shows things which are not
applications in that sense.

Last question on this criterion is: What is the consequence ? If an
application does not have an about dialog, do we really expect to hold
the release until the packager has patched one in, collected the
necessary translations, written a manual, hooked it up, etc ? This
really feels more like a criterion to consult when choosing the
applications to include on the spin.

> There must be no Other menu or category

I've already talked about this. I really don't see us block a release
for this, but having meaningful classifications for all applications is
certainly a useful thing to keep in mind somehow. In fact, I think that
would be a more useful criterion.
 
> No application may unintentionally appear twice in the menus. In particular, 
> items under System must not appear under Applications

This basically does not apply to the shell overview. It does not have
the Applications vs System dichotomy, and I think allowing overlapping
classifications would actually be a very useful thing in the overview;
if not for the fact that the desktop entry spec codifies mutual
exclusion for primary categories, IIRC.


Matthias