Introduction

Can you think of some software you use but don’t like? Most people can. And just what about the software don’t you like? If you’re like me, chances are the software serves an important purpose to you but doesn’t function in the way you would like it to. It might be too complicated for beginners to understand. Or it might have bugs. Or it might be cumbersome to use, no matter how skilled you are.

In other words, the software isn’t very useable.

In this book, I show you how to create highly useable software. Highly useable software is software that is easy to use, does what you expect it to, and does it well. Such software might sound easy to build, but it’s not.

Software is big and complex. So many things can go wrong. And that’s why I’m here with this book. I want to show you what you need to do to ensure that your software will be highly useable.

Over the years, helping programmers understand how to create highly useable software has become somewhat of a mission of mine. I’ve become so frustrated with software, and I’ve seen my friends become so frustrated, that I feel as though I, as both a programmer and a writer, must actually do something about it. You are my peers, and I want to show you why people are not always happy with the products that you and I have created. But even better, I want to show you what you can actually do to improve the situation.

And the result is this book you are holding. If you’re standing in the bookstore, I promise you that you will not be disappointed with this book. You will find at least something you had not thought of, some little piece of information that will make your software better. But if you read the whole book, you’ll probably find lots of great advice. (And don’t worry; I crack a lot of jokes. I can’t help it. It’s just me. You would too if you were me.)

And while I’m at it, I offer numerous little stories or anecdotes about my own frustrations with things other than computers. Often these frustrations are with cars. Or with paper towel holders. Or anything. I present these anecdotes in the form of little side stories that I think you’ll enjoy reading. But the purpose isn’t to just amuse you. (Okay, that’s part of the purpose, but not the only one.) The purpose is to demonstrate to you that you are a user, too. And when you use these products in daily life, you will start to realize that you stand on the other side of the fence every day, dealing as users with the products that other people have created. And you probably get just as frustrated with these people as (dare we admit) our users get frustrated with us. Thus, these stories will help you step into the shoes of your own users.

Helping the world create better software has become one of my missions in life, to show the world that you and I—we—can make better software. No more will people be frustrated. No more will people encounter bugs. From now on, software will function the way people want it to, and they will actually enjoy using the software we create.

Is this possible? Can we really all get together and finally start creating highly useable software? Yes. And I am going to see to it that it happens.

But just making good software isn’t the whole focus. Let’s be honest: If we were all independently wealthy, we probably wouldn’t be writing software. The truth is, most of us are in this to make money. And how do we make money? By selling software. But do we sell just any old software? No. We sell software that serves precisely the needs of the end users. Our software shouldn’t bog them down with unnecessary steps (such as clicking eight extra times every time they need to perform a simple, common task). Our software shouldn’t complain to the user (for example, screaming at them that the disk drive is out of memory and then offering no solutions). Our software shouldn’t run in a manner that drives the processor usage to 100 percent, possibly burning up the computer (we’re nicer people than that!).

Back in the early 1990s, I used to argue that software should be like a telephone: If you’re at work and are talking on the phone to a client, the last thing you want to do is to have to discuss issues pertaining to the phone you’re using. The phone is a tool and you shouldn’t even have to be thinking about the phone while you’re using it. You want to be thinking about the conversation.

Similarly, software is a tool. But I don’t use this argument anymore, because it trivializes the matter. Software is far more complex than a single telephone. (Although the entire telephone system across the planet probably surpasses most software in complexity!) Software isn’t as invisible as a telephone. When you’re using software, you really are thinking about the software, meaning that the software can’t really be invisible. Instead, software should be more like your trusty assistant, helping you along the way.

For example, if you are using a word processor and you accidentally type yuo, wouldn’t a good human assistant proofing your document just fix the error, changing it to you for you? Why should the assistant come and ask you for permission? That’s a feature that Microsoft identified as a highly useable feature, and they put it into Microsoft Word in the form of the AutoCorrect feature.

Software is more than a tool. It’s an assistant, a helper. It’s a tool with a brain more powerful than the computers that put men on the moon.

But unlike a human assistant, highly useable software shouldn’t argue with you or blame you when things go wrong. Instead, software should be quick yet show unending patience. Software should be gentle and kind, offering suggestions when necessary and automatically fixing problems when possible.

In this book, I show you how to create such software. It really is possible. And often it takes a shift in perspective, a move toward a new way of looking at your own products.

Read this book and you’ll see what I mean. And you’ll find yourself creating the best software you’ve ever created.

About This Book

I’ve arranged this book into three main parts:

Part I: Keeping It Simple

This part consists of seven chapters that tackle the more obvious components of the software, focusing on the user interface. The first chapter covers the user interface, where I talk about general GUI issues centering on usability.

Then I move on to Chapter 2, which deals with modeling the real world. I talk about how to model devices and cover such topics as simulators and controllers.

Chapter 3 focuses on windows and dialog boxes. Too many people think this topic is the entire scope of usability. Usability extends far beyond this area, but it is still an important part of usability.

Chapter 4 covers an odd issue, that of managing time with your software. As a user, I get so frustrated by software that seems to freeze up my computer or take forever to perform a task. In this chapter I show you how you can avoid such problems.

Chapter 5 deals with creating software that can be easily navigated. To use most software, you need to click buttons, select menu items, and use hot keys, all of which get you to some part of the program that lets you perform a particular task. Why make the users jump through hoops to get to the parts of the program? Instead, make your software highly navigable.

Chapter 6 is all about reports and data. I’m amazed at how difficult phone bills are to read, even after all these years. Reports and data have their own usability issues much like software does. In this chapter I show you how to reduce the complexity of your reports so that the people reading them can easily understand them.

Chapter 7 is about adding a web interface to your program. This is the twenty-first century, after all, and we’re all using the Internet every day. Most likely, you’ll want your software to be able to access the Internet. But be careful! In this chapter I show you how to keep your software free of problems while it interfaces to the Web.

Part II: The Lonely Engineer

This part consists of four chapters specifically for engineers and programmers. I go underneath the hood and talk about programming issues that might not seem like they affect usability, but they do.

Chapter 8 is a collection of topics that you, as a programmer, must do right or the usability of your software will suffer. For example, I talk about dynamic memory allocation, pointer variables, how to avoid tight loops that burn up laptop computers, and other fun programmer-related issues.

Chapter 9 is all about your software starting up, shutting down, and possibly dying. When I was researching this chapter, I was amazed to see just how many usability issues deal with the starting and stopping of software!

Chapter 10 is all about libraries. Libraries can be incredibly annoying to the user. How many times have you had to install software that dumped who-knows-what into your system directory against your will? I talk about that and similar topics in this chapter.

Chapter 11 is an exciting chapter that’s all about object-oriented programming, or OOP. Now that we’re all familiar with OOP, we can stop talking about the things we already know (such as how to create classes and inherit from them) and move on to the usability issues in OOP. You might be surprised to see just how much usability works into OOP and how mistakes in OOP can adversely affect the usability of your software!

Part III: The Business of It All: It’s “Dollars and Sense”

This part moves away from the programming aspects and talks about business-related issues and how they affect usability.

The first chapter in this section, Chapter 12, covers general business topics pertaining to the design of highly useable software. For example, I talk about how in the ’90s everybody was looking for the “killer application,” and yet today we’re not using any of those software products. Why is that? Because the designers of the killer apps totally missed the whole usability factor, resulting in software nobody wanted.

Chapter 13 is all about testing. All software must go through thorough testing. And almost all software companies have well-staffed test groups. But how many of these groups are looking for usability issues? Not enough of them. In this chapter I show you how you can help your test group move up to the next level and watch for usability bugs.

Chapter 14 covers three related topics: software training, online help, and software installation. Installers are themselves software programs that require high usability standards. After all, what good is your software if the users can’t even get it installed? Training and online help even have usability issues. You want your users to be able to learn how to use your software, and here I show you how to make your training and help as useable as possible.

Chapter 15, the final chapter, is a special chapter devoted to bosses and managers. I’m assuming that both programmers and bosses or managers will read this entire book, but for most of the book I’m talking to programmers. In this chapter I’m talking specifically to bosses and managers, going into some issues that you might be surprised to see in a book on usability. For example, I talk about the different personalities of programmers and how to deal with programmer problems. What does this have to do with usability? Everything. A programmer who doesn’t understand his or her own shortcomings could easily put a major dent in the usability of your software, resulting in bad software and lost sales. If that worries you, then you will certainly want to read this chapter.

Finally, I wrap up the book with an appendix that covers standards, groups, and sources of more information, all focused on software usability.