(This should maybe be moved to the usability list but rather than CC'ing and making the discussion too hard to follow I'll respond here.)
On Fri, 21 Jul 2006, Ryan Paul wrote: > Date: Fri, 21 Jul 2006 23:13:08 -0700 > From: Ryan Paul <[EMAIL PROTECTED]> > To: [email protected] > Cc: Matthias Clasen <[EMAIL PROTECTED]> > Subject: Re: consistency (or lack thereof) > > As long as we are talking about interface consistency, I'd like to bring > up another issue I have noticed while working on documentation. There > seem to be a lot of inconsistencies in menu nomenclature. I'll start by > looking at the first top-level menu in various applications: > * In the dictionary, terminal, and character map utilities it is "File" > * In the Calculator utility it is "Calculator" > * In XChat it's "XChat" > * Beagle-Search uses "Search" I must be looking at the wrong thing because I dont see any menus http://beagle-project.org/Image:Best-shot-thumb.png (Further googling suggests that page may be out of date.) > * GNOME games all seem to use "Game" > * Totem uses "Movie" [1] > * Rhythmbox uses "Music" [1] > * Glade uses "Project" Also File roller uses the a menu labelled "Archive", unlike Stuffit, Winzip, Winrar and others popular archiving applications. To better organise things into two shorter menus I suggested using a standard File menu for the basic file operations and an archive menu for Archive specific operations (Add, Remove, etc). http://bugzilla.gnome.org/show_bug.cgi?id=164505 There are also a few multimedia applications which use the menu "Disc" consistently. If I recall correctly Gnomemeeting/Ekiga uses Call and various Chat applications use either Chat or connect. Generally speaking I think there is room for an additional top level menu and it is better to group things out rather than having an overly long first menu. Microsoft office had a fairly consistent menu layout: File, Edit, View, Insert, Format, Tools, %VARIABLE%, Window, Help. The menu that varied was the most application/document specific: Table in Word, Data for Excel, and "Slide show" in Powerpoint (ugly use of two words for a top level menu). Similarly most applications could have a standard File menu and another menu for more application specific items, like how EoG has both a File menu and an Image menu. Part of the problem is there is a truck sized hole in the HIG which developers have happily been driving through. Developers do great work and like to think they are exceptional, which for them trumps consistency. The HIG doesn't strongly advise against not using a File menu, so it isn't like other cases where we might argue they should push for changes in the HIG first before making their application inconsistent. http://developer.gnome.org/projects/gup/hig/1.0/menus.html#standard-menus "If your application does not operate on documents, name this item for the type of object it displays. For example, many games should have a Game instead of a File menu." A file menu makes little sense in a calculator. It doesn't make much sense in a Game either but if a game did save games which could be saved out and loaded in then in that case I would say it should have a File menu. http://bugzilla.gnome.org/show_bug.cgi?id=172297 The general idea is that in a task based program there are none of the basic file operations like Open, Close or even Save sometimes, in which case there is less of a strong reason for a File menu. However in document based applications there are these file operations but rather than simply having a File menu and there was some suggestion that it might be better to replace the file menu with a document specific menu. Another part of the problem is the lack of stock top level menus which I believe would make things easier and encourage developers to follow the path of least resistance. > I have also noticed some inconsistencies in GNOME game applications (for > which I'm currently engaged in doc revisions). Users start a new game > with either "Game -> New" or "Game -> New Game" depending on the > application. Gnome games has its own stock items and I'd expect them all to be using "Game, New Game" although I did suggest they avoid the redundant repitition. Other games are probably using the stock new item. > GThumb [...] (rather than just using one and having it behave > differently depending on whether or not multiple items are selected) There are several cases where gthumb has two menu items for the one file and multiple file versions of very similar tasks. I think this may have been improved in relation to some of the keybinding requests I made but I'm not sure. > issues at all (I worry that this is just my OCD making an ass out of > me ;-). I apologize in advance if it is inappropriate for me to bring > this up here. Should I be filing bug reports, or attempting to submit > patches to resolve these issues myself? Submitting patches will get things part of the way but in cases where developers disagree with the suggestion you would need to build up some kind of consensus on this list and maybe the usability list which might be enough to convince them. > I also apologize in advance for including in my list of issues > applications that are not "officially" part of GNOME. These kinds of inconsistencies often occur before an application is officlally part of Gnome which can make things a little more difficult to change so I dont think there is any harm in mentioning the wider community. > included by my distribution. Is that relevant for usability issues? At > what point is an application expected to adhere to the HIG, and should I > try to address HIG violations in applications that aren't officially > part of GNOME but use the GNOME libraries? I prefer not to think of it as "violation" but try to suggest to developers there wouldn't be any harm in being more consistent with Gnome. > Thanks for your patience with my n00b questions! We were all neophytes once. My apologies for not being more succint but I was trying to be thorough. -- Alan H. [1] I filed requests for both Totem and Rhythmbox to use to use a standard file menu. _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
