‘A Small Matter of Programming: Perspectives on End User Computing’ was recommended to me (and everybody else on Twitter) by Felienne Hermans after Mathias Verraes threw this hypothesis into the Twitter void:
Hypothesis: “Any tool that lets a non-programmer build executable programs will eventually become sufficiently complicated that the user is effectively a programmer.” I wonder if anyone has named this (or perhaps even proven)?
For me the most interesting part was chapter 6, Collaborative Work Practices, where they investigate how everybody works together and discuss the different layers of knowledge that a group of people can have.
There are a couple of ways that studies have classified the people involved in the process, but this one spoke to me the most:
- Systems programmers: deep level of programming knowledge, no domain knowledge.
- Translators (intermediate position on the side of the systems programmers): intermediate level of domain knowledge, deep level of end user programming
- Local developers (intermediate position on the side of the end users): unspecified level of domain knowledge, deep level of end user programming
- End users: deep level of domain knowledge, light level of end user programming knowledge.
It would be easy to try to rank the importance of these categories, but the book made it clear that all are equally important to make end user programs a success:
though we should make tailoring mechanisms more accessible to everyone, it is also important to make tailoring a “community nity effort” that draws on the varied expertise of different kinds of users. (loc. 1275-1276)
My favorite quotes
a carefully chosen set of task-specific operations that allow programming gramming within a particular set of tasks. (loc. 36)
They lack the power of general programming languages, but they also lack the steep learning curve-hence hence they are much better suited to the needs of users who have little or no training in computer science, and often little interest in computers per se. (loc. 36)
end users will freely write their own applications when they have task-specific programming languages embedded ded in appropriate visual frameworks, and they will write applications in collaboration with other users. (loc. 53)
a broad base of potential end users with a tiny point of professional programmers. (loc. 113)
It is helpful to understand that a key difference between professional programmers grammers and end users is that programmers like computers because they get to program, and end users like computers because they get to get their work done. (loc. 122)
We can define programming gramming as a behavior in which sequences of procedural instructions (typically in textual format) are written in a language that is compiled or interpreted into the application. (loc. 130)
However, we would suggest that writing high level, declarative, textual program specifications ifications also constitutes programming, as does creating diagrammatic representations of system behavior. (loc. 132)
A pervasive assumption about human-computer communication is that ideally it should mimic human conversation. (loc. 199)
first thing we must attend to in any attempt to design a system of communication is to assess goals, (loc. 292)
For many conversational situations imperfect communication is acceptable; unambiguous, biguous, precise communication is not needed. (loc. 316)
Formal systems permit activity to unfold in such a way that tasks can be accomplished accurately and reliably. (loc. 367)
Knitting patterns look remarkably like computer programs. (loc. 406)
this kind of problem solving-which demands knowledge of a set of formal elements and rules about their relations-is a relaxing leisure time pursuit, a kind of “formality mality for fun.” (loc. 434)
People are likely to be better at learning and using computer languages that closely match their interests and their domain knowledge. (loc. 451)
People consistently performed better at problems couched in familiar terms; (loc. 457)
it affords users ready understanding of what the primitives of the language do ‘because they already know them from their task domain’, and it eases application development because users can directly express domain semantics in the high-level operations of the language-there is no need to string together lower-level operations to get the desired behavior. (loc. 470)
the problem with programming is not programming; it is the languages in which people are asked to program. (loc. 478)
Introducing ducing a new [programming] language doesn’t work … but people will embrace what looks like a useful new application in itself.” (loc. 482)
When a man learns his profession he must learn the problem-oriented languages to go with that profession. (loc. 489)
its complexity lies in the relationships between entities in the domain itself-not in the programming needed to create the formulas that model the relationships. (loc. 500)
most users normally use fewer than ten functions in their models; (loc. 508)
The formula language has much less flexibility and generality than a general programming language, but the learning curve is flatter, and the basic operations accomplish tasks that users want to do. (loc. 515)
It is not enough to say that users need systems that are “easy to use”; end user programming systems should allow users to solve simple problems within their domain of interest within a few hours of use. (loc. 525)
systems that are more task-specific than general programming languages, extensible in the way that spreadsheets, FrameMaker, and other such systems are, and (3) easy to use. (loc. 622)
an activity as being composed of subject, object, actions, and operations. erations. A subject is a person or a group engaged in an activity. An object (in the sense of “objective”) is held by the subject and motivates activity, giving it a specific direction: (loc. 653)
Visual programming systems utilize notations that are primarily visual rather than linguistic (loc. 737)
visual notations do not deliver miracle solutions in terms of naturalness (loc. 762)
“Naturalness,” in toto, is a function of the relationship between the system language, the users’ language abilities, the communication task in question, and the computer’s abilities, including hardware capabilities (loc. 977)
end users are often much better at identifying and communicating their needs if they have a concrete program to criticize, (loc. 986)
users incrementally develop successive versions of their programs to help them in understanding their own requirements. (loc. 988)
text and graphics each have their own special strengths and weaknesses, and the best strategy is to exploit each according to its particular characteristics. (loc. 1029)
Hybrid visual programming is not iconic or pictorial in nature but uses graphics to display program state, rather than to represent operations and data flow. (loc. 1036)
Changing the constraints, when that is necessary, is a difficult and dangerous task because changing ing one constraint can of course propagate changes to many (unknown) parts of the model. (loc. 1142)
We often envision a lonely end user laboring in isolation, just barely keeping the computer at bay at the best of times, and mano a mano with the machine at the worst of times. (loc. 1241)
true-end users make good use of other people in their social environments to help them solve their computing problems and to compensate for gaps in their own knowledge of computers. (loc. 1243)
we tend to think of customization as a private, personal matter, the dominant mode of setting up and modifying customization files in her study involved a great deal of social interaction; (loc. 1261-1262)
A final point to be made about the importance of a layered software design is that such a design provides a growth path for individual users, even if they are not classic local developer types. (loc. 1374)
full-time gardeners may lose touch with the domain side of gardening as their activities come to be defined purely in terms of support. (loc. 1450)
The process of transferring ring domain knowledge to a programmer, and going through the necessary iterations to get the desired application, is inefficient. (loc. 1495)
with the right tools, abolish the distinction between “end user” and “programmer.” (loc. 1607)
Links
Version of the book
Bonnie A. Nardi. A Small Matter of Programming: Perspectives on End User Computing. Kindle Edition