[HIG] Comments on HIG 1.0

[Kai Wetzel <kai wetzel1 freenet de>]

Hi,

I've been following the HIG draft for a while and
intended to send some comments earlier but got distracted,
so the following refers to release 1.0 (with some
exceptions where I missed late changes)

First let me thank you for your excellent work on
the HIG - I think it's the best UI document/guide in 
the Free Software arena to date and could form the basis 
for non-GNOME applications (e.g. KDE), as well.

It would be cool if a common project, pulling in 
contributions from GNOME, KDE, and elsewhere, was formed
with a mailing list on freedesktop.org or simpleface.org (where we
briefly discussed this idea a few weeks ago). I hope
to see positive feadback to your invitation from the KDE
folks after they digested the HIG :-)

I notived that I mixed highly opinionated recommendations
with pointing out ovious bugs - sorry for that. For me it 
would have been easier to seperate the two in person-to-person
dialog rather then a written summary (I wanted to pass
it on before you release the next version, after all)

---

PDF version:

You mention you'd like a nice-looking PDF version: me, too!

General:

Maybe a graphics designer could make suggestions on how
to make the HIG easier to follow and look better ? Some
ideas:

  - indent the body text so the document structure/hierarchy
    stands out more clearly
  - color/shade headlines differently
  - add specific locations below prev/next on top like you do
    at the bottom
  - add a "home" or "top" link to every page.
  - add date of generation from CVS sources to the draft.

In chapter 2 the presentation of good usability principles
has many references to the HIGH structure or where to find
further information (not bad in itself). Take it with a grain
of salt but I'd personally like more "structure", e.g.:

  - provide an overview of what the reader can expect from the
    HIG early on (benefits, but also what's in each chapters)
  - try to create "sections" or "parts" containing a few chapters
    each, not 13 chapters flat (why, for example, is the
    chapter on visual language not an earlier chapter ? If this is
    intentional, make it explicite)
  - include background info on cognitive psychology, possibly
    as an appendix.
  - don't include code examples, or offer them seperately
    in an appendix.
  - offer tables, such as a list of shortcuts or
    a UI check list, in an appendix for quick reference.

---

Foreword:

  Maybe you could add something along the lines of 
  the following and offer a general overview in a foreword (or
  chapter 1):

  (from a mail from Seth to the usability list:)
  [...]
  The HIG (even a very complete HIG) is like a
  scratch in the surface of design and usability.  Its
  possible (and even highly likely) for GNOME apps to 
  be 100% HIG compliant (even a future HIG that's 4 times 
  as complete) and still be lame ducks.

  Design is not an engineering discipline, it is an art. 
  The HIG extends this to a concrete set of rules whenever
  possible, but this is possible in a minority of cases
  not the majority.
  [...]

  (Maybe paraphrase but it has the right tone IMHO)

---

[Introduction]

(very nice, well written)

---

[Chapter 1]
- very nice flow overall
- you coul use italics more often to put emphasize where appropriate, e.g.
  "comfort" and "trust", like you did with "accurate" and "precise".

[Chapter 1: Put the user in control]
- ... "such as the current GTK+ theme." maybe mention color scheme(s)
  explicitely ?
- "This means that modes should generally be avoided." Ok, but
  differentiate between modal interfaces and task modes (which have their
  place, after all) more clearly.

[Chapter 1: Forgive the User]
- mention document drafts at the end of the paragraph as example (?)

[Chapter 1: Enable Direct Manipulation]
- maybe this paragraph is too concise for people not familiar with the
  terminology even with Ch. 10 beiong mentioned ?

---

[Chapter 2: Placing Entries in the Applications Menu]
- Revise this paragraph: The distiction between categories
  ("just one") and "keywords" is not clear and is not in
  full agreement with the VFolder spec., where "category"
  is equivalent to "keyword" now IIRC.

[Chapter 2: Menu Item Names]

I know this has been discussed a lot, so I'll only add some considerations"
- It would be nice to come to agreement with KDE about application menu item
  name and tooltips policy, make it easier to build environments
  composed of tools from either source.
- Usually avoid "GNOME" and such, ok - I think "Calculator" is too generic
  if there is a good chance people (or their distribution, their admin)
  installs these from different sets, e.g. "GNOME Calculator" in a KDE-based
  setup. Technical solution: include "GNOME" where the rest of the name is
  generic but mark it "optional" so it's not included if used by the GNOME
  menu system but shown in the KDE desktop's menus.
- I personally prefer "AbiWord (Word Processor)" but in any case maybe the
  "additional" information could be made optional or even be moved to the
  tooltip. (e.g. tooltip line 1 reading "AbiWord Word Processor"; line 2:
  "Create text documents and ... whatever".
- I'd personally even prefer tooltips plus balloon help, but nobody else seems
  to like the latter :*>
- mention that Application long names (menu items) are subject to l10n ? 
  E.g. "AbiWord Word Processor" becomes "AbiWord Textverarbeitung" in German.

[Chapter 2: Menu Item Tooltips]
- add "more formal" guide how to write up tooltips, e.g. example
  the examples are a little incosistent in using "your";
  Same Gnome doesn't make it clear it's a game unlike the Batalla example.

[Chapter 2: Mapping Document Types to Applications]
- integrate/mention KDE, probably a technical thing: will freedesktop.org
  solve this ?

[Chapter 2]
- Does/will GNOME/Nautilus allow adding items to context menus for
  particular file types ? (If yes mention it in chapter 2)

---

[Chapter 3: at the top]
  - I'm glad you removed :"Windows allow users to organize and control
    the information available on their screen at any given time in large
    chunks." :0>

[Chapter 3: Borders and Window Commands]
  - mention roll-up is also known as window shade.
  - _possibly_ include "optimize size" command in a future version like the
    old Mac Finder used to have?

[Chapter 3: Primary Window Titles]
  - While I see your point regarding exclusion of application names from
    window titles I'd highly suggest coming up with something
    allowing consistency between GNOME applications and ideally across
    desktops (KDE, etc.) possibly involving a technical solution using
    WM Atoms (freedestop.org) to pass WM Title and application Name
    seperately for the WM to show or not according to vendor/admin defaults
    or user preferences.
    Personally I'd love to have the apps mini icon plus document title, 
    but that's just dreaming :*)
  - Possibly mention that using the application's short name is enough,
    e.g. "AbiWord" rather then "AbiWord Word Processor" if people don't
    want to follow your recommendation ?

[Chapter 3: Relation between Documents and Windows]
  - very well-written and concise! Compare this to the KDE version, sigh.
  - What you say about "many small files" applies to other applications
    that handle "many files" concurrently as well - maybe be more general
    in the CSDI section, mention pros and cons of the approach ?
  - In the MDI section you now mention tabbed MDI (very late
    change).  It is not clear why/how your criticisms of MDI in general
    relates to tabs in browsers or code editors. How about this:
    - Critisize traditional MDI
    - Elaborate on rationale behind tabbed MDI and give examples
    - Point out that if tabbed MDI is used the user should have
      the option to use SDI instead (WM takes care; rationale).
  - mention pros/const of each approach more clearly

[Chapter 3: Instant Apply, Preference Windows]

  - Shocking! (sorry)
  - Use instant apply where changes can be undone using
    the regular command history, most likely this will be
    property windows affecting the current document (seen, for example,
    in Adobe Pagemaker).
  - use explicite apply otherwise, e.g. most likely in both
    of the examples you give.
  - please get input from other sources and add your reasoning to the HIG.

[Chapter 3: Toolboxes]
  - at least mention why toolboxes should not have titles (width constraints 
?)
    (I personally prefer them to have Titles because it's easier to tell
    them apart when shaded, ahem)
  - ideally find a technical solution for freedesktop.org to supply a special
    titel that can be used by window managers that know about toolboxes.
  - "Toolboxes should have no buttons" very ambigious. Buttons is all most 
    of them have, no ?
  - resizing: what about height ?
  - "... access to a set of actions and ..." isn't ideal in light of your
    warning below that commands buttons should better be placed in toolbars.

[Chapter 3: Toolbox Categories]
  - very nice! the principle of folding sections should be used more widely...

[Chapter 4: Alerts]
  - windows lacking a title are annoying. Have you considered just showing
    the offending applications name so the user can see more clearly what
    tool wants his/her urgent attention ?
    The primary text will catch the user's attention, anyway. Consistently
    showing the application name only in the title for alerts will allow
    users to ignore this section of the window unless it's unclear what
    app caused the alert.
  - Using verbs/phrases has downsides which you should mention: They
    have to be parsed in addition to the suggestion made by the alerts
    text section and may cause horribly long buttons in German (and
    probably other languages, too) So basically verbs/phrases are good if they
    can be kept concise (you mention 3 word limit in later sections) and they 
    involve specific l10n issues.
  - if no action is suggested by the affirmative button, should "Dismiss" or
    "Close" or "Continue" be used instead of "Ok", especially
    for error alerts ? (has this been discussed ?)
  - Has it been considered to use semantic markup rather than explicite Pango
    attributes for primary and secondary text ?

[Chapter 3: Authentication Alerts]
  - mention more explicitely that the affirmative button should be insensitive
    until all needed information has been provided.

[Chapter 3: Spacing in Alerts]
  - The top space is not 12 pixel high in the screenshot
  - Have you considered using symbols rather then explicite pixel
    values (6 and 12), making the transition to high-resolution displays
    a little smoother ? Users on small screens or large PDAs will also
    benefit from a GConf setting for this.
  - It's questionable if the drop-shadow should be counted to be part
    of the icon width.
  - Put "technical details" in an appendix, add short reference here.
  - The error box has wrong spacings ?
  - (Hmm, I have the feeling that the confirmative phrase in example
    3.17 should express "submission of user id/password" rather than "checking
    mail", which has already been initiated (conceptionally or actually,
    depending on technical details only) at this point.)
  - the idea to move to the next input box using return is cool.

[Chapter 3: Dialog Boxes]

  - The above are not "dialog boxes" ?
  - Are my eyes tired or is the outer space > 12 pixels ?

[Chapter 3: Assistents]
  - mention "Assistants (Wizards)"
  - for some applications there is no need to make them app modal, just as
    "File Open" dialogs don't need to be modal in most cases. These only
    have to be made modal if the application has to be in a specific
    state in order for the Assistent or Dialog to be meaningful.
    (But it looks you removed this one anyway)
  - Another possibility to name title bar and title area would be to
    name  the title bar "New Mail Account Assistent" whereas
    the header would read "Create a new mail account". Anyway, nicely
    clarified section.
  - mention the larger space before [Cancel] if it's intentional.
  - is the use of italics intentional and possibly part of some larger scheme,
    e.g. always use italics for explanatory sections (inline documentation)
    in dialogs ?
  - mention that no changes should be applied before the last page, so [back]
    is always possible.

[Chapter 3]
  - Alert: Chapter 3 will explode if a single word is added.[Cancel][Go 
Ahead].
    (Restructure ?)

---

[Chapter 4: Guidelines]
  - "Provide an access key for each menu item [...]" mention the section where
    the term access key is defined.
  - mention that "sensitivity" is defined in chapter ... ?
  - what about menu sections added by components ?
  - what about context menus extended by components or extra services
    provided by loaded components or other special cases ?

[Chapter 4: Popup Menus]
  - maybe have "Help" on top (just an idea) and possibly above the pointer's
    vertical location.
  - not good if Cut, Copy, Paste moves far down in long context menus.
  - There are many cases where submenus are good in context menus, e.g.
    "Open with", "Set Language", ... why not use them where they make sense ?
    (I like pie menus better, anyway)

[Chapter 4: Standard Menus]
  - Maybe mark menus common to almost all applications differnt
    from menus only used by some (such as advanced items like "Save Copy..."
  - Show "Ctrl+Shift" rather then "Shift+Ctrl" since it makes it much 
    easier to scan for relevant information (the added Shift modifier).

[Chapter 4: Standard menus, files]
  - Isolate "Quit" with a separator item for safety.
  - Move "Close" where it belongs: at the bottom of the group containing 
"Open"
    (Or IF you find it more logical: put it at the top of the 2nd section
     like in old Mac applications)
    (Or has this been discussed and decided against ?)
  - Consider renaming "Revert" to "Revert to Saved" like on the old Mac :*)
  - as it was recently suggested and used by OpenView invoking the New menu
    item could trigger creation of the most common Format like Ctrl+N would
    even if multiple Formats or document types were supported. 
  - What's "Properties" doing here? File access privileges, maybe, but not
    content-related things! (I buy "Print" but please not "Document 
    Properties", it's evil ! :)

[Chapter 4: Save Copy ...]
  - Did you consider making this an option of the Save As.. dialog ?
  - maybe the whole thing should be considered in the context of Expot/Import,
    Saving drafts, ... looks a little experimental as it stands.

[Chapter 4: Close]
  - as said above, move it up.

(Have you read the way KDE handles the Close item ? Please convince them
 to follow the GNOME HIG instead :*)

[Chapter 4: Edit]
  - Provide Ctrl+Y as a silent (not advertized) shortcut for convenience in
    addition to "Ctrl+Shift+Z" for Redo.
  - Note that "Undo <my last command>" creates long menu items, too long in
    some languages like German, making the rest of the items harder to use
    because the shortcut string moves far to the right. Consider using a
    tooltip for detailed information instead.
  - Remove the "Preferences" item from the "Edit" menu. It doesn't belong
    here at all! (I can't even believe it was Apple who put it there, must
    have been Netscape)  In this particular case the KDE way is really better
    (though I didn't quite find the Settings vs. Options argument convincing)
    "Preferences" severely violates the spirit of the "Edit" menu!
    I buy your argument that it's convenient, but it's certainly NOT
    suitable.
  - introduce the term "current selection" ?
  - indicate what items are disabled (insensitive) if the current selection
    is empty.
  - mark that "caret" is explained in the glossary.

[Chapter 4: Searching and Replacing]
  - how about highlighting all matching items ?
  - Sure about Ctrl+R for Replace ? Has been used for "Run" and "Reload"
    elsewhere...

[Chapter 4: User Preferences]
  - Provide an "Options" menu (or "Settings", like KDE) see above.
  - Alternative would be an <Application> menu, but I guess this is out
    of questions, don't want to open this can of worms :*)

[Chapter 4: View]
  - In applications where the main view usually doesn't accept keystrokes, 
    +, -, = and/or 1 (without Ctrl) are accepted for zooming, pretty 
    convenient I think.

[Chapter 4: Bookmarks]
  - in KDE Ctrl+B is use to add a bookmaks - ideally make this consistent
    with them.
  - mention and show in the example that a section containing the actual
    bookmarks will usually follow at the bottom of this menu, preceded by a
    separator item.

[Chapter 4: Insert]
  - label the screenshot as "example", rather then "generic".
  - Have you seen the special menu items used by Maya which have
    a left section triggering the default action and a right [...]
    section will show a dialog with more choices ?

[Chapter 4: Windows]
  - I've never quite understood why MicroSoft didn't combine this menu with
    View, but so here it is, sigh.
  - Save All, and Close All (probably) refer to all files, so these items
    should go in the "File" menu, wherease closing _all_ windows would
    actually be the same as selecting "Quit" on anything not beeing a Mac.
    (Ctrl-clicking on the close box of a window will close all windows of the
     app on the Mac, nice feature. Not sure if OS X still does it, the iBook
     is on the road)
  - I don't think labeling the "Windows" menu "Documents" is any good. The
    "Windows" menu is about the container views, not the document entities.
    "Buffers" may be ok for tabbed MDI or emacs-like MDI.

[Chapter 4: Help]

  - Suggestion:

  Help
    Contents    F1
    <other items, like "Tutorial", "Introduction" ... ?>
    --------------------
    About GNOME (and/or about vendor ?)
    About <application name>

---

[Chapter 5: Toolbars]
  - You removed the other examples so only one point left to criticise:
      - having the location bar not seperately has annoyed a lot of mozilla
        users (and Konqueror has this, too, if the window is very wide, sigh).
  - regarding typical browser buttons: It would be cool to use the same
    order between GNOME, mozilla, and KDE. I've always liked
    "home, up, back, forward, reload, stop" but any other consistent
    order should be fine as well!
  - nicely paraphrased in the last three weeks.
  - You mention an "Options->Settings" dialog ?
  (I have some comments on the use of icons with text, but I'll back off
   and present some suggestions in the visual appearance and icons sections
   below)

[Chapter 5: Labels and Tooltips]
  - no access keys: another reason is that showing the text label is optional.
  - "Most controls that appear on your toolbar will require a text label..."
    Hmm, this gives the wrong impression (though it's probably true), rather:
    - Many users, especially new and infrequent user, will benefit from
      text labels.
    - Most controls that appear on your toolbar should not require a text
      label.
  - A funny observation about "priority text" is that text is given to 
    buttons which are used so frequently that the user should find them
    easily without the text, whereas buttons the user doesn't use often
    don't get a text label (so the label needs to be clearly designed).
    This could indicate that the buttons where too small in the first place,
    adding a text label mainly to make the area of the button larger :)
  - Explicitely mention that Undo/Redo will be shown without the
    dynamic portion (And there may be similar cases).

---

[Chapter 6]

---

[Chapter 7]
  - If an application allows multiple lengthy tasks which are carried
    out in the background concurrently and especially if they can be
    interupted individually by the user (file downloads, print jobs,
    searches, ...) external feedback is appropriate unless each
    background task has an associated status bar.
  - In the above case a shared (application internal, but doesn't have
    to be) progress dialog should at least be an option, e.g. the
    well-known print job dialog in Windows or a download manager (I
    assume, never used one myself).

[Chapter 7: Characteristics ...]
  - "They provide enough feedback for users to understand what they are doing"
    They refers to the application but is ambigious when read quickly.

---

[Chapter 8]

---

[Chapter 9]

---

[Chapter 10]

---

[Chapter 11: keyboard navigation]
  - use a color other then red to point to mnemonics and accelerators
    (the lines are a good idea, though)

[Chapter 11: Guidelines]
  - You suggest not to use inline documentation at all. I think it should
    be used sparingly, but it should be clear that if it's used, it better
    followed a common scheme, such as always being marked italic (or marked
    semantically) as suggested in your example for assistants.
  - "when they mouse over": "to mouse" sounds a little strange.
  - make the lists of common translations more prominent
  - mention here and above that capitalization rules are specific to the
    English language or mention that other languages may have different
    capitalization rules.
  - maybe the capitalization rules should be moved here, with a reference
    placed in the layout section.
  - graphical process manager: I think a window showing only those
    processes meaningful to a normal user (applications) like on Mac
    OS 7 would be better then giving no choice but to close the
    largest application (but it's a very specific example anyway).

[Chapter 12]

  - "these ideas may or may not turn out to better than yours": "be" missing

[Chapter 13]

  - no comments :O)

Feel free to forward this mail in whole or in part.

(I'll go over my comments on Chapters 6, 8, 9, 10 and
send them when done, hopefully in a couple of days)

Best regards,
kai