Re: Self Documenting Interfaces

Hi, interesting line of thinking.

Dan Kaminsky wrote:

> All interfaces should be self-documenting.
> In other words, when I look at an app, I should very quickly be able to read
> the subtexts of its shape and understand how to get it to do what I want.

Despite harsh criticism of "Apple's" intuitiveness concept in
the GUI hall o' shame, etc. I think it's a good idea:  If you
_know_ what you want to do, you'll find the functionality in
your applications w/o looking up docs.  Of course it can't works
for advanced stuff (I guess scripting, etc. most certainly falls
in that category ;O) but IMO it's a good idea to keep in mind.


> GUI's are another matter.

Yes, but I'd love to have a GUI-CLI, since I love GUIs
but think the CLI is much nicer for certain tasks, e.g.
"find / -name "*~" -exec rm {} ';' ;O)
(Ok, shouldn't forget the ~, hehe - I keep backups, though.)

> Microsoft has taken two stabs at self-documenting interfaces:  Wizards(which
> basically fully describe an action then give you a box to fill in), and the
> Office Assistant.
> The former is great for new users, but becomes quickly grating, and most
> importantly *provides no means of upgrading to the full command set*.  A
> wizard provides documentation on how to do it the easy way but never
> explains how to do it the hard-but-more-powerful way.

I'd like a comic-style dog as assistent who "jumps/runs" (?) to
the spot it wants to explain to me w/ a transparent background
(shaped window)  Then it would explain to me the feature in
nice english (The dog could carry a US or UK flag to indicate accent
:O)  (Or French, Italien, etc. flag, ok.)  I'd use the US-flag
if the dog's from Texas :)

Apple's red circles around the described feature would
be nice additionally, then the dog wouldn't cover it but
be right next to the oval.  The dog could normally be lazing
around in an area of the screen which is unused or sit
in a corner if everything is cluttered.  The user should
be able to specify how active (distracting) the dog should
be (like in AfterDark: how many flies, how often scratching itself,
how sleepy, wave tail (often|sometimes|never), etc.)
You could also replace the dog w/ other figures, maybe
a more human-like assistent or so.
The asistent could change appearance depending on "workspace",
e.g. wear a suit in "Office", a leisurely wear in "recreation",

Maybe it could whine/howl/bark when something bad happens,
resp. make a more human-like noise if not a dog.  Oh well...

> The latter is a disaster, for a simple reason:  No clear way to turn that
> fugger off without uninstalling it.  It is also incredibly distracting and
> violates my rule about screens organizing by side and not by rectangle.  The
> Office Assistant would have been much much much more effective as a list of
> options the UI can help you with sitting in the upper right corner of the
> buttonbar.  I've never met anyone who liked it.

Yeah, the paper clip sucks (that's what you mean, right ?)
It also tries to ingretiate w/ the user which is a bad
habit and makes him suspicious IMHO.  (Just look at the
large eyes - way too large for a paper clip - it's a
concept and very apparently so)

> There are, indeed, some attempts at valid SDI(self documenting interfaces).
> Tooltips are, indeed, a powerful advance in self documenting interfaces.
> Gone are the days of absolute cluelessness as to what function an icon
> executes.  Now, all I need to do is put the mouse over an icon and wait for
> three seconds...ick.  What if I have a row of clues?  Eek!
> While tooltips shouldn't disappear, I'd like a helpme checkbox up next to
> the rest of the buttons.  This button would signal all tooltips to appear in
> their normal boxes, blue and underlined.

How about a menu item Help->Show All Tooltips" ? Then all
tooltips appear at once.  IMO clicking anywhere should
hide them again, though, I don't like the idea of clickable
tooltips somehow.

For longer explenation balloon help should be available.
The really detailed stuff should go in a separate help
browser window - I prefer the MS style ? cursor and
F1-context help here.

> There's more.  Us "experts" know that keyboard operations are orders of
> magnitude more efficient than using a mouse.  The Xerox PARC designers knew
> this too.  So lets shift up a gear documenting what keypresses do what.  Why
> not have a text entry box on the title that continually lists the key
> combination that would have executed the last command.  For example, click
> the bold button in LyX, and a Control-B command is listed.  What if there
> *is* no command for a specified action?  There'd be a blank box, and the
> user could move his or her mouse up to that blank box, click once, and enter
> their desired key combo.  It would show up in a different color, so if a
> desired command was overridden by user preferences, its showup color would
> make clear what happened.  (Of course, there's need to be a dead-obvious way
> to list, add, or subtract commands.)

I'd say this will make this too easy for newbies, advanced
users will find it easy enough to invoke the configurator
from the Options menu or the "Control Panels" directory in the
file manager.

Showing Ctrl-<key> in the status bar could be good I think.
Also, if it's not too ugly, a little letter for Ctrl+letter
bindings in the top-right corner of buttons would be nice IMO,
similar to the "Ctrl+letter" entry in menu items, just
not the whole accelerator.  I think users will get the
clue as quickly as they learn to hold down two keys at the
same time :O)


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