IBM Ease User Manual
IBMEaseofUse
User Interface Architecture
IBMEaseofUse
User Interface Architecture
Note
Before using this information and the product it supports, read the information in “Notices” on page 33.
Second Edition (December, 2001)
© Copyright International Business Machines Corporation 2001. All rights reserved.
US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract
with IBM Corp.
Preface
Why is the Web changing the world? It is simple; it connects everybody to
everything in a single interface.
It is, however, not easy. Total connection requires universality and standards. You
probably don’t remember eWorld. You probably never used NoteCards or
InterMedia, two of the great hypertext systems in 1980s. Why? These systems
failed to deliver the promised universal networking. They might connect somebody
to something or even have better features than the Web, but they simply lacked the
power of universality that the Web possesses.
Many people acknowledge and accept the standards for such things as power
voltage, power plugs, and even e-mail headers, but deny the need for standardizing
user interfaces. They argue that users are intelligent and instinctive individuals and
can adapt to any given design. It is true that users can adapt to almost anything.
They surely had to do so in the past. Why should users have to adapt to machines?
Do they voluntarily or involuntarily adapt to machines? Research on human factors
in human-computer interaction shows that users of a new interface demonstrate a
consistent desire to ″get started right away″. This distinct desire or preference
forces them to ″figure out″ the interface without the benefits of a user-friendly
design.
This User Interface Architecture describes principles and guidelines for a
user-centered design for IBM
your project will provide the following main benefits:
v The architecture embodies recognized principles of human factors that are
proven to improve usability. These principles may appear ″obvious″ or ″simple,″
but they are often overlooked by designers and, consequently, missing from
consumer products, such as computers, electronics, and Websites. Your design
based on these principles will become easier to use.
v In addition to fundamental principles, the architecture also provides guidelines for
designing user interfaces. These guidelines are effective, practical, and
easy-to-follow. Specific conventions are also derived from the guidelines, telling
you what to do and what to avoid during your design process. These guidelines
and conventions will increase the efficiency of your work. More importantly, they
will help you avoid common design blunders and ease the use of your product.
v The principles and guidelines in the architecture are intended to set design
standards for IBM network-based products. The resulting universality in interfaces
will allow users to transfer their learning experience from one IBM network
product to another and give them a sense of accomplishment and control over a
system. This will ultimately increase their satisfaction and productivity.
You may think that your product is special, and you can deviate from the
recommended user interface architecture. You are not alone; all designers have the
same regard for their products. Indeed, every product has its unique features and
design considerations. However, if every design ″sub-optimizes″ the interface for its
own needs, the overall usability of all IBM network products will diminish, and users
will suffer from the increased inconvenience.
®
network-based products. Applying this architecture in
Just imagine this: You designed a product, disregarding this user interface
architecture, and IBM or affiliates had to pay for an extra amount of valuable
© Copyright IBM Corp. 2001 iii
resources to train the users to use it. Your product might be excellent in its own
right, but without universality or standards, it was not good enough to your users or
IBM.
I urge you to comply with the User Interface Architecture described in this
document. You will save yourself energy, IBM resources, and users much hassle
and confusion. I bet that you will sell more products as well.
Jakob Nielsen
Nielsen Norman Group
http://www.useit.com
http://www.nngroup.com
iv User Interface Architecture
Contents
Preface ............................iii
Introduction ..........................1
UIA overview ..........................1
Design considerations .......................2
Designer’s model .......................2
User-centered design ......................2
Writing systems ........................3
Platforms or enabling environments .................3
Product structure .......................4
Notational conventions ......................5
Typefaces ..........................5
Special characters .......................5
Diagrams ..........................5
Design principles ........................7
Affinity: Bring objects to life through good visual design ..........7
Assistance: Provide proactive assistance ................7
Availability: Make all objects available at any time ............8
Encouragement: Make actions predictable and reversible ..........8
Familiarity: Build on the user’s prior knowledge .............8
Obviousness: Make objects and controls visible and intuitive ........8
Personalization: Enable the user to customize an interface .........9
Safety: Keep the user out of trouble .................9
Satisfaction: Create a feeling of progress and achievement ........10
Simplicity: Do not compromise usability for functionality ..........10
Support: Place the user in control ..................10
Versatility: Support alternate interaction techniques ...........10
Design guidelines .......................13
Controls ...........................13
Predefined actions .......................16
Data transfer..........................18
Message handling ........................19
User assistance ........................23
Windows and layouts ......................25
Portfolio ...........................29
Accessibility ..........................30
Notices ...........................33
Trademarks ..........................34
Glossary ...........................35
Index ............................39
© Copyright IBM Corp. 2001 v
vi User Interface Architecture
Introduction
UIA overview
This section introduces the IBM User Interface Architecture (UIA) and defines its
underlying design principles and guidelines. It also briefly describes other design
factors you need to take into consideration. These design factors include, but are
not limited to, the following:
v Designer’s model
v User-centered design
v Writing systems
v Platforms or enabling environments
v Product structure
Finally, this section explains the notational conventions used in the UIA document.
The UIA specifies rules by which the user interface of IBM network-based products
must be built. The UIA rules are intended to achieve further consistency in design
and ease of use of IBM network-based products.
The UIA rules are categorized into principles and guidelines. The terms principles
and guidelines are defined as follows:
Principles The fundamental ideals and beliefs that guide your decision-making
and courses of action to achieve a predefined goal. Principles are
fairly abstract. You must have extensive interface design knowledge
and experience to understand and interpret them. For example, a
UIA principle governing user assistance reads like this: ″Assist the
user in performing a variety of tasks.″
Guidelines The specific courses of action, based broadly on a set of principles.
Guidelines can be construed as good practices within a general
design domain, such as Windows
generally more specific than principles and require less design
knowledge and experience on your part to understand and interpret
them. For example, a guideline for implementing the UIA user
assistance principle reads like this: ″Provide contextual help for
each choice or object that the cursor can be positioned on.″
Most platforms or enabling environments devise specific guidelines to govern the
design and production of their component products. This UIA draws on the most
effective guidelines currently adopted by these platforms. The principles and
guidelines are applicable to all products for these platforms.
®
GUI or Java™Swing. They are
© Copyright IBM Corp. 2001 1
Design considerations
You need to take the following factors into consideration in your design of user
interfaces.
Designer’s model
The following three models are often used to describe a new interactive system:
Implementor’s
model Demonstrates how a new system is implemented.
User’s model Allows a user to try out and explain a new system. The learning
Designer’s
model Is based on multiple user’s models and describes the collective
This UIA presents a partial designer’s model, with its quintessence described in
“Design principles” on page 7 and “Design guidelines” on page 13 and its elements,
or objects, defined in “Glossary” on page 35. These objects are common to
applications that conform to the UIA.
It is critical that you first develop a designer’s model when you design a product. In
the designer’s model for the product, you define the way that a group, or class, of
objects will appear and behave. These specifications will help create a common
look and feel for the objects in an interface. The resulting consistency will make the
behaviors of the objects predictable and thus the interface intuitive and the product
easy to use.
experience of each user becomes a separate user’s model.
experience of all users with the same system.
Visit http://www-3.ibm.com/ibm/easy/eou_ext.nsf/Publish/569 for a detailed
description of the implementor’s model, the user’s model, and the designer’s model.
The designer’s model is often described in the context of the object view and
interaction design (OVID) method with the unified modeling language (UML). See
Designing for the User with OVID: Bridging User Interface Design and Software
Engineering (ISBN: 1-57870-101-5) for more information about OVID and the
designer’s model.
User-centered design
This UIA assumes that each conforming product will be created to meet the
requirements of the IBM user-centered design (UCD) or its equivalent. The following
table summarizes the UCD process and the UIA considerations relevant to each
step.
UCD Process Description UIA Considerations
Market definition Define the target audience, identify
Task analysis Identify and understand the user’s
the competitors, and determine the
core user needs that must be
fulfilled.
goals and tasks, the strategies they
use to perform the tasks, the tools
they currently use, the problems
they experience, and the changes
they want to see in their tasks and
tools.
Decide whether the UIA is an
appropriate approach tor the
product.
Design your product using the
identified tasks. Each task will be
embodied in the product as a
sequence of views. Analysis of the
frequency of a task will help you
decide if you should provide a
wizard for that task.
2 User Interface Architecture
UCD Process Description UIA Considerations
Competitive
evaluation
Design and
walk-through
Evaluation and
validation
Benchmark
assessment
Determine the design strengths and
weaknesses of the competition.
Using the results from task and
competitive analyses, create
alternative solutions, solicit
feedback through design
walk-through sessions with users,
and choose a solution based on
user input.
Periodically solicit user feedback on
the evolving design, and iterate the
design based on analysis of users’
experiences with it.
Run a head-to-head benchmark
assessment against the competition
to verify that the product has met its
primary objectives. If a third-party
company conducts the benchmark
study, positive results can become
important selling points in product
promotions.
None
Create one or more models of your
product based on the “Designer’s
model” on page 2. Make sure that
all elements in your models
correspond and comply with those
in the UIA. Use design walk-through
sessions to see if the users
understand the models and to
choose a single model for
implementation.
Implement, evaluate, and validate
your design based on the UIA
“Design guidelines” on page 13 or
platform-specific guidelines.
None
Writing systems
This version of the UIA guidelines is intended for user interfaces designed for the
left-to-right, top-to-bottom writing systems. You may need to adjust the guidelines to
accommodate the directionality of languages, such as Arabic and Hebrew, that have
different writing systems.
Platforms or enabling environments
Though the UIA intends to provide a repertoire of rules, it does not normally repeat
those which are already common to all platforms or enabling environments. If you
cannot find a rule for a particular user interface of a particular product, follow the
platform-specific or environment-based guidelines. The ISO/IEC standards and
guidelines for Windows, Java, and UNIX
publications.
®
are available on the Internet and in
Introduction 3
Product structure
The following diagram shows the structure of a typical product that conforms to the
UIA. Make sure that your design conforms to the UIA.
Renderer
architecture
conforms
to
UIA Designers
Model
conforms
to
Platform
Renderer
implements
Common
renderer
interface
Model renderer
Renderable
interface
implements
Exposed
Implementation
Model
Implementation
Model
UIA principles
and guidelines
conforms
to
Business logic
The diagram includes the following elements of a typical product structure:
v A UIA-conforming renderer is used to provide interaction between the system and
the user. It implements the common renderer interface and provides layout that
conforms to the UIA. It is also responsible for such tasks as validating user input
and ensuring that required properties are supplied.
v The model renderer is a key element of the user experience. It controls the
presentation of the exposed implementation model (EIM) to the user and
responds to the user’s actions by applying actions to the business logic through
the EIM. It also accesses the EIM using its renderable interface and the chosen
renderer through its common renderer interface. In addition, it defines the
methods of interaction, such as the choice between the cached and the instant
update of the business logic.
v Business logic is the basic function of any product. The elements of the business
are stored within databases or on other media. The implementation model
represents the software that provides access to the business logic. The first
stage of designing a user interface is to decide the parts of the business to be
exposed to the user. This can be done by creating an EIM that selects the
elements to be presented. By implementing the renderable interface, the EIM
conforms to the UIA designer’s model.
v An EIM provides access to the elements within the business logic with which the
user must work.
4 User Interface Architecture
Notational conventions
This section describes the notational conventions used in this document.
Typefaces
The following typefaces are used to indicate emphases throughout this document:
boldface Text in boldface represents table column headings and definition
italics Text in italics indicates an important concept or term that is usually
monospace Text with monospace stands for the name of a menu item, push
Special characters
The following special characters are used to indicate reserved terms for UIA
designers and different types of UIA design guidelines:
small caps
or brackets Terms in
U Guidelines with a check mark are fundamental to creating a user
terms in a definition list.
defined within the same sentence or paragraph.
button, or keyboard key, a sample output, or a sample system
message.
SMALL CAPS or [ ] are reserved for use by the interface
designers, not their users. The term
ACTION CONTROL or [action
control] is an example of the reserved terms.
interface that is compliant with the UIA and its underlying principles.
You must follow these guidelines in your design work.
Diagrams
h Guidelines with a empty box are consistent with the UIA principles,
but not mandatory to creating a user interface. You are strongly
recommended to follow these guidelines for the overall ease of use
of your product.
The following diagrams or graphics are used to represent objects or views and
relationships among objects or views:
Symbolizes an object that is stored by the system and shown
as a rectangle containing the name of the object. A folder, for
example, is an object.
Symbolizes an aggregate relationship in which one object,
such as a folder, contains another object. This relationship is
shown as a line with a diamond at one end and an arrow at
the other. The folder contains zero-or-more objects. If the
folder is deleted, the contained objects are also deleted.
(from examples)
Folder
(from examples)
Folder
0..*
Object
(from UIA)
Introduction 5
<<View>>
Pointer
moves on
<<View>>
Screen
Symbolizes a depends on or uses relationship in which one
object, such as the pointer, relies on another and is shown
as a dotted line with an arrow. In this example, the pointer
uses the screen.
<<View>>
Icon
(from UIA)
rendered by
Folder
(from examples)
<<View>>
[Action Control]
<<View>>
Menu
<<View>>
Information Area
1..*
<<View>>
Pushbutton
Symbolizes a rendered-by relationship between a view and
the object being viewed. In this example, a folder is rendered
by one-or-more icons.
Symbolizes a subclass relationship in which one object is a
special form of another and is shown as a line with a
triangle. The menu and push button, for example, are both
special forms of
ACTION CONTROL.
Symbolizes a view or mechanism by which the user can
interact with the system. It is shown as an object symbol with
<View> above the name. An information area is an interaction
mechanism.
6 User Interface Architecture
Design principles
This section describes the following UIA design principles:
v Affinity: Bring objects to life through good visual design
v Assistance: Provide proactive assistance
v Availability: Make all objects available at any time
v Encouragement: Make actions predictable and reversible
v Familiarity: Build on the user’s prior knowledge
v Obviousness: Make objects and controls visible and intuitive
v Personalization: Enable the user to customize an interface
v Safety: Keep the user out of trouble
v Satisfaction: Create a feeling of progress and achievement
v Simplicity: Do not compromise usability for functionality
v Support: Place the user in control
v Versatility: Support alternate interaction techniques.
Affinity: Bring objects to life through good visual design
v Understand the principles of visual design. The visual design in a user interface
aims to embody all aspects of the UIA principles. It should support the user
model and communicate its functions without ambiguities. It should not be seen
as ″the icing on the cake,″ but an integral part of the entire design process.
v Follow the visual design principles below. These principles promote clarity and
visual simplicity in a user interface:
Subtractive design
Eliminate any visual element that does not contribute directly to
the intended visual communication.
Visual hierarchy
Establish a visual hierarchy of the user’s tasks in the order of
importance. Give extra visual prominence to a critical object. Use
relative position and contrast in color and size to increase the
visual prominence of an object.
Affordance Ensure an object displays good affordance. That is, the user can
easily determine the action to be taken with the object. Objects
with good affordance often mimic those in the real world.
Visual scheme
Design a visual scheme that maps to the User’s Model and
enables the user to customize the interface. Do not eliminate
extra space in an image just to save space. Use white space to
provide visual ″breathing room.″
Assistance: Provide proactive assistance
v Help the user perform a variety of tasks. The knowledge of the system and the
ability to handle a task vary from one user to another. Enable the system to
recognize the ability of an individual user and offer assistance as appropriate.
v Provide assistance in the forms of captions, hints, or system help. The
assistance information should be simple, concise, and task-oriented to allow the
user to complete a task with relative ease and efficiency. It should also be
© Copyright IBM Corp. 2001 7
flexible. The system should be able to adapt to the improved capability of the
user and train the user to become independent.
Availability: Make all objects available at any time
v Enable the user to use all objects within a view in any sequence and at any time.
For example, the Open dialog in the Windows platforms allows the user to access
all objects in the view of an open object.
v Avoid using modes in which actions of an interface are no longer available or
cause unexpected results. Modes restrict the user’s ability to interact with the
system. For example, menu-driven systems use the modal dialog box, such as
Print and Save As, for the user to request command parameters, but this modal
dialog tends to lock the user out of the system. The user must complete or
cancel the modal dialog to return to the system, creating tremendous
inconvenience.
Encouragement: Make actions predictable and reversible
v Ensure that an action produces the expected results. Try to understand the
expectations, tasks, and goals of the user. Use terms and images that help the
user understand the objects and their relationships for completing a task.
v Encourage the user to explore the system, try out an action, view the result, and
undo or delete the action. The user feels more comfortable with and confident in
an interface if the featured actions do not cause irreversible consequences.
All user actions, including the seemingly trivial deselection should be reversible.
For example, the user spends several minutes deliberating and selecting
individual files to be archived. It frustrates the user if the selections are
accidentally deselected and the deselection cannot be undone.
v Avoid bundling actions together. The user may not anticipate the impact of
bundled actions. For example, do not group the Cancel and Delete functions
together. If the user chooses to cancel a request for sending a note, only cancel
the Send request; do not delete the note. Make actions independent and provide
mechanisms, such as wizards, to allow the user to combine actions for a certain
use.
Familiarity: Build on the user’s prior knowledge
v Allow the user to build on prior knowledge of the system. A user-friendly system
enables the user to learn new concepts and techniques by accomplishing one
task and apply them to a broad spectrum of tasks. In other words, the user does
not have to learn different techniques to perform similar tasks.
v Employ visual designs and interaction techniques in an interface to represent and
reinforce the user’s experience with other systems for the same platform or
environment. A new interface is easy to understand, learn, and use if the required
interaction techniques are consistent with what the user already knows and
expects. Try to discover and understand the experiences and expectations of the
user before you start your design.
Obviousness: Make objects and controls visible and intuitive
v Use realistic representations in the interface. The objects and concepts in an
object-oriented interface should resemble those in the real world. Whenever
possible, avoid artificial representations of objects.
Trash cans and telephones are good examples of realistic representations. In the
real world, a trash can is a receptacle for people to deposit trash. An object
8 User Interface Architecture
Loading...