A Small Matter of Programming: Perspectives on End User Computing

by Bonnie A. Nardi

A Small Matter of Programming asks why it has been so difficult for end users to command programming power and explores the problems of end user-driven application development that must be solved to afford end users greater computational power.Drawing on empirical research on existing end user systems, A Small Matter of Programming analyzes cognitive, social, and technical issues of end user programming. In particular, it examines the importance of task-specific programming languages, visual application frameworks, and collaborative work practices for end user computing, with the goal of helping designers and programmers understand and better satisfy the needs of end users who want the capability to create, customize, and extend their applications software.The ideas in the book are based on the author's research on two successful end user programming systems - spreadsheets and CAD systems - as well as other empirical research. Nardi concentrates on broad issues in end user programming, especially end users' strengths and problems, introducing tools and techniques as they are related to higher-level user issues.Bonnie A. Nardi is a Member of the Technical Staff at Hewlett Packard Laboratories.

Genres: Programming, Computers, Design, Computer Science, Nonfiction, Software

178 pages, Hardcover

First published July 15, 1993

Reviews

[Omar · Rating 5 out of 5]

excellent. the thesis of the book is that end-user programming should be built around an actual task and task-specific operations: if you're a spreadsheet and people want to add stuff, give end users a SUM function, rather than making them declare a loop counter and do a for loop. let them always be working with reference to the task rather than programming details. (motivation being essential to self-directed learning...)

a lot of the book is really a _defense_ of formal languages and text-based programming, drawing on fascinating ethnography of spreadsheet and CAD users. spreadsheet users don't mind writing text formulas, so why should we believe non-textual language like Scratch is necessary for end-user programming?

I also read it as a defense of the end user as an expert in their domain who is willing and able to learn a powerful tool like Excel or CAD and pick up the formalism, not a 'novice programmer' who needs hand-holding and automation.

so a non-obvious conclusion is that 'silver bullet' approaches are wrongheaded for end-user programming.
these and others may be useful techniques, but that's all they are:
- visual (block-based, flowchart) programming
- programming by inference from examples: an especially effective takedown, almost implying that programming by example just requires general AI, since you could be building examples drawing from arbitrary world or mental knowledge
- programming by informal natural language specification (?)

then a really great description of the social practices around end-user programming. I love the "local developer" / "advocate end user" / "gardener" category: 10-20% of every end-user programming group the author had heard of. these people would get into computing, would use the cool features and make macros and help everyone else. mediating between classic programmers and the rest of the users. collaboration as a key part of how these systems work.
and maybe offering a way to move up the learning slope over time? the time evolution of this stuff wasn't clear: are these categories inherent to personality/interests or do people move between them?

still trying to grasp the generalization of spreadsheets to visual formalisms, and less impressed with the concrete ACE system shown at the end, although I like the idea of a meta-system. need to reread those last bits.

[Michael Dubakov · Rating 5 out of 5]

В 90х ребята уже делали то, что мы примерно делаем сейчас в Fibery. К сожалению пришествие интернета фактически приостановило все наработки в сфере no-code решений (это такие штуки, где пользователи решают свои проблемы через создание собственных аппов, типа excel, AutoCAD, etc.).

В книге почти все главы клевые. В частности можно найти ответы на вопросы:

1. Почему голосовые интерфейсы вряд ли станут массовыми? (потому что для многих задач они медленные)

2. Почему не стоит недооценивать интеллект пользователей? В основном эти люди ориентируются на решение конкретной задачи в своем домене, им программирование до задницы как форма интеллектуальной игры. Но многие делают со своими тулами довольно сложные вещи, например создают невероятные таблички с формулами или пишут макросы.

3. Почему языки общего назначения для пользователей плохи? Потому что порог входа в них большой и для решения их конкретной задачи они слишком удалены от домена. Так что для продвинутых пользователей нужны task-specific languages, фактически DSL.

4. Какие есть способы создания приложений? Визуальное программирование, form-based программирование, программирование на основе изменения примеров, автоматическая генерация приложений) и почему все эти способы не сработают в целом (потому что только здоровый микс разных подходов может дать нужный уровень абстракции для разных задач.

5. Почему не взлетел HyperCard (давно) и Eve (недавно)? Потому что были слишком общими средами для разработки приложений, и это было серьезным барьером для пытливых пользователей. А программистам такие штуки нафиг не нужны, у них есть IDE и Java.

Для любого разработчика no-code платформы — весьма любопытная книга с примерами и глубокими мыслями. Мне было очень интересно прочитать, что мы в Fibery во многом дублируем подходы авторов и переизобретаем велосипеды 25-летней давности. Ну что поделать, в вебе нам приходится изобретать эти велосипеды заново...

[Igor Razvodovsky · Rating 4 out of 5]

The answer includes task specific programming languages, visual application frameworks, and support for collaborative computing practice.

[Caroline · Rating 5 out of 5]

a really brilliant and fascinating text on the potential and possibilities of end-user programming, and the social & power dynamics between users vs. software makers (and the construction of that dichotomy in the first place). it's a bit dated, but it's interesting to see how it's aged, and it's quite well-researched and well-cited. this should be a seminal HCI text, imo

[Christopher · Rating 3 out of 5]

Look, I don't read books like this hoping to get good material for a stand-up open mic night. But is there some law somewhere that dictates such books must be as dry and utterly humorless as possible? Is there some concern that cracking even a tiny joke, even a simple pun, every 50 pages would undermine their entire thesis? I fell asleep innumerable times.

Ultimately though, as a persuasive argument i found it lacking. If i didn't already buy into their ideas beforehand I'm not sure I'd have been convinced by the end of the book. I really think the argument for the utility of tools that provide programming power to people who aren't programmers is proven by hands-on usage and demonstration, and long-term in-field deployment with years of supporting data. This book does not provide any such compelling argument.

It basically boils down to, "Spreadsheets and some CAD programs offer ways to develop systems beyond what the daily in-application tools offer, for those users willing to dig into the guts and learn to do so. This has helped people in whose industries those tools are integral. Therefore we should try to provide parallel tools to everyone in all industries."

So then it is made clear to us that such tools must present themselves to potential end-users in the domain language of those users. Yet the shining preview of things to come, ACT, is precisely NOT that. It is some kind of overly abstract, overly generalized tool for defining "People objects" and staff hierarchy charts. If i never hear another utterance of "objects" with "People" or "Animal" or "Vehicle" -style worthless, purely academic abstractions again, I could die at least not-so-grumpy if not happy.

[Dave Paola · Rating 4 out of 5]

Definitely a bit dry but overall there is some good info locked in this book. Anyone designing software for humans should probably at least read the chapter summaries.