GNOME.org
 

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

Attached is a review Chip Alexander, Sun's "styleguide evangelist",
recently wrote on Matthew's 'Improving GNOME 2.0 for Humans' document...
I promised I'd submit this to you and incorporate any comments into the
HIG that we felt were relevant.  (Chip is now also reviewing the public
draft of the HIG, I believe).

Cheeri,
Calum.

-- 
CALUM BENSON, Usability Engineer       Sun Microsystems Ireland
mailto:calum benson ireland sun com    Desktop Engineering Group
http://www.sun.ie                      +353 1 819 9771

                Made in Scotland, from girders.
--- Begin Message --- 
'Improving GNOME 2.0 for Humans' Review Notes
(Issues in order of severity, then by appearance in the document)

- 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.  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.  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.  This guideline would
be a big mistake.

- 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.
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").
4.	A recommendation should be made regarding left-aligning or
right-aligning labels.  I recommend following the JLF guidelines here
and left-aligning.
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.
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.
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.)
8.	Note not to end checkbox labels with a "?".
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.
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.  It should also include
information about how or where to undo what has already been done if the
user desires.

- 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.  Also, as discussed below, I'm not sure bold is not helpful for
dialog short titles.
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 (such as on a product which
is not translated), since identification of the control will not be
accessible without the help tip.
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.
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, and it is
very easy to instead provide a mnemonic on the default button.  This
probably affects the paragraph above this one as well.  (This is
different from what is currently in the JLF, but it is already under
discussion for the JLF.)
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.  A better name would really help here, even if it were
just a larger name like "Dialog Expanders".  My naming suggestion for
the section would be "Hiding Complexity".
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.
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 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.)
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.  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.

- 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.
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, but is more
confusing due to the double-negative.  Just remove it.
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.
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.
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.)
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.

_______________________________________________________________

                  C h i p   A l e x a n d e r

 Designer, Look & Feel Guidelines     650/786-4551 (or x84551)
 CTO-User Experience Group            Chip Alexander sun com
 Sun Microsystems, Menlo Park         (or just ChipA sun com)
_______________________________________________________________

--- End Message ---
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]