Experimenting at Home: The Role of Auto-Biographical Research in Designing for the Family

There has been a rich tradition in ethnography of gaining access to certain communities by using family connections (e.g., the famous Addler & Addler studies of schoolyard dynamics). Similarly, in the design of family communication technologies, it is not unusual for researchers to test new communication technologies with their own families (e.g., Hermes@Home by Saslis-Lagoudakis, Cheverst, Dix, Fitton, & Rouncefield).

Recently, at the “Technology for Today’s Family” workshop we discussed the possibilities of auto-biographical research in this domain. The appeal is clear: it solves the problem of finding willing families, it allows for longer deployments, it allows for ongoing debugging, and it allows access to the kind of data that would otherwise be impossible to get. However, how should such a study be reported? What is the possible role of investigations conducted in the researcher’s home?

In both of the examples from the first paragraph, the researchers revealed their relationship to the participants of the study. However, several recent studies in this domain (3 different that I am aware of) have left this information undisclosed. This never seemed malicious or purposefully misleading. Corresponding with these authors, they mentioned two major classes of reasons for not disclosing relationships to participants:

  • It is common in HCI to use participants you know (e.g., other students in your lab) and not reveal those relationships. It is up to the researcher to decide whether using known participants affected the study results. If the estimate is that it didn’t, there is no need to waste precious paper space disclosing relationships.
  • In general, participants in HCI studies are presented in an anonymous fashion. Articulating a relationship to the author would break this anonymity (since we don’t publish anonymously). Shouldn’t members of the researchers’ family receive the same protection as other participants?

I will not disclose the actual papers because I respect the anonymity of others’ families. But, I think this is an important question for us to decide as a community moving forward. Here are three proposed directions for moving forward:

  1. It’s fine as it is now. There are big advantages to the access that can be gained by doing research with our own families, and disclosing relationships to participants should be up to the researcher’s discretion.
  2. Familial relationships to participants should always be disclosed and implications discusses in the paper. The price of doing research with one’s own family is the loss of their anonymity. The researcher should make sure all family participants consent to their relationships to the author appearing in the paper.
  3. We shouldn’t do research with our own families at all. We run into the risk of designing more for families that are like our own, losing out on the chance to hear from other types of families.

I would really like to hear the opinions of others on this topic. What do you think would be the most reasonable approach to take?

Making Current Videochat Technologies Work Better for Your Family

Photo from NYT article “Grandma’s on the Computer Screen” (November 26, 2008)

As a family communication researcher, people frequently ask me for ideas on making videochat work better for their families (especially between children and grandparents). While I think there is a lot of room to make new technologies in this space, there are ways of leveraging existing technologies, too.

One of the big challenges for videochat is that setup can be problematic and frequently requires a tech savvy adult on each side. For example, a participant in one of my studies described his experience:

Video is nice, but getting it to work from both the ends wasn’t worth it. We’d have the phone going, and I’d be saying “hit that thing on the right” or whatever. It would take forever to get it set up. Especially with people that are not that technical. Like we tried video with grandparents and my dad is the least computer literate person I know. We literally spent and hour and a half setting up a call which lasted 5 minutes. It gets to the point when it’s not worth it. So, our main method is the phone.

One solution is installing TeamViewer on the remote machine (e.g., next time you visit). This free program gives you really easy-to-use remote access so that now you can start the call on both sides at the agreed upon time and do basic troubleshooting without having to do tech support over the phone.

Skype has a setting for automatically answering incoming calls, with video.

Another solution is setting up a dedicated device (such as an old laptop) at a good location in the remote participants’ home. Set Skype to start and auto-login each time the machine restarts and set incoming calls to auto-connect with video. However, the downside of this approach is that you have to use social conventions to manage availability (e.g., call first by phone and agree on a time to connect before trying to Skype).

Another problem with currently-available videochat is that it really gets boring pretty quick (this is especially true while talking to children). The key to making videochat work is coming up with compelling activities to do together, rather than just talking. There is a lot of great research in this space, as well as some existing stuff out there. So, if you’re struggling  to find something to do to keep your videochat sessions more engaging, try a few of these and see if you like them:

  • Story Visit from Nokia is a great free tool to read books together remotely and even gives advice to make the reading experience more engaging!
  • Once you’re done with those stories, you can try to find other books online (you’ll have to coordinate the page-turning yourself, but at least you can see them easily). I suggest using the International Children’s Digital Library which has a huge collection.
  • Yahoo! Multiplayer games can be a good way to stay in touch as long as you can find somebody to help set it up on the other side (or use the TeamViewer trick above). Or try Rounds, which combines videochat and games.
  • If you want to try something that stretches across sessions, I would suggest trying a virtual world together, choosing one that suits your child’s age and interests. The popular ones include: Petpet Park, Club Penguin, Neopets, World of Warcraft, and Minecraft. Unfortunately, the last two are best played fullscreen, so it may reduce the communication to audio-only.
  • You can use an online whiteboard (like Scriblink) to draw together synchronously, or sign up for a specialized social network like Sesame’s Streets familiesnearandfar.org to send asynchronous drawings and messages (this site was made for military families, but is open to everybody)
  • Finally, sometimes it can be fun just to play with regular physical toys over videochat. Some ideas that work well include: puppet show, tea party, playing the game Battleship, showing magic tricks, and dressing up dolls for a fashion show. I’m sure you can come up with other things based on your interests.
If you have other ideas that have worked for you, I would be love to hear them here.


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!