Dont Send Users on a Voyage of Discovery

Peter Coffee: Developers should strive for discoverability in user interfaces and elsewhere.

One of the best words in the modern technical lexicon is "discoverable." If were designing software, the word describes features and behaviors that a user can recognize and use without instructions. If were designing networks, the same word applies to resources that announce their presence to anything else that needs them. And if were discussing litigation, "discoverable" documents are those that were required to produce and share with the opposing side in the dispute.

OK, maybe not all discoverable things have positive associations.

But each of these examples is revealing: We might think were "designing for discoverability," which weve been told is a good thing, when were actually achieving the wrong kind of success.

The legal usage, with its aura of reluctant and arms-length compliance (or, alternatively, deliberately overwhelming detail), reminds me of all too many IT designs. If you suspect that something exists, and you know what its called, you can look it up in the manual. Otherwise, its unlikely that youll even think about it, let alone find it.

Like many Windows applications, or for that matter the entire Windows environment, Microsoft Word offers many examples of useful but below-the-radar shortcuts. Double-click to select a word, left-margin click to select a line, triple-click to select a paragraph, Control-click to select a sentence, Alt-click-drag to select a rectangular block of text. (How many of the last three did you know?)

Bluetooth radio devices embody the network model of "discoverable." A Bluetooth device in a nondiscoverable mode ignores all requests for connection; in limited discoverable mode, it responds to only specific Inquiry Access Code requests; in the general discoverable mode, it responds to anything else thats looking around for potentially useful services.

We can think about being equally discriminating, as a matter of deliberate design, in the way that we announce the existence of features and services to the users of an application or a Web site. If a Web site resource is visible to all, but is only accessible to a certain class of user, were more likely to see attacks against that sites access-control facilities. Best to establish access first, then disclose the corresponding capabilities.

On the local desktop, we can use registry settings to limit visibility and control of a Windows workstations hardware and applications. People dont try to break into what they dont even see.

Finally, theres the best kind of "discoverable": the stuff thats right there in a visual or physical user interface, almost begging us to wonder what it does—and to find out by simple, risk-free experimentation.

Im not talking about the discoverability of ejecting a removable disk from a Macintosh, where you drag the desktop icon for the disk into the trash can. If you ask me, that looks way too much like a command to erase the disk, and I still cant do this (even after 17 years of Mac ownership) without a momentary twinge of discomfort. What if this time, it does the wrong thing? Wouldnt I feel stupid then?

Discoverability in the user interface is a subject with quite a bit of history: The design of online help for the Macintosh, for example, reflects considerable thought and experience with what users will and will not notice—and, for that matter, what users do and do not need.

As you look through the literature of user interface design, though, you may notice that its much easier to identify what doesnt work than to imagine what would be better. The former is just a matter of paying attention. The latter requires actual artistry.

If few of us are artists, perhaps we can at least avoid repeating past mistakes—in the hope that art may have a better chance to emerge.

E-mail eWEEK Technology Editor Peter Coffee