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.

8. Inside Computer Programs:
'Source Code'

The following command was in a sample piece of program code I was reading about. Can you guess what the ticks are?

Talk about buggy code. If you’re a programmer or shrewd logician, perhaps you guessed from the word ‘random’ that ticks refer to ticks of the clock—actually the amount of time since the computer was turned on. It could have been called TimeSinceStart or Seconds or TimeSecondsAccumulated... anything but ‘ticks’ would make the language more readable, learnable and less expensive for training, development, and debugging. But there seems to be no getting away from contrived terminology in programming languages, no matter how many billions of hours are wasted learning, deciphering, and debugging this stuff.

9. Training

I almost didn’t include a chapter on training, because a main theme of this book is that good program design should reduce the need for training. But then I remembered:

The future belongs to companies
that train.

Why? Because anything that doesn’t require training will eventually be done by machines, most of them computers in one form or another. And the machines themselves will not make good money, trust me.

Good computer programs will continue to reduce the need for training, and many programs will actually conduct the training. But the greater portion of business volume remaining for workers to profit from will invariably be accounted for by two phenomena: change and problems.

The geniuses out there will develop the changes and deal with the difficult problems. The companies that can drag along the greatest number of non-geniuses, the most quickly, will be the most competitive. And the only sure-fire way to do this is with systematic training, computerized or personal, or both.

You’ve been warned.

10. Support and Troubleshooting

Support will kill you if you don’t kill it first, trust me. But you probably know this already from your own experiences. If you’re an optimist, or you experienced your worst computer nightmares so long ago that they are now fond memories, perhaps you’d prefer the maxim: What doesn’t kill you makes you stronger.

I handled some support calls at one job. My favorite call was one where we eventually tracked the problem down to the big red power switch on the side of the computer. It was in the off position. Honest.

A somewhat more interesting situation was on-site at a Manhattan drycleaner. Often our customers would report just plain erratic performance, and there was not much we could do to diagnose it. Attempts at serious power monitoring devices were not too successful.

One time, while training the customer at this Manhattan store, before our very eyes, ‘garbage characters’ streamed across the terminal monitor! It happened a few times before the store owner realized that it occurred whenever the old-fashioned cash register did its quaint ‘kerrrrr-ching’ as the cash drawer popped open. The motor in the register was generating interference that got through to the computer terminals. Finally, we had some reproducible, eyewitness corroboration of corrupted data due to electrical power problems.

Knowledgebases

Your only protection against being caught in an infinite loop of troubleshooting problems is to keep a better database of problems and solutions than everyone else. Update it religiously and publicize it to all users. The goal is to make sure that no mistake consumes your time twice.

Microsoft offers their knowledgebase as part of the quarterly package that they sell to developers, called the Developers Platform or the Developers Library. The knowledgebase is pretty good and it’s called Technet. It has a full-text search and other powerful navigation tools. If you have more than 25 computer users get it, at least once.

Make your knowledgebase in whatever tool is suitable to your needs. It can be as simple as a table in a word processor or a full-fledged database system. Include columns for the program that had a problem, the hardware component, the problem, the resolution, and any other valuable information.

A Primer on Technical Troubleshooting

A member of my family had trouble with a brand new $6000 laptop. It had gotten into a state where Windows appeared on the screen but neither the keyboard nor the mouse would do anything, even after rebooting. It was returned to the friendly, in-house support department, who promptly fixed it and sent it back. When asked what they did, the support department gave a typical, vague answer: “We’re not sure what we did that made it work.”

Don’t settle for this sort of mumbo-jumbo that keeps the user community in a state of perpetual non-motion. The computer was probably stuck in a laptop hell called “Suspend mode,” which is a great feature until you try to use it. What they probably did to resuscitate it was stick the point of a straightened-out paper clip into a hole somewhere on the back of the laptop, to press on a hidden reset switch.

I certainly can’t make you an expert in PC troubleshooting but I do have some ideas that might help you out, based on the thousands problems I’ve worked through. Here is my short training course on technical support.

I don’t care what the problem was. Turn your computer off and start all over again. Even an exorbitantly priced consultant will probably suggest this first.

Don’t overlook the possibility that the computer is actually doing what it’s supposed to.

Some of the hardest problems to diagnose are not even problems, sort of. For instance, I once had trouble with a Help window that would not appear. It seemed like it wasn’t working at all. But it was ‘displaying’ after all—it was just too far off the right side of the screen to see. (I had recently changed my screen from 800 x 600 dots to 640 x 480 dots, and the window was residually set to display at perhaps at the 700th horizontal position.

When you are pounding your head against the wall, try to imagine that the computer is actually doing what it’s supposed to. Think of things in a different way to accommodate this possibility, then work from that vantage point.

Before you pull out a screwdriver to start swapping parts, check for software solutions that don’t require such rash measures.

OK, now it’s time for rash measures. Almost all electronic diagnosis these days is done by swapping out components, until the behavior of the system changes. With computers, this consists of swapping both software and hardware.

For instance, a co-worker once had trouble putting a Lotus ScreenCam display into a Microsoft Word document. We fiddled with Word, we fiddled with ScreenCam. Nothing we did would get it to work. Then we ‘swapped’ ScreenCam with another program, Windows Paintbrush; lo and behold, no external data could be pasted into Word, meaning the problem had nothing to do with ScreenCam!

Next we ‘swapped’ her PC for another, pasting her ScreenCam movie into another computer’s Word document, via our office network, and it worked. The problem then was something peculiar about the setup of the laptop computer she was temporarily using for a presentation. It either had an incompatible program called a Dynamic Linked Library (DLL) or had unacceptable settings in a thing called the Registry.

This whole swapping thing is just the computer version of the ol’ process of elimination. If you must become self sufficient with your computer, become an expert in this process.

One last recommendation, some advice for support technicians when working with inexperienced computer users:

Support technicians should never tell the user what he or she should see; instead they should always ask the user what he actually does see,
and work from there.

In other words, never put words in the user’s mouth, or expectations in their head. The communication process is so difficult with inexperienced users that a lot of effort will be wasted with every mistake. You will be surprised at how many times a user can be looking at an entirely different screen or function than you think they are. If you develop the habit of constantly asking them what they see, and working from what they describe (in very small steps), instead of having them work from what you describe, you will make consistent progress.

Questions to Ask About Support

If you’re buying a serious business system, ask as many questions as you can about the vendor’s support operation. Here are some suggestions:

Ø How many support people are there are? (This is just preparation for the next question.)

Ø How many customers are there per support person?

You’ll have to decide whether the ratio is sensible for the type of application you are expecting to buy. The vendor of a point of sale system thought that 100 customers per support person was reasonable. At times it was; often it wasn’t.

Ø What is the average response time to actually work on a problem, not just return the phone call?

Ø Do you have a call-tracking system to assure that all calls are returned and issues resolved?

Ø If they have a call-tracking system, tell the vendor, “We’ll consider you product after we see the printouts of last week’s calls.”

I once installed a system in Hawaii. And it was one of the very few times I actually had time to do any sight-seeing on the road. I took a helicopter flight to see the active volcano on the big island. We flew around and saw the devastation; roads overrun by now-cold lava, vast gray-black moonscapes, smoldering pools of lava. Then our helicopter arrived at the edge of the ocean.

There was a flowing spout of molten lava, about 3 feet in diameter, squirting out into the water like a huge spigot of blood, with another helicopter sticking its nose right into the stuff—what a whirling idiot, I thought. We remained a cautious hundred yards away.

The other helicopter headed off to other sights and we proceeded to do exactly as he had done, stare head-on from about 25 feet into an unregulated funnel of 2000-degree liquid rock. Sort of like buying a computer... I paid a lot of money to flirt with disaster.

11. Action Summaries

This chapter summarizes the various recommendations made throughout the book, grouped by audience so everyone knows what they must do.

So What Are You Going to Do About It?

It’s been fifteen years since the computer revolution. Without question, there have been many great achievements and remarkable improvements in the technology. But the rate of progress in user friendliness is not fast enough for me. If you’ve made it this far in Computers Stink, it’s probably not fast enough for you either. What can you do?

It is a complex problem that makes many of us feel powerless, even when we are the programmers, project leaders, or purchasers... we don’t have enough time...we can’t spend enough money... we can’t change the hardware companies... we can’t tell the big software houses what to do... we’re not the decision makers. How can we solve any of the problems?

I won’t deny that anyone is often justified in their sense of frustration or helplessness. But at a certain point we must all say to ourselves, “They are us. We are them.” We are all responsible to some degree, or it wouldn’t have gotten this bad.

There is no magic fence between us and them. When I accept deadlines that predestine a product for poor quality, I am the problem. When I buy bad software and accept it without objection, I am the problem. When I don’t educate those around me about solutions to software design, I am the problem. When I let someone tell me to write a program without getting ongoing feedback from users, I am the problem. When I don’t encourage my company to strive for methods that learn from the past, I am the problem. You get the point.

The most important thing you can do, you’ve already done. You’ve educated yourself about the problem, and read at least one person’s opinions on the solution.

The next most important thing is to spread the word. Post my “Computer User’s Bill of Rights,” and “Rules for User Friendliness,” prominently. Copies are at the end of the book. Most importantly, publicize these expectations among new programmers. They are next week’s project leaders and next month’s IS directors. And if you are in a position to tell others what to do, use the remaining portions of this chapter to hand out assignments. Lastly, give this book to someone else to keep the process moving.

Actions for Hands-Off Executives

1. Delegate the job of photocopying and cutting up the pages of this appendix and handing them out to the appropriate hands-on folks. Tell them that the next time they ask for a raise you will ask them to show you their list, and whether they did any of the stuff.

The list as a whole is an ideal set of circumstances; any compliance is a step in the right direction and represents a genuine accomplishment.

2. Make everyone know that you value user friendliness, and that it is one of the things that puts people in your good graces.

Actions for Purchasers of Software

1. If you are buying custom made business software, get a written commitment that ‘all options, settings’ utilities, conversions, fixes, work-arounds and functions with predictable entries will be supported by menu options that invoke dialog boxes with values selected from lists, rather than by typing the characters at a command prompt or text box.

2. Write friendliness criteria into your purchasing requirements by including my Bill of Rights. Quantify penalties for unfriendly software design against support dollars.

3. Build usability testing into your written and spoken expectations. Watch untrained users try to cope with your program. Don’t ask or answer too many questions. Just watch and take notes.

4. Big system purchasers: preview the documentation. If you see lots of error messages, make sure you talk to several satisfied users to prove your users won’t be reading them too often. Visit and observe the support staff unannounced.

5. Make a written requirement that all independent components must have independent, menu-driven diagnostic tools that clearly establish the health of their layers. Establish the delivery of these tools as milestones in your implementation and payment plan.

6. Return bad software for a refund. Promote and support companies that write good software.

7. Call the support department before you buy the software. See how long it takes them to answer the phone. If they ask for your serial number, say “This is a pre-sales technical question,” and ask some sort of hypothetical configuration question.

Actions For All Users

1. 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.

2. 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.

3. Store all of your creations in subdirectories under a directory named MYDATA or similar. Name them by project purpose. This will make it easier to back up files, find them later, and move them to a new hard drive when you upgrade or move.

4. Store all of your programs in subdirectories under a directory named MYTOOLS or similar. This will enable you to rebuild your hard drive more quickly when it is broken, or move to a new hard drive.

5. Always copy your data to more than one medium. Always keep copies of critical data in multiple buildings. Before an emergency occurs, test that you can reload the data.

6. Label all hardware related information, write it down, put it in your log book, and keep it in your files.

7. Keep a single chart of your ‘interrupt’ (IRQ) and port settings, drive specs, and every hardware add-on.

Actions for Programmers

1. Put all functions, mouse methods, fancy keystrokes, and instructions on menus.

10. Put functions where users will look for them. When in doubt, ask users where to put functions; put them in more than one place; and make your menus customizable.

12. Use dynamic communication, not dynamic menus and functions. Don’t change menu or dialog text, labels, or appearances based on context. Instead, make the interface inform the user of the situation.

14. Don’t add extra steps that users must invoke in order to save their work. Assume that all work is intended to be saved, and prompt the user to confirm.

15. Stop rationalizing your design decisions based on ‘actual use.’ Allow in your design for those who don’t know what they’re doing, as well as those who do. Never presume what people will or won’t know.

16. Build usability testing into your written and spoken expectations. Watch untrained users try to cope with your program. Don’t ask or answer too many questions. Just watch and take notes.

17. Put elaborate error messages and error recovery information right into the interface.

20. Give users access to the most detailed level of their data, to recover from corruption situations.

21. Make your program support configurable, exhaustive logging, with a menu driven on/off switch.

Actions for Development Managers

1. Allocate a greater portion of time to active, not passive, code sharing. Assign a librarian, and build a catalog. Conduct training sessions as often as you release projects, to introduce reusable modules to all team members.

2. Keep a master list of all of the best features of all programs, for use in all new programs. Make a functional specification out of it, or a working prototype.

3. Make user interface design a job category, even if it’s part-time or contracted out.

4. Include in each project development timeline the following discrete task: have an interface designer or technical writer critique your specifications or builds for wording, and substitute exact, explicit wording as needed.

5. Build usability testing into your written and spoken expectations. Watch untrained users try to cope with your program. Don’t ask or answer too many questions. Just watch and take notes.

6. For larger systems, have a programmer create a tool that supports the registration of newly developed, independent functions, and automatically adds them to all access indexes: alphabetical, date of development, and learning sequence.

7. Make a single programmer responsible for an error trapping methodology, including data microscope, logging, and layer diagnostic tools, and helping with their implementation by all programmers.

Actions for Tech Writers

1. Documentation department leaders: revolutionize your focus. Stop documenting everything. Isolate and target different issues, the difficult things that users are likely to struggle with.

2. Build usability testing into your written and spoken expectations. Watch untrained users try to cope with your program. Don’t ask or answer too many questions. Just watch and take notes.

3. Spend your time writing about the things that you can’t discover directly from the user interface: startup concepts, non-intuitive and incomplete functions, and user technique.

4. Write from interaction with customers, experimentation, and experience, not from written promises. If your company tells you to document, from specs, an application that you can’t actually get your hands on, use all of your persuasive resources to convince the powers-that-be that it is a poor use of the company’s money and not the most profitable way to serve your customers.

5. Put more effort into troubleshooting info, identification of checkpoints, and defining ‘sufficient conditions.’ You’ll notice that this type of information is much more difficult information to collect and organize. But that’s good... it’s a sign that you are actually creating something of value.

6. Diplomatically recommend to your engineers that certain procedures might be good candidates for code on the next go round.

7. Restrict your printed publications to volumes that can be read entirely in a single sitting, emphasizing vital conceptual information.

Appendix 1: A Computer User’s Bill of Rights

3. You should be able to make mistakes without being terminated, executed, canceled, re-booted, or erased.

6. You expect to be forewarned when any work is over-written, undone, or erased.

7. You expect to have most of your work retained
after the power is interrupted.

8. You should be able to accomplish every task and entry with the fewest possible keystrokes.

Appendix 2: Rules for User Friendliness

5. Put all orders on ‘menus’: alphabetical, functional, learning, date, and so on.

23. Don’t limit users to a single design metaphor, combine the best of them all.

Index

This section was omitted from the HTML conversion. Until we rebuild an online index, please use the full-text search on the Usability Institute home page.

Computers Stink, by Jack Bellis

8. Inside Computer Programs: 'Source Code'