[HIG] HIG Review

[Sebastian Rittau <rittau math TU-Berlin DE>]

This is another quick review of the HIG, version 1.0. Great work, everybody!
It seems that the main flaws noted in previous versions have all been
fixed.

Introduction
============

This is still a very nice chapter. I like it.

"Your application will continue to look good when users change desktop
 themes, fonts and colors."
              ^
              ,

"The recommendations here build on design aspects that have worked well in
 other systems, including Mac OS, Windows, Java and KDE. ..."
                                               ^
                                               ,

Accessibility
-------------

Mention the abbreviation a11y like you do in the I18n and L10n section.

Desktop Integration
===================

"There are two elements to basic integration with the user environment of
 the GNOME Desktop."

This is a very generic sentence. IMO there's much more to the "integration
with the user environment of the GNOME desktop" than just how to start the
application. Maybe something like this is more appropriate:

"There are at least to basic ways to make an application available
 from the GNOME Desktop."

Menu Item Names
---------------

I like the change from the old "Function (Name)" recommendation to
"Name Function", e.g. "File Manager (Nautilus)" -> "Nautilus File
Manager".

Menu Item Tooltips
------------------

Maybe it should be mentioned that the application name should not be
repeated in the tool tip. (As a guideline.) Also it could be mentioned
that the "sentence style" (i.e. upper-case first letter, no final
period) should be used.

Mapping Document Types to Applications
--------------------------------------

"This is the mechanism by which Nautilus, Evolution and other applications..."
                                                   ^
                                                   ,

"It is important for users to be able to double-click on documents they see
 on the desktop..."

Double-clicking is not the only of opening files. Depending on the setting,
a single click is enough. Also you can use the "Open" menu item. Clarify
this.

Windows
=======

Focus
-----

Another comma: ", or other input device."

"The focused window is considered the window the user is currently "working
 with"."

-> "considered to be"

Title
-----

"In a "beta" product, where version numbers are critical for bug information,
 placing version numbers can be useful..."

Not really... If a user needs it he/she can still choose to use the about
box. This is especially, since in the FS/OS community many "beta version"
are used on a regular basis in production environments.

Controlled Single Document Interface (CSDI)
-------------------------------------------

"The primary exception to this is an application that must handle large
 numbers of small images well."

Huh? What small images? Maybe "... are applications that must handle many
open documents at the same time." is what is meant? Please elaborate this
a bit so that application programmers can choose if a CSDI is appropriate
for their application.

Multiple Document Interface (MDI)
---------------------------------

"MDI has several inherent usability problems, ..."

Please elaborate this point in the HIG, so that application programmers
can decide why MD interfaces are bad.

Also I have to admit that the addition of MDI interfaces to web browsers
or the GNOME Terminal have improved usability a lot for me. Work is now
much more comfortable.

Dialogs
-------

Nearly all dialog screenshots and descriptions are missing the help
button! (See http://bugzilla.gnome.org/show_bug.cgi?id=75678)

Also an (optional) Revert button can make sense.

Instant apply and explicit apply
--------------------------------

Explicit apply cancel button: Should this button close the window or
not? Use Revert instead to be consistent with instant apply windows?

Toolboxes
---------

"Toolboxes have no title"

That's ugly and can be confusing in the window list. I suggest a title
of "Application Name Toolbox". Exceptions are toolboxes that are not
part of an CSD interface.

"... such as Save and open."
                      ^
Space and Positioning Inside Alerts
-----------------------------------

This is overkill! I will lobby for markup support in GtkMessageDialog.
This should be enough.

"Secondary Text. If you close without saving, changes from the last Time
 Period will be discarded"

The sentence doesn't end in a period. (While the text in the image does.)
Also, I don't think it's a good idea to mandate application programmers
to store the time since the last write.

Menus
=====

"Do not have menus with less than three items on them ..."

Maybe add a word or two about dynamic menus (i.e. menus that change
their contents dynamically, depending on stuff like recently used files
etc.)

Drop-down menus
---------------

"Do not add or remove individual menu items while the application is
 running..."

Again, a word or two about dynamic menus would be nice.

Submenus
--------

"Do not nest submenus within submenus."

Make an exception for user-generated menus, e.g. bookmark menus.

Popup Menus
-----------

"Provide a popup menu for every object, selectable part, and text input
 target such as entry fields."

You are kidding, right? That would mean that I would even need popup
menus for ordinary checkbox widget, even if there is no need for a
menu.

"default action for object"

Maybe this should be printed in bold like Windows does it?

"... and do not use submenus."

I see good application for submenus in popup menus. Just have a look
at Nautilus: "Open with >"

Command Items
-------------

"Label the menu item with a trailing ellipsis ("...") only if the command
 requires further input ..."

Either remove the "only" or make it "if and only if". With the current
wording the ellipsis is optional. ("You can make an ellipsis if you want
in these cases, but you don't have to.") This is bad for consistency.

Mutable Command Items
---------------------

"For example, View->Reload in a browser may change to Stop to allow the
 user to interrupt the operation if it is taking a long time."

Bad example. Normally the Reload button remains useful, even if the page
is currently loading. "Try again, you foolish browser."

Checkbox Items
--------------

Please redo the screenshot. It doesn't match the theme of all the others.

Revert
------

"Present the user with a warning that all changes will be lost, and offer
 the option of cancelling before reloading the file."

... if the document has changed since the last load.

Quit
----

"If there are unsaved changes in any open documents, present the user with
 a confirmation alert for each affected document."

This can be a lot of dialogs. Isn't it better to have a single dialog
like this:

   There are unsaved changes in the following documents:
     * foo
     * bar
     * baz
   These will be lost if you quit now.

                      [Save and Quit] [Cancel] [Quit]

Undo
----

"Note: provide a separate Undo and Redo menu item even if your application
 only supports one level of undo."

"Multiple levels of undo are recommended, though."

Paste
-----

"If there is no current selection, use the caret as the insertion point."

caret = cursor?

Find
----

Shouldn't that be "Find..." There is more input necessary, after all.
(The item to find.)

Sort By...
----------

Please do also permit the use of a sub-menu, e.g.:

Sort By >
  Family Name
  Given Name
  Birthday

This is often easier and quicker than a separate dialog.

Insert
------

Again: caret = cursor?

Graph...
--------

"using the current selection as an indication of which values, axis
 labels and data labels to use."
       ^
       ,