Re: [HIG] [Fwd: 'Improving GNOME 2.0 for Humans' Review Notes]

[Matthew Thomas <mpt mailandnews com>]

Calum Benson wrote:
> 
> Attached is a review Chip Alexander, Sun's "styleguide evangelist",
> recently wrote on Matthew's 'Improving GNOME 2.0 for Humans'
> document...

Cool. I've fixed all the problems listed, where I agreed with the analysis.

>...
> - One Major Issue -
> 1.      "Donít include an Exit, Quit, or similar item for closing all
> those documents or windows which happen to be hosted by the same
> program. As GNOME develops, programs will become more invisible, and
> multiple programs will be able to be used on a single document at the
> same time; so the identity of the program hosting a document at a
> given moment will become more and more arbitrary and irrelevant." -
> The concept here is nice, but the guideline horrible.  If GNOME
> succeeds in not making me think of the windows as part of an
> application, and therefore I want to just close them separately,
> great.  It won't hurt to have Exit in the File menu then.

Heh. That's the same logic which says, `it doesn't matter how many
stupid prefs we have, as long as they all have nice defaults'. Clutter
still hurts.

>                                                            I probably
> won't even be in the File menu, instead just closing the windows with
> their close control.  But to take away the ability to ever close more
> than one window at once for those who do know the relationship is a
> real inconvenience to the user.  As a knowledgeable user, when I am in
> Photoshop, I know all the drawings I have open are related.  Same for
> spreadsheets or text documents or whatever.

As a knowledgable user, when I'm using a computer, all the documents I
have open called `untitled' (no matter what app is hosting them) are
usually related. Should there be a menu item for closing all those at
once too?

I think what you're really looking for here is a smarter window manager
where you can group related windows (no matter which app happens to be
hosting them), and close all windows in a group at once.

>                                              If I had to go to each
> one of the documents and close them individually because someone
> thought that eliminating Exit gave a nice concept, I would switch back
> to another platform.

Which platform would you switch to, exactly? No platform I know of is
consistent, either in always having distinct Close and Exit or always
not. (Even Mac OS sometimes uses `Close' to mean `Quit', and sometimes
to mean just `Close'.)

>...
> - Important Additions -
> 2.      "In general, labels should use sentence case - the first word
> begins with a capital letter, but the others do not unless they are
> proper nouns. Menu items and push buttons should use Title Case" - I
> disagree with this.  I think Title Case is the appropriate way to show
> labels -- "Point of origin" and "Bill of materials" just look silly --
> Windows, the Macintosh, and the JLF all use title case.

No they don't. The JLF Guidelines and Macintosh HIGs both recommend
title case, but this is often ignored by apps on those platforms (e.g.
`(*) Show only three and four star results' in Limewire, and `[/] Use
relative date' and `[/] Calculate folder sizes' in the Mac OS Finder)
because using title case would look daft. The Windows interface
guidelines give recommendations similar to IG2H on when to use title
case and when to use sentence case.

See also `Show Me This Alert Next Time" should be "Show me this alert
next time' <http://bugzilla.mozilla.org/show_bug.cgi?id=64362>.

> 3.      In discussing field labels, it would be good to mention to
> speak in the user's terms, and avoid programming terms like "Flag"
> (such as for an order, "On Hold", not "Hold Flag").

| *   Avoid using terminology which is unnecessarily technical or
|     obscure (such as `reboot', `daemon', and `druid'), when there are
|     more understandable terms available (such as `restart', `manager',
|     and `assistant').

> 4.      A recommendation should be made regarding left-aligning or
> right-aligning labels.

True, but not the sort of thing which there was room for in a 12-page
set of basic guidelines.

>                         I recommend following the JLF guidelines here
> and left-aligning.

This is one of the things which the JLF guidelines unfortunately got
wrong. If the labels vary a lot in width, left-aligning them makes
it unnecessarily difficult to scan the controls and to tell which
control goes with which label. (If the labels don't vary a lot in width,
left-aligning them just looks minorly dishevelled.)

> 5.      For online help, note that you should go to the lowest level
> of context possible, relative to where the user requested help. 
> Dropping the user at the top of a help system table of contents when
> they requested help on a specific page or dialog is maddening.

True, but not the sort of thing which there was room for in a 12-page
set of basic guidelines.

> 6.      In Keyboard Access, note that Home should go to the beginning
> of a line, End to the end of a line, Ctrl-Home to the start of the
> text block, and Ctrl-End to the end of the text block.

True, but not the sort of thing which there was room for in a 12-page
set of basic guidelines.

> 7.      "Try to offer at least one level of undo and redo for all
> editing or formatting actions. If an action cannot be undone or
> redone, change the menu item to Can't Undo or Can't Redo as well as
> making it unavailable." - specifically note that undo does not do a
> redo, even when only one level of undo is provided.  (It is too
> confusing among applications when the second undo sometimes does a
> redo and sometimes does an additional undo.)

True, but not the sort of thing, etc.

> 8.      Note not to end checkbox labels with a "?".

| *   Except for the ellipsis and colon cases above, and parentheses or
|     quote marks, labels should not end with punctuation. For example,
|     the label for a checkbox or option button should not end with a
|     period.

> 9.      Under "General guidelines for windows", add that one should
> usually allow resizing a window, and to always allow resizing if text
> could ever get truncated in length or if there is any scrolling of any
> sort.  This allows the user to enlarge the dialog to see more
> information.

| *   A dialog should not be resizable unless a considerable proportion
|     of the elements in it would benefit from being made larger.

> 10.     "If it makes sense to do so, include a push button which halts
> the task and closes the window. Label the button Cancel if pressing it
> will undo the partial operation and restore the system to its original
> state; otherwise, use Stop." - Add that if the user presses Stop, a
> dialog should appear to confirm the user wants to stop the action even
> though the part done so far will not be undone.

No thanks. By the time you'd processed the alert, the damage you wanted
to stop in the first place would often have been completed.

>                                                  It should also
> include information about how or where to undo what has already been
> done if the user desires.

That should be obvious without using an alert. Of course, it is
preferable to do the work required so that you can provide `Cancel'
instead of `Stop' in the first place.

> - Medium Issues -
> 11.     "Donít use capitalization, font styles, colors, or punctuation
> to emphasize text; use clear layout and visual design to achieve this
> instead." - I think it is actually helpful to change to a different
> font when referring to elements on the page such as button names or
> field labels.

Doing this would make the text look unnecessarily similar to a control
itself. In general, outside of online help (which this guideline is not
aimed at), you shouldn't need to refer to other controls by name in the
UI in the first place (show, don't tell). Where you do, quote marks or
just capitalization should be sufficient (e.g. `You can turn this option
back on in the "Sending" tab of Preferences').

>                Also, as discussed below, I'm not sure bold is not
> helpful for dialog short titles.

Dialog short titles should not exist.

> 12.     "Where the control has a visible label, donít repeat the label
> in the help tip." - should specifically note an exception for when the
> visible label is part of the graphic itself

That shouldn't be true in the first place, surely.

>...
> 13.     "Because most people are unwilling to use more than one mouse
> button, treat shortcut menus as an alternative method for accessing
> functions frequently needed by expert users."  -- The real issue here
> is not that people are unwilling to use it as much as that the feature
> becomes undiscoverable.  There is no visible cue that the command you
> want is in there unless you think to go look.

That may be true. The `are unwilling to' is as much a wakeup call as
anything else.

> 14.     "Except for those controls which are accessed by typing
> Escape, Control+Enter, or (Shift+)Control+Tab, all controls which have
> a label should also have a case-insensitive alphanumeric access key."
> - I suggest that you take Control+Enter out of that list, and in fact
> specifically note that an access key should be placed on the default
> button if the dialog contains a multi-line text field.  Control+Enter
> is something normal users will never discover or get used to,

They don't need to get used to it, unless they rely exclusively on the
keyboard. Even then, they could use the Tab key to get out of the text
field first.

>                                                               and it
> is very easy to instead provide a mnemonic on the default button.

Yes, it would be very easy, simple, and wrong.

>...
> 15.     The term "Expanders" is confusingly similar to tree control
> expanders, and I read the entire section thinking the tree control and
> buttons which enlarge a dialog had been generalized into one category
> and soon I'd read about the tree control part.  In fact, it has
> nothing to do with them.

No, they behave in exactly the same fashion. That's the whole idea. :-)
I didn't discuss their function in tree controls in IG2H, because that
was too obvious to make room for in a 12-page set of basic guidelines.
(They're in the same section in the Macintosh HIGs, too.)

>                           A better name would really help here, even
> if it were just a larger name like "Dialog Expanders".

They may be used not only in dialogs, but also in alerts, utility
windows, and progress windows.

>                                                         My naming
> suggestion for the section would be "Hiding Complexity".

Expanders are only one method of hiding complexity. Other methods
include `Advanced...' buttons, tab controls, and assistants.

> 16.     " If several additional controls apply only to one particular
> option button, indent those controls under that option button so that
> they are aligned with its label, and make the controls inactive unless
> the option button is selected. " - This is a bit too sweeping of a
> statement. There are some cases where it is better to leave the field
> enabled, and automatically select the radio button corresponding to
> that field if a value is entered.  For example, in many print dialogs,
> you can enter the desired pages to print and the radio field next to
> the "Selected Pages" option button will automatically select next to
> it.  This saves having to first click the option button before
> entering the desired page number(s).  Both are valid designs, and it
> is clearly visible which has been done, so just point out the
> possibilities and benefits of each.

The automatic option button selection model only applies when there are
one or two dependent fields, and where those fields are in the same line
as the option button rather than being indented under it. That's why I
was careful to say `*several* additional controls', so that my sweeping
statement was still correct. :-)

> 17.     "Never give an alert a title. A title will almost always be
> redundant with the main message in the alert itself, but will hardly
> ever give enough information to allow the user to deal with the alert
> without reading the main message. Even if this isnít the case for the
> occasional alert, giving that occasional alert a title will slow the
> user down when scanning every other alert in GNOME, by encouraging him
> to check the title just in case it is useful." - I'm hesitant at best
> about this one.  I have seen a lot of dialogs

Dialogs should certainly have titles, but alerts should not. (That's one
of their distinguishing features.)

>                                               where I was able to read
> the short text after the first time, but did need more detail
> originally to understand the message.  For example, a dialog might say
> "File Exists" in bold on the top line, then go on to say "There is a
> file of the name whatever already in the directory wherever.  Do you
> want to replace it?"  It would be awful to have the only message be
> "File Exists", but those two words are all I need to see after the
> first time, and I don't want to read the whole long message each time. 
> (This is actually an example from the JLF in showing such summary text
> in dialogs.)

The text `There is a file of the name "Curriculum vitae" already in the
directory wherever.  Do you want to replace it?' is too wordy in the
first place. It could be changed to `Replace existing file "Curriculum
vitae"?' with almost zero loss in meaning, and a `File Exists' title
would be worse than useless in addition to those few words.

> 18.     "The main action button is almost always the default button;
> the exception is where the action is potentially very dangerous, such
> as formatting the user's hard disk or launching a missile. In those
> cases Cancel should be the default button, activated by Enter and
> Control+Enter as well as by Escape (the main action button will
> require its own access key in that case)." - The problem with this
> solution is that it often leads to confusion that the action was done. 
> The dialog comes up, the user presses Enter, the dialog dismisses, and
> the user thinks the action has been done.  I have had this happen to
> me several times in fact.

There are two issues here, but neither of them are to do with the design
of the alert. The first is that when the key for any control is pressed,
the control should appear pressed for a short time (about half a second)
before the action is carried out -- for example, when pressing Enter in
an alert, the default button should appear pressed for a moment before
the alert is closed. GTK does this, but in Swing it seems to be a bit
inconsistent (it works for Enter, but not for Escape).

The second is that there should be some obvious feedback whenever an
action *is* carried out -- a quiet sound effect, or an animation, or a
clear change in the document itself.

>                            I much prefer the JLF solution to this
> problem: "The alert box in Figure 115 asks users if they want to
> replace an existing file. The alert box has Replace and Cancel
> buttons, neither of which is the default command button. Even though
> the Replace button has focus, it cannot be activated with the Enter
> key; it must be activated with the spacebar. This approach gives the
> user time to reconsider a hasty, automatic confirmation."  This avoids
> the user thinking the action has been done when it hasn't, but still
> provides the safety net.

This is a classic mistake made by less experienced UI designers (and one
which I have to be careful not to fall into, being a less experienced UI
designer myself:-) -- overestimating the probability of users making a
mistake, and comprehensively annoying everyone else as a result. (Other
classic mistakes include trying to turn users into programmers, putting
`Close' buttons anywhere, and repeating strings of interface text
several times in the same window.)

> - Minor Issues (Typos, wording, etc.) -
> 19.     The term "full stop" is used several times.  This is sort of
> vague for people who don't commonly use the term.  Just use the word
> "period", even if you have to use it several times.  Better to have
> word repetition than confusion.

Ok, I didn't realize `full stop' was a Britishism. :-) Fixed.

> 20.     "Avoid using shortcut menus for items that cannot also be
> accessed by another method. And to ensure accessibility, never provide
> a shortcut menu as the only interface for a command, if the item from
> which the menu is opened cannot be given focus or selected using the
> keyboard." - this is completely a repetition of the previous sentence,

Not really. Consider the shortcut menu I have specced for images in
Mozilla (still awaiting implementation, alas):
|
|   Back
|   Forward
| ------------------------------------
|   Copy {Image|Selection }
|   Copy Link Address
|   Save Link As...
|   File Bookmark for Link...
|   Link Properties
| -------------------------------------
|   View Only this Image
|   Copy Image Address
|   Save Image (blarg_01.png) As...
|   {Block | Unblock} Image...
|   {Load | Reload} Image
|   Image Properties {and Description}

Many of these items cannot be accessed anywhere other than from this
shortcut menu. That's what the `avoid' guideline is for. It just so
happens that dealing with Web content is pretty complicated, so Mozilla
*can't* avoid it without causing extreme UI complexity elsewhere.

More serious, though, is the fact that where the image is not a link,
the image can't be focused even to open the shortcut menu with the
keyboard. That's what the `never' guideline is for -- it's acceptable
(though not desirable) to make the menu the only interface for a
function, *as long as* you let the object have keyboard focus so a
keyboard-bound user can get to the menu in the first place. (To that
end, I filed `Provide option to include objects (images etc) in Tab
cycle' <http://bugzilla.mozilla.org/show_bug.cgi?id=58997>.)

> but is more confusing due to the double-negative.  Just remove it.

Not removed, but fixed.

> 21.     "An option button (also known as a radio button) allows the
> user to choose between a number of mutually exclusive options." -
> "Between" should be "among" since the implication is that there can be
> more than two.

Fixed.

> 22.     "Tabs should only be used where the number of panels is fewer
> than about six." -  Should say "about five or fewer tabs", "about five
> tabs or fewer" or (best of all) "a maximum of about five tabs" so the
> number shown is the maximum recommended, not one more than the maximum
> recommended.

Fixed.

> 23.     "As they apply to individual windows or parts of windows, they
> allow the user to establish a custom tradeoff between complexity and
> screen real estate which suits them (unlike over-broad and patronizing
> user modes which apply to an entire application)." - Should say "suits
> what they are doing", not "suits them".  (The whole point is that it
> is not a broad-sweeping thing about the user, but just about what the
> user's needs are on this one task right now.)

I think `suits what they are doing' and `suits them' are functionally
equivalent here, and `suits them' is shorter, so I've left it as it is.

> 24.     "In an alert or dialog, the main action button and the cancel
> button should be the same width (not including the border for the
> default button), and should both be 6 ems wide unless the text of
> either button is too long to fit." - the term ems needs to be defined
> here.  It is actually defined a page later on the second use of the
> term.

Fixed.

Thanks for the comments.

-- 
Matthew `mpt' Thomas, Mozilla UI Design component default assignee thing
<http://mozilla.org/>