Author Archives: Lana Yarosh

About Lana Yarosh

Svetlana “Lana” Yarosh is an Assistant Professor in the Computer Science & Engineering Department at University of Minnesota. Her research in HCI focuses on embodied interaction in social computing systems. Lana is currently most proud of being one of the inaugural recipients of the NSF CRII award, of her best papers at CHI 2013 and CSWC 2014, and of receiving the Fran Allen IBM Fellowship. Lana has two Bachelors of Science from University of Maryland (in Computer Science and Psychology), a Ph.D. in Human-Centered Computing from Georgia Institute of Technology, and two years of industry research experience with AT&T Labs Research.

Making Current Videochat Technologies Work Better for Your Family

Posted on by
Reply

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

Posted on by
3

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”

Posted on by
4

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.