|
|
|
 |
|
Guidelines
A.
User Interface Design Tips and Techniques
In this section we will cover a series of
user interface design tips that will help
you to improve the objectoriented interfaces
that you create.
1. Consistency, consistency, consistency.
The most important thing that you can possibly
do is make sure that your user interface works
consistently. If you can double-click on items
in one list and have something happen then
you should be able to double-click on items
in any other list and have the same sort of
thing happen. Put your buttons in consistent
places on all of your windows, use the same
wording in labels and messages, and use a
consistent color scheme throughout. Consistency
in your user interface allows your users to
build an accurate mental model of the way
that it works, and accurate mental models
lead to lower training and support costs.
2. Set standards and stick to them. The
only way that you’ll be able to ensure
consistency within your application is to
set design standards and then stick to them.
The best approach is to adopt an
industry standard and then fill any missing
guidelines that are specific to your needs.
Industry
standards, such as the ones set by IBM (1993)
and Microsoft (1995), will often define 95%-99%
of
what you need. By adopting industry standards
you not only take advantage of the work of
others you also increase the chance that your
application will look and feel like other
applications that your users purchase or have
built. User interface design standards should
be set during the Define Infrastructure Stage
(Ambler, 1998b).
3. Explain the rules. Your users need
to know how to work with the application that
you built for
them. When an application works consistently
it means you only have to explain the rules
once. This is a lot easier than explaining
in detail exactly how to use each and every
feature in an application step by step.
4. Support both novices and experts. Although
a library-catalog metaphor might be appropriate
for casual users of a library system, library
patrons, it probably is not all that effective
for expert users, librarians. Librarians are
highly trained people who are able to use
complex search systems to find information
in a library, therefore you should consider
building a set of search screens to support
their unique needs.
5. Navigation between screens is important.
If it is difficult to get from one screen
to another then your users will quickly become
frustrated and give up. When the flow between
screens matches the flow of the work that
the user is trying to accomplish, then your
application will make sense to your users.
Because different users work in different
ways, your system will need to be flexible
enough to support their various approaches.
Interface-flow diagrams can be used during
the Model Stage (Ambler, 1998b) to model the
flow between screens.
6. Navigation within a screen is important.
In Western societies people read left to right
and top to bottom. Because people are used
to this should you design screens that are
also organized left to right and top to bottom.
You want to organize navigation between widgets
on your screen in a manner that users will
find familiar to them.
7. Word your messages and labels appropriately.
The text that you display on your screens
is a primary source of information for your
users. If your text is worded poorly then
your interface will be perceived poorly by
your users. Using full words and sentences,
as opposed to abbreviations and
codes makes your text easier to understand.
Your messages should be worded positively,
imply that the user is in control, and provide
insight into how to use the application properly.
For example,
which message do you find more appealing “You
have input the wrong information” or
“An account
number should be 8 digits in length.”?
Furthermore, your messages should be worded
consistently
and displayed in a consistent place on the
screen. Although the messages “The person’s
first name
must be input.” and “An account
number should be input.” are separately
worded well, together they
are inconsistent. In light of the first message,
a better wording of the second message would
be “The account number must be input”
to make the two messages consistent.
8. Understand your widgets. You should
use the right widget for the right task, helping
to increase the consistency in your application
and probably making it easier to build the
application in the first
place. The only way that you can learn how
to use widgets properly is to read and understand
the
user-interface standards and guidelines that
your organization has adopted.
9. Look at other applications with a grain
of salt. Unless you know that another
application follows the user-interface standards
and guidelines of your organization, you must
not assume that the application is doing things
right. Although it is always a good idea to
look at the work of others to get ideas, until
you know how to distinguish between good user-interface
design and bad userinterface design you have
to be careful. Too many developers make the
mistake of imitating the user interface of
another application that was poorly designed.
10. Use color appropriately. Color
should be used sparingly in your applications,
and if you do use it you must also use a secondary
indicator. The problem is that some of your
users may be color blind – if you are
using color to highlight something on a screen
then you need to do something else to make
it stand out if you want these people to notice
it, such as display a symbol beside it. You
also want to use colors in your application
consistently so that you have a common look
and feel throughout your application. Also,
color generally does not port well between
platform – what looks good on one system
often looks poor on another system. We have
all been to presentations where the presenter
said “it looks good on my machine at
home.”
11. Follow the contrast rule. If you are
going to use color in your application you
need to ensure that your screens are still
readable. The best way to do this is to follow
the contrast rule: Use dark text on light
backgrounds and light text on dark backgrounds.
It is very easy to read blue text on a white
background but very difficult to read blue
text on a red background. The problem is that
there is not enough contrast between blue
and red to make it easy to read, whereas there
is a lot of contrast between blue and white.
12. Use fonts appropriately –
Old English fonts might look good on the covers
of William
Shakespeare’s plays, but they are really
hard to read on a screen. Use fonts that are
easy to read, such as serif fonts like Times
Roman. Furthermore, use your fonts consistently
and sparingly. A screen using two or three
fonts effectively looks a lot better than
a screen that uses five or six. Never forget
that you are using a different font every
time you change the size, style (bold, italics,
underlining, ...), typeface, or color.
13. Gray things out, do not remove them.
You often find that at certain times it is
not applicable to give your users access to
all the functionality of an application. You
need to select an object before you can delete
it, so to reinforce your mental model the
application should do something with the Delete
button and/or menu item. Should the button
be removed or grayed out? Gray it out, never
remove it. By graying things out when they
shouldn’t be used people can start building
an accurate
mental model as to how your application works.
If you simply remove a widget or menu item
instead
of graying it out then it is much more difficult
for your users to build an accurate mental
model
because they only know what is currently available
to them, and not what is not available. The
old
adage that out of sight is out of mind is
directly applicable here.
14. Use non destructive default buttons.
It is quite common to define a default button
on every screen,
the button that gets invoked if the user presses
the Return/Enter key. The problem is that
sometimes
people will accidentally hit the Enter/Return
key when they do not mean to, consequently
invoking
the default button. Your default button shouldn’t
be something that is potentially destructive,
such as
delete or save (perhaps your user really did
not want to save the object at that moment).
15. Alignment of fields. When a screen
has more than one editing field you want to
organize the fields
in a way that is both visually appealing and
efficient. As shown in Figure 1 I have always
found that
the best way to do so is to left-justify edit
fields, or in other words make the left-hand
side of each edit
field line up in a straight line, one over
the other. The corresponding labels should
be right justified
and placed immediately beside the field. This
is a clean and efficient way to organize the
fields on a
screen.
16. Justify data appropriately. For
columns of data it is common practice to right
justify integers,
decimal align floating point numbers, and
left justify strings.
17. Do not create busy screens. Crowded
screens are difficult to understand and hence
are difficult to
use. Experimental results (Mayhew, 1992) show
that the overall density of the screen should
not
exceed 40%, whereas local density within groupings
shouldn’t exceed 62%.
18. Group things on the screen effectively.
Items that are logically connected should
be grouped
together on the screen to communicate that
they are connected, whereas items that have
nothing to do
with each other should be separated. You can
use whitespace between collections of items
to group
them and/or you can put boxes around them
to accomplish the same thing.
19. Open windows in the center of the action.
When your user double-clicks on an object
to display its
edit/detail screen then his or her attention
is on that spot. Therefore it makes sense
to open the
window in that spot, not somewhere else.
20. Pop-up menus should not be the only
source of functionality. Your users cannot
learn how to use
your application if you hide major functionality
from them. One of the most frustrating practices
of
developers is to misuse pop-up, also called
context-sensitive, menus. Typically there
is a way to use
the mouse on your computer to display a hidden
pop-up menu that provides access to functionality
that is specific to the area of the screen
that you are currently working in.
B. Prototyping
Prototyping is an iterative analysis technique
in which users are actively involved in the
mocking-up of
screens and reports. The purpose of a prototype
is to show people the possible design(s) for
the user
interface of an application. As we see in
Figure 2 there are four steps to the prototyping
process:
1. Determine the needs of your users.
The requirements of your users drive the development
of your
prototype as they define the business objects
that your system must support. You can gather
these
requirements in interviews, in CRC (class
responsibility collaborator) modeling sessions,
in use-case
modeling sessions, and in class diagramming
sessions (Ambler 1995; Ambler, 1998a; Ambler,
1998b).
2. Build the prototype. Using a prototyping
tool or high-level language you develop the
screens and
reports needed by your users. The best advice
during this stage of the process is to not
invest a lot of
time in making the code “good” because
chances are high that you may just scrap your
coding efforts
anyway after evaluating the prototype.
3. Evaluate the prototype. After a
version of the prototype is built it needs
to be evaluated. The main
goal is that you need to verify that the prototype
meets the needs of your users. I’ve always
found that
you need to address three basic issues during
evaluation: What’s good about the prototype,
what’s
bad about the prototype, and what’s missing
from the prototype. After evaluating the prototype
you’ll
find that you’ll need to scrap parts,
modify parts, and even add brand-new parts.
4. Determine if you’re finished yet.
You want to stop the prototyping process when
you find the
evaluation process is no longer generating
any new requirements, or is generating a small
number of
not-so-important requirements.
C. Prototyping Tips
and Techniques
I have covered the fundamentals of the prototyping
process, so now I want to share with you several
tips
and techniques that you can use to create
truly world-class prototypes.
1. Look for real-world objects. Good
UIs allow users to work with the real-world
objects they are used
to. Therefore you should start by looking
for these kinds of objects and identify how
people interact
with them.
2. Work with the real users. The best
people to get involved in prototyping are
the ones who will
actually use the application when it’s
done. These are the people who have the most
to gain from a
successful implementation, and these are the
ones who know their own needs best.
3. Set a schedule and stick to it.
By putting a schedule in place for when you
will get together with
your users to evaluate the prototype, you
set their expectations and you force yourself
to actually get
the work done. A win-win situation.
4. Use a prototyping tool. Invest the
money in a prototyping tool that allows you
to put screens
together quickly. Because you probably won’t
want to keep the prototype code that you write,
code
that’s written quickly is rarely worth
keeping, you shouldn’t be too concerned
if your prototyping tool
generates a different type of code than what
you intend to develop in.
5. Get the users to work with the prototype.
Just like you want to take a car for a test
drive before you
buy it your users should be able to take an
application for a test drive before it is
developed.
Furthermore, by working with the prototype
hands-on they will quickly be able to determine
whether
or not the system will meet their needs. A
good approach is to ask them to work through
some usecase
scenarios using the prototype as if it is
the real system.
6. Understand the underlying business.
You need to understand the underlying business
before you
can develop a prototype that will support
it. Perform interviews with key users, read
internal
documentation of how the business runs, and
read documentation about how some of your
competitors operate. The more you know about
the business the more likely it is that you’ll
be able to
build a prototype that supports it.
7. There are different levels of prototype.
I like to successively develop three different
types of
prototypes of a system: A hand-drawn prototype
that shows its basic/rough functionality,
an electronic
prototype that shows the screens but not the
data that will be displayed on them, and then
finally the
screens with data. By starting out simple
in the beginning I avoid investing a lot of
time in work that
will most likely be thrown away. By successively
increasing the complexity of the prototype
as it gets
closer to the final solution, my users get
a better and better idea of how the application
will actually
work, providing the opportunity to provide
greater and greater insight into improving
it.
8. Don’t spend a lot of time making
the code good. At the beginning of the
prototyping process you
will throw away a lot of your work as you
learn more about the business. Therefore it
doesn’t make
sense to invest a lot of effort in code that
you probably aren’t going to keep anyway
|
|
|
|
|
http://www.sameerchavan.com |
 |
Guidelines