HuffPost Re-Post

I apologize for the long silence, everybody. I’ve been ultra-busy doing awesome stuff at CHI 2013 and there will be tons of blog posts to follow from some of the stuff that’s been started there. In the meantime, here’s a link to something that has taken a little bit of time to push through AT&T’s PR, but my post about getting into tech research is finally live on HuffPost!

I’m also committing to blog every week until the end of the summer, so hopefully no more long periods of absence on my end. (Edit: And then I got a surprise last-minute PC invite, so I guess my blog-a-thon is on hold for a bit)

Quickly Prototyping Physical Devices for Kids

Frequently, when designing technology for children, I want to have some components that are custom-built or some ways of interacting with a technology that are different from a mouse and keyboard. I have really no hardware experience myself, but I’ve been able to MacGyver a few quick solutions using the skills I have. This is a not a new trick, but it’s worked fairly well for me in the past and it’s something that I share with a lot of the younger students who work with me. I think it’s a good way to get your feet wet with physical prototyping.

It is frequently quite simple to take apart an existing interaction device. For this purpose, I particularly like USB mice (like this one) or USB number pads (like this one). These are cheaper than buying an Arduino board and you don’t need any new skills to make this work — just hack apart the mouse/pad, design a casing that will push something on the device, and use the usual keyboard and mouse events in your code. Here’s one example:

The dock on the right includes a hacked-apart mouse as the "sensor" for figuring out if the small screen is placed onto the dock on not. Lifting the small screen switches the camera from the one on top of the TV to the one taped on the back of the small screen. This is from my work with Kori Inkpen and AJ Brush at MSR.

And here’s another:

This custom box with buttons and a "joystick" was made by two students I advised (Saie Deshpande and Madhura Bhave). Inside is just a number pad. The box itself is cardboard and the button and joystick pieces are 3d printed to push the right button below.

Recently, I’ve also been really impressed with the Logitech USB game controller which is really easy to use for custom functionality because it allows you to assign controls to existing events (e.g., pushing “K” key) and then just watch for those in your code.

Now, if this still doesn’t get you where you need to go, consider picking up Arduino, which is a really straight-forward way to do physical prototyping. For example, in my thesis system — ShareTable — the system places a call to the other table when the cabinet door is open. I originally prototyped the cabinet door sensor with mouse buttons, but it was awkward and not very reliable. Eventually, I caved and went to the Arduino solution. This only took about a day of work to get done (going from zero experience with this stuff) and had been the most robust part of the system. Here’s what the Arduino sensor looks like:

A door sensor for the ShareTable that uses a reed switch on an Arduino board.

I’m sure you can find plenty of Arduino guides online. It’s a bit more expensive than just hacking an existing device, but it’s worth it if it’s a prototype that you’re planning to have around for awhile (rather than just to run a couple of studies).

Let me know if you have other ideas for easy physical prototyping!

 

The Road to “Hello World”

Don't you hate when you can't get the dependencies to work out when trying out some new tool? I do!

Recently, I’ve been thinking about how I pick up new programming skills. There is a fairly substantial body of empirical work on how novices learn to program, but fairly little stuff out there that I’ve seen (please correct me, if I’m wrong) on how intermediate or expert programmers pick up new languages, tools, etc. As I thought about it more, I realized that for me the hardest part of learning some new set of programming skills is getting to the “Hello World” — just getting the basic functionality of the toolkit, language, environment, library, etc. to work. Once I’m there, it’s just a matter of trudging through the documentation and forums to get it to do what I want, this part is fun, but getting to the “Hello World” is frequently just frustrating.

Here’s the general process that seems to happen for me:

  1. I think, “Wow, this toolkit / language / environment / plugin seem like a great solution to the current problem I’m facing. I’m going to try it out!”
  2. I go to the new toolkit / language / environment / plugin page to download and follow instructions to install.
  3. I try to run the most basic thing in context of the problem that I’m facing (essentially, “Hello World”) and I immediately have problems with some sort of dependencies, environment issues, weird errors with vague description, etc.
  4. I Google and madly scour the forums to try address said problem, usually coming up with a set of 5 or more possible solutions. Then either, (1) one of these solutions works, (2) I get stuck but I find somebody to help fix it, or (3) I decide that it’s not worth the pain and just solve the initial problem with some suboptimal work-around.

I am getting a bit better about this over time, but it’s still a big problem for me. I was definitely not taught about this process in classes, where the teacher or TA essentially sets everything up and help troubleshoot. Overall, this process can take anywhere between 1 day and 2 weeks — so it’s not a trivial time expenditure and frequently discourages me from trying new things. However, it wasn’t until I started doing this (sometime around the beginning of senior-level as an undergrad) that I really began to feel like a real programmer. Up until that point, I felt like I was playing in a sandbox — I could do the things I was taught to do, but I couldn’t really get creative with Computer Science.

So, I’d like to propose three ideas for the future:

  • Investigating barriers to picking up new programming skills for intermediate and expert programmers. I think I’m not the only one who struggles with the above process. I’d love to observe and interview programmers as they are setting up a new tool or get started with a new language. I think there’s a lot to be gained by understanding the challenges faced before getting “Hello World” to work.
  • Creating classes that focus on building competences around quickly picking up new tools / languages  / environments / plugins. At Georgia Tech, we have “Build Anything” classes that focus on rapid prototyping of physical devices. I think it would be useful to have a “Code Anything” class sometime around Sophomore or Junior year of undergrad. I think it would help build and cement the students’ identities as programmers and would support their independent exploration in the future.
  • Making the process of getting started easier. Of course, I can encourage toolkit creators to do usability studies of the setup process until I’m blue in the face — it’s probably not going to happen. But, what about an App-store of sorts for plugins / toolkits / libraries / etc. for common IDEs? I’ve never had a problem installing an App on my iPhone and getting it to run (and my friends with Androids are pretty happy with their Marketplace experiences as well). What would happen if there was a similar vetting process for creating toolkits / plugins / language environments / etc. for programmers? I don’t know how hard it would be to do this, but surely there are some steps we can take in this direction?

I acknowledge that my approach here is completely naive. I hope that you guys can share your experiences and your knowledge of previous approaches to this general topic.