USER INTERFACE
To the decision maker, the user 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.jpg 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.png. 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
Fig
ure
5.
24.
Map
of
sale
s vo
lum
e d
raw
n t
o s
cale
.
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.
Fig
ure
5.
27.
Min
ard
's m
ap o
f N
apol
eon'
s 18
12 R
ussi
an C
ampa
ign.
(S
ou
rce:
E. T
uft
e, T
he
Vis
ual
Dis
pla
y o
f Q
uan
tita
tive
In
form
atio
n,
Gra
phic
s Pr
ess
UC
, 198
3,
2001
, p.
40.
) M
ap is
repr
oduc
ed w
ith
per
mis
sion
of
the
publ
ishe
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 can be a particular problem in cross-culturally used systems because they do not mean the same thing to all users.
An alternative to metaphors in design is to rely upon idioms. Unlike metaphors, which 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.
Most of the basic usage of windowing software is guided by idioms. The fact that we 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.
The navigation of the model refers to the movement among the data and functions and 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.
Finally, the look of a system refers to its appearance. No one who knows computer 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.
For example, it is well known that color metaphors mean different things in different 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.
While we do not have many guidelines for user interface today, it is important to reflect 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.
256 USER INTERFACE
Figure 5.37. An alternative menu format. Menu From Marcus, A., “Human Communications in 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.
CAR EXAMPLE
The expected user of the car selection DSS we have been discussing is a consumer who 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.
It is crucial that system designers provide multiple paths through the system to accom-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.
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 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.
The first few screens also set the tone for the system, and hence particular attention 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.
One way to accomplish this is to provide a menuing system through which it is easy 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.
The first option allows the user to enter the manufacturer of automobiles that is preferred (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 middle option of Figure 5.39 provides the options to the users as radio buttons. 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
CAR EXAMPLE 259
Figure 5.39. Three methods by which users can enter data in the system.
requires the radio buttons to be selected, as can be seen in the form section of the code. However, searching the database is virtually the same for this example and the previous one.
Code 5.1
SELECT model FROM new.cars WHERE model = ' #Form . car_pref erence# '
- #model#
”