This book brings together a collection of chapters by different
proponents of design. Many chapters are illustrated by non-software
examples of good design, presumably because there are so few good software
examples to cite! After each chapter Winograd has added a short Profile
(printed for some peculiar reason on rather dark grey paper), attempting
to relate the general lessons from the chapter to the specifics of
software design.
Design here is nothing about algorithm design, or code structuring. It
is hardly even about User Interface design -- that unrealised magic bullet
of the 1980s -- except in that the UI is the part of the system the users
notice and interact with. 1990s software design is about software that is
so 'transparent' the users will hardly even notice it as they go about
whatever tasks they are performing. Design is noticed only when something
breaks down, when the users can't do what they want to do, when their
conceptual models clash badly with reality.
In some ways, I found this a curiously frustrating book. Each chapter
felt like the introduction to a book on design, priming me up for the
revelations to come in the body of the book -- but then I was in to the
next chapter. (There are reading lists, of course, and I may even get
around to following some of them up one day.) Also, I would have liked a
few more concrete examples of good (and bad!) design, to illustrate the
points being made (especially in the chapter on how important concrete
examples are, which didn't follow its own advice particularly well).
However, it is certainly interesting preliminary reading in the subject.
And I found it worth it just for introducing me to the phrase "threshold
of indignation".
Contents
- • Mitchell Kapor. A Software Design Manifesto. 1996
- A reprint of Kapor's 1991 plea that software design is a crucial skill that needs to be recognised as important, and taught
- • David Liddle. Design of the Conceptual Model. 1996
- The user will have a conceptual model of how the software works: the design must be driven by support for a good, clear model
- • Gillian Crampton Smith, Philip Tabor. The Role of the Artist-Designer. 1996
- Content and form cannot be separated: a layer of 'design' cannot be bolted on as an afterthought
- • John Rheinfrank, Shelley Evenson. Design Languages. 1996
- If you have a design language, a set of organising principles, across a range of products, it helps your customers move between these products
- • Paul Saffo. The Consumer Spectrum. 1996
- There is a spectrum in the "threshold of indignation" -- how much hassle the consumer will put up with to use the software. Where consumers and companies are in this spectrum, and how they move around it, needs to be understood.
- • Peter J. Denning, Pamela Dargen. Action-Centered Design. 1996
- Design the software to support the (high level) actions the users
will perform. Ideas from Alexander's
architectural Pattern Languages can be adapted to software design.
- • John Seely Brown, Paul Duguid. Keeping it Simple. 1996
- Use well-known information in the environment, or context, to help keep the content simple
- • David Kelley, Bradley Hartfield. The Designer's Stance. 1996
- Ways to learn to be creative
- • Donald A. Schon, John L. Bennett. Reflective Conversation with Materials. 1996
- Too much specification, and not enough hands-on experience with the consequences, can lead to inappropriate designs
- • Michael Schrage. Cultures of Prototyping. 1996
- A flexible approach to prototyping, and letting the prototypes influence the specification, is important
- • Shahaf Gal. Footholds for Design. 1996
- Designing a (student project) bridge, with the help of the Growltiger package
- • Donald A. Norman. Design as Practiced. 1996
- The design of the power switch on the Macintosh, and why it was so difficult
- • Laura de Young. Organizational Support for Software Design. 1996
- Good design can occur only if the organisation supports the process. (For example, Intuit's customer-focussed approach to designing Quicken.)
- • Sarah Kuhn. Design for People at Work. 1996
- Software should be designed to support real working practices,
which includes all the informal, tacit, implicit communications, as well as the formal tasks.
One problem is that the people who buy the software for the workplace are rarely the people who have to use it.
