Re: [HIG] Division Revision - First Part

[Maciej Stachowiak <mjs noisehavoc org>]

On 07Nov2001 03:43AM (-0600), Gregory Merchan wrote:
> I'm doing this in parts because I haven't fully walked the tree yet.
> 
> Current division:
> 
>  1   Introduction
>  2   Usability Principles
>  3   Menus
>  4   Toolbars and Palettes
>  5   Dialogs
>  6   Controls
>  7   Layout and Appearance
>  8   Designing Effective Icons
>  9   Integrating Applications with the Desktop
>  10  Mouse Interaction Basics
>  11  Keyboard Interaction Basics
>  12  Simple Reality Checks
>  13  Terminology
> 
> Proposed division:
> 
>  1   Introduction
>  2   Principles
>  3   Presentation
>  4   User Input
>  5   Windows
>  6   Controls
>  7   Simple Reality Checks
> 
> Explanation:
> 
> The flow is from general to specific, explaining then applying. Exceptions
> which will be found in later sections should be noted in prior sections, but
> back references should not be necessary. 

I think a more pragmatic order would be to progress from larger
interface elements to smaller ones contained therein; from the big
picture to the details.

An example order would be:

Introduction
Principles 
The Desktop (covers integration issues and desktop-wide UI)
Windows
Dialogs
Menus
Toolbars
Controls
Layout
Icons
User Input (combination of Mouse and Keyboard sections)
Language
Checklist

The Language, User Input, Icons and Layout section all add detail to
the Controls section and others. Also, we were thinking about a User
Feedback chapter that would cover alerts, the status bar, and probably
other stuff I'm not thinking of at the moment. That could reasonably
go ritght after Dialogs.


Overall, I would prefer more shorter chapters than fewer longer
ones. It makes it easier to look for the specific concept you care
about. I think 13-14 is better than 7. I expect the HIG will grow by
adding detail to existing chapters rather than by adding chapters, so
once it becomes full size (~200 pages, say) then a seven chapter
organization will be unwieldy.

Think of this, on some level, as a technical reference work.

> 
>  1   Introduction
>      This is as before; an obvious first.
> 
>  2   Principles
>      Again, this is as before.
> 
>  3   Presentation
>      This will incorporate general presentation of data.
>      Fonts, colors, text, icons, et al. fall here.

It sounds like this chapter will be too damn long. Split it up and put
the items in their proper place in the order.
 
>  4   User Input
>      This is a temporary name for the keyboard and pointer sections.
>      The name needs to be distinct from user feedback (e.g., bug reports,
>       user testing, surveys)

This is a good name, but it should go after "Controls", as I said. You
need to cover what the interface objects are before discussing how to
manipulate them.
 
>  5   Windows
>      The various sorts of root window children (top-level windows).
>      The main app window (and maybe menubars, toolbars, and statusbars),
>       and secondary windows such as toolboxes, palettes, dialogs, and alerts.

I'd make Menus and Toolbars one or even two separate chapters, or this
chapter will be too damn long. Dialogs should be a separate chapter
too.
 
>  6   Controls
>      This is existing widgets in detail, especially those not covered above.

Should cover layout too.
 
"Language" chapter (I'm sort of working on it) should go here.

>  7   Simple Reality Checks
>      As above, though this should probably be renamed - it's condescending.
>      It's also perhaps too enticing to skip to. Maybe "Finishing" would
>       be appropriate and could incorporate or cite documents pertaining to
>       the system behind the desktop - e.g., mime and menu registry.
> 

 
> Note:
>   I don't recall yet seeing a few very important points. These are:
> 
>     Don't fight the system -
>       e.g., it's multi-tasking, multi-user, remember that and expect that
>             your app is not the most important thing running.
> 
>     Don't fight the toolkit -
>       If it's not easy to do, you probably shouldn't be doing it.
>       e.g., In Gtk+ 1.2, it's not easy to change styles, colors, and fonts,
>             inside the program. This is by design. Apps which rely on this
>             kind of behavior typically don't fit or play nice with other
>             apps.
>
>     Don't fight the window manager -
>       Simply put, this will anger users. It's not easy to do correctly anyway.


Overall, these 3 points sound more like X/Unix religion than sound
design principles for human interfaces.

Some are even at times the wrong thing HI-wise. For example, if you
need novel behavior that is not handled by any existing Gtk widget to
express something clearly to the user, then you should write a custom