eight golden rules of user interface design

[sungod <as387 yfn ysu edu>]

the following are dr. ben schneiderman's eight golden rules of user
interface design, as promised. i've tried to line them up with some of
apple's human interface fundamentals, and give examples of how each
would be used. although my interpretation for "implementation" or how
i've chosen to group apple's similar guidelines with them are
contestable, these guidelines have, in fact, been thoroughly researched
and should hopefully be agreed upon for the "fundamentals" section of
our style guide with little argument. if you feel one of them is wrong,
be prepared to cite specific research when you question it. i'm for
simply retyping these in sentence form and throwing them in the style
guide, myself. :) onward:

1. strive for consistency. (intuitive)

nutshell: broad meaning. sequences of actions, terminology, color,
layout, capitalization, fonts, all should be consistent. exceptions
(like not echoing passwords to the screen when typed) should be
comprehensible and limited.

apple's terms: "consistency." same thing. also says that consistency
allows skills learned once to be used similarly across all applications.
other important notes: "is your product consistent
* within itself?
* with earlier versions of your product?
* with Macintosh interface standards?
* in its use of metaphors?
* with people's expectations?"

"perceived stability." faced with the complexity of a new application,
users need stable reference points. consistent graphic elements like the
mac os menu bar (an ever-present white bar at the top of the macintosh
desktop, for those who haven't seen it) are examples they give.

implementation: most of this should be taken care of at library level.
if the library is configurable or themeable then the user will have more
control over what the interface is consistent _with_ but it will always
be consistent within itself.

2. enable frequent users to use shortcuts. (ergonomic)

nutshell: frequent users need reduced number of interaction and
increased pace of interaction. short response times and fast display
rates are necessary for these.

apple's terms: "knowledge of your audience." understanding the needs of
the user is emphasized. this isn't always limited to providing shortcuts
either, but is a good rule of thumb for designing the whole interface.

"accessibility." while shortcuts are part of this, it also means keeping
the application free of "cultural influences" and providing access for
disabled people.

implementation: toolbars fit under this category for mouse-based
programs; keyboard shortcuts fall under this category for text-based
programs like editors and irc. as the scope of gnome opens up to include
bigger, better projects, suitable shortcuts that _actually improve_
efficiency need to be found, like for audio- or motion-based input.

3. offer informative feedback. (intuitive and ergonomic)

nutshell: frequent & minor actions get modest feedback; infrequent or
major actions get substantial feedback. direct manipulation should
result in explicit display of changes.

apple's terms: "direct manipulation." perform physical actions on data,
while it stays selected and visible. simplest form of metaphor is used:
"...a user can move a file by dragging an icon that represents it from
one location to another or can position a cursor in a text field by
directly clicking the location where the cursor should be placed."

"wysiwyg (what you see is what you get)." don't hide features using
abstract commands; people should be able to see what they need when they
need it.

"feedback and dialog." same point as dr. schneiderman's golden rule.

implementation: already at library level (gtk+) for buttons and menus
and similar widgets, but for larger issues (especially direct
manipulation) the author still needs to make sure results of changes are
clear.

4. design dialogs to yield closure. (intuitive)

nutshell: actions should be organized with clear chronology as needed;
sequences of actions should provide clear feedback upon completion.

apple's terms: "aesthetic integrity." okay, apple doesn't limit this
fundamental to dialogs or to sequences of actions, but the principle is
the same: consistent with the principles of visual design, behaviors of
controls should be consistent with their intended behaviors and don't
assign arbitrary meanings to already standard widgets (or vice versa).
apple also emphasizes making the interface look good here, perhaps even
hiring a graphic designer for the application's interface, but that
doesn't quite apply in our case since we are emphasizing themeability
and configurability instead.

implementation: application developers should understand a little
psychology of learning and making errors, so sequences of actions that
require multiple steps (like configuring) are still easily understood.

5. offer error prevention and simple error handling. (intuitive,
ergonomic)

nutshell: constrain user actions to prevent error; if an error is made,
application should be able to detect error and allow for recovery.
erroneous actions should leave application state unchanged.

apple's terms: "forgiveness." again, reversibility and constraints are
suggested. an important point they mention is that "frequent alert boxes
are a good indication that something is wrong with the program design."

"modelessness." this is an important aspect of error prevention and
constraint; if you still think vi-esque modes for even the most basic
tasks like text editing are good design, please read this section of the
apple human interface guidelines carefully. i've run into this
etched-in-stone rule a lot while studying user interface design. yes,
there are times when modes are good, but there should be specific rules
that govern those times.

implementation: constraints are built into the widget set; choose
widgets carefully (use menu selection instead of form entry where
possible). allow users to revert to previous states when applicable.

6. permit easy reversal of actions. (ergonomic, intuitive)

nutshell: encourages exploration of unfamiliar options. consider
multiple "levels" of reversibility: single action, data-entry task,
complete sequence of actions.

apple's terms: this aspect is covered in the "forgiveness" section of
apple's guidelines.

implementation: "undo" and "revert" choices available; for example.
multiple levels of undo are the standard. anything without is considered
"broken" these days.

7. support internal locus of control. (egonomic, intuitive)

nutshell: the _human_ tells the _computer_ what to do, not vice versa.
avoid acausality; make users the initiators of actions rather than the
responders to actions.

apple's terms: "see and point." they lay down two fundamental paradigms:
that the user can see on the screen what they're doing and that users
can point at what they see. although these paradigms may not always fit
gnome (gnome applications should be useable by blind people, for
example) they have the same meaning: "the paradigms are based on a
general form of user action: noun-then-verb."

"user control." the fact that this point is made a second time, so
clearly, and so similar to the first in spite of coming from an entirely
different source and relying on completely different research should
probably tell us that this is pretty important. :)

implementation: this just makes sense for ergonomics, but it's also
crucial for intuitiveness, too: new users should be able to figure out
how to use an application by seeing what options are available, not by
being squeezed into a "wizard," or the computer's preprogrammed ideas of
correct usage.

8. reduce short-term memory load. (intuitive)

nutshell: human short-term memory is limited to "seven plus or minus
two" "chunks" of data (like phone numbers). constraints and mappings are
helpful but the bottom line is to avoid putting this load on the user in
the first place.

apple's terms: "metaphors." quite a lot to deal with "mappings" (or
relationships between controls and functions a user may already be
familiar with)

implementation: don't create any abstract counters or units of measure
or commands. if this is absolutely impossible, make online help
available and easy to access for any arbitrary commands or mappings.
examples would be using percentages or actual units of measure like
centimeters, milliseconds, picas, or pixels rather than "1-255."

comments? suggestions?
-- 
 ______(sungod)_____________________________________
| To ensure privacy and data integrity this message |
| has been encrypted by using dual rounds of ROT-13 |
 --------------------------(as387@yfn.ysu.edu)------