You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sometimes I wonder how important interface design is. As Paul Chiusano says, learning a difficult but powerful interface is a one-time cost. So what's the big deal?
10
+
11
+
## Spirit and Amazon
12
+
13
+
Recently I've spent a lot of time on the phone with customer support, first with Spirit airlines, and then with Amazon.
14
+
15
+
In both cases, the requests I made were fairly straight-forward. They were of the "my flight/package was cancelled/lost and I'd like to reschedule/reorder it" variety. In the Spirit case, this required me to stay on the phone for an hour and then have a fustrating conversation with someone in broken English for 20 minutes. In the Amazon case, I was on hold for only 2 minutes and then on the phone for 10.
16
+
17
+
But if you think about it, rescheduling a flight or re-ordering a product that was lost are very similar activities to schedule a flight or ordering a packing in the first place. And Spirit and Amazon both already have interfaces for doing that. Yet in this error case both of their interfaces fell short: Spirit actually had a bug in their interface which was supposed to let me do this action, whereas Amazon's interface didn't even try to do it. It simply said, "give us a call."
18
+
19
+
So then I called customer support, and spend time on the phone, instructing a human to press buttons on a computer for me.
20
+
21
+
## The internal interface
22
+
23
+
Here's my first question: **what did the customer support rep's internally-facing interface look like?**
24
+
25
+
Did it look like my interface to amazon.com, but instead of "call us for this problem," it displayed the interface to solve that problem?
26
+
27
+
No, we can be pretty certain it didn't look like that.
28
+
29
+
We can also be pretty certain that this rep wasn't writing SQL queries directly on Amazon's database. There's an interface somewhere in the middle that Amazon's internal engineers hacked together to allow the reps to do things that normal users cannot.
30
+
31
+
Here's my next question: **why not simply allow users to do those things?**
32
+
33
+
That is, I don't call up customer support every time I want to buy a book on Amazon. That whole point of buying online is that I can do things myself, without talking to anyone. So why don't we continue in this vein and allow our customers to do what our reps do?
34
+
35
+
Which brings me to my third question: **does the reps interface allow them to do things that they _wouldn't_ want users to do?**
36
+
37
+
We can be pretty sure the answer here is yes. There are two different types of actions the rep can take that the user cannot:
38
+
39
+
1. Discretionary actions, such as giving a refund for an order that never arrived but that the system says arrived.
40
+
2. Rare actions, such as sending a free replacement for a package that the system knows has been lost.
41
+
42
+
If we had a tool that drastically decreased the cost of interface-design, we could categorically solve class 2 problems (except maybe for old people who can't learn even intuative new interfaces).
43
+
44
+
And if you dream really hard, you can even imagine a tool that would solve class 1 problems. Think about a tool that would seemingly allow you to do any action on Amazon.com but if you don't have the authorization to do it, it would somehow display that your constructed action is illegal, and possibly explain why. Then there could be a button that you click such as "request permission" that inclues a textbox where you explain why you'd like to be able to perform that action. Then a rep merely can approve or deny your request. If it's denied, *then* you can call.
45
+
46
+
## The third kind of action
47
+
48
+
One final note. A lot has been said (TODO link needed) about social engineering customer support reps to provide sensative customer information that will allow one to hack into another's account. This is because there is a third category of customer support action that I did not list above:
49
+
50
+
3. Actions that neither the customer nor customer support rep should ever take.
51
+
52
+
We all know that the internal customer support interface has many of these actions available. You may blame training or hiring if these actions are taken by reps. But I blame the interface.
This article was started from [the notes](/notes/bret-victor/learnable-programming) of a re-reading of Learnable Programming by Bret Victor.
12
+
13
+
Here's the framing. Let's start from first principles.
14
+
15
+
human <-> interface <-> computer.
16
+
17
+
Humans want to make things with comptuers. In order to make something you need to have a model of how it works in your head. This model needs to take into account technological realities:
18
+
19
+
* proccessor speed
20
+
* storage
21
+
* network speed
22
+
* computational efficiency
23
+
24
+
However, it doesn't neccesarily mean that you need to understand these realities deeply. Simply that your model helps you account for them. That is, we cannot abstract beyond the capibilities of computers.
25
+
26
+
## Interface for humans
27
+
28
+
On the one extreme to the left, you could make an interface building upon models that people already have in their heads. This is why Microsoft Word is so successful. The cursor is much like the tip of a pencil and the page is much like a physical page. The mapping is clear.
29
+
30
+
## Interface for machines
31
+
32
+
On the other extreme to the right, you could simply have the human learn how the computer works, starting from electrons up through NAND and NOR gates, to proccessors, binary, Assembly, and C. This epitomizes Bret's Alan Perlis quote, "To understand a program, you must become both the machine and the program."
33
+
34
+
## In the middle
35
+
36
+
In the middle, you have powerful models for thinking, which take technological realities into account.
37
+
38
+
Microsoft Excel. Unless you're coming from an accounting background, the grid model is new to you. (Side note: it wasn't until I learned SQL that I learned that properties are at the top and rows are entities. This array of dictionaries metaphor is quite powerful. I imagine people who grow up with Airtable or Fieldbook will learn those powerful ideas seamlessly.) There are two fascinating metaphors in Excel that are incredibly easy to pick up:
39
+
40
+
1.*Underneath* a cell can be a formula that produces it. The metaphor of "under the hood" is easily assimilated.
41
+
2.*Dragging* a formula iterates it over data, updating the references as it goes. Very easy to pick up. Then if you don't want certain references to update as you drag, you learn about the `$` operator. It's a great example of doing the commong thing automatically and letting you ask for a special case when you need it.
42
+
43
+
## Actually, there are two dimensions
44
+
45
+
1. Familiarity of model (is it a human model or comptuer model)
46
+
2. Power of model (does it enable powerful ways of thinking)
Copy file name to clipboardExpand all lines: notes/bret-victor/learnable-programming.md
+93-33Lines changed: 93 additions & 33 deletions
Original file line number
Diff line number
Diff line change
@@ -52,13 +52,13 @@ I'm really getting revved up with the idea of video games, because they align th
52
52
53
53
### Environment / langauge goals
54
54
55
-
While he starts with the environment, I'd rather start with the langauge, or in other words, *start from the user who doesn't know how to code*.
55
+
While he starts with the environment, I'd rather start from *the user* who doesn't know how to code.
56
56
57
57
I believe the core challenge of learning to program is: **the assimilation of models.**
58
58
59
59
Bret calls this: "identity and metaphor -- _how can I relate the computer's world to my own?_")
60
60
61
-
In order to be able to make anything, the user needs to have a ever-improving model of how their tools behave. For example, think about about a child assimilates the model of a hammer. It's clear from the way it's shaped from which end to pick it up. Then when you pick it up, you immediatley notice that it's much heavier on one side. And of course you've seen others people use hammers, so the model snaps right into place: swing this where I want BAM.
61
+
In order to be able to make anything, the user needs to have a ever-improving model of how their tools behave. For example, think about about a child assimilates the model of a hammer. It's clear from the way it's shaped from which end to pick it up. Then when you pick it up, you immediatley notice that it's much heavier on one side. And of course you've seen others people use hammers, so the model snaps right into place: swing this near where I want it to make a BAM.
62
62
63
63
#### Powerful mental models / ideas
64
64
@@ -71,62 +71,122 @@ Thus we want to help students assimilate *powerful* mental models, what Seymour
71
71
72
72
These are the two-sides of the *composability* coin. As we've learned from functional programming, composibility is a very powerful idea. It allows us to do *top-down design*, where one decomposes a problem into its subproblems in such a way that solving the sub-problems automatically solves the solution -- because you've pre-composed the sub-problems properly before solving them.
73
73
74
-
So now that we know composability is a powerful idea, how do we help a new user assimilate it?
75
-
76
-
TODO
74
+
So now that we know composability is a powerful idea, the question to ask is how do we help a new user assimilate it? In his article, Bret compares LOGO and Hypercard to ProcessingJS to show how limited it is on both of these fronts. However, I would be excited by a more thorough discussion on how to build intuitively for decomposition and recomposition.
77
75
78
76
Other powerful mental models/ideas include:
79
77
80
-
* referential transparency (partitioning side-effects) TODO
Additionally, we know about some powerful ways of working:
96
84
97
-
* creating by reacting
98
-
*creating by abstracting
99
-
* small steps
100
-
* refactoring
85
+
* creating by reacting to what's on the screen
86
+
*abstracting similar code via variables/functions
87
+
*working in small steps
88
+
* refactoring code to be more readable, faster, etc
101
89
* version control workflow branching
102
90
* planning a project, estimating time, github issues, prioritizing
103
91
104
-
#### New learnable programming essay
92
+
## The features are not the point
93
+
94
+
> We often think of a programming environment or language in terms of its features -- this one "has code folding", that one "has type inference". This is like thinking about a book in terms of its words -- this book has a "fortuitous", that one has a "munificent". What matters is not individual words, but how the words together convey a message.
95
+
96
+
Love it!
97
+
98
+
## Read the vocabulary
99
+
100
+
> Thought experiment. Imagine if you bought a new microwave, took it out of the box, and found a panel of unlabeled buttons. Imagine if the microwave encouraged you to randomly hit buttons until you figured out what they did.
101
+
102
+
Great metaphor!
103
+
104
+
The demo of hover over for documentation inline is so beautiful. Makes me wonder if we could add that to WoofJS... In Woof, the sprites are given named parameters, so that's ok. However, we could probably improve the understanding of control structures if we added side-notes about them. Currently we add those notes inline in comments which is just awkward. It would also be nice if WoofJS had live update so users could see in real time the effect of their changes - it's a bummer we reload the entire page on any change.
105
+
106
+
## Follow the flow
107
+
108
+
Ah, this section is criticizing what I just mentioned, the immediate update, in addition to not showing incremental steps.
109
+
110
+
> People understand things that they can see and touch.
111
+
112
+
For-loops are the worst. I'd definitely vote to replace them with iterating over an array. Or even a while-loop if neccesary.
113
+
114
+
Allowing the programmer to scrub through the steps is great. In particular it allows them to see how/why things loop around. This would probably entirely eliminate one of the first questions that almost every Scratch student has of how forever-loops work. This is a big deal. The more of those questions we eliminate, the less need there is of trained teachers, the more the environment can scale.
115
+
116
+
Of course, I am excited with functional programming ideas, which have a less-intuitive model of flow. Yet it enables higher comprehension and more powerful thinking once you do understand it. I think the Elm time travel debuggers and the CycleJS devtools diagrams point in interesting directions.
117
+
118
+
### Make flow visible
119
+
120
+
Really cool section! Love the metaphor to driving directions. Also love the way he abstracts over iterations of a loop. He's totally on point that this could be super helpful when you're curious when the loop goes into an inner-if statement.
121
+
122
+
### Make time tangible
123
+
124
+
This is cool too! Giving users another way to slice a program. See it from another angle.
125
+
126
+
However, there feels like a slight arbitrary-ness to some of these examples. That is, I wonder if there's a way to build a langauge in which it's easy to build this visualization tools on top of so that people could build and publish these just like they build and publish libraries and frameworks.
127
+
128
+
### Make time visible
129
+
130
+
Beautiful! This is allowing us to see the path of an object all at once on the screen. Very reminiscent of the Ladder of Abstraction and also the Elm mario time travel debugger (which was probably inspired by this essay).
131
+
132
+
### Summary — Follow the flow
133
+
134
+
> The environment can make flow tangible, by enabling the programmer to explore forward and backward at her own pace.
135
+
136
+
This is key. Time travel debugger.
137
+
138
+
> The environment can make flow visible, by visualizing the pattern of execution.
139
+
140
+
This is also key. CycleJS devtools diagram.
141
+
142
+
> The environment can represent time at multiple granularities, such as frames or event responses, to enable exploration across these meaningful chunks of execution.
143
+
144
+
Again, this sounds to me like add-ons that the community could build given a really solid underlying structure. A structure that Conal Elliot would build. Perfect abstractions.
145
+
146
+
### FRP Scratch
147
+
148
+
I'm reading this essay in part in terms of a new programming environment for children that I've been thinking about recently. Sometimes I call it an FRP Scratch. It's like Scratch but with a more functional reactive runtime, so as to enable time travel debugging and also a CycleJS-like diagram of the code.
149
+
150
+
Yet my conversation with Jason Brennan is making me rethinking directly copying Scratch as much as I was planning to. That is, there's a lot of really interesting metaphors and abstractions outside of Scratch that haven't been explored. For example: direct manipulation. But of course direct manipulation, while intuative, does seem to limit the power of the comptutational abstractions. Things to think about!
151
+
152
+
## See the state
105
153
106
-
Here's the framing:
154
+
> The computer somehow drew that picture, so the computer must have calculated all those scaleFactors itself. Are you seriously recalculating them in your head?
155
+
>
156
+
> ... setting a "breakpoint" ... is like monitoring traffic on the freeway by setting up a barricade ... writing to a "console" ... is like figuring out where your dog goes during the day by following the trail of droppings.
157
+
>
158
+
>
159
+
> The entire purpose of code is to manipulate data, and we never see the data. We write with blindfolds...
160
+
> ... Spreadsheets rule because they show the data.
161
+
> ... Edward Tufte has one primary rule... Show the data.
162
+
> ... the number one thing you can do is to show the data.
107
163
108
-
human <-> interface <-> computer
164
+
Beautiful. I'm sold. Let's show the data!
109
165
110
-
Humans want to make things with comptuers. In order to make something you need to have a model of how it works in your head.
166
+
### Show the data
111
167
112
-
On the one extreme to the left, you could make an interface building upon models that people already have in their heads. This is why Microsoft Word is so successful. The cursor is much like the tip of a pencil and the page is much like a physical page. The mapping is clear.
168
+
This becomes easier when you can step through time easily.
113
169
114
-
On the other extreme to the right, you could simply have the human learn how the computer works, starting from electrons up through NAND and NOR gates, to proccessors, binary, Assembly, and C. This epitomizes Bret's Alan Perlis quote, "To understand a program, you must become both the machine and the program."
170
+
### Show comparisons
115
171
116
-
In the middle, you have powerful models for thinking, which take technological realities into account.
172
+
117
173
118
-
TODO looks like there are two dimensions here:
174
+
Woah. I forgot about this. Beautiful...
119
175
120
-
1. Familiarity of model (is it a human model or comptuer model)
121
-
2. Power of model (does it enable powerful ways of thinking)
176
+
And then when I was mesmerized by that plot, he hit me with the knockout punch:
122
177
123
-
Microsoft Excel. Unless you're coming from an accounting background, the grid model is new to you. (Side note: it wasn't until I learned SQL that I learned that properties are at the top and rows are entities. This array of dictionaries metaphor is quite powerful. I imagine people who grow up with Airtable or Fieldbook will learn those powerful ideas seamlessly.) There are two fascinating metaphors in Excel that are incredibly easy to pick up:
178
+
> Is it possible to understand a loop with, say, thousands of iterations, without drowning in thousands of numbers?
179
+
>
180
+
> Yes -- there is an entire field of study devoted to depicting large amounts of numbers. To visualize this data, we can use all of the standard techniques of data visualization.
124
181
125
-
1.*Underneath* a cell can be a formula that produces it. The metaphor of "under the hood" is easily assimilated.
126
-
2.*Dragging* a formula iterates it over data, updating the references as it goes. Very easy to pick up. Then if you don't want certain references to update as you drag, you learn about the `$` operator. It's a great example of doing the commong thing automatically and letting you ask for a special case when you need it.
182
+
And then he turns the table plot to a graph. And I died. Holy crap I really need to read this Tufte guy. Looks liek Amazon lost the package of his book in transit... Let me call them now.
127
183
184
+
### Eliminate hidden state
128
185
186
+
I love how he explains the two ways to eliminate hiddden state:
0 commit comments