Re: The Help Menu

-----Original Message-----
From: John R Sheets <>
To: Gnome GUI List <>
Date: Thursday, July 30, 1998 11:15 AM
Subject: The Help Menu

>What should the behaviour of the Help menu item be if no help
>exists for an app?  Should it be grayed out (and if so, how will
>it know of the help file's existence?)?

The entire menu shouldn't be greyed out.  I've become a fan of the
Help::About Version/Email/Web/Author information box being integrated into
the actual binary, with a separate-app help browser going into
documentation, providing links to screenplays, etc.

>Or should the menu item be always enabled, and the help browser
>be smart enough to respond with grace?  Perhaps there should be a
>helpful help-finding help page, telling the user that it couldn't
>find help for so-and-so application, and here's how to fix the
>problem or find out more....

Linux needs a Microsoft-style Knowledge Base, only one that works.  How cool
would it be to have a link in the help menu that took you to all relevant
knowledge base entries?  Netscape could/would host it, so bandwidth wouldn't
be as much of an issue, and it'd become second nature to get up to the
minute help on a given application.

Of course, local documentation is required :-)  But supposing the file isn't
available for the help browser to open, it should ask(with a check box
saying "don't ask me again") whether or not to attempt to access the help
file via the Linux Knowledge Base.

Quick side note...this solution requires modal displays, and I'm not sure
how to avoid that.  In fact, the only way I see out of most modal displays
is a stderr window integrated on screen somewhere...but having stderr
windows inside of each app would waste major room, and having a single one
pop up or hang around anywhere would force the user to fly his eyes halfway
across the, anything not integrated into the app window should
be optional, and modal displays are often-but-not-always required

Here's a possible proposal for when modal windows are appropriate.  Modal
windows, in the definition I'm thinking of, are topped windows that prevent
further input into an application until such time as a trigger is hit:

1)  Informational Modal Windows("OK") should be replaced with comments
directed into an onscreen stderr window.  If the user has chosen not to have
an onscreen stderr window, user preferences will allow a stderr window to
"pop up" temporarily:
--At some specificied absolute location.
--At some specified location relative to the window(top left corner, inside,
or top left corner on top sounds decent)
--As a "cooldown" text box overlaid on or above the title bar.  Cooldown
boxes are contain text that appear hot(red?) and then color shift down to
some kind of "dead" color.

    The key is, if you're just informing the user of something, and if they
can't do anything about it, it is rarely appropriate to interrupt the user.
The only exception is notifications before fatal error, in which case both a
modal display and a pipe to stderr is appropriate--modal to make sure they
understand WHY their app just died, and stderr so they can link to the help
file section that describes What Went Wrong.  (Y'all did remember that GNOME
stderr's should be, imho, linked to help files, right?)

2)  Directional Modal Windows("OK", "Cancel") create a neat little addendum
to Kaminsky's Second Law Of User Interfaces("Everything which is consistent
between applications should be accessable consistently between
applications.")  The addendum is, "Everything that is consistent between
tasks should be consistently automatable."  For example, in Photoshop, lets
say I have 30 windows open, and I try to quit.  Photoshop is going to ask me
30 times, wanna save or quit?  Wanna save or quit?  It'd be better to have a
single modal display that lets me add or remove files to and from the save
list, and then to select the save format style in some kind of shift or
control-select group grab.

What do you guys think?

Who could host the Base?  *cough* yo netscape, got some spare bandwidth?

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