[no subject]

Should be "From File..." I guess (uppercase I).

"Do not pop up a dialog asking for a title or location for the bookmark,
 instead choose sensible defaults"

Of course there should be some kind of feedback to the user that the
bookmark has been added.

Help
----

Maybe mention that it can be a good idea to add direct links to some
frequently read help items, e.g.:

Help
  Contents
  Important Stuff
  More Stuff
  ---------------
  About

Toolbars
========

"Don't add buttons for Help, Close or Quit ..."
                                  ^
                                  ,

"return the icon/text/both status for all toolbars in your applicaton to
 the system default"

There's really no need for that. It's a simple, straight-forward setting.
No need to clutter the UI with one more button.

"choose to show text labels either to the side of some or below all toolbar
 icons, and to return this setting to the system default"

Ditto.

Controls
========

"As a further safeguard, remember not to set the default button in a dialog
 until the minimum amount of required information has been entered,"

Isn't it better to disable the default button in this case?

Option Menus
------------

"Assign an access key to every option menu item. Ensure each access key is
 unique within the enclosing window or dialog, not just within the menu."

This would eat up the available access key quite quickly and is normally
not feasible. Just imagine two option menus with 10 entries, each!

Work out the differences between Option Menus and Combo Boxes. E.g.

 * Option Menus should not have for than about ten entries, Combo
   boxes can.
 * Option Menus are normally used for fixed lists, while Combo Boxes
   often have changeable lists.
 * Combo Boxes invite the user to add their own entry to the list
   (although this is not always possible).

Lists
-----

Figure 6.20 seems to be missing.

"For multiple selection lists, show the number of items currently selected
 in a static text label below the list, for example, Names selected: 3.
 Such a label also makes it more obvious that multiple selection is possible."

This costs space and is rarely useful. Make that a suggestion

Trees
-----

Figure 6.22 seems to be missing.

s.a.

Feedback
========

Good.

Visual Design
=============

Instead of giving fixed pixel sizes, recommend the use of the GNOME_PAD
macro family.

Icons
=====

My pet peeve: "... that the user associates with a particular object, state
 or operation."
^
,

Kinds of Icons
--------------

I wonder why document icons like the PGP icons used as an example are said
to have a "table perspective". I would expect then to point away from me
in this case and form a trapezoid.

Application Icons
-----------------

Add a note that the application's logo should not be the dominant feature
of the icons. As a bad example see the Mozilla logo that's often used as
icon for the browser. How many users that don't know about Mozilla or
don't understand the pun on Godzilla will be able to discern the icon
as belonging to a web browser? Many users could even be deterred by such
a monster icon.

I just noticed that this is pointed out later in detail (name suggestive
icons), but I think a small hint here is justified as well.

Suggested Design Process For Toolbar and Menu Icons
---------------------------------------------------

Great section! But I would recommend to split it out into a separate
document (maybe combining it with existing icon tutorials) and put a
link into the HIG. I think there should be a clear distinction between
the HIG as a normative and descriptive document and more "technical"
documents. Especially in the light that we would like other communities
like KDE to endorse the HIG. (This was a general rant about other
technical section in this document as well.)

Figure 9.11. A better icon for the Font Selector
------------------------------------------------

I would recommend using two uppercase A's rendered in different fonts
instead of one upper- and one lower-case A. This would make the point
clearer that there are different Fonts. The currently suggested icons
could mean anything text-related.

User Input
==========

"Do not require the use of multiple (triple- or quadruple-) clicking
 actions for any operations, unless you also provide an accessible
 alternative method of performing the same action."

And do not require the double-clicking of either the middle or the
right mouse button.

Language
========

Controls
--------

"Clear, consistent and concise ..."
                  ^
                  ,

"Do not include text in windows that describes how to use the interface,
 for example You can install a new theme by dropping it here. As well as
 adding visual clutter, descriptive labels can also conflict with
 information provided in documentation."

I don't understand this point. Why could such labels conflict with
information from the documentation. This is then either a bug in the
documentation or the UI. And visual clutter is IMO much less of a
problem that a well-explained and understandable interface.

Checklists
==========

Theming, Colors and Contrast
----------------------------

Missing comma, missing comma!



That's it for now. I just want to emphasize again that I think the the
1.0 version as released is a very good piece of work and I hope that it
keeps improving in the future.

 - Sebastian