release criteria revisions

[Adam Williamson]

On Mon, 2011-05-09 at 13:20 -0400, Matthias Clasen wrote:
> 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. 

I believe this was kind of the reason: the idea was that categories were
used to keep things properly ordered, and the only way we could
guarantee people *didn't* wind up with giant lists to scroll through was
to categorize everything properly. Something winding up in Other was
proof that it wasn't correctly categorized, hence, problem!

> 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. 

That's reasonable to me: personally I'm happy with dropping the
criterion on that basis, though obviously we should still make a best
effort to categorize stuff right.

> 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:

Indeed. Remember, however, that we try to write the criteria as
generically as possible - one goal I have for the desktop criteria is to
try and make sure they're written in such a way that they apply to all
desktops, as long as this is possible without too much compromise.

> > 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.

The idea with writing it in this way was to be future-proof. The Shell
case is actually a good illustration of this: if we'd written it to be
'concrete' as of 2009, it probably would have specified 64x64 or so -
there was no reasonable case for requiring 256x256 at that time. But
since it's generically written, we can claim that now Shell exists, it
requires 256x256 icons without any rewriting :)

> > 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 ? 

I think this was a GNOME 2 design goal, yeah. Suggested changes would be
welcome indeed.

> 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.

I think this is the cause of the 'Applications menu' restriction in the
criterion (that's still in force from two criteria earlier, remember).
But again, if this doesn't make sense in a GNOME 3 world, we can change
it by all means. (It's also something I thought the other desktops
wouldn't be happy with, but remember I sent out multiple requests for
them to review the criteria and no-one complained, so, hey.)

> 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.

Well, whenever there's a bug which involves an application breaching any
of these criteria, 'drop the application' is always an acceptable
resolution. It's often possible to resolve release blocker issues
without _fixing the bug_, exactly. But this is definitely one that I
thought was quite a high bar, and was only included in the first place
because you folks (desktop team) asked for it :) So if you think it
should be revised, again, that's fine.

> > 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.

This may be something the other desktops would want to keep, so we
should probably check with them about it, and see if there's a way we
can word it that makes everyone happy.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net