player, and surround audio system without the user needing to know what’s going on behind the scenes.
Even the Windows user interface slips into the implementation model sometimes.
If you drag a file between directories on the same hard drive, the program interprets this as a MOVE, meaning that the file is removed from the old directory and added to the new directory, closely following the mental model. However, if you drag a file from hard drive C to hard drive D, the action is interpreted as a COPY, meaning that the file is added to the new directory but not removed from the old directory. This behavior is rooted in the implementation model — the way the underlying file system actually works. When the operating system moves a file from one directory to another on the same drive, it merely relocates the file’s entry in the disk’s table of contents. It never actually erases and rewrites the file. But when it moves a file to another physical drive, it must physically copy the data onto the new drive. To conform to the user’s mental model, it should then erase the original even though that contradicts the implementation model.
This inconsistency in the computer’s response to two seemingly similar user actions has the potential to create significant cognitive dissonance (confusion resulting from two contradictory images of reality) for users, which in turn makes this simple interaction difficult to learn. For a user to ultimately be able to achieve a desired result, he must understand that the computer’s behavior depends on the physical nature of the particular storage devices.
Because treating the drag of a file from one disk to another as a COPY function can be desirable behavior, especially when copying files from a hard drive to removable media such as USB flash drives, many people aren’t aware that it is an inconsistent side effect of the implementation model. As computers mature and logical volumes represent more than just physical drives, the side effects stop being useful and instead become irritating because we have to memorize the idiosyncratic behavior of each volume type.
06_084113 ch02.qxp 4/3/07 6:01 PM Page 34
34
Part I: Understanding Goal-Directed Design
Mathematical thinking leads to implementation
model interfaces
Interaction designers must shield users from implementation models. Just because a technique is well suited to solving a problem in software construction doesn’t necessarily mean that it is well suited to be a mental model for the user. Just because your car is constructed of welded metal parts doesn’t mean that you must be skilled with a welding torch to drive it.
Most of the data structures and algorithms used to represent and manipulate information in software are logic tools based on mathematical algorithms. All programmers are fluent in these algorithms, including such things as recursion, hierarchical data structures, and multithreading. The problem arises when the user interface attempts to accurately represent the concepts of recursion, hierarchical data, or multithreading.
Mathematical thinking is an implementation model trap that is particularly easy for programmers to fall into. They solve programming problems by thinking mathematically, so they naturally see these mathematical models as appropriate terms for inventing user interfaces. Nothing could be further from the truth.
DESIGN
Users don’t understand Boolean logic.
principle
For example, one of the most durable and useful tools in the programmer’s toolbox is Boolean algebra. It is a compact mathematical system that conveniently describes the behavior of the strictly on-or-off universe inside all digital computers. There are only two main operations: AND and OR. The problem is that the English language has an and and an or and they are usually interpreted — by nonprogrammers — as the exact opposite of the Boolean AND and OR. If the program expresses itself with Boolean notation, the user can be expected to misinterpret it.
For example, this problem crops up frequently when querying databases. If we want to extract from a file of employees those who live in Arizona along with those who live in Texas, we would say to a human in English, “Find all my employees in Arizona and Texas.” To express this properly to a database in Boolean algebraic terms, we would say, “Find employees in Arizona OR Texas.” No employee lives in two states at once, so saying, “Find employees in Arizona AND Texas” is nonsensi-cal. In Boolean, this will almost always return nothing.
06_084113 ch02.qxp 4/3/07 6:01 PM Page 35
Chapter 2: Implementation Models and Mental Models
35
Any application that interacts with users in Boolean is doomed to suffer severe user-interface problems. It is unreasonable to expect users to penetrate the confusion. They are well trained in English, so why should they have to express things in an unfamiliar language that, annoyingly, redefines key words.
Mechanical-Age versus Information-
Age Represented Models
We are experiencing an incredible transformation from the age of industrial, mechanical artifacts to an age of digital, information objects. The change has only begun, and the pace is accelerating rapidly. The upheaval that society under-went as a result of industrialization will likely be dwarfed by that associated with the Information Age.
Mechanical-Age representations
It is only natural for us to try to draw the imagery and language of an earlier era that we are comfortable with into a new, less certain one. As the history of the industrial revolution shows, the fruits of new technology can often only be expressed at first with the language of an earlier technology. For example, we called railroad engines iron horses and automobiles were labeled horseless carriages. Unfortunately, this imagery and language colors our thinking more than we might admit.
Naturally, we tend to use old representations in our new environments. Sometimes, the usage is valid because the function is identical, even if the underpinning technology is different. For example, when we translate the process of typewriting with a typewriter into word processing on a computer, we are using a Mechanical-Age representation of a common task. Typewriters used little metal tabs to slew the carriage rapidly over several spaces until it came to rest on a particular column. The process, as a natural outgrowth of the technology, was called tabbing or setting tabs.
Word processors also have tabs because their function is the same; whether you are working on paper rolled around a platen or on images on a video screen, you need to rapidly slew to a particular margin offset.
Sometimes, however, Mechanical-Age representations shouldn’t be translated verbatim into the digital world. We don’t use reins to steer our cars, or a tiller, although both of these were tried in the early days of autos. It took many years to develop a steering idiom that was appropriate for the car. In word processors, we don’t need to load a new blank page after we fill the previous one; rather, the document scrolls continuously, with visual markers for page breaks.
06_084113 ch02.qxp 4/3/07 6:01 PM Page 36
36
Part I: Understanding Goal-Directed Design
New technology demands new representations
Sometimes tasks, processes, concepts, and even goals arise solely because new technology makes them possible for the first time. With no reason to exist beforehand, they were not conceived of in advance. When the telephone was first invented, for example, it was, among other things, touted as a means to broadcast music and news, although it was personal communication that became the most popular and widely developed. Nobody at the time would ever have conceived of the telephone as being a ubiquitous personal object that people would carry in their pockets and purses and that would ring annoyingly in the midst of theater performances.
With our Mechanical-Age mindset, we have a hard time seeing appropriate Information-Age representations — at first. The real advantages of the software products that we create often remain invisible until they have a sizable population of users. For example, the real advantage of e-mail isn’t simply that it’s faster than postal mail — the Mechanical-Age view —
but rather that it promotes the flattening and democratization of the modern business organization — the Information-Age advantage. The real advantage of the Web isn’t cheaper and more efficient communication and distribution — the Mechanical-Age view. Instead, it is the creation of virtual communities — the Information-Age advantage that was revealed only after it materialized in our grasp. Because we have a hard time seeing how digital products will be used, we tend to rely too much on representations from the past, Mechanical Age.
Mechanical-Age representations
degrade user interaction
We encounter a problem when we bring our familiar Mechanical-Age representations over to the computer. Simply put, Mechanical-Age processes and representations tend to degrade user interactions in Information-Age products. Mechanical procedures are easier to perform by hand than they are with computers. For example, typing an individual address on an envelope using a computer requires significant overhead compared to addressing the envelope with pen and ink (although the former might look neater). The situation improves only if the process is automated for a large number of instances in batch — 500 envelopes that you need to address.
As another example, take a contact list on a computer. If it is faithfully rendered onscreen like a little bound book, it will be much more complex, inconvenient, and difficult to use than the physical address book. The physical address book, for example, stores names in alphabetical order by last name. But what if you want to find someone by her first name? The Mechanical-Age artifact doesn’t help you: You
06_084113 ch02.qxp 4/3/07 6:01 PM Page 37
Chapter 2: Implementation Models and Mental Models
37
have to scan the pages manually. So, too, does the faithfully replicated digital version: It can’t search by first name either. The difference is that, on the computer screen, you lose many subtle visual cues offered by the paper-based book (bent page corners, penciled-in notes). Meanwhile, the scrollbars and dialog boxes are harder to use, harder to visualize, and harder to understand than simply flipping pages.
Don’t replicate Mechanical-Age artifacts in user interfaces without DESIGN
principle
Information-Age enhancements.
Real-world mechanical systems have the strengths and weaknesses of their medium, such as pen and paper. Software has a completely different set of strengths and weaknesses, yet when mechanical representations are replicated without change, they combine the weaknesses of the old with the weaknesses of the new. In our address book example, the computer could easily search for an entry by first name, but, by storing the names in exactly the same way as the mechanical artifact, we deprive ourselves of new ways of searching. We limit ourselves in terms of capabilities possible in an information medium, without reaping any of the benefits of the original mechanical medium.
When designers rely on Mechanical-Age representations to guide them, they are blinded to the far greater potential of the computer to provide sophisticated information management in a better, albeit different, way. The use of a Mechanical-Age representation in a user interface can operate as a metaphor that artificially constrains the design. For further discussion of the pitfalls surrounding reliance on metaphors in user interfaces, see Chapter 13.
Improving on Mechanical-Age representations:
An example
Although new technologies can bring about entirely new concepts, they can also extend and build upon old concepts, allowing designers to take advantage of the power of the new technology on behalf of users through updated representations of their interface.
For example, take the calendar. In the nondigital world, calendars are made of paper and are usually divided up into a one-month-per-page format. This is a reasonable compromise based on the size of paper, file folders, briefcases, and desk drawers.
06_084113 ch02.qxp 4/3/07 6:01 PM Page 38
38
Part I: Understanding Goal-Directed Design
Programs with visual representations of calendars are quite common, and they almost always display one month at a time. Even if they can show more than one month, as Outlook does, they almost always display days in discrete one-month chunks. Why?
Paper calendars show a single month because they are limited by the size of the paper, and a month is a convenient breaking point. Computer screens are not so constrained, but most designers copy the Mechanical-Age artifact faithfully (see Figure 2-3). On a computer, the calendar could easily be a continuously scrolling sequence of days, weeks, or months as shown in Figure 2-4. Scheduling something from August 28 to September 4 would be simple if weeks were contiguous instead of broken up by the arbitrary monthly division.
Similarly, the grid pattern in digital calendars is almost always of a fixed size. Why couldn’t the width of columns of days or the height of rows of weeks be adjustable like a spreadsheet? Certainly you’d want to adjust the sizes of your weekends to reflect their relative importance in relation to your weekdays. If you’re a businessperson, your working-week calendar would demand more space than a vacation week. The idioms are as well known as spreadsheets — that is to say, universal —
but the Mechanical-Age representations are so firmly entrenched that we rarely see software publishers deviate from it.
Figure 2-3 The ubiquitous calendar is so familiar that we rarely stop to apply Information-Age sensibilities to its design on the screen. Calendars were originally designed to fit on stacked sheets of paper, not interactive digital displays. How would you redesign it? What aspects of the calendar are artifacts of its old, Mechanical-Age platform?
06_084113 ch02.qxp 4/3/07 6:01 PM Page 39
Chapter 2: Implementation Models and Mental Models
39
Figure 2-4 Scrolling is a very familiar idiom to computer users. Why not replace the page-oriented representation of a calendar with a scrolling representation to make it better? This perpetual calendar can do everything the old one can, and it also solves the mechanical-representation problem of scheduling across monthly boundaries. Don’t drag old limitations onto new platforms out of habit. What other improvements can you think of?
The designer of the software in Figure 2-3 probably thought of calendars as canon-ical objects that couldn’t be altered from the familiar. Surprisingly, most time-management software handles time internally — in its implementation model —
as a continuum, and only renders it as discrete months in its user interface — its represented model!
Some might counter that the one-month-per-page calendar is better because it is easily recognizable and familiar to users. However, the new model is not that different from the old model, except that it permits the users to easily do something they couldn’t do easily before — schedule across monthly boundaries. People don’t find it difficult to adapt to newer, more useful representations of familiar systems.
DESIGN
Significant change must be significantly better.
principle
06_084113 ch02.qxp 4/3/07 6:01 PM Page 40
40
Part I: Understanding Goal-Directed Design
Paper-style calendars in personal information managers (PIMs) and schedulers are mute testimony to how our language influences our designs. If we depend on words from the Mechanical Age, we will build software from the Mechanical Age. Better software is based on Information-Age thinking.
07_084113 ch03.qxp 4/3/07 6:01 PM Page 41
3
Beginners, Experts, and
Intermediates
Most computer users know all too well that buying a new cell phone or opening the shrink-wrap on a new software product augurs several days of frustration and disappointment spent learning the new interface. On the other hand, many experienced users of a digital product may find themselves continually frustrated because that product always treats them like rank beginners. It seems impossible to find the right balance between catering to the needs of the first-timer and the needs of the expert.
&nbs
p; One of the eternal conundrums of interaction and interface design is how to address the needs of both beginning users and expert users with a single, coherent interface. Some programmers and designers choose to abandon this idea completely, choosing instead to segregate the user experiences by creating wizards for beginners and burying critical functionality for experts deep in menus. Of course, no one wants to deal with the extra labor associated with moving through a wizard, but the leap from there to knowing what esoteric command to select from a series of long menus is usually a jump off a rather tall cliff into a shark-infested moat of implementation-model design. What, then, is the answer? The solution to this predicament lies in a different understanding of the way users master new concepts and tasks.
07_084113 ch03.qxp 4/3/07 6:01 PM Page 42
42
Part I: Understanding Goal-Directed Design
Perpetual Intermediates
Most users are neither beginners nor experts; instead, they are intermediates.
The experience level of people performing an activity tends, like most population distributions, to follow the classic statistical bell curve (see Figure 3-1). For almost any activity requiring knowledge or skill, if we graph number of people against skill level, a relatively small number of beginners are on the left side, a few experts are on the right, and the majority — intermediate users — are in the center.
Beginners
Intermediates
Experts
What does the
I forgot how to import.
How do I automate this?
program do?
Alan Cooper, Robert Reinmann, David Cronin - About Face 3- The Essentials of Interaction Design (pdf) Page 9
