Archive

Archive for the ‘HCI’ Category

MOOCs: One Size Doesn’t Fit All

March 27, 2014 6 comments

Can a MOOC teach course content to anyone, anywhere? It’s an imagination-grabbing idea. Maybe everyone could learn about topics from the greatest teachers in the world! Create the class once, and millions could learn from it!

It seems like an exciting idea. Until you realize that the entire history of human-computer interaction is about showing us that one size doesn’t fit all.

I went to two terrific talks on MOOCs a few weeks ago. At the GVU Brown Bag, Karen Head and Rebecca Burnett talked about their brave attempt to teach an English composition class free online, for anyone interested. They encountered intriguing challenges. The course said you needed to be fluent in English as a prerequisite, but some people who signed up were far from fluent. The course did reach people all over the world, but some of those people disapproved of Karen’s style of dress. Her attire was conservative by American standards, but the world is a big place and some people felt otherwise and said so, loudly. The instructors used YouTube as part of assignments, but YouTube is banned some of the countries their students live in. Trying to accommodate everyone everywhere turned out to be a stressful endeavor.

The second talk was by Ed Cutrell of Microsoft Research India at the ACM Learning at Scale conference. Ed has been studying engineering education in India. He explained that the top-level universities in India serve about 40,000 engineering students per year. The rest of the universities serve another 4,000,000 engineering students per year. The quality of teaching at lower tier universities in India is wildly variable. In some cases, the instructors don’t know the material themselves. Many aren’t career teachers, but are teaching on a temporary basis until they can find an engineering job. Given those constraints, Ed and colleagues are using a blended learning model where short videos by experts are followed by class discussion. With this approach, the instructor and students learn the material together. Trying to respond to the particularities of a learning context, Ed was able to design a successful solution.

If I am designing a class, even if I limit my audience to “Georgia Tech students,” that isn’t a specific enough. I would design a different class for undergraduates versus graduate students, for computer science (CS) majors versus majors in computational media (CM). I don’t always have the luxury of making those classes different—economics dictates that the CS and CM majors take almost all their classes together. Financial considerations push us to generalize.

Do you own any clothing that is one-size-fits-all? It works great for my nightshirts, but it wouldn’t work if I tried it for pants. And there are some people who don’t fit into one-size-fits-all, even for nightshirts. The analogy to online classes works pretty well. There are a few simple things where one size will work tolerably well. But in most cases we should stop trying to make one size fit all.

Categories: education, HCI, MOOCs, teaching

Balancing HCI and Computational Thinking: Levels of Abstraction and Agency

February 27, 2011 Leave a comment

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!

%d bloggers like this: