Avoiding Hoop-Jumping

Every time the user needs to click something or type something to reach a final goal, that user is, quite likely, performing one extra, unnecessary step. Usability guru Alan Cooper calls all these extra mouse clicks and key presses excise tasks. The term excise is a good one because it’s normally used in reference to taxes. Anything you make your user do that’s unnecessary is taxing the user in many ways, including the user’s patience. If you read Chapter 4, you saw a story

REAL WORLD SCENARIO: The Case of the Misshapen Ice Cubes

This one will never cease to amaze me. A lot of refrigerators come with a built-in icemaker inside the freezer. The icemaker makes ice cubes and dumps them into a plastic bin; you’ve certainly seen this kind of contraption. It’s a great idea; you never need to fill ice trays with water.

But what I just don’t understand is why the ice “cubes” are actually a half-moon shape! Invariably, when I put ice in a glass, one of the ice moons will go right up to the top of the glass when I tip the glass, right where my mouth touches the glass. And the ice moon will rest perfectly along the edge of the glass, with its curved side along the curve of the glass, resulting in a perfectly neat little dam, blocking the water from flowing into my mouth.

Now come on. How many refrigerators will it take before they realize that this is a problem? (Or maybe I’m crazy and nobody else has this problem?) But the real issue is this: As a user of this product, I have to wonder whether there isn’t a better way to shape the ice cubes. Is it simply not possible to shape them any other way? I seriously doubt that it’s impossible to create them in a different shape. Now think how many times users are told, “It’s just the way the computer has to do it and there’s no other way.” Nonsense. There’s always a better way. Don’t release software with bugs, and if people find bugs, fix them and make it better.

about cell phones and how you need to press a million keys just to enter an exclamation point when typing a text message. That’s definitely excise.

I like the term hoop-jumping because for me that’s more what’s happening. I think of when I grew up in Michigan and in the middle of winter in college what it was like having to go out to the mailboxes to check the mail. I couldn’t just run out; I had to put on my heavy boots and my heavy coat and get all “bundled up” (as we Northerners would say), just to go check the mail.

How do you recognize hoop-jumping? By remembering that your software is nothing but a tool. For years, I’ve been preaching this point to my students and clients: A software package is a tool like the telephone. When you are sitting at your desk talking on the phone, you don’t want to have to be aware of the phone. Your goal at the time is to have a conversation, and, most likely, you’re thinking about the person you’re talking to and the topic of discussion. The moment something goes wrong (static on the line, strange noises, the phone falling on the floor, the cord falling out of the wall, and so on) is the moment that you are suddenly aware of the tool.

Software should be the same way. Right now as I’m typing this sentence, my brain is thinking about software usability. If I also had to think about where the mouse pointer is and if I also had to constantly click a bunch of menus and buttons, then my brain would not be able to focus on the task at hand, which is writing about usability. And that would be the moment the software becomes less of a tool and more of an annoyance.

In order to minimize (and all-out eradicate!) hoop-jumping, the first thing you want to do is recognize the three levels of users:

• Beginners and “newbies”

• Intermediates

• Power users

Also, I would probably consider a fourth level, programmers, if you’re developing a product for other programmers. However, if you’re developing a package for programmers (such as an IDE), you’re still going to have the three levels of users in this list:

• Beginner programmers who are fumbling their way through your product

• Some people comfortable with the product

• Power users who are developing macros, add-ins, and other tools for your product to get the most out of it

Now this might come as a surprise to you, but most usability experts have figured something out: Menus are for beginners and also for intermediates and power users when they use a feature they haven’t used before. Part of the reason for this is that menus provide a nice textual list that the users can easily read and scan with their eyes. While that’s not true in all cases (I still use the File Exit menu and the File Print menu), it is true in many cases. In general, here is what people use:

• Beginners use menus.

• Intermediates use toolbar buttons.

• Power users use shortcut keys and macros.

I will personally attest to the shortcut keys and macros. I did one project whereby I had to put a strikethrough through certain words in the document. But I wasn’t just doing it for individual words; there were other cases as well. And so I wrote a macro and assigned a hotkey to the macro. Then when necessary I would press Ctrl+Shift+S and the strikethrough would automatically appear where necessary.

In Chapter 1, “The UUI: The Useable User Interface,” I raved about a command approach to programming. This approach lends itself perfectly to removing hoop-jumping. I can only imagine how much more time my project would have taken if I had to reach over, grab the mouse, highlight the text to be “struck through,” then click Format Font, then click the Strikethrough check box, and then click OK…over and over and over. Those are definite hoop-jumpings. Without going into a bunch of heavy theory, then, here’s what I recommend you do:

• Implement a command-based system, as I’ve talked about many times. Make everything a command: the printing feature, the page setup feature, the options dialog, everything.

• Include menu and toolbar access to all of the commands.

• Make the menus and toolbars configurable (Microsoft Office is a good demonstration of this).

• Include configurable shortcut keys.

Then, for example, a user can configure Ctrl+P to open the Print dialog box. After that, said user doesn’t even have to worry about the File Print menu item. He can just press Ctrl+P to print. (And, for most users, pressing Ctrl+P is faster than reaching over, grabbing the mouse, and choosing File Print.)

In addition, you might want to consider some kind of macro system where your users can write their own macro programs. One interesting (albeit rather advanced) way to do this in Microsoft Windows is by exposing your software commands as functions in a set of COM objects. Provide a root COM object whereby a COM client can access your program. Then, believe it or not, people can automate tasks using the Windows Scripting Host (WSH). I’ve done this, and it provides almost instant macro capabilities to your program, and further, the users can use whatever language they want that’s compatible with the WSH engine. (By default VBScript and JavaScript are available; you can also obtain Python, Perl, PHP, and a whole bunch of other languages.)

Note

I should probably point out, however, that in all truth, such a macro system isn’t a requirement and is more an extra perk for the really advanced people. Usability studies and book sales have shown that very few people actually write macros, and those who do are usually themselves programmers. So consider a macro system only if your schedule has time. Instead, focus on other aspects.

The only additional step is that you’ll need to implement your own shortcut keys. But that’s not hard either; the shortcut keys can simply launch the WSH engine. How do you do that? If the file association mechanism is set up properly and a VBScript file with a .vbs filename extension runs the WSH engine (specifically, the wscript.exe program), then all you have to do is use the ShellExecute Windows API function to “run” the .vbs file. (That’s one cool thing about ShellExecute—you can “run” a document file, and the system will locate the correct executable. For example, if you “run” a .doc file, ShellExecute will cause Microsoft Word to launch, opening the .doc file.)

Now if you have lots of money, instead of writing your own macro system you can license the VBA (Visual Basic for Applications) system from Microsoft. This would be for a pretty big project, but in the end you’d have a seriously powerful application. I haven’t personally done this, but as I understand it you would still have to expose your product as a COM server. (An interesting side note is that you can actually use the WSH engine and your favorite scripting engine to write your own macros that automate Microsoft Word, for example, and bypass VBA if you don’t like Visual Basic for whatever reason. That’s because Microsoft Word is a COM server.)

However you want to do it, I do at least encourage you to explore the possibility of a macro programming language for automating your product. It will be one more touch of professionalism and will give your power users much more power (and make them happier users who will pay you money, which is the real goal here!).