Re: [HIG] Division Revision - First Part

[Seth Nickell <snickell stanford edu>]

I pretty much concur with everything Maciej said here.

On Wed, 2001-11-07 at 03:44, Maciej Stachowiak wrote:
> 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 
> 
> 
> _______________________________________________
> Hig mailing list
> Hig gnome org
> http://mail.gnome.org/mailman/listinfo/hig