My colleague Mark Guzdial wrote a great blog post last week called “HCI and Computational Thinking are Ideological Foes.” A lot of HCI wants to make the computer invisible, like Heidegger’s hammer. While you’re using it, you’re thinking about what you’re trying to accomplish–not about how to use the (computer/hammer). But computer science education takes the opposite approach: please, please look at the computer/hammer! It’s interesting, and if you’re going to really use it, you need to really look at it.
How much detail should we hide from the user? I think about this every time I run software update on my MacOS computers. The system tells me it has stuff to update, and would I please click OK to install it? I have to click a button to ask for what it plans to update. I find the dialog infuriating, as if it’s saying “don’t worry your pretty little head about what we’re going to update–we’ll just take care of it, OK honey?” I click to ask for more details, and it tells me that it’s going to, for example, update iTunes and do a system security patch. OK, that works for me–now I click go ahead. But notice that I didn’t say “OK, but what exact part of iTunes are you going to fix? Show me the original code and the patch.” It seems OK to me that they told me it’s a stability update to iTunes. The level of abstraction is right (for me) after I ask it for more details. I don’t want even more details.
Similarly, Mark isn’t arguing that “kids these days–they don’t know their one’s and zero’s any more! They don’t even know what a decrement register is! Whatever happened to punch cards? Why in high school, I had to program our IMSAI to echo characters on the screen by toggling in binary codes with the front panel switches!” OK, I did have to do that, and I loved that assignment, and I wish everyone could still do that, but it seems impractical. It’s OK in this day and age to keep students at a slightly higher level of abstraction. As Beki Grinter points out in her interesting response to Mark’s post, sometimes we really do want to hide some details from users. Then the question becomes, what level of abstraction is appropriate for what users doing what tasks? And I agree that a lot of HCI today is, like the MacOS software update dialog, pushing the level of abstraction too high.
A complementary concept to level of abstraction is sense of agency. Do I feel like I am taking this action (regardless of whether I’m using more abstracted or lower level tools to do it) or do I feel like the system is doing it for me? The difference is a subtle one. In either case, lower level details are being taken care of without requiring my attention. But when I retain a sense of agency, I feel like I have a clear mental model of what is going to happen and the entire process was set in motion by a deliberate choice on my part. A higher level of abstraction is tolerable when we design in a clarity that helps the user retain that sense of agency.
You might say that designing applications to be used by people and designing CS education are fundamentally different with regard to abstraction and agency. But they are more similar than perhaps it seems at first glance. Consider for example the question of memory management. Do students need to explicitly allocate and free memory? Or is it OK for that to all just happen for them? I suppose that depends on how critical performance is in the application you’re developing, and how good your garbage collection system is. I still think that “serious” programmers need to learn how to do their own memory management, so they understand it, even if they don’t have to do it on a day to day basis. But I do NOT think that serious programmers need to make keys echo by toggling in binary on the front panel switches. The minimum acceptable level of abstraction has migrated upward a bit. Even for the true hacker it has moved up a bit, and for the web developer it has moved up much more.
There’s a delicate and important design problem here. Let’s take the example of creating a new web development environment. How much abstraction is the right choice for this task? How much of how networks and web browsers really work should we expose to the web developer? How do we get the right level of abstraction that lets the web developer have a clear mental model of what’s going on and retain a sense of agency over the task they are accomplishing? The HCI of programming languages and development environments is an absolutely critical research problem.
There’s still a gap in levels in my argument: What Mark saw on the ischools conference program was a lot of HCI for and about end users. Which you might view as being entirely different than designing for programmers. Except that what I find so exciting about modern computer technology is that maybe there doesn’t need to be such a gap between users and programmers. As technology increasingly surrounds all of us, it’s an open question how much real control ordinary people will have over that technology. But what if we think of everyone as programmers? Think of everyone as programmers who need tools with different levels of abstraction for different tasks. The same person may use a high-level tool for one task, and a lower-level look-at-the-details-of-the-hammer tool for another a few minutes later. How can we create these tools with many levels of abstraction, but which always keep that sense of agency–I am the person doing this with the tool, rather than the tool is doing this for me. And Mark is dead right that there is not enough dialog about this at the moment at CHI and the ischools conference and similar. I was thrilled to see a paper accepted for CHI this year on usability of operating system permissions systems. It was one paper. We need 100 more like it.
We underestimate the intelligence and independence of our users when we keep trying to abstract everything away for them, without giving them the choice. HCI and CSED have grown apart, and that’s a tragedy for both traditions of research and for all of us as humans who live with these technologies intertwined through more and more of our lives.
One thing Mark wrote was wrong, though. He concluded his post by writing “Here’s a prediction: We won’t see a panel on ‘Computational Thinking’ at CHI, CSCW, or iConference any time soon.” He’s wrong because I’m going to organize it, and he’s going to be on the panel!