How Software Affects Businesses

Just how much time do you waste with software? Suppose you’re doing a report that you’ll present at your next team meeting. You’re using Microsoft Word. You need to number your headers so that all level-1 headers start with an automatically generated number. The level-2 headers are to be numbered in Roman numerals, and they start at I under each level-1 header. And finally, you want an appendix that starts with a level-1 header but doesn’t have a number on it.

REAL WORLD SCENARIO: When I Pulled on the Paper Towel, the Roll Fell Off into the Puddle.

This isn’t such a big deal. It really isn’t. And so why should it bother me so much? For that matter, I suppose it’s partly my own fault. Here’s the scoop: I have a rather cheap paper towel holder attached to the door of the cabinet under the kitchen sink. And when I need a paper towel, I open the door, grab the end, pull a bit to reveal the entire square of paper towel, and then I yank—hard.

Well, the tension the holder puts on the tube inside the paper towel roll apparently isn’t very strong, because the last few times I did this, instead of getting a single square of paper towel, the entire roll came loose from the holder, unwound, fell right to the floor, and landed in the very puddle of water I was about to clean up.

Now I suppose the irony here is that when the roll landed in the puddle, it soaked up the puddle and did the cleaning job it was supposed to do. Unfortunately, the water soaked through numerous layers and I had to forfeit half the roll to the trash can, which happily swallowed up all those wasted, wet paper towel squares. Such is life.

But the real question is this: Who would sell a product that works only half the time? And why should we, as users, put up with that?

Now you’ve heard me say this before, but I’ll say it again: Imagine if somebody said that about your product. What I experienced was a hardware version of a software crash. (In fact, something soft did go crashing to the floor.)

Now quick: Make a Word document that does all this.

I just tried it. Because I use Word so much, I managed to do it in about three minutes. But I got lucky on one of the items (preventing numbers from appearing on the appendix). For the appendix, I wasn’t sure how to keep the numbers from appearing, so I right-clicked on the appendix header, chose Bullets And Numbering, and in the dialog box clicked None. It worked.

But how quickly can most people do it if they never use the numbering schemes on Word? Well, consider what I had to do: I chose Format Style, and in the dialog box that appeared, I chose the Header 1 style and then clicked Modify to get the Modify Style dialog box. I then clicked the Format button, which produced a strange drop-down menu, in which I chose Numbering. This opened the Bullets And Numbering dialog box, and I clicked the Outline Numbered tab. I clicked on the first numbering sample and then chose Customize. (Oops, it looks like when I chose Customize, I actually modified the defaults in the dialog box. I’m not sure if my changes are permanent, though. The software could be a little clearer about this.) That opened the Customize Outline Numbered List dialog box. And that one is a seriously frightening dialog box to look at; I’m just lucky that I’ve used it many times and wasn’t intimidated by it. But after messing with that dialog box, I managed to set my numbering scheme.

But hey, it looks like I messed up: While describing these steps to you, I realized that I took the long way around. I kept returning to the Modify Style dialog box; the first time I chose Heading 1 and went through the rigmarole of setting the numbering. Then I returned again to the Modify Style dialog box, this time choosing Heading 2 and then going through the same rigmarole. As I just now discovered, it turns out that in the final dialog box I cascaded to, the Customize Outline Numbered List dialog box (that’s four cascading dialog boxes, mind you), I could have set the numbering for all the levels right then and there. I guess there was a faster way, and I didn’t quite know what I was doing. That means I wasted some time.

And now imagine a new user who has never done all this before and the amount of time it would take to do this. Is it really necessary? Wouldn’t some kind of wizard be easier? Besides, the final dialog box, the Customize Outline-whatever-it-was-called, seemed to operate rather independently of the previous dialog boxes. Why did I even have to go though those dialog boxes? I guess Microsoft wanted to sit back and laugh at me. I don’t know.

Now think of the hours spent across the planet on that one task, which is a task that has tripped up many people. Imagine all the time spent, and the wages earned, and how much money could be saved worldwide by businesses if their employees didn’t have to waste any such time on the computer.

Now look at your time spent at home on your own computer: How much time have you spent fiddling with a software installation or with setting up a network connection? And think how much more productive you could have been without having to go through that. (The days of messing with those mysterious things called IRQs in DOS and early versions of Windows come to mind for me. And, of course, I recall my adventures installing a DSL modem at home, which I talked about earlier in this book; see “Don’t Reinvent the Wheel!” in Chapter 4, “Managing Your Software’s Time.”)

Imagine that if software was easier to use and much more straightforward, how many countless hours per month would be saved! Imagine the amount of time you could spend doing what you want to do on your home computer. Imagine how much time your company would save if the workers could get right to the task at hand and not have to fiddle with the software, trying to figure it all out! The prospect is, frankly, frightening. And further, when users are focusing on the software and not their actual work, they might even end up doing a sloppy job of their actual work.

But we, the programmers, have it within our power to change all this. Stop blaming the end users, and instead give the users what they need.

REAL WORLD SCENARIO: The DSL Modem Adventure, Part II

Back in Chapter 4, I lamented about the troubles I had getting the DSL modem set up on my laptop while visiting my sister. She already had the DSL modem and software all set up on her computer. To get it all on my computer, I had to go through a huge installation process.

Well, guess what: Just yesterday, I was at my sister’s again, and she had a second computer that needed to be hooked up to DSL. This time I decided to be smart: I opted to not even use the installation CD the DSL provider had sent her. This was, after all, Windows XP, which was supposed to have all kinds of drivers and such already installed.

Here’s what I did: I opened up the Network Control Panel and clicked Create A New Connection. The New Connection Wizard opened. I clicked Next (after reading a useless introductory screen), and then I chose Connect To The Internet. I clicked Next and then chose Set Up My Connection Manually. I clicked Next again and chose Connect Using A Broadband Connection That Requires A Username And Password. Then I clicked Next. I was asked for the ISP name, which, it turns out, is really just the name that will go below the icon in the Network Connections dialog box. I typed the name of the ISP and clicked Next. I was then asked for a username and password (as well as to confirm the password). I had to choose a few options; the first was whether to use this username and password for all users of the system; the next was whether to make this the default connection; and the last was whether to turn on the built-in firewall software.

I clicked Next, and a final screen came up asking me to verify everything. I clicked Finish. And lo and behold, the connection worked on the first try! I did it all by myself without the help of some silly installation program. Now I really have to wonder what in the world possessed the people at the ISP to write their own software!

Technology Has Improved, but Has the Usability?

This one is a no-brainer. Of course technology has improved. But if usability had improved as quickly as technology, we wouldn’t have a need for this very book you’re reading and the other books in the usability field.

But why is that? Why couldn’t usability improve?

Well, first, usability has improved; don’t get me wrong. The word processor I’m looking at right now is far better than some of the early word processors (anyone remember the original WordStar?). However, that’s not to say that the usability has improved in the same leaps and bounds as the technology. The fact is, back around 1988 I had an Amiga 500 computer, which featured a graphical user interface very similar to the early Macintosh computers. And I had a word processor on that computer that looked, frankly, an awful lot like the current word processor I’m using right now, Microsoft Word. Yes, this new version of Word is light-years ahead of that early Amiga word processor in terms of power. But what about usability? I have to say, with all honesty, that that word processor was, in fact, easier to use than Word. But my answer is a bit weighted in that I’m comparing apples and oranges. In terms of setting the fonts and typing in the text, the two are about the same. But all those extra features that exist today in Word that didn’t exist in that early Amiga word processor are actually a lot harder to use than anything I used on that old Amiga computer. And for that reason, I cannot say that the usability of Word is any better than the usability of the old Amiga word processor.

Let’s face it; how much of Microsoft Word do you really use? Here’s a list of some of the features of Word:

• If your office has a copy of Microsoft Office Server Extensions, you can be notified via e-mail of changes made to a document stored on the server.

• You can create a master document, which contains references to other documents. The master document is like a book, and the other documents are like individual chapters of the book stored in separate documents.

• You can create a form inside a document, populate the form with standard Windows controls, and then send the data over to Excel for analysis. (Try right-clicking on any toolbar, and in the drop-down menu choosing Forms to bring up the Forms toolbar. Then try playing with it.)

In addition, you can use some “fun” features such as these:

• Add a theme to a document that includes a custom background and custom font colors and sizes (just like in a web page).

• Use custom images for your bullets.

And then here are some really useful features that not everybody knows about:

• You can use AutoCorrect to simplify your typing. For example, if I had to type the word Visual Studio .NET over and over, I could choose Tools Auto Correct, and choose to replace vsn with Visual Studio .NET. Then every time I typed vsn, Word would automatically replace my text with Visual Studio .NET.

• If you have a word that you often spell wrong, you can right-click on the misspelled word, choose AutoCorrect in the pop-up menu, and then click the word that you want your common typo to be automatically replaced with in the future.

Okay, these are all features that most people probably don’t use. And so why are they there? Well, some of them are, in fact, quite handy. But some of these aren’t exactly the most useable; some of them are cumbersome to use.

This should be a wakeup call to us all as software developers. The technology is advancing forward, and we’re sweeping ahead with it, but we’re letting our usability lag. How can we do that? By realizing that we have only so many people-hours we can actually spend working on the software, and then figuring out what we have time for and what we don’t have time for. That means opting for usability over feature bloat. And that’s a topic I take up in the next section.

Choose Ease and Usability, Not a Gazillion Features

The purpose of this chapter is to talk about the business issues surrounding usability. I’ve spent a good bit of time talking about features throughout this book; now I’d like to focus on the issue of features from a business perspective.

When you develop software, you have a choice as to how to spend your time: by adding more and more features or by making sure the features you do have are absolutely correct in terms of usability. As you can guess, I’m going to say that you should focus on the usability issues, not on adding more and more features.

But is this practical from a business standpoint? While some users might get all excited over software that does everything from creating beautiful graphics to changing the oil filter in their car, most people don’t want this kind of software. The reason is that software filled with features will, most likely, be filled with far more drop-down menus and toolbar buttons than the average user can comprehend. But from a business perspective, intimidation factors aside, the more features you have in your software, the more complex your software will be (or, at least, will seem). And with that comes more time spent finagling with the software. The users may have to spend time first just getting to the feature. And once they’re at the magical dialog box that controls the feature, they may be confused and have to spend time figuring out how to use the feature.

The people who purchase software in large corporations know this. One of the first questions they ask of a software salesperson is about training: How much training is required? How much is the training going to cost? In other words, they’re concerned about how difficult the software is to use.

Imagine these two scenarios:

• Your software package has 100 major features, and of those the majority are difficult to use.

• Your software package has eight major features, and each one is solid and easy to use and requires little training.

Look again at the first item. Not only is each feature difficult to use, but when you figure people are going to have to be trained on each of those 100 features, you can see that training will take a very long time. And more time spent in training is more time spent away from doing one’s job.

But think about the second item: Let’s say your salespeople waltzed into a client’s office, set the client down at the laptop running the software, and in five minutes the client was up and running and using the software. That would be a pretty easy sell, wouldn’t it?

The fact is, you have limited time to spend on your product. If you have a million years, yes, you could make an incredible product filled with every feature. But you don’t. Therefore, you have to choose your tasks during those limited hours wisely. And one wise decision is to focus on making sure the few major features that you have are of top-notch quality. They’re easy to use, they get the job done, and they’re very clear in how they work.

REAL WORLD SCENARIO: Windows on Your Appliance? Time to Reboot the Fridge!

Some time back, Microsoft created an appliance version of Windows. As you can imagine, this opened up Microsoft for loads of jokes. After all, what happens if the refrigerator crashes? I guess you’ll have to reboot it. And while it’s in a crashed state, does your food spoil? Yeah, yeah, I’m sure Microsoft has heard them all.

But this is an example, perhaps, of technology gone just a bit too far. Do we really need Windows on our appliances? (Okay, so the refrigerator is a bit of an exaggeration, but they do have a form of Windows CE in car stereos.) How much technology do we really need, and how much is too much?

When you use a DVD player, you are interacting with some seriously sophisticated technology, which includes plenty of onboard software. Furthermore, these days all microwave ovens have computer chips inside them, and when you type on the keypad, you are interacting with the software. But does a microwave oven need software as feature-rich as what you find in a DVD player? I don’t see any reason why it should.

Think about the features in your software, and ask yourself if the users are really going to use them. After all, nobody wants to have to reboot the refrigerator after the system software crashes, when the old twentieth-century refrigerators that were software-less worked just fine!

Being Aware of Industry Standards

As much as we developers may hate standards, they are a fact of life. Standards are not going away. And we can do ourselves a major service by adopting the standards.

From both a usability and business perspective, adopting standards is a wise choice. For example, I worked for a bit in the e-book business. A few years ago this was supposed to take the world by storm. It didn’t. It was another early adopter technology that never went past the early adopters.

Yet, one form of e-book lives on: PDF files. Yes, most people have a love/hate relationship with PDF files. But like them or not, PDF files are here to stay. And the reason they survived the e-book fallout is twofold:

• The PDF format existed before the e-book craze.

• The PDF format is a standard.

Not very often is a private company able to create a proprietary format, open the format up for all to adopt, and successfully declare the format a standard. Yet, that’s exactly what Adobe managed to do with PDF. Part of the reason for their enormous success in PDF is that they give away a read-only version of their Acrobat product for free. With Acrobat Reader, you can open PDF files right inside your web browser. People have, in turn, put PDF files on websites left and right. PDF is a fact of life and it’s here to stay.

But what happened to the rest of the people in the e-book business? Many of the companies decided to go with their own proprietary format. Instead of using a standard format, they created their own. And that meant e-books created for their format could be viewed only with their readers. And so if you, as an e-book user, were to look at a catalog of e-books, you would have to first see if you have the viewer for the particular e-book. And that could mean having five or six separate viewers. Or if you looked at the catalog for a particular viewer, you would be missing out on all the e-books for the other viewers.

People saw right through this, and the whole thing was a flop. Almost none of the companies that were proudly displaying their products at the e-book conventions back in 1999 are in existence anymore. Nearly all of them folded.

The moral here is this: If you have a product that reads or displays documents, at least support the various standards. Occasionally I’ll see shareware graphics programs that maintain their own proprietary format and don’t support the standard formats such as JPG and PNG. What good is such a program? Imagine how many people will turn away from the software package simply because of the lack of standards. From a business perspective, ignoring standards can be a very bad idea.

This doesn’t mean you have to make one of the standards your native format. A lot of the better graphics programs have their own format, for example, and then you can import from and export to the standard formats.

When a Standard Isn’t Always the Best Standard

Back in 1999 when I spent a little bit of time in the e-book business, many of us were well aware of the Great PDF Monster lurking on the horizon. We knew that PDF was frankly not the best solution for reading a book online, whereas a format such as HTML was far better. The reason is that PDF is a fixed-page layout, whereas with HTML a browser reflows the text to fit the screen. You can see where PDF has a problem when you have text arranged in columns on a single page, such as in a typical book index. If you’ve ever looked at an index page in Acrobat Viewer, you know what I’m talking about: The text in both columns might scroll down past the bottom of the screen. If you’re scanning the left column, you will scroll down to the bottom, and then when you get to the bottom, you’ll have to scroll back up to the top to get to the column on the right side.

Furthermore, if you have a page that’s printed with an extremely tiny font, and you zoom in to make the font big enough to read, the margins of the page may now extend off the sides of your screen. You must then scroll horizontally. And if you’ve ever tried to read a document that’s too wide for the screen and requires horizontal scrolling, you know what a nightmare it is.

Yet, those of us in the e-book business were well aware that PDF was a standard and was not going away. Further, we knew that it would behoove us to adopt PDF into our e-book software programs. But alas, many companies chose not to, and they paid the price—they vanished.

Today PDF lives on and it is definitely one of the most popular online formats, and certainly one of the most successful, even though it’s far from perfect. Yet, you could say that about almost any product that has been successful. People who used OS/2 extensively knew that OS/2 was far superior in many ways to its competitor at the time, Windows 95. But it didn’t matter; Windows 95 quickly took off as the operating system of choice, and OS/2 withered away. And programmers who embraced OS/2 as the platform for their software were quickly disappointed in their lack of sales.

Therefore, remember: Embrace the standards and the leading technologies, even if you know they’re not perfect. Your job, after all, is to sell products, right?

Even the well-known software applications that have a proprietary format often support importing from and exporting to competitors’ formats. For example, the copy of Microsoft Word I’m using right now can read and write WordPerfect 5.0 files.

Ways You Can Defend Your Business against Problems

I’m going to assume that only software developers will be reading this book. As much as I’d like to see people from other areas reading this book, most of you are software developers. Therefore, I’m going to focus on what you can do within your software development organization to help defend against problems.

The problems you might encounter can fall into these two main categories:

• Your organization might purchase software for the employees, and this software might have usability problems.

• Your organization might be creating software that has usability problems.

If your organization is purchasing software, here’s the single biggest thing you can do to help in the cause to make software better:

RULE

Demand only the best.

No longer should you settle for pretty good or fair. Surely you have software that you use on a daily basis that you have gripes about, right? If you’ve read the previous 11 chapters you can see that I sure have plenty of gripes. It’s time to take a stand and demand better software now.

If you’re analyzing software for a potential purpose and you find problems, let the developers know. In fact, if these problems have convinced you to not purchase the software, let them know as well! If you’ve already purchased the software, tell them you’re thinking about ditching their product and going with the competition, and make a list of things that you don’t like about their software. Don’t worry about being kind. Give it all you’ve got, and let them know exactly how you feel. They need to hear it!

I can’t tell you how many companies I’ve worked for where two or three major software applications were in use, and my coworkers all griped endlessly about the software. And yet the companies continued to use the software packages. But in hindsight, did any of us bother to contact the people who made the software and let them know that we were upset? No. So did the company even know about these problems? Maybe. But even if they did, if they’ve received very few complaints, then maybe they pushed them off to a severity-4 bug, meaning the problem will never get fixed!

But don’t complain only about bugs. Complain about general usability issues as well. Does the software package contain cascading dialog boxes that are cumbersome to use? Let them know about it. Are there features that would be better suited on the toolbar, but you can’t customize the toolbar? Complain! Be vocal about it. They need to know if you know of a way for them to improve their software package. (And if you’re feeling particularly mischievous, you might send them an e-mail with your gripes and CC their competition. That might be a good wakeup call for them!)

But now walk over to the other side of the fence. Suppose you are the software developer. Then this should be your motto:

RULE

Build only the best.

How do you know what’s best? By following all the guidelines I’ve put forward in this book and by following the guidelines in all the other great books on usability. Resources are everywhere; study them. But don’t put usability at a low priority, as if it’s just one more issue you need to look into. Usability should be the top priority. You want your software to be the best, even if it has fewer features than the competition. After all, what good are those extra features in the competitor’s software if they’re impossible to use?

Here are ways you can guard your business and ensure that you will release only the finest, highest-quality software:

• Include full usability studies when you are designing the software.

• Get feedback from your testers on usability.

• Focus on usability during beta testing; don’t just look for bugs.

• Listen to customer complaints and gripes and take them seriously.

• Be open-minded and ask yourself how you can improve the usability of your software.

The final item should take place throughout the development process, not just when you’re thinking about the next version. Be open-minded, and don’t be afraid to be self-critical. When you and the others on your team are designing the software, put yourself in the shoes of the end users. Pretend you are not very computer literate. Allow yourself to be your own worst user nightmare.

Only when you can be open-minded and truly see your software the way that your users do can you improve it. And finally, remember this:

RULE

Respect your users. You need them more than they need you!