[HIG] My review, part 1

[Maciej Stachowiak <mjs noisehavoc org>]

This includes overall comments and comments on the introduction and
menus & toolbars sections. I'll try to write up comments on the other
parts ASAP. I apologize for the poor writing, this was hastily
written.



Part 1:

Overall comments, Introduction, menus and toolbars


I wrote this review while reading the HIG draft [1] as well as the
corresponding sections of the Aqua HIG [2], the MacOS 8 HIG [3], the
Macintosh HIG [4], the Java L&FDG [5], the Microsoft OGUIDD [6], and
Michael Thomas's completely separete UI guidelines draft [7].


Overall strucure and style

* Let's take "Mini" out of the title.

* Logically, the sections on Controls and Layout belong before the
  sections on Dialogs and Menus and Toolbars.

* It seems like it would be useful to have a general secion on
  "Windows" covering usage of top-level windows.

* It would be useful to cover visual style a bit. Maybe we can get
  Tuomas to write up something on how to get icons to fit with the
  GNOME visual style and combine that with the section on icons from
  "Integrating Applications with the Desktop" and make that an "Icons"
  chapter (the app icon is really not specific to just the menu).

* Custom widgets - we should have some advice for people who write
  custom widgets because the standard ones do not cover their needs
  (this will always be the case sometimes - nuts to
  Havoc). Specifically, we should cover how to make custom widgets
  work right with theming, internationalization, and accessibility (I
  think the answers are: use the gtk_paint_* routines; use pango; and
  use atk plus provide keybindings respectively). This section could
  also have some advice on proper use of metaphor in custom controls
  and consistency with the standard ones.

* We should have a separate section covering general design
  principles. Check out the Aqua HIG [2] for an example that is short and
  sweet, but covers general principles very well. And/or incorporate
  some from Matthew Thomas's guidelines[7].
  
* Some of the language is too vague and overly wordy. Keep it concise,
  specific, and on point.

Intorduction

* See my proposed alternate introduction.

Menus and Toolbars

* Consinder splitting sections on menus and toolbars.

* General principles to add: 

  ** Try to limit the number of top-level menus and number of items in
     a menu (I'd avoid a specific number since that can lead to
     usability problems from jumping through hoops to meet the
     requirement).

* drow-down menus: these are provided by a window, not an
  application. There should be guidance as to what kinds of windows
  should have menus (dialogs - probably not; main application windows
  for document-oriented applications - yes). Addding a "Windows"
  section may help with this.

* Let's refer to "popup menus" as "contextual menus" instead like most
  other systems (maybe we can fix this in the GDP word list too).

* Menu organization: generally items should be oranized from most
  commonly used to least common, but grouping related items supersedes
  this.

* Submenus: no nested submenus

* Submenus: submenus should be used when there is a set of related but
  infrequently used commands or when commands start with a common word
  or phrase.

* Naming Conventions: Menus (as opposed to menu items) should be named
  with a word or short phrase that best conveys the kinds of actions
  in the menu or the objects they act on (so it may be a verb phrase
  or a noun phrase).

* Naming conventions: menu items may form a verb phrase with the
  parent menu name rather than being themselves a verb phrase (for
  example Edit > Preferences... or View > Show > Toolbar). Attribute
  menu items may be a noun phrase instead of an adjective phrase.

* Naming conventions: Menu and menu item names should use title caps.

* Standard menus: Should File be present for applications that don't
  do anything file-related? (Not sure how common this is).

* Standard menus: what about these commonly seen menu names: "Windows"
  "Window" "Game", "Settings", "Preferences", "Insert" "Format"
  "Tools", "Bookmarks", "View", "Go". We should pick the preferred
  names out of similar alternatives and describe what sort of items
  should go in such menus (not necessarily in detail).

* File menu: "Close Window" or "Close", not "Close docname" IMO. Also
  this item should be next to "Close all" and "Quit".

* File menu: "Quit" not "Quit appname". app name there is noise and
  hinders visual recognition of the item while adding no useful info.

* What if there's more than one kind of New item to create?

* Print Preview: this shouldn't be necessary if the app is truly
  WYSIWYG

* Edit: should cut/copy/paste say what item(s) they will
  cut/copy/paste? As in "Copy text", "Paste files", "Cut image".

* Edit: what about "Find Again"?

* Edit: I don't think the "Select None" item is needed. It's trivial
  to deselect the currently selected items most of the time with
  either mouse or keyboard, so this just clutters the menu.

* Options: The standard way to reach the preferences dialog should be
  via "Edit > Preferences...". If an app has other preferences
  settings, it should have a "Preferences" menu with "Edit
  Preferences..." bringing up the main preference dialog.

* Toolbars: are labels to the side of items OK?

* Toolbars: is having labels for only some items OK?

* Toolbars: suggest title caps for item names, but sentence caps for
  tooltips.

* Toolbars (Suggestions): I don't think it's a good idea to suggest
  more than one kind of standard toolbar.

* Toolbar buttons: we should define one standard size, not two.

* Toolbar icons: Ideally, the rules for all kinds of icons should be
  in a separate Icons section (covering both app icons and toolbar and
  other UI icons).

* Toolbar menu: This seems like overkill. Specific suggestions:

   ** Show / Hide Toolbar doesn't need to be in a submenu if there is
      only one toolbar. Even for 2 or 3 putting then in the View menu
      is fine.

   ** Showing text / icons / both should be in the applications's
      Preferences dialog or in the control center, not in a menu.

   ** "Customize Toolbar..." can also be in the top level of the View
      menu. We should talk about the preferred UI for customizing the
      toolbar. I like the MacOS X way where you can drag items from a 
      palette onto the toolbar. (The choice of text vs. icons vs both
      is on the same dialog, which makes sense to me).

* Toolbar layout [office apps] - suggest dropping Help (redundant with
  the Help menu, clutters toolbar).

* Toolbar layout [browser apps]: suggest this layout (reload looks
  wrong between Home and some random navigation button). Alternately
  REload could be right before Stop.

  [Back][Forward][Other Navigation][Reload]-[Home][OtherAppSpecific]-[Stop]



References:

[1] The GNOME 2.0 Mini Human Interface Guidelines
http://developer.gnome.org/projects/gup/hig/menus-toolbars.html

[2] Aqua Human Interface Guidelines -
http://developer.apple.com/techpubs/macosx/Essentials/AquaHIGuidelines/index.html

[3] Mac OS 8 Human Interface Guidelines -
http://developer.apple.com/techpubs/mac/HIGOS8Guide/thig-2.html

[4] Macintosh Human Interface Guidelines -
http://developer.apple.com/techpubs/mac/HIGuidelines/HIGuidelines-2.html

[5] Java Look and Feel Design Guidelines -
http://java.sun.com/products/jlf/ed1/dg/index.htm

[6] Microsoft Official Guidelines for User Interface Developers and
Designers -
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwue/html/ch00b.asp

[7] Improving GNOME 2.0 for Humans -
http://geocities.com/mpt_nz/ig2h.html