[HIG] My review, part 2

[Maciej Stachowiak <mjs noisehavoc org>]

This part covers "Dialogs" through "Integrating Applications with the
Desktop". Apologies for it's late arrival. I'll try to cover the
remaining sections in a final installment tomorrow.


Overall comments:

* One more overall comment that came to mind while reviewing these
  chapters: we need more screenshots. We should have screenshots of
  standard controls and dialogs (essential), and screenshots that show
  examples of general suggestions (optional).


Dialogs chapter:

* The definition of dialog boxes doesn't seem to capture their essence
  and distinction from other windows very well (dialog vs. utility
  window). I think we need a chapter on Windows to address this.

* types of Dialog boxes: the subsections of this section are not
  parallel. Druids and informational dialogs are not alternatives to
  modal and modeless dialogs. Split off modal vs. modeless from
  discussion of semantic dialog types.

* We should explain when it is appropriate to use a modal dialog
  (examples: error alert, save dialog)

* Do we want a distinction between application modal and document
  modal dialogs?

* The section on Information Dialogs implies that such dialogs are
  appropriate, whereas they should be strongly discouraged. A dialog
  is usually not useful unless it lets you make a choice. One possible
  exception is alert dialogs.

* The section on Druids should say more about when they are
  appropriate, and provide advice for designing them well. (Limit the
  number of steps, put steps in a logical order, don't mix unrelated
  steps on one page, etc). Should also discuss special aspects of
  buttons (previous, next, finish, etc) for druids.

* We should have a section specifically discussing alert dialogs.

* Other special kinds of dialogs worthy of discussion include
  preference dialogs and object property/style dialogs.

* Dialog box layout: this section is nearly content-free. We should
  either point to the layout chapter or provide specific advice on
  laying out controls in dialogs.

* Dialog box behavior: we should take a more specific stance on
  instant vs. deferred application of changes.

* Dialog box buttons: this section does not correspond very well with
  the existing button order proposal. Move we strike it and replace
  with button order proposal, with perhaps slight adjustments to
  it. The distincion between "Action" and "Closing" buttons is not
  very clear in my mind, given that some action buttons will also
  close the dialog. We should just say that the positive response /
  primary action should be farthest on the right, negative response to
  the left, alternative action to the left of that after a space, and
  help button leftmost with a space. This is assuming we want the
  Mac-like button order.

* We should consider whether switching to mac-like button order is
  wise, given the likelihood that non-GNOME2 apps (KDE, Java, GNOME1,
  legacy X) will be running on the desktop.

* Dialog window titles / standard dialogs: we shouldn't necessarily
  put the app or document name first in the dialog title or even
  always have it. Putting it first is particularly bad since window
  titles in the task list are truncated at the beginning. 

* It might be a good idea to make dialog titles match the command that
  opened the dialog, if it was launched by one.

* We should suggest putting default values for widgets in a dialog
  wherever possible (for example, an authentication dialog should have
  a reasonable choice for username already filled in).

* Text in a dialog should be selectable (and of course copyable)
  whenever it would be useful (error text in an alert for
  instance). (Note: does Gtk provide selectable labels?)

* We need to discuss when error checking of fields should happen (and
  suggest that the best choice is to make it impossible to enter a
  "wrong" value, of course, but this is not always possible).

* We should specifically describe behavior when quitting or closing
  with unsaved changes (exactly what the dialog should look like and
  what actions should result from the various buttons). Heck, the Save
  Changes dialog deserves to be a standard dialog as much as alerts
  and file open / save dialogs. We might also want to define special
  behavior when quitting or closing all and multiple documents ar
  eunsaved.

* We should talk about standard print/print setup dialogs.

* We should talk about dialogs for choosing the file target of an
  action that is neither opening nor saving.

Controls chapter:

* What about single-line text entries?
* What about multi-line text fields?
* What about labels?
* What about lists / trees / multi-column variants / etc ?
* What about notebooks?
* What about groups?
* what about spinboxes?
* what about sliders?
* what about scrollbars?
* what about color / font / file entries?
* What about paned widgets (separators)?

* it bears repeting again: we need screenshots of all of these. Also
possibly suggested size and spacing metrics.

* progress bar: we should mention that a determinate progress bar
  should always get all the way to the end if the task completes
  normally.

* maybe status bar section belongs w/ menus and toolbars. Should
  describe appropriate status bar use a bit more.

* We should talk a bit about custom controls (don't reuse the same
  element for different behavior, instead create a new element; how to
  make custom controls themable, localizable and accessible; etc)

Layout chapter:

* Label positioning: The label section is not very clear to me.

* Aesthetics: let's say "interface" instead of "GUI"

* Grouping and separators: let's give some advice (maybe example
  layouts?) on when to use group boxes and when to use
  separators. Does Gtk+ allow for labeled horizontal separators (I
  guess you can use a label and a separator in an hbox)? These can be
  useful substitutes for group boxes to reduce visual clutter.

* Fonts and text: we should mention respecting the system font, and
  suggest making other font sizes relative to the standard font size.

* Capitalization: this belongs in a chapter on language.

* Captialization: suggest calling it Title style, not Book.

* Color and contrast: this section belonds in the controls chapter
  IMO.

* The color use example is poor, I have a harder time reading the
  second "better" version.

* We should talk about compatibility with theming in contexts other
  than just visually impaired users, and point to technical advice on
  how to get theme-compatible colors.


Integrating applications with the desktop chapter:

* Icons: this should be a separate chapter, it applies to other use of
  icons in the UI too (toolbar buttons, menu icons, button icons,
  alert dialog icons, etc etc).

* Menu Entry Captions: suggest changing this to the now-preferred
  "Nautilus File Manager" style instead of "File Manager (Nautilus)".

* Menu Entry Tooltips: lets give examples for a word processor and a
  spreadsheet to show examples for "big" apps.

* The technical details on integrating your app with the desktop
  should be in a separate document; the HIG should simply point to the
  relevant documentation and describe the effects we want to see, not
  the mechanism. 

* This separate document should cover .mime, .keys, .application and
  .desktop files, and should apologize for .desktop and .application
  files being different.

* The separate document should _not_ suggest installing a .mime or
  .keys file for mime types already defined by the system, only for
  custom app-specific ones. In particular, gnome-vfs already defines
  all the intersting info for text/html.

* We may want to add comments here about special ways of integrating
  with the destkop: panel applets, control center panels, and nautilus
  views.

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