CIS 251 - System Development Methods
Chapter 8: User Interface Design
Objectives:
This lesson discusses material from chapter 8. Objectives important
to this lesson:
- Interface design
- Interface components
- Output design
- Input design
- Assignments for the week
Concepts:
Chapter eight begins with the idea that interface
design is the first part of the system design phase of a project. It
is important to have everyone in your team making things that look like
they belong in the same application.
Page 236 begins a discussion of what user interfaces are, have been,
and typically look like currently. The text presents a couple of dichotomies
that show changes in interface design over time.
- process-control systems are characterized as older
interfaces that were based on the programs that the user needed to
run
The text also portrays this kind of interface as representative of
systems in which users had to make requests for simple reports through
the IT staff, instead of being able to ask for such reports themselves
through a system interface. User interfaces were typically limited
to character based screens, and were not major parts of systems.
- user-centered systems are described as being used
in more modern systems, allowing users to make requests for their
desired output without IT staff intervention
User interfaces became more complicated when technology supported
it, when systems began having graphics, and processing power supported
Graphic User Interfaces (GUIs).
This began around the time Windows was available on personal computers.
It was at that time that user interfaces became a feature of a system,
which naturally caused system developers to be interested in their
development.
It is a bit unfair of the authors to characterize the interfaces of
the sixties and seventies as less friendly to users, and to imply that
those character based systems were designed to be less friendly. It
is more accurate to describe them as being from the days of lower computing
power and less capable graphics cards. It is not so much that designers
did not think about the users' needs, but that there was not much a
designer could do with a system before we had decent graphics and pointing
devices (mice). We owe a great deal to the graphics card industry and
to Xerox
PARC.
The views of IBM are mentioned several times in this section of the
text. Their idea seems to be that a system should be as easy
to use as possible, and that it should allow users to get what they
want rapidly and painlessly. Page
240 presents a series of steps to follow in designing
a user interface. These steps echo the analysis methods in the previous
chapters. The difference is simply that they focus on interface design.
- Understand the business - Determine what the users
need to do in the interface, asking questions about
their needs and making charts of their intended use
of the system.
- Maximize graphical effectiveness - The text advises
us to use visual elements to help users function
and to learn the system. Good use of screen
space should be a goal for every system.
- Think like a user - This means more than getting
the user requirements. It means to understand what the users know,
what they are used to in a system, and what will
work from their point of view.
- Use models and prototypes - This is a reiteration
of the idea of making prototypes, showing
them to users, and improving the system based on
user feedback. An intermediate design step we have
not discussed in this context is the use of a storyboard.
A storyboard can be as simple as a comic strip, or can be a series
of mocked up screen shots.
- Focus on usability - The text recommends striking
a balance between too much on a
screen and too little. Another recommendation from
the world wide web is to minimize the number of clicks
needed to reach an objective. If a system takes too long
to use, it will not be successful.
- Invite feedback - The text reminds us to listen
to users during development, and to listen to their
comments after the system is deployed as well. The
testers of your system may not encounter features of the system that
the users will come to love or hate.
- Document everything - We have seen this advice
before. This time the advice is about user interfaces, but the general
idea is the same: record your findings, your tests, and your results.
You may continue a project or someone else may continue it, but no
one can do a good job without the information gathered at each step.
When you get to the actual design stage, you should follow the principles
that begin on page 241. Unfortunately, there is a good bit of repetition
in this list.
- Design a transparent interface - this means to
make the interface support the application and the user; don't make
it stand out so much that it gets in the way
- Make it easy to learn and use
- this makes perfect sense, but it is puzzling that this is a separate
point, since it was covered in the text's expansion of the point above
- Enhance productivity - A good interface makes a
user more productive, and a bad one makes a mess of an otherwise good
application. The text advises us to place commonly used options near
the top of menus, lists, and screen sequences. Shortcut keyboard sequences
are recommended, but they can also be problematic. Make sure that
users want your shortcuts, and that they do not get in the
way. Let me tell you about the keyboard shortcuts
in 3DS Max.
- Two concepts: Make it easy to get help, Make it
easy to correct errors
Both concepts have to do with something going wrong. Typically, help
systems address user training that has not taken place, while error
correction addresses mistakes on the part of the user, the data provided,
or the system itself. The point is that it should be easy to find
out how to do something and how to change data that should not be
in the system. The interface should not be so automatic that the user
can't back away from a wrong choice.
- Minimize data input problems - the most common
advice is to make data input screens mimic
the forms or screens that users gather their data
from; the text advises that you should build data entry rules
(validation rules) in the system so that only acceptable data may
be entered in any field
- Provide feedback to users - the suggestion should
have said "meaningful feedback"; many systems
provide error messages that are uninformative, which lowers productivity;
avoid this problem by giving users helpful prompts
and error messages
This item relates directly to the previous item. They could have been
combined into one.
- Create an attractive layout - the advice in this
section is about functionality as well as aesthetics; go over all
the suggestions in this list
- Use familiar terms and images
- this one relates to the advice to know the users and how they think;
it's a waste of your time and the user's time to explain things in
terms that are unfamiliar to the user
The text continues with a list of control features
to consider including in your interfaces. The list is about control
in the sense of operational control, not security.
This is really a list of commonly found objects in a GUI, specifically
features found in Windows interfaces. The features apply to iOS, Android,
and other operating systems as well.
The chapter turns to Output design on page 254. It
begins with standard questions that should be asked
about the reports any system should produce.
- What is the report for?
- Who gets the report? What security restrictions apply?
- What information will be in the report?
- Is the report to go to a screen, a file, a printer, or elsewhere?
- Is the report to be run on a schedule, or on demand?
The text discusses report types and components
for several pages. You should have encountered these concepts in programming
and database classes. Review these concepts starting on page 255:
- detail reports
- exception reports
- summary reports
- report features starting on page 256
Output is not limited to what most people would consider a report.
Other output types are listed on pages 259 and 260.
Remember that a system may output credentials, receipts,
purchased tickets and coupons, and
other documents and objects not listed in the chapter.
On page 261, the text turns to Input design, which
may seem backwards to you. I hope it does not. This is an application
of a common technique you have been advised about in several chapters:
decide what the system must produce first, then use
that information to decide what must be put into it
to make that production possible.
The text refers to the classic warning about input:
garbage in, garbage out. When you enter bad data, the
system can only produce bad output. In a way, it is comforting to see
this familiar advice. It reminds us that we know what to do, we just
have to make sure we are doing it.
The text discusses source documents, back on page 253, in terms of
proper design of forms. A form can be a piece of paper
or an input screen for a system. It doesn't matter
if it is a paper or electronic form: proper design says to make it easier
to use than the last tool. The text offers some advice on good form
design. Consider some of these points:
- make the form flow left to right and top
to bottom: this leads to less scrolling, and fewer items
being missed. The authors assume you are creating the form in English
or another language that flows this way. If you are creating a system
in a language that does not follow this flow on a page, you
should follow the natural flow of that language instead.
- make the instructions easy to see: consider instructions
for each part of the form, or mouseover help on fields
that need examples
- validate data as it is input instead
of waiting for the user to reach the end of the form
- if using paper forms whose data must be transferred
to an IT system, make the paper form and the data
entry screens as much alike as possible
A previous version of the text discussed the opinion of Dr.
Jakob Nielsen, who says that users do not read
web pages, they only scan them. I would agree, up to
a point. I encountered a particularly bad case of this behavior not
long ago. A student told me he could not follow my notes, and that he
needed to see how something is done to learn it. (Despite the
fact that I had just demonstrated how to do it it. I have doubts about
his chances of success in life.) I hope he is not typical of students
or workers, but Dr. Nielsen seems to believe that many people have learned
that they do not have to pay attention to something
on a web page. I am sure the phishing scammers love this idea. We can
hope that students and workers are motivated enough to notice what is
in front of them. Apparently, we cannot expect a customer to meet any
standard of attentiveness.
- Make each screen short and pleasant.
- Keep to the point.
- Don't ask for things you don't need.
Review the points about screen elements that help
users input data (formatting, examples,
error trapping). If you are an analyst, but not a programmer,
it may not have occurred to you that a system can impose the kinds of
error checks presented. A well designed system should include all of
these where needed. (If you are a programmer, but not an analyst, you
may be shocked to learn that a user will enter unformatted or inappropriate
data in a field. Welcome to the real world.)
