release criteria revisions

[James Laska]

On Mon, 2011-05-09 at 10:49 -0700, Adam Williamson wrote:
> 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

Thank you Matthias for kicking this off!

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

Bingo!  I was trying to recall history reading old mailing list posts,
but Adam nails it.  That matches my recollection of where that criteria
comes from.

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

So far, from the bugs I've seen, I think most testers have been able to
correctly evaluate what "sufficiently high resolution" means.  Worst
case, we could always call out specific results for different desktops
in the test case itself
(https://fedoraproject.org/wiki/QA:Testcase_desktop_menus).

Note, that test case has some additional language about the icons ...
"Examine each menu entry in each level of the default system menu
layout, and ensure each application has an icon, at a resolution high
enough not to appear pixelated, and consistent in appearance with other
icons"

The term pixelated seems to have more meaning for me than, appearing
blurry.  Thoughts?

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

Tom's comment in another email makes me wonder if we want to keep this
criteria, but rephrase.  I agree with Matthias' thoughts on having items
show up in multiple categories.  Perhaps it can be reworded such that we
would capture any cases where an application is duplicated (due to a
broken .desktop entry).  For example, if I activate the overview and
type "terminal" ... if two identical entries show up matching
"Terminal" ... someone needs to fix their .desktop, right?

Thanks,
James

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/test/attachments/20110509/cbf00381/attachment-0001.bin