[HIG] REVIEW of Mini-HIG draft

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

    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'
    *   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.:-)


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'

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
    > 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
    >                                    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. 

    *   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

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
    > 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
    > 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
    > 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. 

    *   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
    *   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

    *   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

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
    > 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). 

    *   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
    > 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' >
    > 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

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).


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

    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

    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

33. Mini-HIG > `Dialogs' > `Types of dialog' > `Informational dialog
    > 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

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.

    *   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
    | *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.

    *   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

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


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? :-)


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
    > If an application falls into a general class of applications (for
    > example, "Email Client" or "Word Processor") they should follow

    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
    *   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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]