Christopher Blizzard

I’d like to spend some time talking about the an idea that I’ve been chewing on for a while. That idea is context of use.

A little background to start. Red Hat has been heavily involved in the One Laptop per Child project. We’ve got quite a few developers working full time on the project. A huge part of that work has been to think about what we’re delivering to kids all over the world. We have had to ask questions like “what’s relevant? what’s useful? what kind of experience do we want to create for kids on these laptops?” I don’t want to talk about the answers to these questions at this point – those are worth a post of their own – but instead I want to talk about what we’ve learned about the process and what happens when you start asking those questions.

From the start the most important thing you can do is to understand the problem at hand and frame the question in the right way. For example, asking “how do I port gaim over to the one laptop screen size?” is not the right level to ask a question. The right level to ask is something more like “how do we create an interesting social environment for kids to share and learn together?” Sometimes an existing piece of software might solve the problem, and sometimes it might not. But you need to be willing to leave yourself open to answers to the question that you present that are different than what you expected. Too often in technology I see people starting with an answer and trying to find a way to change the question to fit the answer. Free software seems to breed an unusual emotional attachment to code and interfaces.

The second part that’s important to understanding your particular context of use is to make sure that you talk to people. Do research. Find people who know, people who do and people who use. And throw in some outsiders just for a sanity check. In our case, we’ve spent a lot of time talking with people involved in the project directly, people in the various countries who have to deploy this hardware and software, free software people, people who have done a lot of deep research in various educational and learning areas. The most important thing to realize is that you aren’t going to be able to do this alone, and what other people have learned is far more important than what you’re bringing to the table. Your project is not a one man band.

Ask about how people will use this software, how it interacts with the hardware, what has worked in the past and what people will think will work in the future? Understand the physical constraints. The battery limitations, the way it is deployed, what other computers and network infrastructure is available, what tasks the kids could do with these machines – then you have the start of the picture.

At this point you understand a couple of things: your constraints and the a priori assumptions that everyone else has brought to the table. If you were good, you actually asked everyone to list their agendas. Everyone has agendas. We ran into quite a few at this point in development. People who wanted us to use Java for Java’s sake, people who wanted to see their particular software on the laptop, people who wanted to control what kids would see, and what educational content they would be exposed to – everything. But in the end if you don’t get them out in the open, you can never have an honest discussion about what those mean in your particular context. It’s hard to get people to be open about their agendas – often they don’t even know that they have them. But with gentle probing and an understanding that everyone does it, it’s often enough to get people talking about it. Think of it is as design psychotherapy.

These are the common elements to defining a good context of use for your software. Ask the right question. Do research. Be open to everyone’s experience. Understand the environment. Make sure that you’re aware of everyone’s agenda. From there you can start to figure out what you actually want to do.

But that’s a topic for another post.