Sherry Turkle gave a brilliant talk at the GVU Brown Bag at Georgia Tech today about her book Alone Together. Towards the end of the question session, she had a fascinating exchange with Carl DiSalvo about robots to bathe elders. Sherry argued that people who no longer can bathe themselves should be bathed by caring humans. (I can imagine the dialog: “Hello Mrs. Johnson! It’s time for your bath. I saw your son was here yesterday. Did you have a good visit?”)
Carl responded: We all agree that would be ideal. But in reality, the attendants are often workers paid minimum wage who are unkind to their charges. When you interview real nursing home patients on the subject, they all say “I’d rather be bathed by a robot who isn’t expected to care than by a human who fails to care.”
Here’s my thought in reply: What’s the difference between a robot that bathes you and one that you use to bathe yourself? It’s a subtle point–a question of where the sense of agency resides. (Of course when I’m done bathing myself, I’d also like a real human to ask how my visit with my son yesterday went.)
A hygiene-assist robot is an easier problem to solve than a sociable robot–one whose primary purpose is social or emotional. Could we still keep the sense of agency with the person in those cases? It’s harder to understand what that might mean. The problems Turkle raises in her book are serious.
This theme of agency and of designing to keep the sense of agency with the individual keeps cropping up in different areas of HCI. It feels to me like a core principle–something we should highlight in HCI classes and emphasize wherever possible in design. The more this technology pervades different aspects of life, the more human agency seems important.
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!
Every April the Undergraduate Research Opportunities in Computing (UROC) program at Georgia Tech holds a research symposium where students show off their work. We take over the picnic area of the college’s main building, and set up live demos. When we first started in 1998, this was a herculean effort on the part of of our Technology Services Organization (TSO). Large computers and monitors were borrowed from labs. Cables were run for net access. Project requirements had to be matched to borrowed hardware. Project one needs more RAM, but project two needs the better video card…. It was complicated.
Today was our planning meeting for UROC 2010, and our loyal TSO rep showed up as always, ready to do battle. And we couldn’t find anything for him to do. Not a thing. Computers? Well, almost everyone’s project runs on their laptop. Net access? We have wireless. Here was our final technical to-do list: have some extra ethernet cables handy, in case someone wants to switch to a wired connection. That’s it.
A bit of perspective on how things have changed!