Dont Send Users on a Voyage of Discovery

 
 
By Peter Coffee  |  Posted 2002-04-15 Email Print this article Print
 
 
 
 
 
 
 

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
 
 
 
 
Peter Coffee is Director of Platform Research at salesforce.com, where he serves as a liaison with the developer community to define the opportunity and clarify developers' technical requirements on the company's evolving Apex Platform. Peter previously spent 18 years with eWEEK (formerly PC Week), the national news magazine of enterprise technology practice, where he reviewed software development tools and methods and wrote regular columns on emerging technologies and professional community issues.Before he began writing full-time in 1989, Peter spent eleven years in technical and management positions at Exxon and The Aerospace Corporation, including management of the latter company's first desktop computing planning team and applied research in applications of artificial intelligence techniques. He holds an engineering degree from MIT and an MBA from Pepperdine University, he has held teaching appointments in computer science, business analytics and information systems management at Pepperdine, UCLA, and Chapman College.
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...
 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Thanks for your registration, follow us on our social networks to keep up-to-date
Rocket Fuel