Interface design bibliography

Brooks, Jr., F., The Mythical Man-Month, Boston, Addison Wesley Longman, Inc., 1995

A collection of essays wherein the author challenges assumptions in software engineering based on his experience and observations. This edition contains reflections twenty years after the original was published, allowing the author to reflect on his original assertions.

Gilb, Tom and Gerald M. Weinberg, Humanized Input: Techniques For Reliable Keyed Input, Reprint ed., QED Information Sciences, Inc., 1984

Major sections of the book include how inputs are designed, default
messages, positional messages, and adaptive checking. The over-arching theme is to take operators in to account when designing systems in order to improve working conditions and productivity.

Ledgard, H., Singer, A., and Whiteside, J., Directions in Human Factors for Interactive Systems, Berlin, Springer-Verlog, 1981

Using a system designed by the authors as a case study, a process for growing software to work with people is critiqued. The authors discuss in detail design decisions, what worked, and perhaps most importantly, what didn’t and why.

Mehlmann, Marilyn, When People Use Computers: An Approach to Developing an Interface, Englewood Cliffs, Prentice-Hall, Inc., 1981

‘Things to think about when developing terminal-based applications,’ may have been a better title, although I’m probably showing my bias. The work does not go in to the detail of Humanized Input, but is more of an overview or quick reference for the developer.

Nelson, Ted, Computer Lib/Dream Machines, Revised ed., Redmond, Tempus Books of Microsoft Press, 1987

This two-book book covers the big topics in the field of computers: programming languages, major corporations, enthusiasts, uses, history, and (most importantly) the impact on the everyday person. Dream Machines focuses on interactive uses of computers, such as games, movies, interfaces and the like.

Schneiderman, B., Designing the User Interface: Strategies for Effective Human-Computer Interaction, Reading, Addison-Wesley Publishing Company, 1987

Extremely dense work, more a collection of essays than a cohesive book. Lots of research is referenced in exploring high-level concepts, good practices in designing software for people, and the constraints people encounter physically and mentally.

Norman, D., UI Breakthrough-Command Line Interfaces, http://www.jnd.org/dn.mss/ui_breakthroughcomma.html, 2007

Command line interfaces were viewed as too complicated for novice computer users, so the graphical user interface gained prominence. Search engine commands, the author argues, are really a return to CLIs that are more flexible than the GUI and even more flexible than their predecessors.

Norman, D., Design as Communication, http://www.jnd.org/dn.mss/design_as_comun.html, 2004

An argument for a shift in thinking about design: that it is really a communication between the designer and the person using the software, with the technology as the medium. In this sense, it becomes necessary to explain why things are, not just whether they can be used or not. This helps to build understanding through conceptual models.

Norman, D., Logic versus Usage: The Case for Activity-Centered Design, http://www.jnd.org/dn.mss/logic_versus_usage_t.html, 2006

The problem with using logic to define interactions is that people don’t act logically. It is better to design around the concept of activities and grouping objects based on their relation to each other in activity as well as providing some logical structure for things that fall outside of that model.

Norman, D., Simplicity Is Highly Overrated, http://www.jnd.org/dn.mss/simplicity_is_highly.html, 2007

An argument against creating things as we think they should be and designing for how they really are. Many examples of complex objects chosen over simplified ones based on decisions completely outside of work flows, ease of use, and the like.

Norman, D., Why doing user observations first is wrong, http://www.jnd.org/dn.mss/why_doing_user_obser.html, 2006

It is too late to do user observations once the project has started. The research should be done before deciding on projects to pursue so that viable endeavors can be decided on before they start. Once a project is rolling, the rest of the team is held up by the interface designers doing research.