Re: [HIG] Comments on the GNOME 2.0 Human Interface Guidelines

[Gregory Merchan <merchan phys lsu edu>]

On Thu, Jan 03, 2002 at 03:19:54PM -0800, Kathy Fernandes wrote:
> 1.  Recommend that one of the sections in the Introduction address 
> what it means to be "GNOME-compliant."  This term is used in the 
> GNOME User's Guide but not defined there.  I would like to see the 
> HIG provide some general policy statements about what developers need 
> to do if they want to describe themselves as "compliant" with the 
> GNOME style.  When I made a similar comment on a previous draft of 
> the HIG, the response was that "hackers will do what hackers want to 
> do."  Not everyone who uses the HIG will be a hacker; some of us work 
> with developers that will be directed (contractually) in the near 
> future to deliver a "GNOME-compliant style," and it would be helpful 
> if these statements were available for those of us who need them.

As far as I can tell, this will not change. If it does change, it seems
most likely that the change will be the result of a few hackers
making some decision, the rest going along, and someone taking the
time to try to write it down.


> 2. Make Your Applications Consistent
<snip>
 I can't say anything about this.


> 3.  Utility Windows - Why does the list of frame commands for a 
> Property window and a Preferences window include Maximize?  I would 
> expect the normal size of these types of window to be large enough 
> for all of its contents visible without having to resize or maximize. 
> Recommend deleting Maximize from the command lists.

The reason is . . . error. This should be corrected.


> 4.  Alerts - Nonconcur with the guideline that places OK in the 
> bottom right corner of a window (e.g., Confirmation Alert, 
> Authentication Alert) and Cancel to the left of OK.  Users in western 
> locales scan the button row from left to right and expect to 
> encounter the positive actions first.  Users should not have to scan 
> the entire row before finding the "default" or desired action in the 
> window.

I would really like hard data on this. It seems the correct order will
have to be decided by the total time to scan the row and move the mouse
to the default action, or by the time to scan and trigger the default
with the enter key, or by the time to tab through and trigger the
default. If all are considered, I don't know how the times should
be weighted in case of disagreement. Such data would probably not
resolve the particular alignment and ordering should OK be placed
on the left; I do not know what would.


> 5.  Dialogs - What is the difference between a Property window and a 
> Preference window (as described in the section on Utility Windows) 
> and a Property dialog and Preferences dialog (as described in the 
> section on Dialogs)?  If they provide the same basic functionality, 
> why do they have different sets of frame commands?

The principle difference is when the settings are applied. The dialog
version require confirmed application by pressing of OK, Apply, or a
similar button. The others apply when the gui control of the setting
is triggered. E.g., given a preference window with some radio buttons,
toggling a radio button would change the setting; no further action
is required. A preference dialog would require clicking OK or Apply to
change the setting.

The frame commands are different for two reasons. The trivial one is
that I am not sure whether a dialog should be modal to what it applies
and how this affects whether Minimize, Stick and Unstick should be
present. (As acknowledged above, Maximize should be part of neither
and Restore - as a frame command - is merely the counterpart to Maximize.)

The other reason is that a Property or Preference window should not
have the row of buttons that a dialog has because the controls it contains
will immediately affect some other part of the system and presenting
such buttons would confuse users who expect the confirmed behavior of a
dialog. To not confuse users it is recommended that the Close command be
removed from the window frame because it would not be apparent whether
that applies the settings, leaves the settings as they are or returns
them to the state prior to opening the dialog.

However, it seem most likely that the instant-apply windows will have
a button labelled "Close" or "Done". If this is so, then the descriptions
of utility windows should be merged with those of dialogs and the framing
recommendations should not include a Close command because if they do
then two controls to perform the same action would be presented to
the user causing unnecessary hesitation as to which close is the 'right'
one.

> 6.  Labels and Tooltips - Recommend that users be able to turn on and 
> turn off tooltips as desired.

I think this is actually possible already.
I'm not sure of the locus of control.


Cheers,
Gregory Merchan