Designing Highly Useable Software

Reviewed by Eddie VanArsdall

The beauty of English Language is that it changes and adopts itself to express ideas freely. It even adopts words from foreign languages to maintain its cutting edge in power of expression. Thus we have Indian words like “hawala”, “bandh”, “dhaba”, and “chamcha”, in English lexicon. And the latest in the series is “Badmash”.

Author: Jeff Cogswell      Paperback: 342 pages      Price: US$39.99      Size: 7.5 x 9 inches      Publisher: Sybex Inc.

If you think no author could possibly have a fresh perspective on usability, think again. Jeff Cogswell’s Designing Highly Useable Software examines usable software design from the inside out. An accomplished software engineer, Cogswell contends that many software disasters happen in parts of the program that users cannot see. Unlike many authors on usability, he devotes only three of his book’s fifteen chapters to user interface design, and even those chapters emphasize usability within the context of best programming practices.

Cogswell has extensive experience in programming Windows software; so many of his examples are drawn from Windows (although he does occasionally refer to conventions used on the UNIX and Macintosh platforms). Although he acknowledges that many Windows idioms are not especially intuitive (for example, “That stupid desktop metaphor,” pp. 11–13), he recommends that software designers generally stick with the “established idioms” unless their designs are improvements.

Part I, “Keeping It Simple,” comprises seven chapters covering usable interfaces, real world device modeling, system response time, report layouts, and Web interfaces. We are introduced to the author’s pet peeves, which include systems that (1) display confusing messages, (2) force users to reboot, (3) exit without saving user preferences, and (4) require overuse of the mouse without providing keyboard shortcuts. For each of these annoyances, Cogswell provides a solution giving users more control. 

The four chapters in Part II, “The Lonely Engineer,” are devoted to specific programming practices, with most code samples given in C++. Cogswell provides advice on handling startup issues, shutdown issues, and system errors, and on managing dynamic link libraries (DLLs) and object-oriented programming constructs. He discourages programmers from imposing arbitrary limits on software behavior, such as the number of files that can be opened, and promotes the use of dynamic memory allocation to handle the number of open files.

Directed to business owners and managers, Part III, “The Business of It All: It’s ‘Dollars and Sense,’” emphasizes that technology companies must conduct thorough usability testing and must listen to customer feedback; otherwise, they won’t survive. Chapter 14 emphasizes the importance of ensuring that software is easy to install, providing online help, and offering training options. Written for “bosses and managers” (p. 304), Chapter 15 identifies and describes six programmer personality types and how they can contribute to—or ruin—a project team. 

Fortunately, Cogswell’s lively sense of humor prevents Designing Highly Useable Software from becoming overly dry and technical. In his “Real World Scenario” sidebars, he discusses usability issues inherent in everyday things such as refrigerator doors and paper towel dispensers. And his admonishments to programmers can be stern but downright funny: “As for Abort, Retry, and Ignore, all I’m going to say is this: Don’t you dare” 

Technical communicators can benefit from reading this book, largely because the information on back-end software issues can help improve your communications with engineers. You’ll now have a realistic grasp of the workaday constraints experienced by these colleagues, the best practices that they should be observing, and the types of suggestions from you that might sound plausible to them. Having some background in programming and scripting is helpful but not essential for understanding Cogswell’s recommendations.

This article has been reprinted with permission from the July/August issue of Capital Letter, the newsletter of the Washington, DC chapter. This article may have undergone some changes in compliance with the editorial policy of Indus.

Eddie VanArsdall has worked in various technical communication disciplines since the late eighties. His experience includes technical writing and editing, instructional design for print and the Web, instructor-led training, and usability evaluation. He has designed information solutions for government agencies, law firms, the World Bank, and telecommunications and health insurance clients.