Nardi, Bonnie A. A small matter of programming: Perpectives on end user computing. MIT Press, 1993.

Reviewed by: Frank Wales

This book discusses end-user programming as it has so far turned out, criticizing many proposed methods, and attempting to draw out those common threads within the few apparent success stories in order to help deliver programming power to ordinary users of computers. The results of interiews with spreadsheet and CAD svstem users are discussed, as are the uses of visual formal- isms, and how collaborative work practices can be enhanced by the right kinds of applicatlon archltecture.

Having met Bonnie Nardi at a workshop on Psychology ot Programming where she presented some of her work on the ACE project at HP Labs, I was interested to read her views on what types of end-user programming seem to work, and why there seem to be so few examples of actual programming being done by non-computer protesslonals as a part of their work. As a professional programmer. I have my own views on this and this work helped me to refine them with some carefullv considered discussions of existing and proposed techniques.

It is taken as an axiom of the book that end-users ought to have programming power at all; this may be a diffficult hurdle for so-called real-world acceptance of some of the important ideas put across by Nardi. since there are many managers who have difficulty accepting that their non-manaerial staff can be trusted with any decisions at all, let alone technical ones. For those of us for whom this is not an immediate point of divergence Nardi's book is a careful studv of end-users' needs and motivations that should be considered by all development staff whose works end up in use by ordinary computer users.

Perhaps its most valuable contribution for me is analysing the context of computer use, and making a cogent argument for structuring software such that it supports distinct classes of users, named by Nardi as workers, tinkers and programmers. For each group tools are needed, and different levels of motivation applv to the group using those tools. For example, workers, who form the bulk of users, and who are the traditional end-users ''need to be able . . . to solve simple problems within their domain of interest within a few hours of use'', otherwise their motivation to continue with the system is seriouslv diminished (here. I disagree with Nardi; I'd claim this should take an hour at most, but this is a small point of discussion in a large area of agreement).

Over the vears, many systems have claimed to have a natural-language. or English-like, syntax to allow use bv non- programmers (this has included COBOL and SQL, now undoubtedly considered as non- end-user programming languages) pred- cated on the assumption that mere end-users cannot handle structured or formal lan- guages. Chapter 2 highlights the deficiencies with the conversational programming model and makes the case that humans don't necessarily always use the mundane conver- ational mode when communicating (giving court behaviour as an example of a formal conversational process that the participants must learn to abide by), and suggests that people don't have difficultv with computer languages as formal conversational tools per se, but with specific ones (such as C, LISP, etc.). Nardi makes a strong case that formal, but task-specific. Ianguages are perfectly acceptable to end-users, and, in Chapter 3, provides further detailed examples of widely used formal languages. such as baseball scorecards and knitting patterns.

Nardi spends some time using the spread- sheet formula language as an exemplar for other task-specific programming languages, almost labouring the point that spreadsheet languages provide pre-built task-specific operations, rather than requiring the user to build them themselves from more basic general-purpose language features. She also implies that the clean break between the formula language, used by workers, and the macro language, used by tinkerers, helps delineate the boundaries of where it's appropriate for a worker to ask for a tinkerer's assistance.

Nardi mentions the importance of different levels of support for different user groups (talking about layered/modular functionality, with easy-to- learn domain-specific features for fast prod- uctivity for end-users, and more domain- abstract languages for more advanced prog- ramming). but I'd like to have seen more on the necessary relations between these different languages. Nardi also comments that what makes layered systems so effective for development is not that end-users finally "come up to speed'' and learn the advanced features, but that they collaborate with sophisticated users right from the start. All of this is consistent with my experience, and confirms my belief that tinkerers and site experts will always be needed to get full value from computer systems, although the end-users must do most of the work.

Interestingly, and probably controversially, Nardi argues in favour of textual over graphic lanuages. claiming that thev are . . . compact, efficient, and can be developed in less time than graphical languages." This third claim is especially interesting to me (I happen to believe this too), but no references are given for these particular claims, which will no doubt make snipes at these opinions easier.

Nardi also claims that svntax is not the problem it would seem to be in textual languages, because users come to depend on the system to perform proper syntax checking on their behalf, something I know professional programmers do all the time. Of course, this requires languages that admit ot such a thing, and this requires deliberate design to achieve well.

Nardi spends some time cogentlv criticiz- ing much modern research; for example (sic), Programming by Example seems to be a fine product of the Hiding-to-Nothing Company with a list of problems such as: how to specify conditionals and terminating condi- tlons on the iterations they infer; users feeling uneasy about the spontaneous taking of control by the program; not being able to accommodate human behaviour well (errors, experimenting, fidgeting); no error- correction mechanism; the high cost of interface mechanisms.

A significant comment on the user of the computer as a tool for exploring problem domains appears on page 83, where Nardi notes that ". . . discovery of requirements through tentative development takes place for experienced users of spreadsheets." Nardi argues in favour of the iterative struggle to discover needs along with the development of the program, but wishes we could make it . . . as short. attractive and productive as possible.'' She claims spread- sheets have succeeded in showing this line of argument to be productive. I wish students of the software development process would take the hint that all programmers seem to do this.

Other important points mentioned include the discussion about use of spreadsheet visual behaviour for navigation and feedback on actions (instant gratification). Nardi makes an interesting comment on the end-users' dislike of creating names for things; in spreadsheet cells and ranges. rows and columns all have names already; this is consistent with comments I have heard from programmable calculator users, complaining about the switch away from numbered registers to named objects, and how the need for inventing names for working storage detracts from the process of thinking about the calculations being done.

Nardi emphasizes the importance of hav ing a community of co-operating users. It may seem that this only works for medium- and large-sized organizations, but com- munities of users are becoming more common, not less, with the growth of user groups and Internet activity, so future development should be designed with com- munities in mind. Nardi makes the point that we should capitalize on the strengths of users (their domain-specific skills), rather than try to compensate for their weaknesses (their lack of programming knowledge), and we should eschew terms such as novice and casual with respect to end-users since these are preju- dicial in assigning prominence to the computer. where it most certainly does not belong.

The book concludes with an elaborate example-building a patient diagnosis svstem using the tools Nardi worked on at HP Labs. Nardi encourages an approach that mixes user-mterface design with application development.

One criticism I have heard of this book from others who have read it is the large amount of opinion wrung from narrowly- focused data (interviews with spreadsheet and CAD system users). I suspect that, were there a large set of diverse data to choose from, the book wouldn't have been half as necessary as it is, since the successes of end-user programming are made so obvious by their rarity. In addition, the points made by Nardi regarding the diffficulties with existmg approaches to end-user program- ming, and the ways in which communities of users spring up, gibe with my experiences.

Perhaps. Iike In Search of Excellence, this work will spawn further works by Nardi and others, that provide more concrete, blow-bv- blow advice and information for actual programmers on building systems acceptable to end users. God knows, they're sorely needed.

Reference

PETERS, T. 1982. In Search of Excellence. New York: Harper Collins.

back to ... Bonnie Nardi, A Small Matter...