I decided to take this project back up after a close friend told me they thought this stuff was cool, so we're getting back into it! This next chapter is one of the juicy ones in this book—we're actually on design design stuff now. Like previous chapters, I'm going to try and simplify Nardi's points to be less abstract, and try and explain why this book is more relevant than ever in today's world of technology.
Chapter 4: Interaction Techniques for End User Application Development
The core argument of this chapter is simple: there is no singular interaction technique that can "solve" end-user programming. If interaction paradigms were tools in a tool belt, the metaphor here is that for different type of projects, you wouldn't just use a hammer or just a screwdriver. Similarly, each paradigm has its strengths and weaknesses. The goal shouldn't be to build some super Swiss army knife, but rather identify the strengths and weaknesses of each tool so end-users can be presented with the right tool at the right time.
At this point though, the metaphor breaks down. With end-user programming, we're not just evaluating tools—we're evaluating tools (paradigms) to make better tools (end user programming tools)...that end-users can use to build tools (end user programs) for themselves. Yeah...it's pretty meta 😅
The tools that we want to evaluate on the top level are these design paradigms I've mentioned. The specific paradigms that Nardi wants to look at are:
Visual programming
Forms-based systems
Programming by example modification
Programming by example
Automatic programming by informal program specification
These terms sound complicated, so I'll do my best to simplify them as we go. If you haven't done some form of design before, things still might be a little hard to follow.
Visual Programming
Visual programming is the idea of using graphics, pictures, and icons as the core units for an end-user programming interface (rather than text). The idea here being that pictures and the like are "natural" identifiers for concepts, and can represent more abstract concepts that words can't. Since pictures are more universally understood (relative to computing concepts), you would think that an interface using entirely pictorial elements would provide an easy access point to programming.
The issue with this approach is that it relies so heavily on the idea that images are "natural", and therefore would be easier building blocks to use versus learning some syntax (see the previous chapter for more on syntax).
But like...what does "natural" even mean? At what point does something visual go from a human construct to something natural? We could go down the rabbit hole and look at this via philosophy (semiotics) or via psychology (gestalt)—but in reality no framework of thought provides answers to what resembles a consistently "natural" concept, much less a natural computing concept. Nardi also compares this argument to other claims of "naturalness" in coding paradigms, none of which hold up either.
A key indication that claims to "naturalness" dissolve into nothing more than dogmatic assertions is that so many different programming paradigms avow naturalness, and yet none provides any evidence for such naturalness, or even says what is meant by "natural" (p. 63)
In addition, nothing particular about visuals resolve the need to understand syntactical rules. It's a sort of abstract point, but basically the idea is that even if you had a system of just graphics, you'd still have to figure out what "set" of graphics signal the correct intentions. And for identifying this "set" of signs, there's not an advantage unique to visuals compared to words.
So, we can conclude that visuals can't "solve" syntax, at least on their own. Even if they can't be used to construct statements on their own though, they still have their benefits.
On their own, visuals can communicate relatively high level concepts. Even though they sometimes rely on cultural literacy, or real-world knowledge, Nardi finds that they're useful for communicating high-level concepts like structure and how distinct concepts are related to each other. For example, nested layers of shapes are great for communicating that a concept hierarchically is part of another concept.
Communicating this very simple image above^^ with only words would prove to be incredibly difficult and confusing. Even without specifics of what each name means relative the shape encasing it, you can quickly and easily get an idea of what's going on. With this in mind, we should remember visuals are useful, but—like the rest of these techniques—are no silver bullet for getting an end-user programming tool.
TL;DR for this technique: Sure, a picture is worth a 1000 words, but what are those words?
Forms-based systems
When Nardi says "Forms-based systems", the forms she's referring to are these:
You've seen these before—they make up most of how we input our data on the web. Forms are so universally understood that it would make sense for them to work as an interaction technique. However, the reasons that make them so user friendly are the same reasons they cannot be used the singular end-user programming interaction.
A major limitation of forms-based systems is that they generally do not handle complex procedural tasks well. ... Many forms-based systems work only for a class of problems that can be conceived of as a combination of a relatively small variables with associated allowable values. (p.67)
Basically, what Nardi is saying that a form is, by design, restrictive on what you can input. This restrictiveness prevents you from putting together the "complex procedural tasks" that you would need to actually complete a task.
For example, if you're filling a form for an address, for example, that form will only ever handle data for addresses. But what if you needed to go through a list of addresses and find the ones that were, for example, within 5 miles of another address on the list? You can see how this could become incredibly complicated if you stuck to forms-based systems.
In short, if you were to build a form that could capture all the branching behaviors and layers for a programmed task, it would be so complex and take up so much space that the benefits of using a form (clarity of intent, fixed allowable values) would disappear.
Still, like visual programming, forms have their uses! They're great for acting as a reliable interface for pre-defined constructs. Clay, the company I'm working at, has a great example of this.
Actions are a feature in Clay's product that allow non-developers to use Web APIs (Application Programming Interface) easily. APIs are one of the ways computers can communicate with each other over the web. However, they can be complicated without prior experience and require a certain amount of knowledge on network requests to use them properly. But by using forms, we can use a layer of abstraction to present only what's valuable to users—the user inputs. By acting as a rigid interface, forms can make complex systems easier to use.
TL;DR for this technique: Pros: Forms are rigid; Cons: Forms are rigid
Covering this whole chapter in this one post would be quite long, so I'll tackle the remaining interaction techniques—"programming by example modification", "programming by example", and "automatic programming by informal program specification" in the next post! See you then!