[HIG] REVIEW: My first-pass review of HIG

[Adam Elman <aelman users sourceforge net>]

Here's my first-pass review.  I'll try to take a second pass in the 
next few days, but for now here are my reactions.

One additional note: I will probably take a copy-editing pass at some 
point after the next set of revisions go in; I'll be editing for 
American vs. British usage (as I've posted before, we prefer American 
usage for GNOME) and other items.

Later,
Adam

General comments:

	We need to adopt consistent language for stating
	recommendations/suggestions.  We should replace passive language
	like "Recommendation: All toolbar buttons are the standard size"
	with more active language like "All toolbar buttons should be
	made in the standard size."  Similarly, language like "Most menu
	items will be labeled" should be replaced with "Most menu items
	should be labeled."

Section 2.1.2 Popup menus

	I agree with Calum, I don't like the name either, especially as
	the Macintosh seems to refer to what we call "option menus" as
	popup menus.  Unfortunately, the GDP is pretty clear here in
	calling these "popup menus," so that's probably what we should
	stick with.

Section 2.1.3 Menu Organization

	I agree with the text here that menu items should never appear or
	disappear while an application is running; however, it is
	generally acceptable for _entire_menus_ to appear or disappear
	while the app is running depending on circumstances such as the
	type of document being worked on, or the nature of the selection
	(text vs. a table vs. a graphic).  Menus in a menu bar are
	visible to the user at all times; thus, their appearance and
	disappearance is also visible and can be logically connected to
	events by the user.  Since menu items are only visible when the
	menu is open, however, their appearance and disappearance based
	on selection or document change is invisible to the user, and
	therefore very difficult to explain.

	This section should also note explicitly that rather than having
	menu items disappear or appear, they should instead be disabled
	and enabled.

Section 2.1.6 Toggled menu items

	This can be a significant source of UI nastiness.  This section
	needs to be much less ambiguous.  There should be a note about
	how to represent different states of menu items -- i.e. via icons
	in the menu -- and there should be strong recommendations to
	avoid some common mistakes made in this area.  These mistakes
	include:

	* Confusing menu items acting as radio buttons in a group with menu
	items acting as checkboxes.  Can these be distinguished in GTK by
	different icons?  If not, we should recommend that the two types
	of toggle menu items should never be available together in the
	same menu.

	* Ambiguous names for toggle menu items which make it difficult for
	the user to determine the actual state.  For instance, "Use
	Grid," which might either change to "<check> Use Grid" or "Don't
	Use Grid."  Instead, use an unambiguous command like "Turn Grid
	On" which changes to "Turn Grid Off".  (This example is from the
	Mac HIG, so we should find another.)

Section 2.1.7 Shortcuts and accelerators

	We should use the term "access key" for the underlined letter in
	a menu that allows keyboard navigation, and "shortcut key" for
	things like "ctrl-x = cut," as per the GDP wordlist.

Section 2.2 Standard menus

	We don't describe a View menu anywhere.  Since we refer to it in
	a couple of places we should probably define it as a "standard"
	menu of some kind.  We should also provide an alternative if
	there is no "View" menu.

Section 2.2.1 File menu

	The recommendations here are all for apps which edit documents.
	What about apps which do _not_ obviously edit documents?  We need
	to provide recommendations of how to handle this menu for those
	as well, beyond simply suggesting renaming "File" to "Game" for
	games.  We do not want to recommend that people have a "File"
	menu with only one item: "Quit."

Section 2.2.1.1 File access

	The summary of the menu says "Revert to Saved", while the text
	here says "Revert."  I prefer "Revert to Saved."

Section 2.2.1.2 Printing

	Nearly every app I've seen uses "Page Setup" instead of "Print
	Setup;" I'd argue for leaving this as "Page Setup" without a
	compelling reason to change.

Section 2.2.1.3 Quitting

	The menu items should be listed in the same order in which we
	recommend they appear in the menu.

Section 2.2.2.2 Clipboard Access and Deletion

	Should we note here that "Delete" should not affect the
	clipboard?

Section 2.2.3 Options

	To be honest, I don't really care whether we call these
	Preferences, Settings, or Options.  I am fond of the distinction
	that Darin Adler and others make between Preferences and
	Settings, but the fact of the matter is that users don't
	understand the difference, and we're not going to change that in
	the short term.  A good short term solution is to standardize on
	a _single_ term and put there everything that the user might
	expect to find.

	That said, I'm not sure an Options menu works well.  It might be
	better to recommend a standard "Edit -> Options" menu item which
	brings up a dialog box which looks like the Control Center for
	handling application-wide options, and a separate mechanism for
	handling document properties.  In any case, I think it's a
	mistake to simply cop out and not make a strong recommendation
	here because people are sensitive.  At least if we have a single
	model for this, it's consistent.  Clearly nobody has figured out
	the "right" approach to this yet.

	If we do stick with an "Options" menu, I strongly disagree with
	the recommendation to developers that they put "frequently-used"
	options in the Options menu as checkbox items.  It seems to me
	that program-wide options should need to be changed fairly rarely
	for a single user; an option that needs frequent change is
	probably evidence of a feature that could use redesigning.  (I'm
	happy to discuss this and possibly change my mind given some real
	examples.)

Section 2.3.3 Controlling Display and Appearance of Toolbars

	Again, if we're going to recommend usage of the View menu, we
	need to define it.

	I'm not 100% sure I am comfortable with this means of toolbar
	control, but at the moment I don't have a stronger positive
	recommendation.

Section 2.3.4 Default Toolbar layout -- Office Applications

	Re the delete icon: wouldn't a red "X" be better than a trash can
	for most uses of delete?


Section 3.1.1.2 Informational Dialog Boxes

	Informational dialog boxes are generally only modal -- I can't
	think of an example of a modeless info box.  Also, they're
	generally not terribly useful; they should be limited for
	information that is critical for the user to know immediately.
	Their use should generally be considered evidence of an
	interaction design problem; i.e. if you need an info box you
	might have a more serious underlying problem to fix.  On the
	other hand, info boxes may be necessary to notify the user of
	network or filesystem problems; however, in general it would be a
	much better idea to actually offer the user a choice of how to
	_deal_ with the problem rather than simply throwing up an error
	message and saying "sorry!"

Section 3.1.1.3 Druids

	We should note that functionality accessed through druids should
	also be accessible via other means such as menus.  Language
	should be consistent, so that users can actually have a chance at
	learning quicker means of accomplishing the same tasks.

Section 3.1.3 Dialog box behavior

	This is really specifically referring to modeless dialogs, I
	think; should that be noted?

Section 3.1.5 Dialog window titles

	I think "parent window" should be "document" here instead.

Section 3.2.1 File selector

	When the selector is being used to save a file, its title should
	be "Save <docname>," not just "Save File."  Sure, the docname
	will likely be "Untitled" but in some contexts it won't be.  And
	even if it is, it still helps clarify the document to which the
	dialog applies.

Section 3.2.2 Font selector

	I don't like the title "Pick a Font".  There must be something
	better.

Section 4.4 Radio buttons

	Pet peeve of mine: a group of radio buttons should always have a
	default.  (If nobody can think of any examples of mistakes in
	GNOME, I'm happy to have this one left out for space reasons.)

Section 4.6 Combo boxes

	We should note here _why_ one would want to use a combo box, not
	just what it is.  (Because it provides a way to list common
	choices while allowing the user to pick anything s/he wants).

Section 4.7 Progress bars

	The language here should be strengthened.  The use of determinate
	progress bars for tasks which are actually indeterminate
	undermines the user's trust for progress bars, and makes them
	less useful overall.  Hence, it's very important to make a clear
	distinction between the two and always use the appropriate type
	of progress bar.

Section 5.1 Order and Relationships

	Might want to note the exceptions to the "label should be above
	or to the left" rule: radio buttons and checkboxes, where the
	label should be to the right.  Or are the labels part of the
	widget in GTK, in which case this probably need not be mentioned?

Section 6.1.1 Menu Entry Icons

	The discussion of icons here might be moved to its own section
	(as it is in the Mac HIG), as most of these rules are generally
	applicable.

	"Icons based off word games" should be "Icons based on puns or
	other word games."  Also, I would argue that the example of web
	icons for the WWW in the early-mid-1990's is not an appropriate
	example here; it's a little obscure, and also arguably not quite
	the same issue.

Section 6.1.2 Menu Entry Captions

	Nothing specific here, but I got confused in the terminology
	between "Caption" and "Tooltip".  We should use whatever GDP
	terms are appropriate, but we need to clarify the difference
	between these two concepts.  My instinct is that most people
	think of a "Menu Entry Caption" as just a "Menu Entry" or "Menu
	Entry name".

Section 6.2 Providing a Connection between Documents & Applications

	I think this is important, but we should either leave out the
	technical bits of this section and provide a pointer elsewhere,
	or leave out the whole section and provide a pointer elsewhere.
	(The section itself seems like it'd be a reasonable developer
	document to put somewhere separately.)

Section 7.1 Mouse buttons

	"The right mouse button should be used to pop up and select
	actions from a contextual menu." (replacing "The right mouse
	button is used...")

	I'd argue that we'd be better off just mapping the middle button
	to Paste; that's what it seems to do in most cases in X.  But
	perhaps I'm missing more sophisticated uses?

Section 7.2.1 Mouse and keyboard equivalents

	I think clicking on a blank area in the window should generally
	deselect all.  It'd be nice if selection was included in the
	undo chain, though.

Section 7.2.2 Rubber-band selection

	Might want to mention a graphics/drawing program like dia as well
	as Nautilus.
--