Self Documenting Interfaces
- From: "Dan Kaminsky" <effugas best com>
- To: <gnome-gui-list gnome org>
- Subject: Self Documenting Interfaces
- Date: Thu, 23 Jul 1998 06:55:28 -0700
I've been tossing around various theories of GUI design around my head as of
late. In addition to my previously stated design statement(Everything that
is consistent between applications should be accessable cnsistently between
applications), I've also been tossing around something else:
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.
This has *always* been a weakness in CLIs, and always *will* be. Because
*so* much power is given to the user in execution form, so *little* of the
interface may be directed towards the user in explanation form. Attempts
are made to alleviate this by expanding the power of the available
documentation(man .commandrc,
command --help, --fullcommandnameinsteadof_fcn_), and they work to some
extent. But, in general, CLI's have trouble self documenting because each
line is an independant entity that is not surrounded by documenting
information.
[SUBNOTE: Wow, I just realized a spiffy thing for GnomeTerm might be to be
able to highlight a word and immediately send it to apropos, man, HOW-TO, or
a specific search engine.]
GUI's are another matter. By giving much less power to the user(it's
inevitable) and much *more* attention to self documenting via innumerable
analogies and constructs, they're far quicker and simpler to learn, but
rarely document past the minimal actions necessary to complete a single task
part, let alone a huge chunk.
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.
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.
But, Microsoft has a point: Interfaces *need* to tell users how to do
things. The problem is that Microsoft created two systems by which a *new*
interface was created instead of bringing users up to speed on the superior
old system.
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. They should be links to the
help/man/whatever file that describes their usage. Click once, and the
tooltip unfolds in front of you with an indepth description of the function.
This would of course posess a pushpin so if you wanted to have the docs
available while attempting to utilize a function, they'd be there for you.
That's A Good Thing!
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.)
Finally, there's something I think is critical, absolutely *necessary* for
GNOME to be the most explosive SDI out there: RECORDING CAPABILITIES.
Record the X environment, allow it to be played back with a compressed and
live-encoded soundtrack, and watch *real* tutorials occur. Best of all(but
perhaps hardest), since Gnome would be doing the recording, the themes could
still be those of the user him or herself!
Well, that's it for me, I've spent about 3 and a half hours with UIs, time
for me to catch some Z's. Lookin forward to wakin' up and hearing from you
all!
Dan
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]