[HIG] REVIEW of Mini-HIG draft
- From: Matthew Thomas <mpt mailandnews com>
- To: hig gnome org
- Subject: [HIG] REVIEW of Mini-HIG draft
- Date: Mon, 15 Oct 2001 06:29:05 +1300
Greetings, usability fans
What follows is a semi-exhaustive list of problems I have with /The
GNOME 2.0 Mini Human Interface Guidelines/ as it exists currently. It's
only semi-exhaustive because I'll try not to repeat anything Kathy and
Calum have already said (I've just joined this list, but I've read
through the relevant bits of the archives). I've written an alternative
set of guidelines, /Improving GNOME 2.0 for humans/ (or `IG2H' for
short) <http://geocities.com/mpt_nz/ig2h.html>, and where appropriate
I'll compare the two to illustrate my disagreement.
Overall problems
----------------
1. Length. As I understand it, the reason these guidelines are being
compiled in a hurry, and without extensive usability testing, is in
order to produce a relatively short and concrete set of suggestions
for improving the usability of apps in GNOME 2.0. In line with this,
the guidelines were originally intended to be ten pages long.
However, Calum tells me (I haven't tried to print it myself) that
they are currently 40 pages long, even with a couple of sections
missing.
In those sections which are present, I think the signal-to-noise
ratio is generally too low. Not to pick on anyone in particular (I
have very little idea of who wrote each section), but there
are a lot of fluffy sentences which don't really say anything, and
there are many recommendations which aren't as clear, concise, and
assured as they could be.
Given the above, I am concerned that busy hackers may get halfway
through the Introduction or the first section and then give up.
2. Repetition. There are a number of topics which are discussed in more
than one section, and in some cases the guidelines even appear to be
contradictory. In particular:
* icon design is discussed in the `Menus and Toolbars' section,
the `Integrating Applications With the Desktop' > `Menu Entry
Icons' section, and the `Layout' > `Colour and Contrast'
section;
* button order in dialogs is discussed in both the `Dialogs' >
`Dialog box layout' section and the `Dialogs' > `Dialog box
buttons' section;
* label ellipsis is discussed in the `Menus and Toolbars' > `Menu
Principles' > `Naming Conventions' section, and the `Controls' >
`Buttons' section;
* label capitalization is discussed in the `Menus and Toolbars' >
`Menu Principles' > `Naming Conventions' section, the `Menus and
Toolbars' > `Toolbars' subsection, the `Controls' > `Buttons'
section, and the `Layout' > `Capitalisation' subsection.
3. Style. Consistency is generally a good idea in an interface. The
interface for the mini-HIG itself uses UK spelling in some places
(such as the `Introduction', the `Mouse Interaction Basics' section,
and the `Layout' section), and US English in other places. It also
uses Old-Style Title Case for some headings, and Sentence case for
others. There are plenty of spelling and grammar errors throughout
as well (`kindred' and `username' are a couple of the less obvious
ones), but to avoid tedium I won't list them here. (There are still
a few grammar errors in IG2H, too.:-)
Introduction
------------
4. The Introduction has a total of one subsection, `Why We Care About
Usability'. The subsection could be removed, and the Introduction
could perhaps be renamed `Why you should care about usability'.
5. Mini-HIG > `Introduction' > `Why We Care About Usability':
>
> What a disappointment it should be when a user's ability to access
> one of the features we have coded is impaired or altogether halted
> because they don't understand how to manipulate the interface.
So as to avoid giving up the usability battle before a single shot
has been fired, `should', `when', `have', `is', and `don't' should
be changed to `would', `if', `had', `was', and `didn't'
respectively.
6. Mini-HIG > `Introduction' > `Why We Care About Usability':
>
> Any time a user needs to ask for help to make progress, or commits
> an interface blunder due to a non-standard interface the
> application developer has failed to provide functionality.
This is not necessarily the case; the developer may have provided
too much `functionality', or (even more likely) provided the
appropriate `functionality' but in a confusing manner. (Pay no
attention to that grating noise; it's just my teeth reacting to the
`f' word.:-)
7. The story about Lord Halifax is amusing, but its relevance to the
subject at hand is not as clear as it could be.
Menus and Toolbars
------------------
8. It is unclear what the `Menu Principles' subsection is supposed to
cover. Certainly details like separators, shortcuts, and access keys
don't seem to be `principles'.
9. Mini-HIG > `Menus and Toolbars' > `Menu Principles' > `Drop-Down
Menus':
>
> Applications may possess a menubar
The contents of the menu bar is dependent on the window, not the
application. (It is true that the contents of the menu bar should be
almost identical between multiple windows of the same program, but
splitting programs into multiple executables to achieve this is
unlikely to be the sort of change which can be carried out before
the GNOME 2.0 release.)
10. Mini-HIG > `Menus and Toolbars' > `Menu Principles' > `Drop-Down
Menus':
>
> providing a number of drop-down
> menus. This menubar will be visible at all times
This isn't necessarily true; a program may provide a full-screen
mode where the menu bar is temporarily hidden. There should,
however, always be an obvious (and keyboard-accessible) method of
showing the menu bar again when it has been hidden.
11. Mini-HIG > `Menus and Toolbars' > `Menu Principles' > `Popup menus':
>
> Clicking on an object with the right mouse button may display a
> popup menu which should contain commands which can be applied to
> the selected object. (The act of clicking may change the
> selection.) Since popup menus are not accessible via the keyboard
> and since the user may not be aware of their presence, any items
> they contain should also be available via the application's
> menubar.
IG2H > `Menus and keyboard access' > `Shortcut menus':
|...
| Usually a shortcut menu provides quick access to contextual
| commands related to the selection or to the item which is under
| the pointer or which has keyboard focus; but it may also include
| very common non-contextual functions which are quicker to access
| from a shortcut menu than from the toolbar or main menus.
|
| * 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. 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.
Rationale:
* Mac OS uses the term `popup menu' to refer to an option menu, so
referring to GNOME shortcut menus as `popup menus' would be
unnecessarily confusing. (`Context menu' or `contextual menu'
would also be misleading, since the items in the menu aren't
always contextual.)
* Sometimes it may not be practical to duplicate every item from a
shortcut menu in the main menus; this is acceptable as long as
the keyboad accessibility conditions described above are met
<http://bugzilla.mozilla.org/show_bug.cgi?id=34357>.
12. Mini-HIG > `Menus and Toolbars' > `Menu Principles' > `Submenus':
>
> Submenus may be used to add a further level of hierarchy to a menu
This is like saying that the purpose of adding more lanes to a
highway is to make the highway wider. It's confusing the means with
the end.
13. Mini-HIG > `Menus and Toolbars' > `Menu Principles' > `Naming
Conventions':
>
> Most menu items will be labelled with verbs or adjectives, which
> describe commands or properties respectively.
This may be true, but only just. Often menu items will be labelled
with nouns (e.g. `Tools' > `Spelling', `Format' > `Paragraph...') or
prepositions (e.g. `View' > `Sort' > `by Date').
14. Mini-HIG > `Menus and Toolbars' > `Menu Principles' > `Toggled menu
items':
>
> Menu items may be toggled between two states.
This sounds as if it applies to all menu items, when it does not.
15. Mini-HIG > `Menus and Toolbars' > `Menu Principles' > `Shortcuts and
accelerators':
>
> Developers may assign keyboard shortcuts to menu items.
>...
> Shortcuts should consist of the Ctrl key and an alphanumeric key,
> or of one of the keys F1-F12, Insert, Delete, Home, End, Page Up
> or Page Down.
IG2H > `Menus and keyboard access' > `Keyboard access':
|
| * Keyboard shortcuts to carry out particular actions should
| generally consist of the Control key combined with an
| alphanumeric key. Except for the cases given above, the Alt
| key should be used only for access keys and window manager
| keyboard shortcuts, not for application-specific keyboard
| shortcuts. The F1 to F12 function keys should not be used for
| keyboard shortcuts; they should be reserved for macros or
| routines defined by the user.
Rationale:
* Where Control+ a non-alphanumeric key is used as a keyboard
shortcut, it will generally be an editing shortcut (such as
Control+Up = previous paragraph) which is not shown in the
menus.
* As keys for keyboard shortcuts go, the F1 to F12 keys are the
worst, since they have no mnemonic value at all (hence the
proliferation of WordPerfect decals above the function keys of
keyboards during the 1980s, since the keyboard shortcuts were
extremely difficult to remember by themselves). It seems
sensible for the function keys to be reserved for quick keyboard
access to global functions (F1 = open a new Web browser, F2 =
find a file, etc), in much the same way as the Foot menu allows
quick mouse access to global functions. That way you can be much
more confident that the shortcut will be remembered, because the
user put in the effort to define the shortcut himself.
16. Mini-HIG > `Menus and Toolbars' > `Standard Menus':
>
> There are a number of standard drop-down menus for common
> operations. The menus on a menubar should be placed in the
> following order: File, Edit, application-specific menus, Options,
> Help.
IG2H > `Menus and keyboard access':
|
| * Keep your menu structure, item wording, and choice of keyboard
| shortcuts, as close as possible to that shown in the following
| example menus. If you include menus other than the ones shown
| here, they should be placed between the "Format" menu and the
| "Tools" menu in the following structure.
|...
| File
|...
| Edit
|...
| View
|...
| Format
|...
| Tools
|...
| Help
Rationale:
* Many applications will have `View', `Format', and/or `Tools'
menus, so it is worth describing the basic structure of such
menus to ensure consistency.
17. Mini-HIG > `Menus and Toolbars' > `Standard Menus' > `File':
>
> _File
> _New Ctrl-N
> _Open... Ctrl-O
> Open _Recent >
> ---
> _Save Ctrl-S
> Save _As...
> Re_vert to Saved
> _Close docname Ctrl-W
> ---
> _Print Ctrl-P
> Print Preview...
> Print Setup...
> ---
> Close All
> _Quit appname Ctrl-Q
This layout is very reminiscent of the 1980s -- when applications
were more important than documents, when documents had to be
manually saved frequently to avoid being lost, when the Internet
was practically unheard of, and when the climax of the life cycle
of a document was to be printed on a printer. I think it's highly
unsuited to a modern computing system where multiple applications
are open at once and where computers are usually connected to the
Internet.
17 Mini-HIG > `Menus and Toolbars' > `Standard Menus' > `File':
>
> All applications should have a File menu [...] Applications which
> do not obviously operate on files may rename this menu to
> something more appropriate. For example, games may have a "Game"
> menu instead of a "File" menu.
IG2H > `Menus and keyboard access' > `File':
|
| * Always call the first menu "File", even if the application
| doesn't deal with documents. The extra smidgen of accuracy you
| may achieve from calling it "Game", "Application", or whatever
| is much less important than users' efficiency in recognizing
| the menu at a glance, in accessing the menu with a consistent
| keyboard access key, and in accessing the "Edit" menu and
| (where it exists) the "View" menu in a consistent horizontal
| position with the mouse.
18. Mini-HIG > `Menus and Toolbars' > `Standard Menus' > `File' > `File
Access':
>
> On document-editing applications, [...] Open [...] must be
> present, [...] and Open Recent may be present.
IG2H > `Menus and keyboard access' > `File':
|
| Similarly, only have one top-level "Open..." item, to preserve
| muscle memory for the later items in the menu. If you have more
| than one "Open" command, or if your application maintains a list
| of recently-opened files, use an "Open" submenu, and assign the
| Control+O shortcut to the first item ("Open File..." or similar).
Rationale:
* It's not just muscle memory which is affected if some `File'
menus have an `Open Recent' item and others do not; it's also
the average speed with which users can open a file. If a
separate submenu is used, users will habitually go into the
`Open Recent' submenu *just in case* the file they want is
there, before exiting and moving back up to the `Open...' item.
If `Open File...' and the list of recent files are in the same
submenu, this problem is avoided.
19. Mini-HIG > `Menus and Toolbars' > `Standard Menus' > `File' > `File
Access' > `Open':
>
> If the user's choice is already open in that application then the
> user should be notified via a dialog that the file is already open
> and the window containing that file should be given the focus and
> raised.
This is reasonably likely to be infuriating, especially if the user
really *did* want to open another copy of the document -- to view
different sections of the document at the same time, or to compare
the document before and after changes that the user was making, or
whatever. Far better, I think, to put up a note alert explaining
that `The document "The odyssey of King Fred" is already open. This
copy will be opened in read-only mode.' -- or, if the program
supports it, to make both windows editable and for each to reflect
changes in the other.
20. Mini-HIG > `Menus and Toolbars' > `Standard Menus' > `File' > `File
Access':
>
> Close docname
As others have said, I think the inclusion of the document name here
is unnecessary. After all, we don't have the document name after the
`Print' or `Save' items.
21. Mini-HIG > `Menus and Toolbars' > `Standard Menus' > `File' >
`Quitting':
>
> All Applications must have a Quit item. Applications which are
> capable of editing multiple documents simultaneously should have a
> Close All item.
IG2H > `Menus and keyboard access' > `File':
|
| * Don't include an "Exit", "Quit", or similar item for closing
| all those documents or windows which happen to be hosted by
| the same application. As GNOME develops, applications will
| become more invisible, and multiple applications will be able
| to be used on a single document at the same time; so the
| identity of the application hosting a document at a given
| moment will become more and more arbitrary and irrelevant.
(The `Exit'/`Quit' item is going to disappear from non-Mac versions
of Mozilla as soon as I find someone to implement it.)
22. Mini-HIG > `Menus and Toolbars' > `Standard Menus' > `Edit' >
`Manipulating the Selection':
>
> Select None
>
> Deselects all parts of the document.
I have never seen an application in which such a menu item is
either necessary or desirable. When editing text, any of the arrow
keys should clear the selection; when multiple files are selected in
a file manager, or multiple objects selected in a drawing program,
Escape should clear the selection. In neither case does the action
need to be listed in the menus, just as other basic shortcuts such
as Control+Left/+Right and Page Up/Page Down are not listed in the
menus.
23. Mini-HIG > `Menus and Toolbars' > `Standard Menus' > `Edit' >
`Searching and Replacing':
>
> Replace
>
> Brings up a Replace dialog.
I think it is a mistake to separate Find and Replace; since the
finding part of the interface for each would be practically
identical, the replacing function can be accessed in a less modal
manner by showing or hiding a `Change' section of the same dialog.
`Replace' is also a misnomer, since the user may be formatting or
transforming the found items rather than replacing them. All
replacements are changes, but not all changes are replacements.
24. Mini-HIG > `Menus and Toolbars' > `Standard Menus':
>
> Options
>...
> In reality, there needs to be a proper analysis of application
> configuration mechanisms. There are a number of different models,
> with no obvious consensus. Consideration needs to be given to,
> among other things, the distinctions between application, window
> and document settings, how multiple running instances of the same
> application interact, etc.
This is an odd paragraph which looks like it wandered into the
mini-HIG by mistake. I hope it is not intended to be permanent.
IG2H > `Menus and keyboard access' > `Edit':
|
| In general, an entire menu for setting options should be
| avoided; it would be unnecessarily prominent for most users,
| and would provide an awkward interface for altering settings
| which often need to be changed in combination.
25. Mini-HIG > `Menus and Toolbars' > `Standard Menus' > `Help':
>
> Search Help
>
> Brings up a dialog allowing the user to search the
> application's documentation.
This is a mistake. Users will only choose to search a set of
documents *after* they discover that the top-level navigation
provided for the documents is inadequate. (This will often be the
case, but not always; and if it was designed well, using top-level
navigation would be quicker than sifting through search results,
which is why users are willing to give the navigation a sporting
chance before hitting the search.)
Therefore, the user should not be persuaded that she needs to choose
whether she wants to search the help before she has even seen what
the top-level navigation is like; instead, the search function
should be easily accessible in the help browser itself.
26. Mini-HIG > `Menus and Toolbars' > `Toolbars' > Controlling Display
and Appearance of Toolbars':
>
> _View
> ...
> ...
> _Toolbar > _Show/_Hide Toolbar (see below)
> ---
> [x] Te_xt Only
> [x] _Icons Only
> [x] _Both Text and Icons
> ---
> _Customize... (if supported)
It is probably a bad idea to have the radio items in the submenu if
toolbar customization is supported. The user's choice of text,
icons, or both will often depend on how many buttons he has included
in his customized toolbar, so it is most convenient to change the
icons/text/both setting in the customization window itself.
27. Mini-HIG > `Menus and Toolbars' > `Toolbars' > Controlling Display
and Appearance of Toolbars':
>
> While the toolbar is displayed, the first item in the submenu
> should be labelled _Hide Toolbar. While the toolbar is hidden, the
> first item in the submenu should be labelled _Show Toolbar.
Unlike in the `Help' menu, in the `View' menu ease of scanning is
more important than coming up with the most painfully-easy-to-
-understand presentation of the system state. So it is better
to have a `Toolbar' checkmark item, than a non-checkmark item which
toggles between `Show Toolbar' and `Hide Toolbar'.
28. Mini-HIG > `Menus and Toolbars' > `Toolbars' > `Default Toolbar
Layout - Office Applications':
>
> Figure 8. Buttons that should appear on the main toolbar of an
> office application.
>
> New Open Save | Print | Undo Redo | Cut Copy Paste Delete | Find
> Replace | Help
`Replace' is discussed in point 23 above. As for `Help', if your
main toolbar needs a `Help' button, your interface is probably too
difficult for a `Help' button to be much use.
29. Mini-HIG > `Menus and Toolbars' > `Toolbars' > `Default Toolbar
Layout - Browser Applications':
>
> Applications for browsing documents or other objects, such as web,
> file, help or documentation browsers, should use the following
> layout for their main toolbar:
>
> [Back][Forward][Other Navigation][Home]-[Reload]-[Other
> AppSpecific]-[Stop][Help]
Not gonna happen. :-)
Well, I suppose you want more detail than that ...
The first thing to understand is that ease of access should not be
commensurate only with how common a function is and how dangerous
it is, but also with how much of a hurry you are likely to be in
when you want to use it. The example here is `Stop'. Judged by
frequency of use alone, `Stop' doesn't deserve to be in the toolbar
at all; but when you *do* need it, you need it so quickly that
nothing else except a toolbar button will do.
Now, sometimes when you need `Stop', it's at a random point when a
page is loading, so it doesn't particularly matter where in the
toolbar the button is. All that is important is that it must *not*
be near the right end of the toolbar (as recommended in the
mini-HIG), because there it would disappear when the window was
sized to a narrow width.
However, a decent proportion of the time when you need `Stop', it's
a fraction of a second after you've clicked, `Back', `Forward', or
`Reload', and decide that you really really don't want to go back or
forward or reload the page after all. For this purpose, it is best
if the `Stop' button is as close as possible to all three of those
buttons (and not on the other end of the toolbar, as recommended in
the mini-HIG).
So the usability-maximizing arrangement -- the arrangement where
`Stop' is as close as possible to each of those three buttons -- is
Back, Forward, Stop, Reload. Microsoft worked this out some years
ago; hopefully it'll be fixed in Mozilla sometime in the next month
or two.
Obviously some applications (those accessing information from local
storage) do not need `Stop', while other applications do not need
`Reload', so this might not be the sort of thing you can make
guidelines for in the first place (especially if you don't offer the
reasoning behind them).
Dialogs
-------
30. Mini-HIG > `Dialogs' > `General Principles':
>
> Dialog boxes come in a number of different forms, suitable for
> different situations, and each with their own UI implications.
This admission alone should have set alarm bells ringing.
It turns out that this section combines dialogs, alerts, utility
windows, `druids', and possibly progress windows too (though those
aren't explicitly mentioned) into a single category called
`dialogs', specifying confusingly similar appearance for each. This
is akin to an English grammar book combining verbs, adverbs,
adjectives, interjections, and prepositions into a single category
called `verbs', and specifying the same position in a clause for
each. Such an approach is hardly going to be conducive to effective
communication.
With that basic problem laying the foundation, other problems in
this section start popping up rather quickly.
31. Mini-HIG > `Dialogs' > `Types of dialog' > `Modal and modeless
dialog boxes':
>
> All dialogs can be classified according to whether they are modal
> or modeless.
Unfortunately (and understandably, given point 30) the mini-HIG
doesn't specify *how* users will be able to tell, just by looking at
a `dialog', whether it is modal or modeless. It is easy to imagine a
user clicking on a parent window in the background in order to bring
both it and its child dialog to the front, only to have the dialog
disappear completely behind its parent window because it was
unexpectedly modeless.
(You can probably guess the chain of events which follows ... The
user flusters about for half a minute, then opens a second instance
of the same dialog and uses that, then much later discovers the
first instance of the dialog still waiting patiently, thinks that
the second instance of the dialog can't have worked for some reason,
and repeats his action in the first dialog ... The net result is at
least a few minutes of wasted time, and at most dataloss of some
sort.)
IG2H > `Windows' > `Dialogs':
|
| Like an alert, a dialog is modal to its parent window; the
| modality is indicated to the user by the lack of a close button in
| the title bar (in the default window manager configuration), and
| by the existence of a row of buttons along the bottom of the
| dialog. These buttons either close the dialog or (in a few cases)
| open a secondary dialog or help window. Where it is practical to
| do so, you should use a utility window rather than a dialog, as
| this avoids modality and allows for easier experimentation by the
| user.
32. Mini-HIG > `Dialogs' > `Types of dialog' > `Modal and modeless
dialog boxes':
>
> In general, modeless dialogs are preferable to modal dialogs since
> they are less intrusive.
This isn't really true; intrusiveness is a property of the size,
focus behavior, frequency, and expectedness of a window, but not of
its modality. What modality does do is restrict your ability to
return to the first window after the second window has already
intruded; this is often useful (in which case you should use a
dialog), and sometimes not (in which case you should use a utility
window).
33. Mini-HIG > `Dialogs' > `Types of dialog' > `Informational dialog
boxes':
>
> Informational dialog boxes are those which do not require the user
> to enter any data or make choices; they are merely for
> notification purposes. These dialogs typically only need a label
> for the user to read and a button to close the dialog.
These are note alerts. It's curious that the mini-HIG describes note
alerts but not error alerts or confirmation alerts.
34. Mini-HIG > `Dialogs' > `Types of dialog' > `Druids':
>
> Druids are dialog boxes which lead the user through a sequence of
> steps.
IG2H > `Language' > `General guidelines for language':
|
| 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").
(Cue Gregory Merchan approaching with a baseball bat. Indeed, the
underlying toolkit functions probably do refer to `druids', but the
interface never should.)
35. Mini-HIG > `Dialogs' > `Types of dialog' > `Druids':
>
> Druids are best suited to situations in which the user requires
> some sort of "hand-holding", due to the way in which they can
> combine documentation and functionality. Experienced users tend to
> find them inefficient and patronising.
Speak for yourself.
36. Mini-HIG > `Dialogs' > `Dialog box layout':
>
> The top portion of a dialog box should contain the main area, the
> content of which is very much up to the developer.
If this sentence was removed, it's fairly likely that no-one would
notice.
37. Mini-HIG > `Dialogs' > `Dialog box layout':
>
> At the bottom of the dialog window should be a single row of
> buttons which pertain to the whole dialog. These can be divided
> into four main types: Action buttons, closing buttons, navigation
> buttons and help buttons.
Again, the mini-HIG neglects to describe how the user would be able
to tell the difference between these four types of button, or indeed
why the distinction is worth making at all (especially dubious since
an `OK' or similar button would fall into two of those four
categories simultaneously).
38. Mini-HIG > `Dialogs' > `Dialog box layout':
>
> These buttons should be laid out as follows: Action or navigation
> buttons should be on the extreme right. Closing buttons should be
> to the left of any action or navigation buttons.
IG2H > `Windows' > `Alerts' > `General guidelines for alerts' [the
same button order guidelines apply to dialogs]:
|
| * If there is a "Cancel" button, always put it immediately to
| the left of the main action button. This allows the user to
| establish muscle memory for cancelling the alert.
|
| * If there are other action buttons, put them to the left of the
| "Cancel" button, starting from the left of the alert message
| text.
Rationale:
* Besides providing a consistent position for the `Cancel' button
(which putting it to the left of however many action buttons
there are would not achieve), this arrangement would also allow
for more efficient tabbing through the buttons. Since the main
action button will (almost always) be activated by pressing
Enter, and the `Cancel' button will be activated by pressing
Escape, tabbing is most useful for buttons *other* than those
two -- the other action buttons, which will appear to the left
of `OK' and `Cancel' and therefore be earlier in the tab order.
39. Mini-HIG > `Dialogs' > `Dialog box behaviour':
>
> Dialogs should reflect the current state of the application. If
> changes are made to the state of the application while the dialog
> is on the screen then these changes should be immediately visible
> in the dialog.
I cannot think of a legitimate case where the state of an
application could change while a dialog was open. An example here
would be good.
40. Mini-HIG > `Dialogs' > `Dialog box behaviour':
>
> Care should be taken to ensure that it is obvious to the user
> whether changes made within the main area will immediately affect
> objects external to the dialog or whether the user will have to
> perform another action to apply those changes. For example, the
> presence of a button labeled "Apply" would imply that any changes
> would only be applied once that button had been pressed,
Again, the mini-HIG neglects to describe how to achieve this
state of obviousness -- especially since, on those platforms which
have fallen prey to `Apply' buttons, `OK' can be clicked without
first clicking `Apply'. (Understandably, many people -- even expert
users -- never figure this out, especially since a few programs use
`Apply' *instead of* `OK'.)
IG2H > `Windows' > `Dialogs':
|
| * Don't carry out any actions or changes specified in a dialog
| before the "OK" or equivalent button is clicked -- for
| example, don't include an "Apply" button. Over the user
| population as a whole, the time wasted from the resultant
| confusion of meaning of the "OK" and "Cancel" buttons would be
| greater than any benefit from being able to test the settings
| in a dialog. If it is useful to test settings in a dialog
| before it is closed, offer a preview area (labelled "Preview"
| if it uses actual content from the document, and "Sample" if
| it does not) to display the result of the settings. If this is
| not appropriate for a given dialog, or you need other things
| to happen before the dialog is dismissed, you should be using
| a utility window instead.
41. Mini-HIG > `Dialogs' > `Dialog box buttons' > `Action buttons':
>
> The leftmost action button should be the default button, and so be
> activated by the Enter key
IG2H > `Windows' > `Alerts' > `General guidelines for alerts' [the
same button order guidelines apply to dialogs]:
|
| * Always put the main action button (e.g. "OK") in the bottom
| right corner of an alert. This is where the user's eyes come
| to rest after scanning the alert, and putting it in a
| consistent horizontal position also allows the user to
| establish muscle memory for carrying out the main action. 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).
42 Mini-HIG > `Dialogs' > `Dialog box buttons' > `Action buttons':
>
> in addition to any other accelerators
> it may possess.
IG2H > `Menus and keyboard access' > `Keyboard access' [emphasis
added]:
|
| *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.
Rationale:
* Buttons accessed by pressing Enter or Escape should not have an
access key; this would only slow users down, by encouraging them
to look for an access key instead of using the quicker Enter or
Escape method of activating the button. Indeed, giving an access
key to a `Cancel' button would make it *less* obvious that it
could be accessed by pressing Escape, because there would no
longer be anything distinguishing it visually from an action
button.
43. Mini-HIG > `Dialogs' > `Dialog box buttons' > `Closing buttons':
>
> The situation is slightly different again
[another warning bell]
> for informational
> dialogs. As always, the closing button should close the dialog,
> but the labelling of the button is a decision for the developer
> and is dependent upon the context in which it appears. As a rough
> guide, "Close" will generally be an appropriate label for dialogs
> appearing in response to a user's request for information, while
> "OK" will often be more appropriate for unrequested alerts.
`Close' is on my list of labels which push buttons should *never*
have, and alerts are no exception to this.
IG2H > `Windows' > `Alerts' > `Error alerts':
|
| * Always label the button "OK". Giving it a different label
| (such as "Continue") would only slow down a user by misleading
| him into thinking that the button itself was useful to read.
44. Mini-HIG > `Dialogs' > `Dialog box buttons' > `Closing buttons':
>
> In all of these cases the closing button should be activated by
> the escape key. On purely informational dialogs where the dismiss
> button is the only button in the bottom row of the dialog, it
> should also be the default button and so be activated by the Enter
> key.
This would be bad. Activating `OK' in a note alert (for example) by
pressing the Escape key could very easily mislead a user into
thinking that she could cancel the action which had already
finished.
Controls
--------
This is generally the best-written section of the mini-HIG. I have just
one quibble at the moment:
45 Mini-HIG > `Controls' > `Radio Buttons':
>
> Only one radio button within a group may be checked at any one
> time.
Consider a `Paragraph Formatting' dialog, which has option buttons
for paragraph alignment: `Left', `Center', `Right', and `Justified'.
Imagine selecting a few paragraphs, some of which are left-aligned
and some of which are centered, and then opening the dialog. What
would you see? :-)
Layout
------
46. Mini-HIG > `Layout' > `Fonts and Text':
>
> Even to a user with normal vision, textual output provides the
> majority of the information and feedback in most applications.
This implies that textual output provides even *more* of the
information and feedback in most applications for some people ...
who? People with better-than-normal vision? People with
worse-than-normal vision?
Integrating Applications with the Desktop
-----------------------------------------
47. Mini-HIG > `Integrating Applications with the Desktop' > `Placing
Entries in the Panel Menu':
>
> The panel menu is arranged into a set of broad categories. An
> application should place an entry in just one of these categories
First, a program should check to see if the Panel Menu exists.
(It may have been written for GNOME 2.0, but installed on a much
later version of GNOME which doesn't have a Panel.)
Then, if the Panel Menu exists, the program should *ask the user*
which category (if any) an item should be placed in. I might have
biffed all the entries in the `Graphics' category into `Multimedia'
and gotten rid of `Graphics', in which case I'd be pretty annoyed if
the next app I installed recreated the `Graphics' category just to
put itself in it.
48. Mini-HIG > `Integrating Applications with the Desktop' > `Menu Entry
Captions':
>
> If an application falls into a general class of applications (for
> example, "Email Client" or "Word Processor") they should follow
> the format APPLICATION TYPE (APPLICATION NAME).
This (Could) Get (Very) Annoying (Indeed). If GNOME wants programs
to specify their task as well as their name, these should be entered
in separate fields in the registry -- so that current or future
Panel designs can present the name and task in more pleasant ways
than crooked parenthesized columns.
| Browse the Web, send e-mail, chat, and create Web pages (Mo... |
I'd argue that such task-dominated entries are only necessary for
tasks in which the default client must be easily switchable to
ensure the health of the standards governing the system -- that is,
clients for Web browsing, e-mail, Usenet, and other basic Internet
protocols. For other tasks, the recognition problem can be solved by
renaming the default program to match its task; for example,
Nautilus should be renamed the File Manager. If a user goes out of
their way to choose a program other than the default for a task,
then they will know what it is called anyway, and the recognition
problem will not be present.
Mouse Interaction Basics
------------------------
I'm surprised to see this section in a mini-HIG; it seems more suited to
a full-HIG which has hundreds of pages. But never mind ...
49. `Mouse Interaction Basics' > `Mouse Buttons':
>
> Every operation that can be done with the mouse can also be done
> with the keyboard.
IG2H > `Menus and keyboard access' > `Keyboard access':
|
| And for accessibility reasons, it is important to provide keyboard
| equivalents to all mouse actions where possible. (Some exceptions
| to this are action games, drawing or painting programs, and
| toolbars and the means of customizing them; these are practically
| impossible or pointless without a pointing device of some sort.)
50. `Mouse Interaction Basics' > `Drag and Drop':
>
> Suggestions:
>
> * A tooltip is provided when the pointer is paused over a valid
> drop target. It describes what will happen if the object is
> dropped there. Is this feasible in GNOME?
Tooltips have, up to now, only been provided when the mouse button
is not down. I predict that if tips were provided during a drag and
drop operation, users would find it extremely disconcerting.
51. `Mouse Interaction Basics' > `Drag and Drop':
>
> * Attempting to drop multiple objects on a target which can only
> accept a single object brings up a pop-up menu. From this
> menu, one of the objects can be selected, or the operation can
> be cancelled.
The behavior of opening a menu when a drag is dropped is described
in the /User Interface Hall of Shame/ (in the case of
right-click-and-drag in Windows Explorer) as `perhaps the *least*
intuitive operation ever conceived in interface design'
<http://iarchitect.com/explore.htm#EXP2>. I agree.
52. `Mouse Interaction Basics' > `Drag and Drop':
>
> * Objects may be copied between applications, but not moved.
>
> * By default, dragging is non-destructive, i.e. dragging an
> object from one container to another drags a link or copy,
> leaving the original intact.
This is grasping at the general rule, but not quite getting it. The
general rule is that dragging within a container will move the item,
whereas dragging between containers will copy the item. The trick is
to work out what the user expects a `container' to be. A few
examples:
* a mail server is a container -- dragging from one mail folder to
another on the same server should do a move, whereas dragging to
a mail folder on a different server should do a copy;
* a disk is a container -- dragging from one folder on a floppy
disk to another folder on the same disk will do a move, whereas
dragging to another disk should do a copy;
* a program is a container -- when the Customize Toolbar dialog is
open, dragging a toolbar button to another place in the toolbar
of the same application will do a move, whereas dragging it to
another program should (eventually:-) do a copy.
Keyboard Interaction Basics
---------------------------
Most of the problems with this section are already covered in earlier sections.
53. Mini-HIG > `Keyboard Interaction Basics' > `Standard Application
Shortcuts and Mnemonics' > `Table 7. Standard GNOME application
shortcuts and mnemonics -- Bookmarks menu':
>
> Add _Bookmark Ctrl+B Add a bookmark for the current location
Given that more than 95 % of Web users use browsers where the
shortcut for `Add Bookmark' is Control+D or Command+D, not to
mention the thousands of Web pages which exhort you to bookmark them
by typing Control+D, the choice of Control+B for this function is
... interesting.
That's all, folks.
--
Matthew `mpt' Thomas, Mozilla UI Design component default assignee thing
<http://mozilla.org/>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]
