[HIG] Gnome HIG mini-guidelines outline

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]