|
|
|
Created circa 1999
User-Friendly
Interface Requirements for RFPs
Free
Text to Use in Your Request for Proposals (RFPs)
|
What |
- Copy
all of this page to use in your own requests for
proposals or even design documents. The
copyright on this page content is waived. You
have unlimited permission to reprint this material.
- Several items in this list were inspired by "Avoiding
'We can't change THAT!': Software Architecture & Usability," by
Bonnie E. John, et al. The paper is at http://www.sei.cmu.edu/publications/documents/01.reports/01tr005/01tr005chap02.html
|
|
Why |
- So that usability requirement don't start from a
blank page and build upward on every project, which
inevitably leads to forgotten items.
- To finally deliver quality, usability, and usefulness.
|
|
How |
- Copy it into your specs.
- Delete the irrelevant.
- Add the unique.
- Consider crediting www.usabilityInstitute.com at
your option. We
make no stipulations whatsoever on how you must use
this material or acknowledge us as its source, but
if you are so inclined, we hope that by mentioning
us you will speed the adoption of these rules elsewhere.
|
|
Who |
|
|
How Much? |
|
|
Updated |
- 2008-Jan: Minor updates
- 2006-Jan-21 Credit noted, above in "What" section
- 2005-Nov-7 Broke
into cateogories
- 1999 Created
|
Part 1, Lofty Goals
- Minimal Reading
If
possible, the
software should be usable without reading a printed guide.
If the complexity
of the tasks being automated cannot feasibly be embedded
into the software interface, reading a printed guide may
be unavoidable.
In this case, the most that any individual user should have
to read for a particular role is 50 pages...short enough
to
read in one sitting.
- The
system should utilize step-through (wizard) dialogs for
multi-step procedures.
- Functionality
provided by the steps in the wizards should also be directly
accessible (without using the wizard).
- Browsability
The
interface should enable all interaction techniques and
input to be discoverable
and chosen from a browse-able, heirarchical structure,
arranged in order of the functions the user needs to perform.
Prior to the advent of the Web, this simply meant supplying
an exhaustive menu or menu-like outline of choices, supported
by dialogs
with options
and click-able choices. More recently, this requirement
is being satisfied by multiple graphical choices, in
the form
of icons and segmented, click-able graphics known by
various names, such as imagemaps. In either case, what this
requirement
specifically precludes is reliance solely on any of the
following techniques: command line syntax; parameter
(INI) file options
not built into the interface; techniques supported only
by combination keystrokes, mouse techniques, or combinations
thereof; techniques requiring knowledge of special, manually
entered values.
- Fewest
Actions
Users should be able to accomplish every task and
entry with
the
fewest possible keystrokes. For instance, dates should not
necessitate typing four digits for the year unless the
context
of the given field leaves considerable doubt as to which
millennium might be intended. In many cases, keying in
any characters
at all for the year may be an unnecessary expense of the
users' time.
- Any Order of Action
The
software should enable users to do things out of order without
being penalized.
- Self-Evidency
The interface and messages should make it clear why the program does what it
does.
- Error
Tolerance
The software should enable users to make outright
mistakes without losing progress or data entered to the
point at which the mistake occurred. Support multiple levels
of undo or cancel. An absolutely marvelous standard is set
by Macromedia Fireworks which enables the user to drag a
slider control back and forth over a hisory
list of edits.
- Power Tolerance
Most
of the users' work should be retained after power interruptions.
Part 2, Facility
Facility is basically efficiency, but also encompasses all
of the different things you can do, not just how fast. It
corresponds to item 3,
"Fewest Actions," in the Lofty Goals section above.
- Direct Manipulation
- Wherever feasible, objects can be acted upon directly
rather than through independent dialogs.
- Drag and drop is supported for movement and copying.
- Multiple Invocations
Provide multiple methods where applicable to invoke a given function (menu, right-click, keyboard, mouse, docked palette).
- Text-Based Editing
Where applicable, in addition to the graphical (mouse,
menu, dialog) interaction with the data, systems should enable
text-wise (ASCII) maniuplation of the data so that macro
(single-action) techniques can invoke changes across a broad
set of data.
- All Sort Orders
Provide access to information and objects via all
common orders that could conceivably structure the objects,
including but not limited to:
- Categorical (hierarchical by function, affinity,
or conceptual/learning order)
- Alphabetical (by inherent identifiers or assigned
keywords)
- Numerical
- Date (history)
- Alphabetical by every word (full-text search)
- Popularity
- Other orders include geographical, color and so on
- Quick Search
- Where applicable, a search feature should be available
throughout all main windows and pages.
- The search function should search through all popular
indexes.
- The search results should redisplay the search invocation
features.
- Object Scope
- Objects should be able to be edited at all levels
of system scope, such as system-wide, template level,
document or project level.
- Object properties should be able to be inherited
dynamically, if explicitly opted for.
- Object properties should be able to be inherited
on demand, when chosen by the user.
- Object properties should be able to be copied among
objects at all levels of system scope.
- Docking (Dialog-less) Invocation
Repeatedly-accessed functions should be able to
be clicked or invoked without repeatedly opening dialogs,
such as from docked tool palettes or hotkeys.
- Group (Mass) Operations
Functions and property changes should be able to
be applied to multiple objects, not just one at a time.
- Tables
- All table columns should be sortable.
- The order of sorted columns should be indicated.
- Tables of more than 7 rows and more than 50% of the
width of the screen should be provided with row highlighting
when the mouse is rolled over the row. See http://www.alistapart.com/d/tableruler/tableruler.html for
the effect.
- Pick List
Recent files should be able to be re-opened by a "pick-list," that
is, in a single action.
- Provide Features Expected of "MS Windows" Controls
The input, display, and interaction controls should provide the convenience features typical of Windows systems:
- Seeking: Typing the first letter or letters in a list advances to the matching item.
- Field Selection: Tabbing into a field preselects the entire contents of a simple text box.
- Option Selection: Check boxes and radio (option) buttons should be able to be selected by clicking not just the button but also anywhere in the text labels. See Google.com>Preferences for example code.
- Hotkeys
- Where feasible, common functions should be supported
by standard Windows/MS Office hotkeys:
- F1 for help.
- F5 to refresh.
- Control-S to save.
- Control-P to print.
- Control-X, C, V to cut, copy, paste.
- Control-A to select all.
- Control-click to extend selection/multi-select contiguous
- Hotkeys are described on the pertinent menus where
the functions appear.
Part 3. Interaction
- Save by Default
The
system should save all of what the users type, by default,
meaning
without extra steps.
- Don't
Overwrite
Users should be forewarned when any work is over-written,
undone,
or erased.
- Undo
Allow the user to undo their actions.
- Cancel
Allow the user to confirm actions prior to committing to them.
- Resizeable Text
Text sizes should be resizeable by the user.
- Error Messages
- Errors should be trapped at every spot where errors
could occur. In other words, errors should not be grouped
together, such that the message does not sufficiently
narrow the cause and resolution.
- Error messages
should describe the problem and solution in
terms the
user can
take action
on.
- Error message text should be selectable, to copy.
Part 4, Support
- Introductory Explanations
- Functions that are neither trivial nor obvious
should display introductory explanation panels.
- The introductory
panels should provide a check box labeled "Do not
show this message again."
- The check box should default
to unchecked.
- A preferences function should enable introductory
messages to
be reactivated individually or all at once.
- Embedded Information
For infrequent tasks that require explanation, put the information right into the interface.
- Error Messages
- Errors should be trapped at every spot where
errors could occur. In other
words, errors should not be grouped together, such that
the
message
does not sufficiently narrow the
cause and resolution.
- Error messages should describe the problem
and solution in terms
the user can take action on.
- Error message text should be selectable,
to copy.
- Sandbox
A test database or environment should be provided to encourage
user experimentation.
- Online Help
- Expert systems should provide online help...
- The online help should be context-sensitive to the page, window, or dialog.
- The online help should be in HTML pages or a help viewer application.
- The online help should respond to the F1 key if feasible.
- The online help should provide full text searching.
- The online help should provide a docked table of contents.
|