Re: [HIG] Division Revision - First Part

[Gregory Merchan <merchan phys lsu edu>]

On Wed, Nov 07, 2001 at 03:44:07AM -0800, Maciej Stachowiak wrote:
> 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 right after Dialogs.

Layout applies to control and in them when they are composite. My concern is
to present the general principles and then how they apply to various controls
so that when a special widget is created it flows from the general principles
not from a guess as to making it fit.

I assume it is known what the existing widgets are.

> 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.

This seems fine to me. I should have posted the next level.)

> 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.

No problem. I'm not convinced on the order yet. (Either way.)

> >  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.

We can't cover every object that will ever exist.

> >  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.

Ok, see my reply to Seth on this one and I'll post a revision soon.

> >  6  Controls
> >     This is existing widgets in detail, especially those not covered above.
> 
> Should cover layout too.

I suspect we have different concepts of controls. I'm not sure.

> "Language" chapter (I'm sort of working on it) should go here.

I need to know what this will cover.

> >  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.

If you mean religion as a matter of faith, then no.

If you mean religion as a tying together, then hell yes.

The system is the thing being interfaced. If you start fighting that, then
you should be working on another operating system instead.

Fighting the toolkit leads to apps which do not fit and confuse users who 
will find the same thing behaving in different ways. Typically, it also
excludes an entire class of users because something has been done incorrectly
and will not adjust, as the rest of the system will, to accommodate users.

As for fighting the window manager . . . who has not been annoyed when
netscape has thrown javascript-controlled windows all over the screen?

> 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 [widget].

Writing a custom widget is not fighting the toolkit. Trying to make an
existing widget act in another way is.