Output: Screen Layout and Visual Effects
- window housekeeping
Multiple windows are used to display different sets of (dependent or
independent) information or interaction items in a meaningful way.
Window housekeeping is the task of placing, moving, raising and
lowering windows as needed to offer the desired overview.
- If the user's tasks are well understood and regular, the system may
employ an effective multiple-window display strategy.
The window housekeeping performed by the user can then be minimal.
- Window housekeeping is not related to the user's task, and should
therefore be automatic if at all possible.
- Smaller (low resolution) screens require more window housekeeping than
larger screens, because more windows will be overlapping.
- Tiled windows require more screen space but are easier to use.
They require no window housekeeping.
MS-Windows version 1 offered only tiled windows (except for dialog boxes).
Unfortunately display resolution was too low at that time to make
tiled windows practical.
- handling a single window
- A window should be identified by a meaningful title.
This holds for full-fledged windows as well as for dialog boxes.
A dialog box with as title "Dialog box" or "Confirmation" requires the
user to make the connection with the action which caused the dialog box
to appear.
- The color of the titlebar is used to indicate which window has the
focus (will receive keyboard events).
- Borders are often given a "3D" look, which looks neat but costs
more screen real-estate than needed.
- When opening a new window the best place is with the upper left-hand
corner near the mouse pointer but far enough to not obscure the object
the mouse is pointing at.
Window placement is a difficult issue. Opening windows in a fixed place
has the disadvantage that subsequent windows will obscure each other.
Opening dialog boxes in a fixed place (like in the center of the related
window) often requires too much mouse movement.
- Resizing is easiest if all borders and corners can be grabbed and moved.
The Macintosh permits resizing only from a box in the lower-right corner.
The (X-windows) "twm" window manager allows resizing only from a box
in the upper-right corner.
- Moving a window is typically done by dragging the title bar.
It is best if the window remains displayed completely while it is being
moved, but many computers do not have enough processing power (or I/O
bandwidth to the screen) to do this, so they only show an outline being
moved.
- Windows can be brought forward (raised) by clicking on them (in Windows'95)
or by clicking in the title bar.
Features like "autoraise" are annoying.
In order to raise a window which is completely obscured other methods are
needed.
Often there are keyboard shortcuts, mouse-operations or menu selections
to raise and lower windows, but these are hard to remember and different
on all window systems.
- When a window is too small to display its contents, scroll bars
may be added. Scroll bars should be placed (and shaped) consistently.
Scrolling should be used with caution: horizontal scrolling of text
is not usable, and scrolling in drawing tools may make the creation of
large objects (like lines) difficult.
- multiple-window design
Here is a short list of different techniques for providing simultaneous
views to different sources of information:
- multiple monitors: increases screen real-estate at the expense
of more eye and head movement.
- rapid display flipping or virtual screens:
causes a lot of cognitive overhead if information from one virtual screen
is needed to interpret information from (or enter it on) another virtual screen.
- split displays: work like tiled windows, and were introduced
in early text-oriented systems such as emacs.
- tiling windows: usable on large screens; aims for space filling
and no overlapping, and causes little cognitive overhead.
- zooming: allows to temporarily enlarge a window (possibly to
full-screen) and reduce it back to its previous size.
MS-Windows has this feature as a window system, but some Windows applications
such as Microsoft Powerpoint offer the feature as well: it can display
reduced versions of each slide, which can be zoomed to full-size.
- arbitrary overlap: this gives a two-and-a-half-D impression
of windows floating on top of each other, and is useful for windows of
independent applications, but within a single application it is difficult
to ensure that overlapping windows do not obscure relavant information.
- cascades: some window systems or -managers (e.g. Motif)
place subsequent windows slightly offset of each other, giving the
impression of a deck of cards.
Early versions of CMU's Andrew system did the same with menus as well.
Although not inherently difficult to use this type of menus was too different
from other menus on the same (Unix and X-Windows) platform to be comfortable.
Empirical tests have repeatedly shown that tiled windows lead to better
performance than any other technique.
- coordination between dependent windows
Applications may (temporarily) create multiple windows, for additional
output as well as input. These windows need to be coordinated.
- synchronized scrolling: useful for comparing documents.
- hierarchical browsing: one window shows an index and another
window shows the content of an item selected from that index.
The Windows'95 'Windows Explorer" uses this technique.
Many sites on World Wide Web use Netscape's frames to provide this
presentation as well.
- direct selection: pointing at an icon, button, or word
pops up a window containing a definition, short help info, etc.
- dependent-windows opening: the windows should be opened near
the location of the mouse-pointer, to avoid overhead in mouse movement.
When several dependent windows are opened the last one opened should not
block interaction with other windows if such interaction is still meaningful.
- dependent-windows closing:
several dependent windows may close simultaneously because of a single
user action.
- layout within a single window (or full-screen)
- Information or widgets should be distributed evenly over the screen
or window.
- Important information should be placed near the top left corner.
This is because a user starts reading from the top left corner.
Note that this habit is culture dependent!
- Error messages should appear in a fixed position or near the error.
Error messages near the error are easy to spot for the novice user,
while error in a fixed position require that the user is trained to
pay attention to that spot.
- In enumerated menus the numbers appear to the left of the menu items.
In forms a field label appears to the left of the input field.
This again is culture dependent.
- Pull-down menus are placed at the top of the screen or window,
and style guides often require a specific order.
- Frequently used buttons are displayed at the top, but below the menus.
- Palettes usually appear on the left.
- grouping
- Information items should be grouped according to a criterion that
makes sense to the user.
The "logical" or "object-oriented" structure of parts of the system or
application may not be meaningful to the user.
- Groups are separated by whitespace, horizontal or vertical rules,
or by changes in font size or typeface.
- Text fields should be grouped in no more than 5 fields,
numbers in groups of 3 or 4.
- Grouping by means of layout is preferred. Use other methods like
color or brightness only if layout is not sufficient.
- Information that needs to be displayed simultaneously should be
combined into the same window.
Separate windows are used or information that arrives later or for
temporary dialogs.
- color
- Use color only when other means of visual distinction have been
exhausted. (first use position, upper- vs. lowercase, graphical icons, etc.)
- Try to use no more than 3 colors.
A common mistake is to aim for beauty rather than usability.
- Use colors with similar brightness.
This advice causes problems when user-interfaces aimed for color displays
are used on black-and-white or grayscale displays, because colors with
the same overall brightness result in the same shade of gray.
- Do not use complementary colors, except for black and white.
A simple experiment shows that after looking at a color and then closing
your eyes leaves a "ghost" image in the complementary color.
- Use black letters on a white background, but make sure there is no
screen flicker.
- Make colors configurable: each person has personal preferences.
- brightness
- Use no more than 2 brightness levels.
- When the screen contains system-generated as well as user-entered text,
make the user's text brighter than the system's.
Actually, when using black letters on a white background, "brighter" should
be interpreted as "darker". The contrast between the text and the background
should be higher for the text the user types than for the system-generated text.
- Inverting colors (especially black and white) is useful for indicating
text selected by using the mouse.
- The use of different brightness levels should be consistent
throughout the user-interface.
- blinking
- Blinking text should only be used to quickly attract the attention
of the user. It should not remain displayed for a long time.
- The user should be able to stop the text from blinking.
- Implement blinking in the background. Do not make the text itself blink.
- If at all possible, avoid blinking. There are other ways to
emphasize information.
- fonts and case
- User lowercase except in complete sentences where the first
letter is capitalized.
- A proportional font is easier to read than a fixed-width font.
- Do not right-adjust text except in WYSIWYG applications that require
this.
- charts and tables
- Charts give a quicker overview but are less precise.
- Changes are easier to interpret in charts than in tables.
- Keep tables and charts simple.
- To compare bar- or line graphs, use overlaying graphs
(rather than side-by-side presentations).
- messages
- Indicate the order in which to complete actions.
- In conditional suggestions, give the condition first.
Showing the condition first makes the user read and evaluate the
condition before deciding on the action.
- Use the user's terminology.
A typical albeit innocent example where this has gone wrong is the use of
"OK" buttons in message boxes.
Such messages are often used to indicate that something the user really
wanted to do has failed.
The user may not want to press the "OK" button, because she does not
consider the error to be "OK".
- Use short sentences.
- Use active formulations.
- Avoid double negation.
- Avoid abbreviations and codes.
- If there are only a few possible answers to a question,
suggest the answers (between parentheses).
- Show the default answer to a question.
- If there is no choice, don't make it appear like there is.
This is another reason for not using an "OK" button when the situation
is not "OK". The user will look for a "Not-OK" button but there is none.
- visual information on the keyboard
- Lights on the keyboard should only be used to indicate a certain
state (such as "Caps-Lock").
- Blinking lights should only be used when immediate user-action is
required.
- The effect of visual information on the keyboard is limited
because many users never look at the keyboard.
- auditive signals
- The user must have control over volume.
- The user must be able to disable the "beep" or replace it by a
visual signal, in case noise is to be avoided, like in a crowded office.
- A long continuous or intermittend signal is only appropriate if
immediate user-attention is required.
- Fancy auditive gadgets must be optional. A user may wish to turn them
off.