Type A Learning Agency

Usability or confusability?
How ease-of-use can backfire if you don't think about long-term needs
by Arlo Leach

Introduction
I don't think anyone would argue with this statement: "The more you know about your computer, the better able you'll be to make it work for you." But many software developers these days seem to be operating under an opposing principle: "The less we tell you about your computer, the easier it will be to use." New "features" should empower the user in the short and long term, but often create limitations by obscuring the actual workings of the computer. In this article, we'll look at a few examples of this approach, and suggest alternative approaches that address usability in much broader terms.

Where am I?
When the World Wide Web started to take off, computer makers jumped on board with the goal of easing the transition to network computing for their users. A key part of Microsoft's strategy at that point was to make your local hard drive act just like a website, and it pursued this goal by adding a Back button and location bar to windows, allowing folders to open with a single- rather than the traditional double-click, and generally integrating Internet Explorer into the Windows operating system.

That last move wasn't just a bad idea from the Department of Justice's point of view — it also leads to real confusion among users about the boundaries of various computing environments. I've helped aspiring web designers, using FrontPage on Windows, who literally couldn't tell me whether their files resided on their hard drives, their server, both, or neither. That kind of confusion raises the risk of deleting files or overwriting them with older versions, and, when pointed out, greatly undermines a user's confidence in learning new skills.

Software designers should certainly create similarities between different operating environments to ease users' transitions from one to another, just like city planners should locate bus terminals near airports to allow travelers to easily make connections. But making the insides of buses look just like the insides of airplanes wouldn't ease the traveling experience, and would probably make it more dangerous. In order for computer users, like travelers, to behave appropriately in each environment, they need to know exactly where they are at all times.

Problem? What problem?
DOS and other early operating systems relied on still-familiar file extensions to indicate the format of each file. By the time Windows 95 came along, Microsoft's engineers started to realize how clunky the extensions looked to their users, so they solved the problem in a characteristic way: they added the ability to hide file extensions across the entire computer. The extensions were still there, just hidden, so users didn't have to pay attention to them.

That's a little like auto manufacturers building a soundproof engine compartment, removing all gauges from the dashboard, and telling customers that their cars no longer need engines. Everything will be smooth and worry-free for drivers for a while, but they'll be totally unprepared when that hidden engine finally breaks down.

Of course, the ideal solution to maintenance problems is a car that truly doesn't need an engine, or a file system that doesn't need file extensions, like Apple's "classic" Mac OS. But as long as the extensions are necessary, users deserve the opportunity to see them, learn how they work, and gain some experience that will come in handy when they encounter a file with a missing or incorrect extension. At the very least, that situation provides users a specific question to ask — "What extension does this file need?" — which is a much more helpful than the generic, "Why doesn't this file work?"

Now where did I leave that icon?
Windows 2000 introduced a new wrinkle to the Start menu: only recently used items appear in the often cluttered, hierarchical menu; users don't see the full menu until they click a triangle icon at the end of the list. This was an attempt by Microsoft to make its operating system do some thinking of its own and try to get a step ahead of you in predicting your needs. Microsoft Office applications exhibit a similar behavior with pulldown menus, and Windows XP can even do it with your desktop icons.

Now, think back to grade school, when you were learning arithmetic. It might have taken you a while to remember that 6 x 7 equaled 42, but imagine how much more difficult that would have been if 6 x 7 had sometimes equaled 41, sometimes 43, and sometimes 0. Consistency is crucial for learning, and if users are to learn where items reside in menus, a minimum requirement is that those items stay in the same place. The attempt to eliminate unwanted choices for you is well-intentioned, but this feature actually contributes to an unstable, unlearnable environment.

A better solution for Start menu clutter would be to provide users with an easy way to manage its contents. In fact, this feature already exists, but it's hidden under an intimidating "Advanced" button located several clicks away from the desktop. Another solution would be to write software installers that give users more choice about the proliferation of shortcuts that get installed in the first place.

Everything I needed to know, I learned without wizards
A wizard is a step-by-step process initiated by a software application, designed to guide you through a potentially difficult task. But, despite their imposing (and subtly confidence-eroding) name, wizards are a primitive form of artificial intelligence that can only handle the tasks for which they've been programmed. Even worse, wizards are poor teachers — they keep their inner workings to themselves so you can't learn from the experience of using them.

Image scanning software provides a good example. Most scanners come with software that features a "simple" mode, with big buttons for scanning each of a few different types of documents (photo, line art, text, etc.). Users are never directly confronted with choices about resolution and color settings or file formats, which, granted, would be daunting for many people. But I've seen enough 300 dpi web graphics to know that even the least experienced designers need more control of their software.

A better solution would be a well-designed interface that provides all the necessary options while making their purpose clear. Developers who want to go the extra mile can also include some documentation that educates first-time users about the general concepts involved. After all, if users know what to do, and have the tools to do it, who needs a wizard?

But I don't want to be integrated!
Many software developers boast of "tight integration" among their products. This might mean, for example, that Microsoft Word can import Excel files, or that PowerPoint contains a button that opens a text field in Word, which seems like a good thing if you own the whole suite of products. But what if you have a favorite word processor that's not Word? Then you're usually out of luck, and may have a tougher time using your tools of choice than you did before this trend toward "integration."

This gets especially tricky when you're working on the Internet, where established but non-proprietary standards determine file formats and functional limitations across many computing platforms. Microsoft likes to add new features by going beyond the standards, often creating client/server combinations that can only work with each other in the process. Did you ever wonder why FrontPage lets you set up search routines and other advanced features not available in any other HTML editor? Or why Outlook can notify you when a message has been received, which other email software can't do? That's because FrontPage relies on special extensions that need to be added to non-Microsoft servers, and Outlook only works if you replace your non-Microsoft server entirely.

Besides the hassles and forced upgrades for server administrators, the danger for users lies in obscuring the line between standard and proprietary functionality. I've heard people, using a standards-compliant email program for the first time, say, "Oops, there's a mistake in that proposal I sent. But I can just retract the message, right?" Or, "I've built this really cool web site with FrontPage, now I'm ready to post it to my ISP (which is running a Unix server)." At that point, the ultimate usability problem arises: worse than a desired feature being difficult to find or use, we now have an expected feature that's not available at all.

I'm not opposed to functional enhancements, or even to proprietary file formats. But it's important to present unique features as such, rather than gloss over the differences and prop up non-standard functionality with back-end technology that may not be available to all users.

Conclusion
I haven't met a software developer yet who doesn't genuinely try to create intuitive products, but developers have to look beyond the first use and make sure their new "features" don't leave users in the lurch when the environment changes or something goes wrong. At Type A, we've invested a lot of effort in time-saving tools and intelligent architectures, but more importantly, we encourage our clients to take control and learn how their products really work. We can't provide all the answers in advance — we don't even know them yet ourselves — but we can prepare our clients to confidently and effectively put their software products to work for them.