How do you know when you have included enough “intelligence” in a decision support
system? Provide 3 examples of user interfaces that support your answer.
Need about 2-3 pages with peer-reviewed references. APA formatted. Attached chapter for the week.
Note: No AI generated content. It gets filtered out in plagiarism check!
USER INTERFACE
To the decision maker, the use
r
interface is the DSS
.
The user interface includes all the
mechanisms by which commands, requests, and data are entered into the DSS as well as
all the methods by which results and information are output by the system. It does not
matter how well the system performs; if the decision maker cannot access models and data
and peruse results, invoke assistance, share results, or in some other way interact with the
system, then the system cannot provide decision support. In fact, if the interface does not
meet their needs and expectations, decision makers often will abandon use of the system
entirely regardless of its modeling power or data availability.
To paraphrase Dickens, it is the most exciting of times for designing user interfaces,
and it is the most frustrating of times for designing user interfaces. It is an exciting
time because advances in computing technologies, interface design, and Web and mobile
technologies have opened a wide range of opportunities for making more useful, more easily
used, and more aesthetically pleasing representations of options, data, and information.
It is a frustrating time because legacy systems still exist, and there are a wide range
of user preferences. Some DSS must be built using technologies that actually limit the
development of user interfaces. Others must at least interact with such legacy systems and
are therefore limited in the range of options available. In this chapter, the focus will be
on the future. However, remember that “the future” may take a long time to get to some
installations.
Decision Support Systems for Business Intelligence by Vicki L. Sauter
Copyright © 2010 John Wiley & Sons, Inc.
215
USER INTERFACE
GOALS OF THE USER INTERFACE
The purpose of the user interface is communication between the human and the computer,
known as human-computer interaction (HCI). As with person-to-person communication,
the goal of HCI is to minimize the amount of incorrectly perceived information (on both
parts) while also minimizing the amount of effort expended by the decision maker. Said
differently, the goal is to design systems that minimize the barrier between the human’s
cognitive model of what they want to accomplish and the computer’s understanding of the
user’s task so that users can avail themselves of the full potential of the system.
Although there has been an active literature on HCI since the 1990s, the actual im-
plementation of that goal continues to be more an “art” than a science. With experience,
designers become more attuned to what users want and need and can better provide it
through good color combinations, appropriate placement of input and output windows, and
generally good composition of the work environment. The key to making the most out of
it is knowing when to apply it. Some of the material is quite pertinent for all user interface
design. Other material applies only in certain circumstances. But there are some guiding
principles and those will be discussed first.
A prime concern of this goal is the speed at which decision makers can glean available
information. Humans have powerful pattern-seeking visual systems. If they focus, humans
can perceive as many as 625 separate points in a square inch and thus can realize substantial
information. The eyes constantly scan the environment for cues, and the associated brain
components act as a massive parallel processor, attempting to understand the patterns among
those cues. The visual system includes preattentive processing, which allows humans to
recognize some attributes quite quickly, long before the rest of the brain is aware that it has
perceived the information. Good user interfaces will exploit that preattentive processing to
get the important information noticed and perceived quickly. However, the information is
sent to short-term visual processing in our brain, which is limited and is purged frequently.
Specifically, the short-term visual memory holds only three to nine chunks of information
at a time. When new information is available (we see another image), the old information
is lost unless it has been moved along to our attention. Hence we lose the information
before it is actually perceived. Since preattentive processing is much faster than attentive
processing, one goal is to encode important information for rapid perception. If the data are
presented well, so that important and informative patterns are highlighted, the preattentive
processes will discern the patterns and then they will stand out. Otherwise the data may be
missed, be incomprehensible, or even be misleading.
The attributes that invoke the preattentive processing include the hue and intensity of
the color, the location, the orientation, the form of the object (width, size, shape, etc.), and
motion. For example, more intense colors are likely to provoke preattentive processing,
especially if those around it are more neutral. Longer, wider images will get more attention,
as will variations in the shapes of the items and their being grouped together. However,
clutter, too much unnecessary decoration, and an effort to overdesign the interface may
actually slow down the perception and therefore work against us.
In addition to making the information quickly apparent, the user interface must be
effective. These interfaces must allow users to work in a comfortable way and to focus
on the data and the models in a way that supports a decision. Equally important is that
the interface must allow these things without causing users frustration and hesitation and
without requiring them to ask questions. This requires designers to make navigation of the
system clear to ensure that decision makers can do what they need to do easily. It also
requires the designers make the output clear and actionable. To accomplish this, designers
GOALS OF THE USER INTERFACE
should organize groups, whether they be menus, commands, or output, according to a well-
defined principle, such as functions, entities, or use. In addition, designers should colocate
items that belong to the same group. This might mean keeping menu items together or
putting results for the same group together on the screen. Output should be organized to
support meaningful comparisons and to discourage meaningless comparisons.
A third overall principle of interface design is that the user interfaces must be easily
learned. Designers want the user to master operation of the system and relate to the system
intuitively. To achieve this goal, they must be simple, structured, and consistent so that users
know what to expect and where to expect it on the screen. A simple and well-organized
interface can be remembered more easily. These systems have a minimum number of user
responses, such as pointing and clicking, that require users to learn few rules but allow
those rules to be generalized to more complexity. Well-designed systems will also provide
good feedback to the user about why some actions are acceptable while others are not and
how to fix the problem of the unacceptable actions. Such feedback can take the form of
the hour glass to demonstrate the system is processing to useful error messages if it is not.
Similarly, tolerant systems that allow the user multiple ways to achieve a goal adapt to the
user, thereby allowing more natural efforts to make a system perform.
The goal of making the interface easily learned (and thus used) is complicated because
every system will have a range of users, from beginners to experts, who have different
needs. Beginners will need basic information about the scope of a program or specifics
about how to make it work. Experts, on the other hand, will need information about how
to make the program more efficient, with automation, shortcuts, and hot keys, and the
boundaries of safe operation of the program. In between, users need reminders on how to
use known functions, how to locate unfamiliar functions, and how to understand upgrades.
All of these users rely not only on the information available with the user interface but also
on the feedback that the system provides to learn how to use the system. Feedback that
helps the users understand what they did incorrectly and how to adjust their actions in the
future is critical to learning. Not only must the feedback be provided, but also it must be
constructive, helping the user to understand mistakes, not to increase his or her frustration.
It should provide clear instructions about how to fix the problem.
Finally usable systems are ones that satisfy the user’s perceptions, feelings and opinions
about the decision. Norman (2005) says that this dimension is impacted significantly by
aesthetics. Specifically, he says that systems that are more enjoyable, makes users more
relaxed and open to greater insight and creative response. The user interface should not be
ugly and should fit the culture of the organization. Designers should avoid “cute” displays,
unnecessary decoration and three-dimensional images because they simply detract from
the main effort. Cooper (2007) believes that designing harmonious, ethical interactions that
improve human situations and are well behaved is critical to satisfying user needs. Cooper
(2007, p. 203) provides some guidance about creating harmonious interactions with the
following:
• Less is more.
• Enable users to direct, don’t force them to discuss.
• Design for the probably; provide for the possible.
• Keep tools close at hand.
• Provide feedback.
• Provide for direct manipulation and graphical input.
• Avoid unnecessary reporting.
218 USER INTERFACE
• Provide choices.
• Optimize for responsiveness; accommodate latency.
By “ethical,” Cooper (2007, p. 152) means the design should do no harm. He identifies
the kinds of harm frequently seen in systems that should be avoided in DSS design as
follows:
• Interpersonal harm with insults and loss of dignity (especially with error messages)
• Psychological harm by causing confusion, discomfort, frustration, or boredom
• Social and societal harm with exploitation or perpetuation of justice
Cooper (2007, p. 251) also provides guidance about designing for good behavior when he
notes that products should:
• Personalize user experience where possible
• Be deferential
• Be forthcoming
• Use common sense
• Anticipate needs
• Not burden users with internal problems with operations
• Inform
• Be perceptive
• Not ask excessive questions
• Take responsibility
• Know when to bend the rules
Throughout the chapter, we will discuss the specifics these overriding principles of
user interface design. The primary goal is to design DSS that make it easy and comfortable
for decision makers to consider ill-structured problems, understand and evaluate a wide
range of alternatives, and make a well-informed choice.
MECHANISMS OF USER INTERFACES
In addition to understanding the principles of good design, it is important to review the
range of mechanisms for user interfaces that exist today and those mechanisms that are
coming in the near future. Everyone is familiar with the keyboard and the mouse as
input devices and the monitor as the primary output device. Increasingly users are relying
upon portable devices. Consider, for example, the pen-and-gesture-based device shown
in Figure 5.1. Information is “written” on the device and saved using handwriting and
gesture recognition. This allows the device to go where the decisions are, such as an
operating room, and to provide flexible support. Or, the user might rely upon a mobile
phone, with much smaller screens such as the ones shown in Figure 5.2. These mobile
devices have a substantially smaller screen yet have much higher resolution. On the other
hand, if the decision makers will include a group, they might rely upon wall systems to
MECHANISMS OF USER INTERFACES 219
Figure 5.1. Pen-based system. HP Tablet. Photo by Janto Dreijer. Available at http://www.
wikipedia.com/File:Tablet:jpg used under the Creative Commons Attribution ShareAlike 3.0
License.
Figure 5.2. Mobile phones as input and output devices.
220 USER INTERFACE
Figure 5.3. Wall screens as displays. Ameren UE’s Severe Weather Centre. Photo reprinted cour-
tesy of Ameren Corporation.
display their output, such as those shown in Figure 5.3. These large screens may have lower
resolution. Designing an interface for anything from a screen 5 in. x 3 in. with gestures and
handwriting recognition to one that might take the entire wall and use only voice commands
is a challenging proposition. User interfaces are, however, getting even more complicated
for design. Increasingly, virtual reality is becoming more practical for DSS incorporation,
so your system might include devices such as those shown in Figure 5.4 or even something
like the wii device shown in Figure 5.5.
The future will bring both input and output devices that are increasingly different from
the keyboard and the monitor that we rely upon today. Consider the device shown in Figure
5.6, which was developed in the MIT Media Laboratory. The device is a microcomputer. It
includes a projector and a camera as two of the input/output devices. This device connects
with the user’s cell phone to obtain Internet connectivity. The decision maker can use his
or her hands, as the user is doing in the photograph, to control the computer. The small
bands on his hands provide a way for the user to communicate with the camera and thus
the computer. This projection system means that any surface can be a computer screen and
that one may interact with the screen using just one’s fingers, as shown in Figure 5.7. In this
figure, the user is selecting from menus and beginning his work. You can integrate these
features into any activity. Notice how the user in Figure 5.8 has invoked his computer to
supplement the newspaper article with a video from a national news service. Or, the decision
maker can get information while shopping. Figure 5.9 shows a person who is considering
purchasing a book in a local bookstore. Among the various kinds of information considered
is the Amazon rating and Amazon reviews pulled up from his computer. Notice how they
are projected on the front of the book (about halfway down the book cover).
It is important to think creatively about user interfaces to be sure that we provide the
richest medium that will facilitate decision making. Different media require different design
MECHANISMS OF USER INTERFACES 221
Figure 5.4. Virtual reality devices. Ames developed (Pop Optics) now at the Dulles Ames of the
National Air and Space Museum. Source: http://gimp-savvy.com/cgi-bin/ing.cgi7ailsxmzVn080jE094
used under the Creative Commons Attribution ShareAlike 3.0 License.
and there is not a “one size fits all.” It is important to think of the medium as a tool and let
context drive the design and to customize for a specific platform. The general principles of
this chapter will help readers evaluate the needs of the user and the medium. Most of the
examples, however, will focus on current technologies.
Figure 5.5. A wii device. Wii remote control. Image from http://en.wikipedia.org/wiki/File:
Wiimote-lite2 used under the Creative Commons Attribution ShareAlike 3.0 License.
222 USER INTERFACE
Figure 5.6. MIT Media Lab’s view of user interface device. Demonstration of the Sixth Sense
Project of the MIT Media Lab. Photo taken by Sam Ogden. Photo reprinted courtesy of the MIT
Media Laboratory, P. Maes, Project Director, and P. Mistry, Doctoral Student, (pictured).
Figure 5.7. MIT Media Lab’s view of user interface device. Demonstration of the Sixth Sense
Project of the MIT Media Lab. Photo taken by Lynn Barry. Photo reprinted courtesy of the MIT
Media Laboratory, P. Maes, Project Director, and P. Mistry, Doctoral Student (pictured).
DSS in Action
Friends
The FRIEND system is an emergency dispatch system in the Bellevue Borough, north of Pitts-
burgh, Pennsylvania. This system, known as the First Responder Interactive Emergency Naviga-
tional Database (FRIEND), dispatches information to police using hand-held computers in the
field. The hand-held devices are too small to support keyboards or mice. Rather police use a stylus
to write on the screen or even draw pictures. These responses arc transmitted immediately to the
station for sharing. Police at the station can use a graphical interface or even speech commands
to facilitate the sharing of information to members in the field.
USER INTERFACE COMPONENTS 223
Figure 5.8. MIT Media Lab’s view of user interface device. Demonstration of the Sixth Sense
Project of the MIT Media Lab. Photo taken by Sam Ogden. Photo reprinted courtesy of the MIT
Media Laboratory, P. Maes, Project Director, and P. Mistry, Doctoral Student.
USER INTERFACE COMPONENTS
We must describe the user interface in terms of its components as well as its mode of
communication, as in Table 5.1. The components are not independent of the modes of
communication. However, since they each highlight different design issues, we present
them separately—components first.
Figure 5.9. MIT Media Lab’s view of user interface device. Demonstration of the Sixth Sense
Project of the MIT Media Lab. Photo taken by Sam Ogden. Photo reprinted courtesy of the MIT
Media Laboratory, P. Maes, Project Director, and P. Mistry, Doctoral Student.
USER INTERFACE
Table 5.1. User Interfaces
User interface components
• Action language
• Display or presentation language
• Knowledge base
Modes of communication
• Mental model
• Metaphors and idioms
• Navigation of the model
• Look
Action Language
The action language identifies the form of input used by decision makers to enter requests
into the DSS. This includes the way by which decision makers request information, ask for
new data, invoke models, perform sensitivity analyses, and even request mail. Historically,
five main types of action languages have been used, as shown in Table 5.2.
Menus. Menus, the most common action language today, display one or more lists of
alternatives, commands, or results from which decision makers can select. A menu provides
a structured progression through the options available in a program to accomplish a specific
task. Since they guide users through the steps of processing data and allow the user to avoid
knowing the syntax of the software, menus often are called “user friendly.” Menus can be
invoked in any number of ways, including selecting specific keys on a keyboard, moving
the mouse to a specific point on the screen and clicking it, pointing at the screen, or even
speaking a particular word(s).
In many applications, menus exist as a list with radio buttons or check boxes on a
page. Or the menu might be a list of terms over which the user moves the mouse and clicks
to select. Or the menu might actually exist as a set of commands in a pull-down menu
such as seen in the menu bar. As most computer users today are aware, you can invoke the
pull-down menu by clicking on one of the words or using a hot-key shortcut. When this
is done, a second set of menus is shown below the original command, as illustrated with
Analytical menu bar shown in Figure 5.10.
Menus and menu bars should not be confused with the toolbars available on most
programs. In Figure 5.10, the toolbar is the set of graphical buttons shown immediately
below the menu bar. They might also show up as part of the “ribbon bar” that Microsoft has
built into its 2007 Access, shown in Figure 5.11. These toolbars provide direct access to
some specific component of the system. They do not provide an overview of the capabilities
and operation of a program in the way that menus do but rather provide a shortcut for more
experienced users.
Table 5.2. Basic Action Language Types
Menu format
Question-answer format
Command language format
Input/output structured format
Free-form natural language format
USER INTERFACE COMPONENTS 225
Figure 5.10. One form of a menu. Menu from Analytica. Used with permission of Lumina
Decision Systems.
Menu formats use the process of guiding the user through the steps with a set of pictures
or commands that are easy for the user to understand. In this way, the designer can illustrate
for the user the full range of analyses the DSS can perform and the data that can be used for
analysis. Their advantage is clear. If the menus are understandable, the DSS is very easy to
use; the decision maker is not required to remember how it works and only needs to make
selections on the screen. The designer can allow users keyboard control (either arrow keys
or letter key combinations), mouse control, light pen control, or touch screen control.
Menus are particularly appealing to inexperienced users, who can thereby use the
system immediately. They may not fully understand the complexity of the system or the
range of modeling they can accomplish, but they can get some results. The menu provides a
pedagogical tool describing how the system works and what it can do. Clearly this provides
an advantage. In the same way, menu formats are useful to decision makers who use a DSS
only occasionally, especially if there are long intervals between uses. Like the inexperienced
user, these decision makers can forget the commands necessary to accomplish a task and
hence profit by the guidance the menus can provide.
Menu formats tend not to be an optimal action language choice for experienced users,
however, especially if these decision makers use the system frequently. Such users can be-
come frustrated with the time and keystrokes needed to process a request when other action
language formats can allow them access to more complex analyses and more flexibility.
This will be discussed in more depth under the command language.
Figure 5.11. A “ribbon bar” as a menu. Microsoft’s “Ribbon” in Excel 2007 from http://en.wikipedia.com/wiki/
File:office2007vibbon . Used under the Creative Commons Attribution ShareAlike 3.0 License.
226 USER INTERFACE
Figure 5.12. Independent command and object menus.
The advantage of the menu system hinges on the understandability of the menus. A
poorly conceived menu system can make the DSS unusable and frustrating. To avoid such
problems, designers must consider several features. First, menu choices should be clearly
stated. The names of the options or the data should coincide with those used by the decision
makers. For example, if a DSS is being created for computer sales and the decision makers
refer to CRTs as “screens,” then the option on the menu ought to be “screen” not “CRT.
”
The latter may be equivalent and even more nearly correct, but if it is not the jargon used
by decision makers, it may not be clear. Likewise, stating a graphing option as “HLCO,”
even with the descriptor “high-low-close-open,” does not convey sufficient information to
the user, especially not novice or inexperienced user.
A second feature of a well-conceived menu is that the options are listed in a logical
sequence. “Logical” is, of course, defined by the environment of the users. Sometimes
the logical sequence is alphabetical or numerical. Other times it is more reasonable to
group similar entries together. Some designers like to order the entries in a menu according
to the frequency with which they are selected. While that can provide a convenience for
experienced users, it can be confusing to the novice user who is after all the target of the
menu and may not be aware of the frequency of responses. A better approach is to preselect
a frequently chosen option so that users can simply press return or click a mouse to accept
that particular answer. Improvements in software platforms make such preselection easier
to implement, as we will discuss later in the chapter.
When creating a menu, designers need to be concerned about how they group items
together. Generally, the commands are in one list, and the objects of the commands1 are in
an alternate list, as shown in Figure 5.12. Of course, with careful planning, we can list the
commands and objects together in the same list, as shown in Figure 5.13, and allow users
to select all attributes that are appropriate.
In today’s programming environment, designers tend not to combine command and
object menus. The primary reason to combine them in the past was to save input time for
the user since each menu represented a different screen that needed to be displayed. Display
!The “objects of the commands” typically refer to the data that should be selected for the particular
command invoked.
USER INTERFACE COMPONENTS 227
Figure 5.13. Combined command and object menu.
changes could be terribly slow, especially on highly utilized, old mainframes. The trade-
off between processing time and grouping options together seemed reasonable. For most
programming languages and environments, that restriction no longer holds. Several menus
on the same screen can all be accessed by the user. Furthermore, most modeling packages
allow a user several options, depending upon earlier selections. If these were all displayed in
a menu, the screen could become quite cluttered and not easy for the decision maker to use.
An alternative is to provide menus that are nested in a logical sequence. For example,
Figure 5.14 demonstrates a nested menu that might appear in a DSS. All users would begin
the system use on the “first-level” menu. Since the user selected “graph” as the option, the
system displays the two options for aggregating data for a graph: annually and quarterly.
Figure 5.14. Nested menu structure.
USER INTERFACE
Note that this choice is provided prior to and independent of the selection of the variables
to be graphed so that the user cannot inadvertently select the x axis as annual and the y axis
as quarterly data (or vice versa).
The “third-level” menu item allows the users to specify what they want displayed on the
y axis. While this limits the flexibility of the system, if carefully designed, it can represent
all options needed by the user. Furthermore, it forces the user to declare what should be the
dependent variable, or the variable plotted on the y axis, without using traditional jargon.
This decreases the likelihood of misspecification of the graph.
The “fourth-level” menu is presented as a direct response to the selection of the
dependent variable selection. That is, because the decision maker selected La Chef sales,
the system “knows” that the only available and appropriate variables to present on the x
axis are price, advertising, and the competitor’s sales. In addition, the system “knows” that
the time dimension for the data on the x axis must be consistent with that on the y axis
and hence displays “quarterly” after the only selection that could be affected. Note that
the system does not need to ask how users want the graph displayed because it has been
specified without the use of jargon.
Finally, the last menu level allows the users the option of customizing the labeling
and other visual characteristics of their graphs. Since the first option, standard graph, was
selected, the system knows not to display the variety of options available for change. Had
the user selected the customize option, the system would have moved to another menu that
allows users to specify what should be changed.
In early systems, designers needed to provide menu systems that made sense in a fairly
linear fashion. While they could display screens as a function of the options selected to that
point, such systems typically did not have the ability to provide “intelligent” steps through
the process. Today’s environments, which typically provide some metalogic and hypertext
functionality as well as some intelligent expertise integrated into the rules, can provide
paths through the menu options that relieve users of unnecessary stops along the way.
Depending upon the programming environment, the menu choices might have the
boxes, or radio buttons illustrated in Figure 5.12 or underscores or simply a blank space.
The system might allow the user to pull down the menu or have it pop up with a particular
option. Indeed, in some systems, users can click the mouse on an iconic representation of
the option. These icons are picture symbols of familiar objects that can make the system
appear friendlier, such as a depiction of a monthly calendar for selecting a date.
Ideally the choice from among these options is a function of the preferences of the
system designers and users. In some cases, the choice will be easy because the programming
environment only will support some of the options. In still other cases, multiple options
are allowed, but the software restricts the meaning and uses of the individual options. For
example, in some languages, the check box will support users selecting more than one of
the options whereas the radio button will allow users to select only one. Before designing
the menus, designers need to be familiar with the implications of their choices.
However the options are displayed on the screen, users might also have a variety
of ways of selecting them. In most systems, the user would always have the arrow keys
and “enter” key to register options. Similarly, most systems support pressing a character
(typically the first letter of the command) to select an option. Many systems also support
the use of a mouse in a “point-and-click” selection of options. Less often, we find a touch
screen, where the user literally selects an option by touching the word or the icon on the
screen, or a light pen, where the user touches the screen with the end of a special pen. In
a voice input system, the user selects an option by speaking into a microphone connected
to the computer. The computer must then translate the sound into a known command
USER INTERFACE COMPONENTS 229
Figure 5.15. Question-answer format.
and invoke the command. This option is still rare. Voice systems can accept only limited
vocabulary and must be calibrated to the speech patterns of each user.
Question-Answer Format A second option for the action language is to provide
users questions they must answer. In the text form, this is actually a precursor to the modern
menu and tends to be found only in legacy systems. However, the option appears in newer
systems that use voice activation of menus. Since it is easier to show the text form in the
book, that is the example that will be used. An example of computer questions and user
answers is shown in Figure 5.15.
One attribute of the question-answer format in some environments is the opportunity
to embed information into the questions. Such information might be the name of the user,
the project of interest, or other information regarding the use of the system. For example,
the previous example could be redefined as shown in Figure 5.16. While some users
respond favorably to the use of their name in these questions, others find it quite annoying.
Furthermore, the use of the personalized questions tends to slow down the processing and
make the questions appear much longer and more difficult to read.
The goal of the question-answer approach is to give the appearance of flexibility in
proceeding through the options of the system. Indeed, its usefulness is optimized when it
is most flexible. The question-answer format works best when the user has more control
over the system and its options. However, coding such flexibility can be infeasible in many
programming environments. Thus this type of action language is generally implemented as
a fixed sequence and format, which is very rigid and often limiting to the user.
Command Language. The command language format allows user-constructed
statements to be selected from a predefined set of verbs or noun-verb pairings. It is similar
to a programming language that has been focused on the task of the DSS. An example of a
command language format is shown in Figure 5.17.
The command language format allows the user to control the systems’ operations
directly providing greater latitude in choosing the order of the commands. In this way, the
230 USER INTERFACE
Figure 5.16. Personalized question-answer format.
user is not bound by the predetermined sequencing of a menu system and can ignore the
use of options that are not pertinent to a specific inquiry. It can be structured hierarchically,
however, so that one major command will control all auxiliary commands unless specific
alternations are required. Notice that in the example the user must specify the columns and
rows to be able to display a menu. In the event the user wants more control over the report,
he or she can have it, as shown in the latter parts of Figure 5.17.
More importantly, command language gives the user complete access to all the options
available. Hence, users can employ the full range of commands and the full variety of
subcommands. Since the combinations and the ways in which they are used are unlimited,
Figure 5.17. Command language format.
USER INTERFACE COMPONENTS 231
the user has greater power than is available with any other action language format. The
command language format is thus appreciated by the “power” user, or the experienced and
frequent user who wants to push the system to its full capability.
However, such a format is a problem for the infrequent user and a nightmare to the
inexperienced user who is likely to forget the commands or the syntax of their use. Such
problems can be mitigated with the use of “help menus,” especially those that are context
sensitive.
Generally DSS do not support only command language formats because of their in-
accessibility. However, good design typically allows both a menu format and a command
language format. In this way, the user has the ability to make the trade-offs between
flexibility (or power) and ease of use.
Input-Output Structured Formats. The input-output (I/O) structured formats
present users with displays resembling a series of forms, with certain areas already com-
pleted. Users can move through the form and add, change, or delete prespecified information
as if completing the form by hand. Like question-answer formats, this kind of user interface
tends to be associated primarily with legacy systems.
Consider a DSS used by builders or designers of homes. Once they are satisfied with
their design requirements, they need to place an order to acquire the necessary materials.
While ordering is not the primary function of the DSS, it might be very useful if they could
simply take the information from their design specifications and move it to an order form
like the form shown in Figure 5.18. Once the users are satisfied with the completed form,
they can send it directly to the wholesaler.
Figure 5.18. I/O structured format.
USER INTERFACE
It is not surprising that such I/O structured formats are not commonly seen in DSS,
because they replicate a repeated, structured manual process. They should not be a primary
action language option in a DSS; however, they can be used as a supplement. It makes
sense to include an order form as a part of the DSS in our example because its function
is integrated with the primary function of the system. Since the completion of the form is
integrated with the development of the design, as design features change, the form will be
updated immediately. For example, if the designer later finds a need for three items, rather
than the two items first entered into the form, the order form will be updated immediately.
Or, if the designer decides a conventional widget will not suffice and substitutes an oblique
widget, the form will be updated automatically.
The question that should be troubling you is, why have the designer complete the order
form at all? Why not have a clerk place the order? Under some circumstances that might
be reasonable. However, a designer tends to have preferences for styles, workmanship, and
other factors of particular manufacturers. Part of the actual design is in fact the selection of
the manufacturer. Or, the designer might want to complete some cost sensitivity analyses
on a particular design in order to make trade-offs among various options which could have
differential impact on the total cost. Hence, the costing function must be part of the DSS.
However, part of the functionality of the system might be to send information to clerks
about parts not specified by the designer so they can actually place the orders.
Free-Form Natural Language. The final action language option is the one most like
conventional human communication. By “free-form,” we imply that there is no preconceived
structure in the way commands should be entered. By “natural language,” we imply that
the terms used in the commands are not specified by the system but rather are chosen by
the users themselves. Hence, the system cannot rely upon finding “key terms” in the midst
of other language (as it might with the question-answer format), because they may not be
present. For example, rather than requesting a “report,” users might request a “summary”
or a “synopsis” of the information. The system must be able to scan a request, parse the
language, and determine that the requested summary is actually a report. So the same
request that was presented in Figure 5.15 (in the question-answer section) might now be
presented as in Figure 5.19.
Figure 5.19. Free-form natural language format.
USER INTERFACE COMPONENTS 233
While parsing of this request can be accomplished, it takes extra computer power
and extra processing time. Under conditions of limited possibilities for the requests, such
systems have been shown to perform adequately. However, this approach might produce an
inappropriate result, especially if the user has particularly unusual terminology (as might
be the case if the system serves users transnationally) or if the range of options is large. The
possibility is troubling because the requested information might be close to the intended
result and the error might not be noticed.
If the input medium is voice, a free-form natural language format can become particu-
larly difficult to implement because of the implications of intonation and the confusion of
homonyms. On the other hand, it is with voice input that natural language makes the most
sense, especially for addressing special circumstances or needs. Such systems have their
greatest contribution in serving handicapped users who cannot use other input mechanisms.
Under these conditions, the extra programming and computer needs are justified because
they provide empowerment to users.
Display or Presentation Language
While the action language describes how the user communicates to the computer, the second
aspect, the presentation language, describes how the computer provides information back
to the user. Of course, such an interface must convey the analysis in a fashion that is
meaningful to the user. This applies not only to the results at the end of an analysis but
also to the intermediary steps that support all phases of decision making. Furthermore,
the presentation must provide a sense of human control of the process and of the results.
All of this must be accomplished in a pleasing and understandable fashion without unduly
cluttering the screen.
Visual Design Issues. The goal of the display of a DSS is for people to be able to
understand and appreciate the information provided to them. The display should help users
evaluate alternatives and make an informed decision and do that with a minimum amount
of work. Don’t make the users think about how to use the system, but rather encourage
them to think about the results the system is providing. To that end, displays should be
simple, well organized, understandable, and predictable.
Since 1992, IBM has worked with the Olympic Committee to create the Olympic Technology
Solution. This tool was written in object code for use in future Olympic games. The system works
with 40,000 volunteers as well as countless home users. This requires the system to be truly human
centric and accessible. Part of the secret in achieving clarity of the user interface is to separate the
various components of the system into separately accessed modules. Hence, users can focus on
the Results System, the Press Information System, the Commentator Information System, or the
Games Management System. The Results System will deliver times to the 31 Olympic venues,
the pagers, and the Internet. Hence, scoreboards and a Web page will obtain their information
from the same source at approximately the same time. The Press Information System and the
Commentator Information System get not only the game results but also personalized athlete
profiles and other statistical information. The Games Management System handles all of the
operational information for the games.
USER INTERFACE
The first rule of design is that the display should be readable. Of course that means that
it should be understandable and not overly verbose. All interfaces should use the fewest
possible words and the terminology used on the display should be that of the user, not
the designers. Readability also implies that you can discern the words. Reading is really a
form of pattern recognition, and so a combination of uppercase and lowercase letters is the
easiest text to read. The chosen font should also be selected to help users recognize patterns.
Although most written word uses serif fonts, researchers have found they are harder to dis-
cern on a display. Instead designers should use a sans serif font, such as Arial, Helvetica, or
Tahoma. In addition, the font size should be large enough for comfortable reading; generally
this requires a font size of at least 10 pixels. Finally, to allow pattern recognition implies that
the user can discern the letters. This requires there to be the greatest contrast between the
color of the background and the font as possible. If the colors are too close together, such as
navy and black or yellow and white, users will have difficulty finding the letters. Of course,
if your interface is audible, then similar rules apply, such as making the words clear, talking
slowly enough to discern words, and avoiding background sounds that get in the way.
The second rule of design is to control color. There is the temptation for designers to
use every color that is available to them. But, using many colors increases the time it takes
users to discern the information on the screen. Instead of making it easier to see patterns,
users actually spend more time trying to remember what the various colors mean and may
actually miss the patterns afforded to them. Similarly, designers should limit the number of
saturated colors used and take care in their placement. The basic display should use neutral
colors, which have a calming and actually encourage people to stay looking at it. As stated in
the previous paragraph, there must be enough contrast between items for the user to discern
them. However, designers should take care not to use saturated complementary colors
because that much difference actually causes optical illusions. On a neutral background,
bright colors, used selectively, can focus the users’ attention to important or concerning
results on the display. Or designers can highlight relationships and similarities by repeating
colors for different information. Finally, designers should take care that colors are not the
only cues available since many individuals have some form of color blindness and thus will
not be able to discern the differences.
The third rule of design is to control location and size. On a display, the largest item
and the one in the top, left corner will get the users’ attention first. Using that information,
designers can display items so as to help users to find the most important, the most critical,
the most frequently used, or the most summarized information. The order in which items
appear on the screen should make sense to the audience and reflect their view of the choice
context. Continuity in location will cause decision makers to believe the items should be
considered as a group, so separate diverse items. Information that belongs together should
be put together on the display and connected. A small box or lines around such items will
help to focus the user on the similarities; the color of these lines should be consistent with
the primary font and should be as narrow as possible.
The fourth rule of design is to keep the display organized. Of course, the less that is
on the screen, the easier it is to look organized. Designers should avoid clutter and noise
in the interface that might distract from the important objects the user needs to consider.
Overembellishment, overuse of boxes and rules, insufficient use of white space, and poor
use of color all threaten the look of organization on a page. Instead, consistent (within a
particular display and across displays) and moderated use of size, shape, color, position,
and orientation on the screen make the page appear more organized.
The fifth rule of design is to make the navigation easy. Of course this means there
should be an obvious way for the user to move from display to display, to drill down in
USER INTERFACE COMPONENTS 235
the data, or to find wanted information. It also means not having items that appear to be
navigational devices on the page. For example, it is best not to have arrows that do not
function just to be design elements. Icons should be used sparingly and in a well-defined
manner so people do not confuse them with navigational tools. If the display takes more
room than just the viewable display, make sure there are clear scrollbars to help them see
the additional information.
Finally, any design element that takes away from the user interacting with the infor-
mation should be avoided.
Windowing. How one accomplishes the task of organizing information depends on
the kind of models, the kind of decision maker, and the kind of environment in which
one is working. For example, in the New York City courts example illustrated in Chapter
1, designers faced the problem of how to profile defendants in a manner that would help
judges see the entire perspective of the case. Their solution to the enormity of information
available about each defendant is to use a four-grid display in a Windows environment. The
top half of the screen displays information about the infractions in which the defendant may
have been involved; the left portion provides information about the complaint in question
while the right portion summarizes the defendant’s prior criminal history. The bottom-left
quadrant summarizes the interview data about the defendant’s socioeconomic and health
conditions. Finally, the bottom right is reserved for the judge’s comments. The software lets
the user focus on any of the quadrants through screen maximization and the use of more
detailed subroutines. For instance, in its normal state, the bottom-left interview screen
displays the defendant’s education level (ReadingProb: Y), housing status (Can Return
Home: N, Homeless: Y), and drug habit (Requests Treatment: N). Maximized, it details
everything from what drugs the person uses to whom he or she lives with and where. In
addition, problematic answers are displayed in red so as to highlight them for users.
The one underlying tenet of presentation language is that the display should be “clean”
and easy to read. Today, use of the Windows standard for many products makes the design
of an uncluttered display easier. In particular, this standard brings with it the analogy of a
desktop consisting of files. On the screen, we see windows, each representing a different
kind of output. One window might include graphs of the output while another includes a
spreadsheet and still another holds help descriptions that encourage sensitivity analyses.
An example is shown in Figure 5.20. The use of different windows for different kinds of
information separates different kinds of results so users can focus their attention on the
different components; the windows give order to the items at which the user is looking.
Of course, everyone has seen desktops that are totally cluttered because there are so
many aspects of the problem one needs to consider. Layering options allow the various
One of the most widely publicized examples of virtual reality used by the public is a setup
created by Matsushita in Japan. This is a retail application set up in Japan to help people choose
appliances and furnishings for the relatively small kitchen apartment spaces in Tokyo. Users
bring their architectural plans to the Matsushita store, and a virtual copy of their home kitchen
is programmed into the computer system. Buyers can then mix and match appliances, cabinets,
colors, and sizes to see what their complete kilchen will look like—without ever installing a single
item in the actual location.
236 USER INTERFACE
Figure 5.20. Windowed output.
windows to overlap in many applications. Designers should, however, refrain from putting
too much on the screen at once for the same reason decision makers are discouraged from
having cluttered desks—too many things get lost, and it becomes hard to get perspective on
the problem. Instead, if the application allows it, the designer should use icons to indicate
various options, as illustrated in Figure 5.21. When the users want to examine that particular
aspect of the problem, they can simply click on an icon to enlarge it so it can be viewed in
its entirety.
Windows can be sized and placed by the users so they can customize their analysis of
the information. Hence, users can have cluttered desktops if they choose, but clutter should
not be inherent in the design of the DSS.
Representations. The most common form of output is to show the results of some
analysis. Suppose, for example, that the goal were to show the sales of the various divisions
for the last year. The appropriateness of the output depends on what the decision maker
expects to do with the information. If the decision makers simply wanted to know if the
various regions were meeting their goals, they might appreciate the use of metriglyphs, such
as those shown in Figure 5.22. Metriglyphs are simply symbols that help convey information
to the user quickly. Those with “smiling faces” show sales that met the goals, while those
USER INTERFACE COMPONENTS
Figure 5.21. Icon options.
with “sad faces” did not. Further, the larger the smile, the more sales exceeded objectives,
and the larger the grimaces, the more seriously they missed. We can even illustrate one set
of results with the “smile” and another with the “eyes” of the face. For example, if the smile
represented the profit level, the eyes might represent the dividend level. Closed eyes would
represent no dividends, while the size of the open eyes would represent the magnitude
of the dividends. Of course, not all decision makers (or all cultures) appreciate the cute
use of metriglyphs as output. Today a user is more likely to see common glyphs, such as
the traffic lights in Figure 5.23, to allow a quick evaluation of the conditions. This figure
provides the same evaluation as in Figure 5.22. However, the user can easily discern the
meaning because of his or her understanding of traffic lights. It has the additional benefit of
redundancy of message, once with the color and once with the location of the highlighted
signal. In addition, use of such glyphs heep with accessibility for those with color vision
disabilities.
Alternatively, if the goal of the analysis were to determine where sales were largest,
we might display those on a map with different shadings or colors as codes to show the
Figure 5.22. Metriglyphs.
238 USER INTERFACE
Figure 5.23. Using traffic lights as metriglyphs.
range of results. Designers should avoid drawing the map to scale in proportion to the sales
of the region, as shown in Figure 5.24, since many people do not have a sufficiently strong
memory of the size of geographical places to make such representations meaningful.
If the goal were to determine trends over several years, then the most appropriate
output is a graph of the results, as shown in Figure 5.25. It is easy to see that some regions
increased sales while others decreased and to read off the relative amounts (such as “a lot”
or “a little”).
On the other hand, if the decision maker wanted the actual numbers (e.g., to do some
hand calculation), then the graph in Figure 5.25 is inappropriate because it is difficult to
glean the actual sales figures from it. In this case, a table of numbers, such as Figure 5.26,
is more useful.
Designers should take care to use rich visualizations that convey the analysis most
accurately and most efficiently to the user. Consider Figure 5.27, which shows Napoleon’s
march. This graphic by Charles Joseph Minard, portrays the losses suffered by Napoleon’s
army in the Russian campaign of 1812. Beginning at the Polish-Russian border, the top band
shows the size of the army at each position during the offensive. The path of Napoleon’s
retreat from Moscow is depicted by the dark lower band, which is tied to temperature and
time scales. So, by simply looking at the graph, you can discern the size of the army and its
location and direction at any time as well as the temperature on some days. That powerful
graphic contains a substantial amount of information for in-depth examination but also
allows users to simply get an overview of the situation.
Some situations are best represented with the association of two or more variables
as they change over time. Most of us are not particularly adept at drawing (or viewing)
three- or more dimensional depictions. But, with today’s technology, it is possible to view
those changes by watching a graph move over time. The two graphs shown in Figures
2.7 and 2.8 illustrate the end points of such a graphic. Figure 2.7 shows two axes, “life
expectancy at birth” and “average number of children per woman.” The graph also shows
the data by country with the bubbles in the chart. Each country is a bubble. The relative
size of the bubble indicates the size of the country, and the color of the bubble illustrates
the continent on which the country is located. You can watch the video on Gapminder’s
website (http://www.gapminder.org/) to see it move, but the end result is Figure 2.8. In
this graphic, you can see multiple variables and how they interact over time, again inviting
either the in-depth analysis or a quick overview of the data.
Data visualization techniques for qualitative data have improved over time as well.
Consider the question of something like relationship data, which illustrate how groups are
related to one another. For example, consider Figure 5.28. This is a relationship diagram
from a social networking site showing one person’s contacts through the site. The names
around the circle are people with whom this individual is connected. The lines represent
associations that these individuals have with others in this group. As you can see, some
F
ig
u
re
5.
24
.
M
ap
o
f
sa
le
s
vo
lu
m
e
d
ra
w
n
t
o
s
ca
le
.
240 USER INTERFACE
of the individuals (particularly those at the top) are highly connected to one another while
those at the bottom seem relatively unconnected to others in the group. This kind of diagram
allows the user to investigate how people—or items—are related and where hubs of activity
might be.
Another relationship diagram is shown in Figure 5.29. This diagram shows not only
associations but also the types of associations. This particular diagram illustrates all of the
companies (the darker highlighted items) at which we have placed interns in the last year
as well as how many and what kinds of other relationships they have with the department
and with each other (the lighter highlighted items). It allows the decision maker to see the
depth of the relationship, not simply that there is a relationship.
There are a myriad of other diagramming tools available to the DSS designers to help
them help decision makers understand their data properly. Of course, the appropriate output
might be animation and/or video rather than a display on a screen. For example, if the model
is a simulation of a bank and varies the number of clerks, the types of services handled by
each clerk, and number of queues as well as the impact of each factor upon queue length,
Design Insight:
Speech Emulatioi
When we emulate speech in a computer, designers need to worry about more than speech recog-
nition and synthesis. Researchers have found three important aspects of speech that need to be
incorporated. First, speech is interactive. Few of us can actually hold our part of the conversation
without hearing something in return. Without some form of feedback, our speech will probably
increase in speed and probably even in tone. Research teams at MIT* found that these changes
in speech can actually cause the computer to reject commands it would otherwise adopt. Hence,
they incorporated phrases such as “ah ha” that would be uttered at judicious times and found that
it helped the human keep his or her speech in a normal range. In other words, some utterances in
speech are protocols such as those found in networking handshaking.
A second important part of speech is that meaning can be expressed in shorthand language
that probably would be meaningless to others if the participants know each other weih Over time,
shared experiences lead to shared meanings in phrases. For example, occasionally one of my
colleagues will utter “1-4-3-2″ in a conversation. Those of us who know him well know this is
shorthand for *lI told you so” (the numbers reflect the number of letters in each of the words). To
others, it makes no sense. Another colleague, when discussing the potential problems of a strategy
I was about to adopt for a meeting, warned me to remember Pickett’s charge. Now, to those who
know nothing about the American Civil War, this warning tells us nothing. To those who know
about the war, and the Gettysburg confrontation in particular, know that he was telling me that we
all face decisions with incomplete information and that we should not become too confident in
our abilities in light of that incomplete information, In fact, he was warning me to (a) check my
assumptions and (b) look for indications of crucial information that could suggest a need to my
strategy. Many historians believe that had PickeLt’s charge been successful, the American Civil
War might have had a different outcome.
A third important part of speech is that it is contextual. A phrase or sentence in context
might be totally understandable but quite baffling out of context. For this reason, we generally
have redundant signals in human interactions, Somehow that same redundancy needs to be
incorporated into human-computer interactions to ensure un der standabi lily.
*Negroponte, K, “Talking with Computers,” Wired, Volume 2.03, March, 1994, p. 144.
USER INTERFACE COMPONENTS 241
Figure 5.25. Graphical representation.
then an animation of the queues might be more illustrative than the aggregated, summary
statistics.
Perceived Ownership of Analyses. In addition to providing the appropriate type
of output for the results under consideration, designers should remind the users that they
control the analyses and therefore the decision-making authority. Computer novices may
not feel “ownership” of the answer because it was something “done by the computer,” not
really by them. One way of counteracting this tendency is to provide users an easy way of
changing the analyses if the results do not answer the question appropriately or completely.
For example, consider the screen labeled Figure 5.30. Note that in this analysis we can
compute profitability either with discounting or without it. The decision maker has chosen
discounting (that box is checked). However, the results without discounting are easy to
obtain given the on-screen keys. Similarly, Figure 5.31 encourages users to experiment
with the model (by providing different estimates for key variables) by prompting the user
with the “revise” buttons and by making it easy to do. Note in Figure 5.31 that the user
has the option of revising both decision variables under consideration, clerks and queues.
Similarly, the user has the ability to affect the value of the environment variable, expected
242 USER INTERFACE
Figure 5.26. Disaggregate posting of results.
number of customers per hour.2 However, relevant statistics (in this case, average waiting
time) are only recomputed after the user selects the “recompute” button. This provides the
users the ability not only to acquire new values but also to validate that the entered value is
the one intended. Similarly, the simulation is only rerun for the user when requested.
Graphs and Bias. Just as it is important to provide users unbiased use of models,
it is also important to provide them unbiased output. What and how designers provide
information can affect how that information is perceived by the decision maker. Of course,
we assume the designer will not intentionally rig the system to provide biased results.
However, the more dangerous problem is when the rigging is done unintentionally.
2 While an average would have been provided automatically, the user may want to test the sensitivity
of the model to the parameter. Users should not expect to complete such testing blindly. Hence, there
is a button that allows them to review the relevant statistics over different time horizons and during
different times of the day.
F
ig
u
re
5.
27
.
M
in
ar
d
‘s
m
ap
o
f
N
ap
ol
eo
n’
s
18
12
R
us
si
an
C
am
pa
ig
n.
(
S
o
u
rc
e:
E
. T
u
ft
e,
T
h
e
V
is
u
al
D
is
p
la
y
o
f
Q
u
an
ti
ta
ti
ve
I
n
fo
rm
at
io
n
,
G
ra
ph
ic
s
Pr
es
s
U
C
, 1
98
3,
20
01
,
p.
4
0.
)
M
ap
is
re
pr
od
uc
ed
w
it
h
p
er
m
is
si
on
o
f
th
e
pu
bl
is
he
r
244 USER INTERFACE
Figure 5.28. Relationship diagram.
Suppose, for example, the user is considering a decision regarding the management
of two plants and examines average daily productivity in those plants. If it provides only
the average values, the system could be giving biased output because it does not help the
user see the meaningfulness of those numbers. Average productivity at plant 1 could be
5000, while that at plant 2 could be 7000. This appears to be a big difference. However,
if we know the standard deviation in daily productivity is 2000, the difference no longer
looks so significant. Hence, simply providing the appropriate supplementary information,
as described in Chapter 4, will help provide better support.
Another place where designers inadvertently provide bias in the results is in the display
of graphs. Since most decision makers look at graphs to obtain a quick impression of the
meaning of the data, they might not take the time to determine that their impression
is affected by the way the graph is displayed. For example, consider the effect of the
difference in scaling of the axes in Figure 5.32.
In the first version of this graph, the axes were determined so that the graph would
fill the total space. Clearly this graph demonstrates a fairly high rate of revenue growth.
However, by simply increasing the range of the x axis, the second graph gives the impression
of a considerably higher rate of growth over the same time period. Similarly, increasing
the range of the y axis makes the rate of growth appear much smaller in the last graph.
The designer must ensure this misrepresentation does not occur by correctly choosing and
labeling the scale.
USER INTERFACE COMPONENTS 245
Figure 5.29. Depth of relationship diagram. UMSL’s external relationship map. Software devel-
oped by S. Mudigonda, 2008.
The use of icons on bar charts can leave inappropriate impressions too. Consider Figure
5.33, which presents a histogram of the revenues for three different regions using the symbol
for the British pound sterling. Clearly, revenues are greatest in region 2 and least in region
3. However, the magnitude of the differences in revenues is distorted by the appearance of
the symbol. To increase the height of the symbol and maintain the appropriate proportions,
we must also increase the width. Hence, the taller the symbol, the wider it becomes. As
both dimensions increase, the symbol’s presence increases at the square of the increased
revenues, thereby exaggerating the magnitude of the increase. Instead, a better option is to
stack the icon to get the appropriate magnitude represented, as shown in the second portion
of the figure.
Another factor that can provide perceptual bias for decision makers is the absence
of aggregation of subjects when creating a histogram or pie chart. Consider Figure 5.34,
which displays the sales of 23 sales representatives from nine regions. It is impossible to
determine any differences in the typical performance in the regions, because the data are
not aggregated; rather what you see in this graph is the differences among sales associates.
246 USER INTERFACE
Figure 5.30. On-screen analysis change prompting.
The eye is directed toward the outliers, such as the tenth associate, who had high sales, and
the thirteenth associate who had relatively low performance. The problem is exacerbated,
of course, as the number of subjects increase.
Consider, instead, Figure 5.35, in which sales associates are aggregated by region. Here
the regional pattern is much clearer and we are not inappropriately distracted by outlier
observations. On the other hand, aggregated data can allow decision makers to generalize
Figure 5.31. Additional on-screen prompting.
USER INTERFACE COMPONENTS
inappropriately from the data. Specifically, Figure 5.36 does not identify how many sales
associates work in each region and what the dispersion of performance is among those
associates. A better design would identify the number of associates and a measure of
dispersion either as a legend or on the graph.
We cannot here enumerate all the distortion and bias that can be represented in a graph.
However, awareness of the problems can help to avoid bias problems in DSS design.
Support for All Phases of Decision Making. Displays must be constructed so as
to help decision makers through all the phases in decision making. According to Simon’s
model discussed in Chapter 2, this means there must be displays to help users with the
intelligence phase, the design phase, and the choice phase.
In the first of these phases, intelligence, the decision maker is looking for problems
or opportunities. The DSS should help by continually scanning relevant records. For an
operations manager, these records might be productivity and absenteeism levels for all
the plants. For a CEO, they might be news reports about similar companies or about
the economy as a whole. Decision support is the creation and automatic presentation of
exception reports or news stories that need the decision maker’s attention. Hence, when
the operations decision maker turns on the computers, he or she could automatically be
notified that productivity is low in a particular plant or absenteeism is high in another as an
indicator of a problem needing attention. When the CEO turns on the computer, automatic
notification of changes in economic indicators might suggest the consideration of a new
product. The system does not make the decision; rather it brings the information to the
user’s attention. What must be scanned and how it is displayed for it to highlight problems
or opportunities are a function of the specific DSS.
Figure 5.32. Scaling deception.
248 USER INTERFACE
Figure 5.32. (Continued)
USER INTERFACE COMPONENTS 249
Figure 5.33. Distortion in histogram.
In the second phase of decision making, users are developing and analyzing possible
courses of action. Typically they are building and running models and considering their
sensitivity to assumptions. Displays must be created that will help users generate alterna-
tives. This might be as easy as providing an outlining template on which to brainstorm or
the ability to teleconference with employees at a remote plant to initiate ideas.
Displays must also be created to help in the building, analysis, and linking of models.
This includes the formulation of the model, its development and refinement, and analysis.
This means displays should be able to prompt users for information necessary to run the
model that has not been provided. The system should provide suggestions for improvements
to the models as well as alert the user to violations of the model’s assumptions. Finally,
displays must provide diagnostic help when the model does not work appropriately.
In the choice phase, the decision maker must select a course of action from those
available. Hence, the displays should help users compare and contrast the various options.
In addition, the displays should prompt users to complete sensitivity of the models to
assumptions and scenarios of problems.
250 USER INTERFACE
Figure 5.34. Individual histogram.
Figure 5.35. Aggregated histogram.
USER INTERFACE COMPONENTS 251
Figure 5.36. Use of international symbols. Menu from Marcus, A., “Human Communications in
Advanced Uls”, Communications oftheACM, Vol. 36 , No. 4, p. 101-109. Image is reprinted here
with permission of the Association of Computing Machinery.
Regardless of what phase of decision making is being supported, the goal of the display
is to provide information to the user in the most natural and understandable way. It is critical
that any display be coherent and understandable and provide context-sensitive help. Since
no one can anticipate in all the ideas that might be generated from any particular display, the
system must be flexible enough to allow nonlinear movement. For example, the user should
be able to transfer to a new topic or model, display a reference, seek auxiliary information,
activate a video or audio clip, run a program, or send for help.
Knowledge Base
The knowledge base, as it refers to a user interface, includes all the information users must
know about the system to use it effectively. We might think of this as the instructions for
systems operation, including how to initiate it, how to select options, and how to change
options. These instructions are presented to the users in different ways. Preliminary training
for system use might be individual or group training and hands-on or conceptual training.
To supplement this training, there is typically some on-screen prompting and help screens
with additional information.
In the DSS context, there are additional ways of delivering the knowledge base. One
popular mechanism is training by example. The user is taken through a complete decision
scenario and shown all the options used and why. The system also can provide diagnostic
information when the user is at an impasse, such as additional steps in an analysis. Or
it can offer suggestions for additional data use or analyses. For example, the system
USER INTERFACE
might recommend to users of mathematical programming techniques that they consider
postoptimality analyses.
The goal is to make the system as effortless as possible so as to encourage users to
actually employ the software to its fullest. This means there must be ways for experienced
users and inexperienced users to obtain the kind of help they need and the training and help
must be for specific techniques and models. Users typically are not experts in statistical
modeling, financial modeling, mathematical programming, or the like. They need help in
formulating their models and using them properly. This help must be included in the system.
Knowing how the users will employ the system is important to understanding what
one can assume of them. Historically, users have used DSS in three modes: subscription
mode, chauffeured mode, or terminal mode.3
Subscription mode means that the decision maker receives reports, analyses, or other
aggregated information on a regular basis without request. This mode does not allow for any
special requests or user-oriented manipulation or modification. Reports might be generated
on paper or sent directly to the user’s computer for display. Clearly there is very little involve-
ment of the user with the system and hence users expect the computer requests to be trivial.
Chauffeured mode implies that the decision maker does not use the system directly, but
rather makes requests through an assistant or other intermediary, who actually performs and
interprets the analysis and reports the results to the decision maker. Since these “chauffeurs”
are often technical experts, the systems designer can provide more “power use” instructions
and less help with interpretation instructions.
Finally, terminal mode implies the decision maker actually sits at the computer, requests
the data and analyses, and interprets results. These users are often high-level executives
who should not be expected to remember a lot of commands and rules for usage. It is
especially important for them to have easy navigation through the system, accessible help
options for both navigation and content that are context sensitive, and recommendations
regarding better analyses. Touch screens, mouse entry, and pull-down menus have made
many sophisticated systems seem easy.
Modes of Communication. In a listserv discussion group regarding the use of
computers in education, one teacher wrote that her class requested information about “what
it was like before computers.” The answers they obtained with regard to communication
included discussion of voice inflections, gestures, and other forms of nonverbal communi-
cation that helped people understand what others were trying to convey. Many of us can
remember when neatness in written work was another aspect of communication. In any
kind of communication, there is significant room for misinterpretation. Keeping in mind
the fact that computers do not understand nuances, nonverbal communications, or voice
inflections, you begin to understand the care with which designers should regard the user
interface design. As user interfaces become more sophisticated, as technology allows for
greater variation in the kind of interfaces designed, and as decisions become more global,
our concern about the appropriateness of every kind of communication is increased.
Four basic elements of communication need attention: mental models, metaphors,
navigation of the model, and look. The mental model is an explanation of someone’s
thought process about how something works in the real world. It is a representation of
the surrounding world, the relationships between its various parts, and users’ intuitive
perceptions about their own acts and their consequences. It, in fact, describes how we
3The classical definition of modes also includes the clerk mode. This mode differs from the terminal
mode only in that decision makers prepare their requests offline and submit them in batch mode.
While once common, such batch processing of DSS is rarely being seen today.
USER INTERFACE COMPONENTS 253
believe tasks are performed. The advantage of the mental model is that it provides a series
of shortcuts to explaining the relationships among ideas, objects, and functions and how
they might work to complete a task.
For example, consider how people thought about the economic meltdown of 2008.
The economy was referred to as a shipwreck, a perfect storm, an earthquake, a tsunami, an
Armageddon, a train wreck, a crash, and cancer. Each of those terms brings with it a set of
activities that must occur, a set of feelings of the user, and insight about how to respond. In
computer terms, it is common today to use a desktop as a representation of the operation of
a computer because it is familiar. Users know how to behave in an office, understand what
the items are for (e.g., information might be kept in file folders, access to messages might
be through a telephone icon, the erase function might be represented by a garbage can), and
have an intuition for how to work in it. This way of representing specific operations makes
sense because it brings with it all the shared meaning of these objects. However, if your
place of business is not an office, this way of organizing your computer probably would not
make sense. For example, if your task is in an operating room of a hospital, you need your
user interface to resemble the functions you are accustomed to performing. Your screen
should look more like a medical chart because it groups together processes and information
in the way medical personnel are accustomed to reading it. Understanding how users think
about their job is crucial to making the system work for them.
Within the mental model are metaphors. These metaphors rely upon connections the
user has built up between objects and their functions to help bolster intuition about how to
use the system. Since metaphors provide quick insight into purposes and operation, it is
thought they can help users see purposes and operations of the system more clearly with less
training. They are used every day to represent fundamental images and concepts that are
easily recognized, understood, or remembered, so as to make the system operation easier
to understand. The desktop image, for example, helps us understand how applications are
launched and controlled by using those technologies. Similarly, the classroom metaphor
brings with it not only an expectation of how furniture is arranged but also the general
operating rules of the group. In the design of DSS user interfaces, metaphors refer to the
substitution of a symbol for information or procedures; the substitution of an associated
symbol with the item itself, such as a red cross with medical care; the personification of an
inanimate object; or the substitution of a part of a group for the whole, such as the use of
one number to indicate data. Before building metaphors into a system, we need to be sure
they will convey the intended meaning by being intuitive, accurate, and easily understood.
Whether icons, pictorial representation of results (such as in animations or in graphics), or
terminology (such as the difference between browse mode and edit mode), metaphors ease
and shorten communication but only if all parties share the meaning. Consider Figure 5.36,
which provides metaphors for type specification. While many people would understand the
symbols at the right of this screen, clearly not everyone would.
Design Insights
Flexibility
Often the benefit of user interfaces is in simplicity. For example, in one DSS used for supplier
selection, users are required to enter information into only a limited number of cells in a matrix,
To them, this provides complete flexibility because they can still get decision support even in the
face of incomplete information. Once the data entry is complete, the DSS ranks the criteria by
importance and presents a model that displays only those factors that ranked highly. This facilitates
comparison of alternatives among important dimensions. In addition, if a decision maker notices
the absence of a particular criterion thai he or she believes is important, he or she is warned of a
problem immediately,
254 USER INTERFACE
Some designers dislike using the literal metaphor approach to design because it can
be limiting. Using a metaphor ties the operation of the system to how those items work
in the real world. Generally systems do not work like things in the real world so icons do
not convey what system designers really mean. That means that there are not many sets of
metaphors that are appropriate for explaining how software works, and those that exist do
not scale well to involving a large number of functions or activities. Furthermore, while
they may help the novice user learn to use the system better, they can prohibit the more
Design Insights
Window Size
Often designers of DSS and other computer systems do not attend well enough to questions of
the impact of the screen design on the use of the technology. Studies have shown that some
factors heighten emotional response while others calm it. In tact, the literature, taken as a whole.
suggests that individuals’ interactions with computers and other communication technologies
are fundamentally social and natural· One of the current projects of the Social Responses to
Communication Technology Consortium is an examination of the effect of the size of the image
of a human displayed on a computer for teleconferencing upon individuals” responses to that
image. Stanford Professor Byron Reeves was quoted as saying that “many cultures around the
world assign magical properties to people who are small . , . These small people grant wishes» they
monitor behavior and they keep people safe, But they also can punish or be bad just for the hell of
it.” Professor Cliffford Nass further elaborates in that same article, 41We want to know, when you
see a small face on a screen, do you respond to it as if it were magical? Is it perceived as powerful
or capable?” So, the question is, do you have a different response to the two screens below?
■H5
■
i
Source: From I Morkes, + USER INTERFACE COMPONENTS advanced user from truly seeing the options available in the software. Finally, metaphors An alternative to metaphors in design is to rely upon idioms. Unlike metaphors, which Most of the basic usage of windowing software is guided by idioms. The fact that we The navigation of the model refers to the movement among the data and functions and Finally, the look of a system refers to its appearance. No one who knows computer For example, it is well known that color metaphors mean different things in different While we do not have many guidelines for user interface today, it is important to reflect 256 USER INTERFACE
Figure 5.37. An alternative menu format. Menu From Marcus, A., “Human Communications in CAR EXAMPLE
The expected user of the car selection DSS we have been discussing is a consumer who It is crucial that system designers provide multiple paths through the system to accom- CAR EXAMPLE 257
Figure 5.38. Initial screens from commercial automobile purchasing system. USER INTERFACE Early screens should guide users to the part of the system that will meet their needs. The first few screens also set the tone for the system, and hence particular attention One way to accomplish this is to provide a menuing system through which it is easy The first option allows the user to enter the manufacturer of automobiles that is preferred The middle option of Figure 5.39 provides the options to the users as radio buttons. CAR EXAMPLE 259
Figure 5.39. Three methods by which users requires the radio buttons to be selected, as can be seen in the form section of the code. Code 5.1
can be a particular problem in cross-culturally used systems because they do not mean the
same thing to all users.
rely upon the user having intuition about how the system works, idioms rely upon training
of the user to accomplish certain tasks even if the user is unsure why those tasks work. This
approach to designing systems does not require users to have the technical knowledge to
understand why the system works; instead it only requires they know that certain actions
do accomplish the users’ goals. There is not an intuitive link because of experience; rather
it is a leaned link, much the same way people learn idioms in speech. For example, one
does not intuit the relationship between a piece of cake and “being easy”; one learns that it
is frequently said that something easy is a piece of cake.
can open and close windows and boxes, click on hyperlinks, and use a mouse is not guided
by our intuition in using these items. Rather we can use them because they have been taught
to the users. They are easy to learn and transfer from situation to situation. Users become
conditioned to the idioms and they make the software easier to use. They do not wear down
because of changes in the environment or become less useful because of cultural changes
or changes over time because they are not dependent upon those things. Thus, generally,
they are preferred to metaphors.
how it can be designed to provide quick access and easy understanding. In one environment,
it might make sense to group together all the models and to create subgroups of, say, specific
statistical functions, because users differentiate them from mathematical programming
functions. However, in another environment, users think of the kind of question, not the
kind of technique, when moving among the options in the DSS. Here, it would be appropriate
to group certain statistical tests with financial data and analyses and certain mathematical
models with production planning.
company culture would expect to see the same dress code at IBM that was observed at
Apple Computer Corporation. By extension, then, we would not expect to find preferences
for the same user interface at the two corporations. Just as corporate culture can affect
preferences for the user interface, other cultural influences associated with national origin,
sex, race, age, employment level, and the interaction among all of those influences will
affect the way a person responds to particular user interfaces. However, designers have
assumed that all users will respond similarly.
cultures. While a red flashing light might be interpreted as an indicator of something
important to one culture, it might suggest users stop all processing in another. Similarly,
it is believed that the size of the image can affect how we respond to it. A group of
researchers at Stanford is studying how different cultures respond to “little people” (as
good luck? or as a curse?) to help understand how best to size human images to be
for effective teleconferencing in a DSS framework. Others believe the linear, restrained
treatment of menus is received differently in different cultures. They suggest a menu that is
more curvilinear and less aggressive, such as that in Figure 5.37, might be received better
by some cultures.
on possible differences in needs and use them in our development efforts. Research is being
conducted now that will be used in the future to guide in the development effort.
Advanced Ills”, Communications of the ACM, Vol. 36 , No. 4, p. 101-109. Image is reprinted here
with permission of the Association of Computing Machinery.
intends to purchase an automobile. It may be the first automobile the user has ever selected
or the user may have purchased new automobiles every year for the last 20 years. In addition,
the user may never have touched a computer before or may be an expert computer user.
This leads to a wide range of user capabilities and user needs for the system, which in turn
leads to complications in the design of the user interface.
modate the needs of all kinds of users. For example, some users may have no idea what
kind of automobile to acquire and need guidance at every step of the process. Other users
may have a particular manufacturer from which to select, while other users have particular
criteria that are of importance to them. Still others may have a small number of automobiles
they want to compare on specific functions. The system must be able to accommodate all
these decision styles, and the user interface needs to facilitate that process. Examples of
commercial systems are shown in Figure 5.38.
The temptation exists to use the first few screens to gain some insight into the user’s needs
and his or her preferences for information, but the temptation should be resisted. Users want
to see information on these first few screens that convinces them the system will facilitate
their choice process; background information about themselves will not do that. Rather, it
is important to use some simple mechanism for screening users and deciding what part of
the system will be most appropriate to use. Some designers simply ask whether the user
wants “no support,” “partial support,” or “total support” from the system. While this may
be appropriate in some circumstances, it can be very confusing unless the user can query
the system and find what kinds of analyses and access each of those levels provide. An
alternative is to pose the question of whether the user knows the set of automobiles from
which a selection will be made, whether the user knows the criteria that should be applied to
the choice process, or whether the user needs full support in understanding the dimensions
that should be evaluated. Further, if the user selects known criteria and specifies financial
information, then the choice process should follow a financial model selection. That does
not mean that the system cannot pop up warning messages or help screens that suggest
consideration of other criteria. Rather, it means that the focus of the process must have face
validity and seem relevant to the user.
must be given to their design. The screens need to be simple, clean, and easy to follow.
There should be sufficient instructions to help the novice user to move through the system
easily while not slowing down the more proficient user. In addition, users will want to see
information that moves quickly but is easily discerned.
for the user to maneuver. Consider, for example, the three options demonstrated in Figure
5.39. Please note that a designer would not place all three of these options on the same
screen. They are presented here for the purposes of discussion.
(Code 5.1). After this the user can select the option to start the search. From a programming
point of view, this is the easiest of the searches to accomplish; the Cold Fusion shown in
Figure 5.39 illustrates the process that must be used to accomplish the search. While it
appears user friendly at the outset, it actually is not a particularly useful user interface. One
problem is that the user is restricted to searching for only one manufacturer of automobile.
Many people want to search on multiple manufacturers; they would have to make several
trips through the system and would have more difficulty comparing the results. A second
problem is that this method requires users to be able to remember all the manufacturers
they might consider. This may cause them to neglect some options, either because they
forgot about them or because they did not know they existed. While it is acceptable for
the user to narrow his or her search, it is not acceptable for the system to do it on the
user’s behalf. A third problem is that this method requires the user to spell the name of
the manufacturer correctly. Often users do not know the correct spelling, or they make
typographical errors, or they use a variation on the name (such as Chevy for Chevrolet).
Unless the search “corrects” for these possible problems, no relevant matches will be made.
The code for this is shown in Code 5.2. This has two advantages. First, it reminds the user
what models of automobiles are available to the user (which is especially good for the
novice user). Second, it does not rely upon the user spelling the automobile type correctly
or using the same form of the model name as the designer. It does, however, limit the user
to selecting only one option; only one radio button of a group may be selected. The coding
can enter data in the system.
However, searching the database is virtually the same for this example and the previous one.
What make of automobile is of interest to you?
SELECT model FROM new.cars WHERE model = ‘ #Form . car_pref erence# ‘
- #model#
”