Re: [HIG] Division Revision - First Part



Seth Nickell wrote:
> 
> I pretty much concur with everything Maciej said here.

me too

> 
> 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
> 
> _______________________________________________
> Hig mailing list
> Hig gnome org
> http://mail.gnome.org/mailman/listinfo/hig



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