Exit behaves as it does now, closing the document and application.
Figure 17-4 The revised file menu now better reflects the user’s mental model, rather than the programmer’s implementation model. There is only one file, and the user owns it. If she wants, she can make tracked or one-off copies of it, rename it, discard any changes she’s made, or change the file format. She no longer needs to understand or worry about the copy in RAM versus the copy on disk.
23_084113 ch17.qxp 4/3/07 6:08 PM Page 363
Chapter 17: Rethinking Files and Save
363
A new name for the File menu
Now that we are presenting a unified model of storage instead of the bifurcated implementation model of disk and RAM, we no longer need to call the leftmost application menu the File menu — a reflection on the implementation model, not the user’s model. There are two reasonable alternatives.
We could label the menu after the type of documents the application processes. For example, a spreadsheet application might label its leftmost menu Sheet. An invoicing application might label it Invoice.
Alternatively, we can give the leftmost menu a more generic label such as Document. This is a reasonable choice for applications like word processors, spreadsheets, and drawing applications, but may be less appropriate for more specialized niche applications.
Conversely, those few applications that do represent the contents of disks as files —
generally operating system shells and utilities — should have a File menu because they are addressing files as files.
Communicating status
If the file system is going to show a user a file that cannot be changed because it is in use by another application, the file system should indicate this to the user. Showing the filename in red or with a special symbol next to it would be sufficient. A new user might still get an error message as shown in Figure 17-3, but at least some visual clues would show the reason the error cropped up.
Not only are there two copies of all data files in the current model, but when they are running, there are two copies of all applications. When a user goes to the Windows taskbar’s Start menu and launches his word processor, a button corresponding to Word appears on the taskbar. But if he returns to the Start menu, Word is still there! From the user’s point of view, he has pulled his hammer out of his toolbox only to find that there is still a hammer in there.
This should probably not be changed; after all, one of the strengths of the computer is its capability to have multiple copies of software running simultaneously. But the software should help users understand this very unintuitive action. The Start menu could, for example, make some reference to the already running application.
23_084113 ch17.qxp 4/3/07 6:08 PM Page 364
364
Part III: Designing Interaction Details
Are Disks and File Systems a Feature?
From a user’s point of view, there is no reason for disks to exist. From the hardware engineer’s point of view, there are three:
Disks are cheaper than solid-state memory.
Once written to, disks don’t forget when the power is off.
Disks provide a physical means of moving information from one computer to another.
The second and third reasons are certainly useful, but they are also not the exclusive domains of disks. Other technologies work as well or better. There are varieties of RAM that don’t forget their data when the power is turned off. Some types of solid-state memory can retain data with little or no power. Networks and phone lines can be used to transport data to other sites, often more easily than with removable disks.
Reason number one — cost — is the real reason disks exist. Nonvolatile solid-state memory is a lot more expensive than disk drives are. Unfortunately, disk drives have many drawbacks compared to RAM. Disk drives are much slower than solid-state memory is. They are much less reliable, too, because they depend on moving parts. They generally consume more power and take up more space, too. But the biggest problem with disks is that the computer, the actual CPU, can’t directly read or write to them! Its helpers must first bring data into solid-state memory before the CPU can work with it. When the CPU is done, its helpers must once again move the data to the disk. This means that processing that involves disks is necessarily orders of magnitude slower and more complex than working in plain RAM.
DESIGN
Disks are a hack, not a design feature.
principle
The time and complexity penalty for using disks is so severe that nothing short of an enormous cost differential could compel us to rely on them. Disks do not make computers better, more powerful, faster, or easier to use. Instead, they make computers weaker, slower, and more complex. They are a compromise, a dilution of the solid-state architecture of digital computers. If computer designers could have economically used RAM instead of disks they would have done so without hesitation —
and in fact they do, in the newest breeds of handheld communicators and PDAs that make use of Compact Flash and similar solid-state memory technologies.
23_084113 ch17.qxp 4/3/07 6:08 PM Page 365
Chapter 17: Rethinking Files and Save
365
Wherever disk technology has left its mark on the design of our software, it has done so for implementation purposes only, and not in the service of users or any goal-directed design rationale.
Time for Change
Only two arguments can be mounted in favor of application software implemented in the file system model: Our software is already designed and built that way, and users are used to it.
Neither of these arguments is valid. The first one is irrelevant because new applications written with a unified file model can freely coexist with the older implementation-model applications. The underlying file system doesn’t change at all. In much the same way that toolbars quickly invaded the interfaces of most applications in the last few years, the unified file model could also be implemented with similar success and user acclaim.
The second argument is more insidious, because its proponents place the user community in front of them like a shield. What’s more, if you ask users themselves, they will reject the new solution because they abhor change, particularly when that change affects something they have already worked hard to master — like the file system. However, users are not always the best predictors of design successes, especially when the designs are different from anything they’ve already experienced.
In the ‘80s, Chrysler showed consumers early sketches of a dramatic new automobile design: the minivan. The public gave a uniform thumbs down to the new design.
Chrysler went ahead and produced the Caravan anyway, convinced that the design was superior. They were right, and the same people who initially rejected the design have not only made the Caravan one of the bestselling minivans, but also made the minivan the most popular new automotive archetype since the convertible.
Users aren’t interaction designers, and they cannot be expected to visualize the larger effects of interaction paradigm shifts. But the market has shown that people will gladly give up painful, poorly designed software for easier, better software even if they don’t understand the explanations behind the design rationale.
23_084113 ch17.qxp 4/3/07 6:08 PM Page 366
24_084113 ch18.qxp 4/3/07 6:08 PM Page 367
18
Improving Data Entry
In Chapter 12, we discussed how interactive products should be designed to behave like considerate and intelligent people. One of the ways in which products are least capable in this regard is when the user is required to enter data. Some unfortunate artifacts of implementation-model thinking prevent people from working in the way they find most natural. In this chapter, we’ll discuss problems with existing ways of dealing with data entry and some possible strategies for making this process more focused on human needs and less focused on the needs of the database.
Data Integrity versus Data Immunity
/> One of the most critical requirements for properly functioning software is clean data. As the aphorism says, “garbage in, garbage out.” As a result, programmers typically operate according to a simple imperative regarding data entry and data processing: Never allow tainted, unclean data to touch an application. Programmers, thus, erect barriers in user interfaces so that bad data can never enter the system and compromise the pure internal state that is commonly called data integrity.
The imperative of data integrity posits that there is a world of chaotic information out there, and before any of it gets inside the computer it must be filtered and cleaned up. The software must maintain a vigilant watch for bad data, like a customs official at a border crossing. All data is validated at its point of entry. Anything
24_084113 ch18.qxp 4/3/07 6:08 PM Page 368
368
Part III: Designing Interaction Details
on the outside is assumed to be suspect, and after it has run the gauntlet and been allowed inside, it is assumed to be pristine. The advantage is that once data is inside the database, the code doesn’t have to bother with successive, repetitive checks on its validity or appropriateness.
The problem with this approach is that it places the needs of the database before those of its users, subjecting them to the equivalent of a shakedown every time they enter a scrap of data into the system. You don’t come across this problem often with most personal productivity software: PowerPoint doesn’t know or care if you’ve formatted your presentation correctly. But as soon as you deal with a large corporation — whether you are a clerk performing data entry for an enterprise management system or a Web surfer buying DVDs online — you come face to face with the border patrol.
People who fill out lots of forms every day as part of their jobs know that data isn’t typically provided to them in the pristine form that their software demands. It is often incomplete, and sometimes wrong. Furthermore, they may break from the strict demands of a form to expedite processing of this data to make their customers happy. But when confronted with a system that is entirely inflexible in such matters, these people must either grind to a halt or find some way to subvert the system to get things done. If, however, the software recognized these facts of human existence and addressed them directly with an appropriate user interface, everyone would benefit.
Efficiency aside, there is a more insidious aspect to this problem: When software shakes down data at the point of entry, it makes a very clear statement that the user is insignificant and the application is omnipotent — that the user works for the good of the application and not vice versa. Clearly, this is not the kind of world we want to create with our technological inventions. We want people to feel empowered, and make it clear that computers work for us. We must return to the ideal division of digital labor: The computer does the work, while the human makes the decisions.
Happily, there’s more than one way to protect software from bad data. Instead of keeping it out of the system, the programmer needs to make the system immune to inconsistencies and gaps in the information. This method involves creating much smarter, more sophisticated applications that can handle all permutations of data, giving the application a kind of data immunity.
Data immunity
To implement this concept of data immunity, our applications must be built to look before they leap and to ask for help when they need it. Most software blindly
24_084113 ch18.qxp 4/3/07 6:08 PM Page 369
Chapter 18: Improving Data Entry
369
performs arithmetic on numbers without actually examining them first. The application assumes that a number field must contain a number — data integrity tells it so. If a user enters the word “nine” instead of the number “9,” the application will barf, but a human reading the form wouldn’t even blink. If the application simply looked at the data before it acted, it would see that a simple math function wouldn’t do the trick.
We must design our applications to believe that a user will enter what he means to enter, and if a user wants to correct things, he will do so without paranoid insistence. But applications can look elsewhere in the computer for assistance. Is there a module that knows how to make numeric sense of alphabetic text? Is there a history of corrections that might shed some light on a user’s intent?
If all else fails, an application must add annotations to the data so that when — and if — a user comes to examine the problem, he finds accurate and complete notes that describe what happened and what steps the application took.
Yes, if a user enters “asdf ” instead of “9.38” the application won’t be able to arrive at satisfactory results. But stopping the application to resolve this right now is not satisfactory either; the entry process is just as important as the end report. If a user interface is designed correctly, the application provides visual feedback when a user enters “asdf,” so the likelihood of a user entering hundreds of bad records is very low. Generally, users act stupidly only when applications treat them stupidly.
When a user enters incorrect data, it is often close to being correct; applications should be designed to provide as much assistance in correcting the situation as possible. For example, if a user erroneously enters “TZ” for a two-letter state code, and also enters “Dallas” for a city name, it doesn’t take a lot of intelligence or computational resources to figure out how to correct the problem.
What about missing data?
It is clearly counter to the goals of users — and to the utility of the system — if crucial data is omitted. The data-entry clerk who fails to key in something as important as an invoice amount creates a real problem. However, it isn’t necessarily appropriate for the application to stop the clerk and point out this failure. Think about your application like a car. Your users won’t take kindly to having the steering wheel lock up because the car discovered it was low on windshield-washer fluid.
Instead, applications should provide more flexibility. Users may not immediately have access to data for all the required fields, and their workflow may be such that they first enter all the information they have on hand and then return when they
24_084113 ch18.qxp 4/3/07 6:08 PM Page 370
370
Part III: Designing Interaction Details
have the information needed to fill in the other fields. Of course, we still want our users to be aware of any required fields that are missing information, but we can communicate this to them through rich modeless feedback, rather than stopping everything to let them know something they may be well aware of.
Take the example of a purchasing clerk keying invoices into a system. Our clerk does this for a living and has spent thousands of hours using the application. He has a sixth sense for what is happening on the screen and wants to know if he has entered bad data. He will be most effective if the application notifies him of data-entry errors by using subtle visual and audible cues.
The application should also help him out: Data items, such as part numbers, that must be valid shouldn’t be entered through free text fields, but instead should be entered via type-ahead (auto-completion) fields or bounded controls such as drop-downs. Addresses and phone numbers should be entered more naturally into smart text fields that can parse the data. The application should provide unobtrusive modeless feedback on the status of his work. This will enable our clerk to take control of the situation, and will ultimately require less policing by the application.
Most of our information-processing systems are tolerant of missing information. A missing name, code, number, or price can almost always be reconstructed from other data in the record. If not, the data can always be reconstructed by asking the various parties involved in the transaction. The cost is high, but not as high as the cost of lost productivity or technical support centers. Our information-processing systems can work just fine with missing data. Some of the programmers who develop these systems may not like all the extra work involved in dealing with missing data, so they invoke data i
ntegrity as an unbreakable law. As a result, thousands of clerks must interact with rigid, overbearing software under the false rubric of keeping databases from crashing.
It is obviously counterproductive to treat workers like idiots to protect against those few who are. It lowers everyone’s productivity, encourages rapid, expensive, and error-causing turnover, and decreases morale, which increases the unintentional error rate of the clerks who want to do well. It is a self-fulfilling prophecy to assume that your information workers are untrustworthy.
The stereotypical role of the data-entry clerk mindlessly keypunching from stacks of paper forms while sitting in a boiler room among hundreds of identical clerks doing identical jobs is rapidly evaporating. The task of data entry is becoming less a mass-production job and more of a productivity job: a job performed by intelligent, capable professionals and, with the popularization of e-commerce, directly by customers.
In other words, the population interacting with data-entry software is increasingly less tolerant of being treated like unambitious, uneducated, unintelligent peons.
24_084113 ch18.qxp 4/3/07 6:08 PM Page 371
Chapter 18: Improving Data Entry
371
Users won’t tolerate stupid software that insults them, not when they can push a button and surf for another few seconds until they find another vendor who presents an interface that treats them with respect.
Data entry and fudgeability
If a system is too rigid, it can’t model real-world behaviors. A system that rejects the reality of its users is not helpful, even if the net result is that all its fields are valid.
Which is more important, the database or the business it is trying to support? The people who manage the database and create the data-entry applications that feed it are often serving only the CPU. This is a significant conflict of interest that good interaction design can help resolve.
Alan Cooper, Robert Reinmann, David Cronin - About Face 3- The Essentials of Interaction Design (pdf) Page 50