Chapters 1-3 <You are here
Note: This is a quick conversion of what had been a glued-binding book, to a 3 long HTML files. Over time, I'll improve the conversion. A single PDF (854K) and DOC file (774K) are also available.
Sadly, though this book was written in 1997, most of the complaints about software design are just as true today.
—Jack Bellis, March 11, 2003
This book is free to copy as you please. No copyright is claimed by the author.
All brand names used in this book are the trademarks, registered trademarks, or brand names of the respective holders.
For Susan, Jessica, and all the computer users waiting for the promise to be fulfilled without the problems.
The table of contents has not been converted to HTML yet.
1. Introduction 7
Is This Book For You? 8
Cut to the Chase! 8
Mass Market Improvements Haven’t Filtered Down to Business Software 9
What About Popular Style Guides? 10
Topics in this Book 10
Programs and the Complexity of Machines: How Bad Is It? 11
About Me 12
My First Computer Idea 12
Changeable Neon 12
Programming Mysteries 13
Ideas and Solutions 15
2. What Do Users Expect From A Program? A Computer User’s Bill of Rights 17
3. The Underlying Problems 21
One Central Problem 21
Electronic Troubles 21
Walking the High Wire 22
A Beginner’s Guide to Backup 22
The Invisible World: Directory or Hiding Place? 24
'Distributed Processing' 24
Most Programs Are Only Half Finished 24
User-Friendliness is Long-Term Marketing in a Short-Term Market 25
Lack of Knowledge or Concern 25
Windows 95, or... Computers Still Stink 26
4. The User Interface: Hit Any Key to Continue 28
Importance of the Interface 28
What Is Human Factors Engineering? 28
The Communication Burden: Interface or Documentation 29
Elements of the User Interface 30
The Machine Makes You a Machine 30
There Are Very Few User Interface Designers 31
Major Problems with User Interface Design 31
Form Follows Function? 32
Most Development Starts Over Again from the Beginning 33
Complex Procedures That are Never Converted to Program Functions 34
Special Values that Never Get Built into the System 34
Bad Design 34
Developer’s Indifference 36
Paranoia? Mistaking Secrecy for Security 37
Lost Productivity Hall of Fame... Can You Guess? 37
No Usability Testing 38
Rules For User Friendliness 39
#1: Put All (ALL ALL ALL) functions, Mouse Methods, Fancy Keystrokes, and Instructions on Menus 39
#2: Use Verbose Phrasing 41
#3: Use Perfectly Accurate Words 42
#4: Be Explicit, Not Implicit 44
#5: Put All Orders on ‘Menus’: Alpha, Functional, Learning, Date 46
#6: Provide a Master Menu, Integrating All features 47
#7: Display from the General to the Specific 47
#8: Always Let Users Navigate by Descriptive Values, Not Internal Codes 48
#9: Use Buttons as an Additional Option—Not an Alternative—to Menus 50
#10: Put Functions Where Users Will Look for Them 51
#11: Always Show the Level at Which Options Are Invoked 51
#12: Use Dynamic Communication, Not Dynamic Menus and Dialogs 52
#13: Always Provide Visual Cues 53
#14: Default to Saving Work 54
#15: Tune for Learning, Not Just Cruising Speed 54
#16: Usability Testing 55
#17: Build Error Message Details Right into the Program 55
#18: When the User Does Not Have Control, Announce it Prominently 56
#19: Use Color to Speed Recognition, and Sound for Feedback 56
Some Not-So-Easy Recommendations 57
Microscope: Detailed View of Internal Data 57
Trace: Detailed View of Program Commands 58
Layer-Testing Diagnostics 59
Mixing Metaphors 60
5. The Nine Levels of Help 61
1. None 61
2. Bad Books or Help 61
3. Good Books 62
4. Good Books, Online, Context Sensitive, Interactive 62
5. Better Books 62
6. Good Programming 63
7. User-Sensitive Help 63
8. User Contributory Help 64
9. Wizards: Step-Through Dialogs 65
6. PC Hardware 67
Modular Hardware? 67
Write It Down 69
The Computer as a Household Appliance 71
7. Documentation: One Step Forward, Two Steps Back 73
Why Documentation Stinks 73
Reason #1 Why Computer Books Stink: Insufficient Emphasis on Valuable Information 73
Reason #2: Books Are Often Written From 'Specs' 75
Reason #3: Companies Expend Resources on Superficial Editing, Not Usability Testing 75
Reason #4: ‘Cookbooks’ Without Troubleshooting 76
Reason #5: Failing to Roll the Books Back into the Product 77
To Print or Not to Print... 78
What is the Real Issue? 78
Strengths of Paper and Electronic Documentation 78
Put All of the Information Online 78
Print a Short Read-Through Guide 78
What Should Be in a Read-Through 79
Videos and Other Passive Learning Tools 80
8. Inside Computer Programs: 'Source Code' 83
Make Descriptive Terminology a User Option 83
Provide Menu Support For Program Syntax 85
9. Training 87
10. Support and Troubleshooting 88
A Primer on Technical Troubleshooting 89
Questions to Ask About Support 90
11. Action Summaries 92
So What Are You Going to Do About It? 92
Actions for Hands-Off Executives 93
Actions for Purchasers of Software 94
Actions For All Users 95
Actions for Programmers 96
Actions for Development Managers 97
Actions for Tech Writers 97
I’ve got to stop writing this book! But every day I come home from work with more examples of how much time is being wasted with stupid, avoidable computer problems. There seems to be no end. To make this book, I’ve taken every example and asked myself, “How could computer software be improved to make the problem go away?” I’m convinced that a significant portion of the answers are now contained in the following pages, so I will force myself to stop and leave the results in your hands.
Just remember as you read, I’m not opinionated, I’m right.
Those who agree with us may not be right,
but we admire their astuteness.”
— Cullen Hightower
I called a professional printer to get an estimate on producing the book you are reading now. His estimating software crashed as he was entering the job information—yes, really. He said he’d call me back.
Productivity. That was the promise, right? And what a payoff we got. I can now operate the equivalent of a publishing house from my home office. With programs like Ventura Publisher or Macromedia Director, I can learn in weeks what used to take a lifetime apprenticeship, and get results with a fraction of the time and money that used to be required. That’s the good news. But the average computer user does not go half a day without some sort of unnecessary frustration, problem, or time loss. That’s the bad news that I want to turn around.
The printer whose program crashed was using an estimating program that he had created himself, and he probably deserves a lot of credit for the accomplishment. In fact, he gave me the first part of the pricing information in a matter of seconds, just before the program had a problem. This put him head-and-shoulders above the other printers I called, who all seemed to act as if obtaining a price estimate required conjuring spirits. So his experience was very typical: computers both elevate his business and make it more frustrating. Go figure.
This book describes why computer programs are so difficult to use, why more time is often lost than gained, and what can be done about it. The concepts discussed in this book apply to all software and hardware, and the perplexing array of technologies and activities that intertwine the two.
Take your own informal survey of computer efficiency—I did. Ask the people you work with when the last time was that they wasted time with a computer problem. Then ask them what percentage of time they think they lose to those problems. I routinely get responses of “yesterday” and “10-20 percent.”
Most of the recommendations in this book are for programmers and their bosses. But you will benefit from this book if you use or buy programs, or manage people who do. Even if you don’t, you should find much of interest here, if you are 'Howard-Beal-mad-as-hell' about the troubles you've had using computers and want to understand why, whose fault it is, and what to do about it.
No matter how easy this stuff is, I don’t suggest that it is common sense. If it were, it would already be common practice.
By some estimates, businesses spend more on computer technology than on the natural gas, automotive, petrochemical, steel, and mining industries combined. Now imagine how the results of your survey impact such a huge expenditure.
In a nutshell, more technology—in and of itself—is not the answer. But the entire computer industry loves to make you think it is. That way, they can foist on us all the latest techno-miracle, and by the time we realize it hasn’t reduced the inefficiency, they’ll have another one.
The current flavor-of-the-month is called Java, the latest in an endless parade of programming languages, which developers must learn again from a standing start. According to the industry it cures cancer, makes you live forever, and gives you wealth beyond imagination. According to me, it’s another distraction from the real goal: following through on established practices to fully capitalize on the great technology that we already have.
and the Complexity of Machines:
How Bad Is It?
I've used computers since 1982. At that time, I had an idea for a program, bought a cheap computer, and thought I'd make the necessary program and sell it. Although I didn't have any expectations about how long it would take me to make the program —I had no experience in programming— I suppose I thought it might be several months.
Two years later, the program was ready to sell. In the interim, I learned just how far computers had come in a few short years and just how far they still had to go if they were to fulfill the expectations that had developed.
I particularly remember one night when I stayed up ‘till about 4 AM trying to get letters to scroll smoothly across the top of the screen. (A coarse, bumpy, scroll was built into the machine, but smooth scrolling required something akin to decoding the Rosetta Stone.) When I finally got it, I thought it was the happiest day of my life. It was the hardest problem I had solved since Rubik’s Cube.
Pretty exciting stuff, eh? (I’ll bet some of you propeller heads are out there mumbling to yourselves, “Add accumulator 7, store accumulator 212...”) To make a long story short, the whole thing taught me that computers stink. No matter how much more powerful they keep getting, the power doesn’t seem to consistently translate into productivity. The same mistakes seem to occur time and time again. With each new technology, we seem to start at the beginning again. All over the place the machines are mastering their users instead of vice-versa. Why?
Ideas and Solutions
In the words of the immortal Howard Beal of the movie Network, I'm mad as hell and I'm not going to take it any more. I've used hundreds of computer programs, learned 17 languages for talking to computers, and I've seen the same mistakes repeated over and over for 14 years now...
I've seen one company after another have endless meetings to solve the same customer support problems... I've suffered through the same troubleshooting scenarios on my own and coworkers' computers time and time again... and I've heard the same excuses over and over. And, while I see improvements, they’re hit-or-miss. I don’t see organized, steady progress.
You shouldn't have to read a manual,
certainly not a huge one.
For large business systems, certainly manuals might be unavoidable. But documentation is not a substitute for making the user interface do most of the work. It’s true that many of today’s programs replace what was once a lifelong apprenticeship with what is now a $100 program. The training required to eventually equal the skill of the trained artisan might still take a considerable investment of time and energy, but good programs make it possible to get results with a minimum of effort.
I recall reading in a recent book about the Internet that it takes a certain seriousness of effort to jump the first few days’ hurdles of navigating the net, because all programs must choose between power and friendliness. That’s nonsense—it’s the same old excuse we’ve been hearing forever. One software house after another is proving this false.
Ø Hitting Enter gives you today’s date.
Ø If the user enters a single digit, such a 8, the system assumes he means the 8th of the current month, and fills in the full date January 8, 1996.
the user enters 3 or 4 digits, such a 110, the system assumes that the final two digits are
the month (for DD/MM/YY users such as in the
Don’t think of this page as intentionally blank...
it is ‘paragraphically challenged.’
There is one central problem that is ultimately at the root of all of this trouble:
Electronic processes are invisible to the naked eye.
More to the point, the inner workings of the computer are so microminiaturized as to be completely beyond our ability to cope when things are not entirely as we expect. Almost all other problems are really results of this one deadly killer; don't be fooled.
What Can You Do?
Use every countermeasure to battle against the most hidden aspects of the computer. Improve the hardware, software, documentation, training, purchasing demands, support, and record keeping. Insist on every countermeasure that increases the visibility of the machine’s inner workings. That’s what the rest of this book is about.
How can I blame so much on so singular a factor? The limiting factor with today's computer systems is not their performance when things are working right, but their ability to frustrate us when things are less than perfect. With mechanical systems, by my rough estimate, one in three people can understand or even fix a problem; two in three can at least understand what's causing the problem. This is even true for what are called 'electro-mechanical' systems such as automobiles of the 1960's.
But once electronics enter the scene, I’m sure the numbers change dramatically for the worse. Perhaps only one in a hundred people can diagnose an electronic system. In fact, true root-cause diagnosis is almost never done. Instead, whole electronic modules and even whole products are replaced when there are problems. This is often done without genuine diagnosis, but with a process that requires less expertise: swapping parts in a crude process of elimination. Too many times the underlying problem goes unresolved and rises again to destroy the newly installed part.
From a troubleshooting perspective,
computers are an insidious subset of electronic appliances, exacerbating the already disastrous nature of electronic troubleshooting with more levels of intricacy and variability.
In the sentence above, it took me a long time to settle on the word 'disastrous,' after rejecting softer alternatives such as difficult, troublesome, and untenable. Too strong a word? Tell that to the folks at a nuclear power plant. Or how about the many folks who insist that their automobiles accelerated without their having pressed the gas pedal?
I hate having electronic appliances fixed because I expect the repairman to replace what is essentially the entire electronic device. At one point, our house had a microwave oven that worked whenever it wanted, a TV remote control that worked by appointment only, an electronic air cleaner that worked sometimes, and a furnace fan that worked incessantly when the mood struck it—all electronic marvels.
What can you do?
Make sure at every step of the way that you are mastering the technology and not vice versa. Strive to understand the layers of technology that have brought us to this level of performance, or get people who do.
What can you do?
Get down from the high-wire every so often. Prove that YOU determine when you get up and down, not the technology. Do backups and prove you can restore them. Test your operation with various aspects of your computer not functioning.
If failure can happen, you can bet it will happen at the worst time, and it’s not always just coincidental bad luck. Many system failures occur at the worst times because those are the times when the system is stressed or tested the most. Expect the unexpected.
The following advice is primarily for users who are relatively new to computers. If you’ve never lost any work on a computer, you are relatively new! Computer backup has at it’s core a very simple tenet realized a long time ago when thrill-seekers would perform stunts on the wings of flying airplanes:
The first law of wing-walking: don’t let go of one wing until you grab hold of the other wing.
If you’re a computer veteran, of course, the following advice is unnecessary for you... right?
Ø Establish your pain threshold for repeating work, and save your work that often. In other words, let’s say the most work that you could bear repeating is 20 minutes of work. Save your work every 20 minutes. If your program has an automatic, timed backup, set it for 20 minutes. And even though you have an automatic timed save, still save your work manually every 20-30 minutes.
I have to interrupt this good advice for my most recent computer horror story. I was using the previously-most-popular word processing program in the world recently when it started giving me trouble. It would freeze, indefinitely, and wouldn’t let me enter any text, click on anything, or even restart it without restarting Windows 95.
Then I noticed that it was happening like clockwork. Aha! I turned off Timed Backup and the problem went away. Something was making the Timed Backup fail, and instead of issuing a message, the best it could do was its own version of what some folks call the Black Screen of Death. Let this be a warning to you—I just don’t know what the warning is.
Ø Once a project consumes more than a day of work, save at least one older copy under a different name, still on your hard disk drive. Having only a single copy of your data on your hard disk drive is a prescription for misery. Sooner or later you will use a program that corrupts your data and the authoring program will not be able to read the copy of the file you are working with. By having an alternate version, you can revert to that one.
Ø After adding days of work to a project, copy your data files out of your computer to another medium such as a diskette. Sooner or later your hard disk drive will fail due to static electricity, voltage surges, electronic deterioration, disintegration of the magnetic drive surface, or degradation of the rotating mechanism.
Ø After working on a project for more than a few days, get your backup diskettes or tape out of the building. I keep copies of this book in my car, to protect against theft, flood, and fire, and randomly rotate new copies back and forth to the car or office.
When I worked at the Franklin Institute, I took a trip one time to bring back an entire holography laboratory. I came back after museum hours, so I put everything away as well as I could. The only problem was a big can of holographic film , about the size of a five-gallon paint drum—it had to be put in the refrigerator, which was behind locked doors. After looking around a little, I found a good spot. Being in the basement, the cool weather made the ten-foot-deep window wells a good choice.
I hesitated as I walked out our door, thinking to myself, “What are the chances that someone will come in our shop to clean the window wells for probably the first time in the 70-year history of the building... no, don’t be paranoid, it says in big letters right on the can, “Holographic Film, Do Not Expose To Light.”
The next morning, I was busy with some chores when I passed by the building engineers walking into our shop as I walked out. Halfway down the hall, my eyes bulged out and my neck stiffened. What are they doing in our shop!? Yes, less than 10 hours from the return of my trip, the basement window wells of the Franklin Institute were being cleaned. I’m certain it was the first time ever, and yes, the can was already open, the bright yellow Kodak label lying on the ground, the three layers of tape ripped from around its tightly sealed top, and the dark black paper peeled back. As I told you, expect the unexpected.
Months later, I learned that much of the film ended up working quite well. I don’t know how much was lost.
One of the most repetitive problems with software is just finding your work. The typical computer disk drive has hundreds, sometimes thousands, of directories. With the DOS limitation of 8-letter filenames, most organized folks create a deep hierarchy of cubbyholes in which to store their many projects. The result is that the disk drive can become a huge hiding place, despite its surprisingly compact size. But programs and operating systems have made slow, hit-or-miss progress at addressing this problem.
All applications, utility programs, and operating systems must take more responsibility for finding things. Search features must not be treated as an afterthought or optional accessory. Features which search or sort must work across all directories and disk drives.
What can you do?
1) Create separate directories for all categories of data. When in doubt about whether a directory should be a subdirectory or at the same level as the previous one, make it at the same level.
2) Store all of your creations in subdirectories under a directory named MYDATA or similar. Name them by project purpose. Don’t store them with the relevant authoring programs, as many programs encourage you to do.
3) Store all of your programs in subdirectories under a directory named MYTOOLS or similar.
By relegating all projects and tools to two subdirectories, the highest level directory on your drive (the root directory) will be less cluttered, which will make your directories easier to work with. And it will be easier to identify what must be moved or copied when it is time to rebuild your system or move it to another machine or hard drive. That day will surely come.
A trend that is now only a few years old, called distributed processing, is taking things to new extremes of frustration. Distributed processing means splitting up programs into pieces that are then put on multiple computers instead of on a central system. It is synonymous with ‘client-server’ computing and has resulted in software solutions that use between seven and ten layers of technology.
Eventually this approach will be refined to a point where a successful balance is reached between the costs and rewards of this complexity. Until then it is a pot of gold for software developers because creating the full solutions—not simply the programs—is an incredibly tenuous process, fraught with finger-pointing at ever turn.
None of distributed processing’s problems are unique. Its problems are simply more and ‘better’ versions of what the technology already offers: invisible behavior, poor diagnostic methods, piecemeal engineering, and for the pièce de résistance, new state-of-the-art tools every month.
The pressure to be first to market is intense in the computer business. You know that. It’s one excuse that most programs don’t do everything they should. As programming standards have improved, we are starting to understand just how much a program can do when it is as good as it can be. The recent method which Microsoft calls a wizard is, if not the ultimate, close enough. Wizards prompt you for the minimum required information, and lead you by the hand through what would otherwise be a complex process. An example is presented in Chapter 5, The Nine Levels of Help. In earlier generations of programs, such processes would have been lengthy written procedures in the documentation, supported by many separate menu functions of a program.
But wizards demand the ultimate expenditure of effort from the programming staff. After all of the basic functions have been built into a program, a wizard puts them together, adds elaborate instructions, and even makes assumptions and suggestions about how those functions will be tied together. The following quote, possibly attributed to Peter Norton, a prominent computer expert, summarizes this unfortunate tradeoff for users:
There is always a tradeoff between the convenience of the programmer and the convenience of the user.
Another way of saying it is that good user interface design takes more work. Wizards, however, are only one type of thorough program, one suited to predictable procedures.