[HIG] Critique on the HIG draft

[Sebastian Rittau <srittau jroger in-berlin de>]

Hi!

I want to introduce me shortly: I'm a third grade CS student with
Psychology as second subject. From that you may infer that I'm quite
interested in the HI aspect of software, but I will also warn you that
my experience on that sector is currently limited to a user's or
programmer's point of view. My opinions are therefore only personal and
not based on a scientific background.

Please Cc me when you respond, since I'm not subscribed to the HIG mailing
list.

First of all, I think it's great that an effort is made to produce a new
HI guidelines document for Gnome. This is the foundation for an
integrated, polished, and consistent desktop environment. What is
already there looks very good. Nevertheless, I have some points of
criticism.

Just some general criticism at the beginning: At the web-site of the
usability project, I didn't find any hint on where to get the (DocBook?)
source of the HID, or its CVS repository. I would have liked to comment
on the latest CVS version, but couldn't.

Since I used the PS version, I couldn't copy & paste from the document
and I may have introduced typos that are not in the original text. Also,
please add a "IMO" mentally to each of my comments below.

One thing I noticed is that GNOME/Gnome is spelled inconsistently. In
the first chapter it's called Gnome, while in the second chapter it's
called GNOME.

Chapter 1
=========

> These guidelines are meant to help you write applications that are
> easy and consistent with the Gnome desktop. Following thse guidelines will
                                                        ^^^^
> have many benefits:

Chapter 2
=========

Very well done IMO.

2.2.2. A small inconsistency:

> GNOME has excellent support for both internationalization (also
> referred to as i18n) and localization (also referred to as L10n).
                 ^^^^                                        ^^^^
2.5. This section mentions that feedback "can be visual, audio, or
both". But audible feedback should always have a visual alternative as
well. (Think of deaf users or systems/environments without sound
capabilities.) This should be mentioned is this section as well.

Chapter 3
=========

3.1. The Menu Categories

There should be an explanation of the categories:

  * Internet
    [I would actually call this Communications - this would broaden this
     category so that things like gfax could be put here, too.]
    "This category consists of end-user application for Internet-use (web
    browsers, chat programs, e-mail, etc.), and other communications
    programs (like Fax applications)."
  * Multimedia
    [Multimedia is a really bad word. What does Multimedia consist of?
     Why are music programs and video programs multimedia, but graphics
     programs not? Maybe this should be called something like "Sound and
     Video"?]
  * Office
    [I don't like the term "office" for software, but that's probably a
     personal feat.]
    Applications which are typical for in-office use like word
    processors, spreadsheets, or accounting software belong in this
    category.
  * Graphics
    [Currenty, gnome-gv is in this category. I think it's misplaced,
     since it's more of a "document viewer" than a "graphics viewer".]
    This category consists of software for viewing and manipulating
    computer graphics.
  * Utilities
    Various small tools and utilities that can be used for very specific
    tasks. On the one hand this consists of programs for tasks that are
    computer-specific (but are not for system administration), like file
    browsers, file finding utilities, floppy formatters, or bug reporting
    software. On the other hand in contains small tools that are used to
    support your work on the computer, like calculators, to-do lists, or
    dictionaries.
  * Development Tools
    [Why the emphasis on tools? It wasn't called Graphics Tools or
     Internet Tools either.]
    Software in this section is used in software development and
    programming. It consists of IDEs, compilers, debuggers, or project
    managament applications.
  * Games
    Small and large games and fun programs.
  * System
    ["System" is not very clear to me. What about "Administration" or even
     "System Administration"?]
    This section consists of programs and applications that are used for
    system administration. On most systems and configurations, these
    programs are only meaningful to the root user.

I would maybe suggest an additional "Viewers" category for stuff like
gnome-gv, eog, xdvi, etc.

In the following two sections on Menu Entry Captions and Tooltips, there
should be a reference to the capitalization rules later in the document.

3.1.1. Menu Entry Captions

> Menu entries require captions (or "names" as the panel calls them)

We should settle on one name. Either it's "captions" or "names", but not
one here and something other somewhere else. If the panel calls them
"names", the panel should be changed.

> [Captions should be "APPLICATION TYPE (APPLICATION NAME)"]

I think this is a very important point. Why should a user know what a
"Nautilus" is?

> ... for an application to fufill the concept ...
                            ^^^^^^
			    Typo.

> Example 3-6: A caption for AisleRiot: AisleRiot

I think this is a bad example since AisleRiot belongs in the more
general class of solitaire games. ("Patiencen" these card-based solitaire
games are called in German - is there an English equivalent?) Hence, it
should be:

  Solitaire Game (AisleRiot)

I would instead suggest using a game like Gnobots as example:

  Example 3-6: A caption for GnobotsII: GnobotsII

> If possible, it is better to remove explicit mention of GNOME or
> X-Windows ...

Oooh. X(7) says:

|        The X Consortium requests that the following names be used
|        when referring to this software:
| 
|                                    X
|                             X Window System
|                               X Version 11
|                       X Window System, Version 11
|                                   X11

"X-Windows" is just terrible and reminds of a certain OS. The point is valid, though.

Following this section are two more examples, which look out of place here.
Maybe, some bad examples with "platform details" should be listed,
instead.

3.2. Providing a Connection between Documents & Applications

The paragraph "The Application & MIME database ..." exists twice.

Chapter 4
=========

4.1. Names

Names are titles, aren't they? I needed a moment to understand the term
"name" in this context. The term "title" should be at least mentioned in
this section. "All top-level windows must have names, also called 'titles'."

> The name must have the proper name of the application and an
> identification of the window's purpose or content.

If the application name must be in *every* window title, a specific
format like "APPNAME: PURPOSE" should be stated. If it's not, we will
end up with titles like:

 * Nautilus: /home
 * Homepage of Foo Bar, Inc. [Galeon]
 * MyApp's Main Window

4.8.1. Informational Alerts

> The button will be placed in the bottom right corner of the alert.

This is different to all other guidelines, I know of. Normally, dialogs
with only a confirmational button, place it in the middle of the button
bar. Is there any good reason to change this?

4.8.1. Informational Alerts

> The button will be placed in the bottom right corner of the alert.

This is different to all other guidelines, I know of. Normally, dialogs
with only a confirmational button, place it in the middle of the button
bar. Is there any good reason to change this?

4.8.1. Informational Alerts

> The button will be placed in the bottom right corner of the alert.

This is different to all other guidelines, I know of. Normally, dialogs
with only a confirmational button, place it in the middle of the button
bar. Is there any good reason to change this?

4.8.1. Informational Alerts

> The button will be placed in the bottom right corner of the alert.

This is different to all other guidelines, I know of. Normally, dialogs
with only a confirmational button, place it in the middle of the button
bar. Is there any good reason to change this?

4.8.1. Informational Alerts

> The button will be placed in the bottom right corner of the alert.

This is different to all other guidelines, I know of. Normally, dialogs
with only a confirmational button, place it in the middle of the button
bar. Is there any good reason to change this?

4.8.1. Informational Alerts

> The button will be placed in the bottom right corner of the alert.

This is different to all other guidelines, I know of. Normally, dialogs
with only a confirmational button, place it in the middle of the button
bar. Is there any good reason to change this?

4.8.1. Informational Alerts

> The button will be placed in the bottom right corner of the alert.

This is different to all other guidelines, I know of. Normally, dialogs
with only a confirmational button, place it in the middle of the button
bar. Is there any good reason to change this?

4.8.1. Informational Alerts

> The button will be placed in the bottom right corner of the alert.

This is different to all other guidelines, I know of. Normally, dialogs
with only a confirmational button, place it in the middle of the button
bar. Is there any good reason to change this?

4.8.1. Informational Alerts

> The button will be placed in the bottom right corner of the alert.

This is different to all other guidelines, I know of. Normally, dialogs
with only a confirmational button, place it in the middle of the button
bar. Is there any good reason to change this?

4.8.1. Informational Alerts

> The button will be placed in the bottom right corner of the alert.

This is different to all other guidelines, I know of. Normally, dialogs
with only a confirmational button, place it in the middle of the button
bar. Is there any good reason to change this?

4.8.1. Informational Alerts

> The button will be placed in the bottom right corner of the alert.

This is different to all other guidelines, I know of. Normally, dialogs
with only a confirmational button, place it in the middle of the button
bar. Is there any good reason to change this?

4.8.1. Informational Alerts

> The button will be placed in the bottom right corner of the alert.

This is different to all other guidelines, I know of. Normally, dialogs
with only a confirmational button, place it in the middle of the button
bar. Is there any good reason to change this?

4.8.1. Informational Alerts

> The button will be placed in the bottom right corner of the alert.

This is different to all other guidelines, I know of. Normally, dialogs
with only a confirmational button, place it in the middle of the button
bar. Is there any good reason to change this?

4.8.3. Alert Buttons

> Affirmative Button. The affirmative button should be placed in the
> lower right corner of the altert.

Again, this is different to most other implementations (except as it
seems MacOS X), including nearly all X and Gnome applications, I know
of. Changing this will lead to a lot of confusion. Also, I don't see the
point in changing it.

> Negative Button. The negative button should be placed immediatly to
> the left of the affirmative buttons.

This is also dangerous. It is better to spread the affirmative and the
negative button as far apart as possible to avoid clicks on the wrong
one. Think accesibility!

> Help Button.

I would propose, not placing the help button in the button bar, at all.
It's function is quite different to all other buttons, which will
dismiss the alert and force a reaction. IMO, a help button belongs in
the upper part of an alert.

> Alternate Actions

Should be placed between affirmative and negative button, in order of
their "negativeness" or "affirmativeness".

The "Save confirmation alert" shows how unintuitive the new button order
is: I'm used to click on the left-most button to confirm a "quit without
save". Instead I will be thrown back into the application. If I click on
the right-most button, I would like to cancel quitting the application.
It does the opposite.

Also, the buttons are very confusing:

| Don't Quit | Don't Save | Save |

"Don't Quit" will bring me back to application. Will it save my changes.
Probably not. What does "Don't Save" and "Save" do? Well, they will
save/not save my changes. And then? Will I'll be back in the application
or will the application quit? *I* know what these buttons are supposed
to do, since I've got enough experience with computers, but it will
confuse people. (Also, looking at the existing buttons, you may ask
yourself where the "Quit" button is. All other combinations exist as
well.)

4.10. Assistants

> An assistant is an application modal secondary window ...

Huh? What is a "secondary window". And does "application modal" mean
the same the "local mode" from 4.3?

5.1.2. Popup menus
            ^
	    M

It should be mentioned that there should always be some kind of
indication that a popup menu is available.

5.2. Menu Organisation

> Menus and menu items should not appear or disappear while the
> application is running.

There are exceptions to that rule, like the list of "recently opened
files" or window lists (or for that matter, any kind of dynamic list of
things).

5.7. Standard Menus

> There are a number of standard drop-down menus for common operations.

This could be read as if these menus must exist in every application.

5.7.1.3. Quitting

> Quit
>   [...]
>   Save All should behave like the File|Save command ...

> Close All
>   [...]
>   Save All should behave like the File --> Save command ...

Inconsistent. It seems the latter form is used in other places, too.

Chapter 6
=========

Fine.

Chapter 7
=========

Fine.

Chapter 8
=========

8.1. Order and Relationships

> Labels should be placed either above or to the left of the controls
> they relate to.

Following this sentence are four example label placements. One of the
below the control, one of the right of the element. Also, I don't agree
that the label should always be at the left of the control. It should be
vice versa for radio and check buttons.

Chapter 9
=========

Fine.

Chapter 10
==========

10.1.1. Mouse Buttons

> Actions are not assigned exclusively to the middle button of a
> three-button mous: not all mice have one.

This holds also true for the right button. Mac mice have only one
button. Also, it's mentioned a little above this quote that some
assistive technologies emulate only one button, too.

Chapter 11
==========

I like this chapter, but I would suggest moving it to the front of the
document, near chapter 2, as they are somewhat related.

11.2.2. Internationalization and Localization

> If you intend your application to be translated into different
> languages, ...

Every Gnome application should be translated into different languages.
i18n should be an important goal im Gnome.

Regards,

 - Sebastian