[HIG] Gnome HIG mini-guidelines outline

[Adam Elman <aelman users sourceforge net>]

Hey folks --

OK.  Here's a proposed outline for the mini-guidelines.  All is still 
open for discussion, I would say, but we should probably think about 
deciding by, say, early next week (say, Tuesday the 14th?) on a 
preliminary set of essential and optional guidelines to include.  If 
that's okay with everybody I'll also put together a calendar and post 
that within the next couple of days.

We need to decide which of these are optional and which essential.

I'm also trying to incorporate some of the accessibility guidelines 
in this outline.  Finally, except where obvious, I don't have any 
real basis for the order of sections here, so that's also open (but 
let's not spend too much time on it :).

Gregory, could you post URLs for the UI hit squad report and any 
other relevant guidelines you think we should adapt?

Think about which sections you might want to take primary 
responsibility for (I'd prefer #1 and #2, personally :).

1. Introduction: "Why we care about usability (and so should you)"
   I have an idea for this in my head, and will write it in the next 
week or so and post it here.  If y'all don't like it, we don't have 
to include it. :)

2. General interaction guidelines
   These are some basic design principles (if you want to debate 
these, please start a separate thread :), such as:
   * Respect the user: never make them feel stupid
   * Don't miss the forest for the trees: remember that the user is 
using your app in a context
   * Take responsibility for dangerous actions: rather than having an 
"Are you sure" dialog, make actions undoable.  (This might conflict 
with Calum's "prevent users from doing the wrong thing" principle; 
I'd be happy to debate that separately).
   * Don't ask the user for more (or less) information than you need
   * Don't provide the user with more (or less) information than they need
    * Provide feedback for all operations:success, failure, and 
progress on lengthy ops
   * Allow restoring default settings
   * Any other principles we think of, including some or all from Calum's GAG

3. Controls and Layout (I'm not sure that "aesthetics" is the term we 
want to refer to colors/fonts, but it might be the best one)
    * When to use which controls
    * How to lay them out
       - How to indicate that a group of controls is related
       - When to use tabbed pages
       - How to use labels.
       - Colours and fonts.
       - etc.

4. Dialogs -- let's just start with Colin's doc on this.

5. Menus (let's start with Colin's guidelines here; I have some 
quibbles, but I think overall it's a good start)
   * Overall principles (these are generic principles I've seen in 
other platforms, somebody with GTK knowledge should probably adapt 
them with any necessary GTK-specific changes):
      - All features should be available through the menus
      - Never "invisibly" change the options available in a pull-down 
menu (i.e., don't add or remove items; disable/enable them instead 
when appropriate).  Only add/remove _entire_ menus (which is at least 
visible, although probably should be avoided anyway since it's 
outside the user's locus of attention).
      - All options should have keyboard access letters (whatever the 
underlined letter is).
      - Keyboard shortcuts should be available for frequently-used 
items and should always be shown in the menu.
    * "Standard" menus
       I think Colin's guidelines here copy a few things from 
existing environments that I think are bad, but we can debate those 
separately; again, it's a good start.

6. Keyboard and Mouse
    - Include Calum's accessibility guidelines (which are generally 
useful) for keyboard/mouse navigation, including focus, field 
tabbing, etc.
    - Keyboard shortcuts
    - Default key bindings
    - Other keyboard/mouse behavior

7. Terminology

I'm not 100% certain that the above is way too much for a 20-page 
document (it _is_ way too much for a 10-page :) but I definitely 
think cutting things out is a good idea.  Still, should we 
concentrate more on principles or on specific dos & don'ts?  I think 
the specific dos & dont's are more likely to be listened to, but to 
be honest I think the principles are more important in the long term.

Anyway, let's discuss this and try to have a preliminary outline by 
next Tuesday, and then people assigned to each section by say Friday 
the 17th.

Later,
Adam
--