thesisbeans

Prototyping 3 – Custom Interface Test Run

Last Friday night, I ran yet another prototyping session. This time, we were finally using the custom interface I finished hacking together. The parameters for the prototype were:

  • 2 people total
  • One had never cooked before in his life. Let’s call him “Reluctant Cook.”
  • The other knew his way around the kitchen. Let’s call him “Experienced Cook.”
  • I was not a participant; instead I observed
  • The recipe was Split Pea Soup with Bacon, adapted for the prototype

My three main goals for this prototype were:

  1. To see how well the OpenTok API performs in an actual cooking session
  2. To test the usability of the recipe display and keyboard navigation
  3. To see whether the little step indicator dots add anything to the experience

The Setup

The prototype took place in my kitchen and Reluctant Cook’s kitchen, with me observing “on location” at my kitchen.

There were a few minutes dedicated to upgrading to the latest version of Flash and getting the videos to connect. Then a few more spent finding spots for the laptops that afforded the best views of the kitchen. Video setup and laptop positioning have been recurring themes, but I think this time it took longer due to Flash being uncooperative. Experienced Cook finally settled on the top of the fridge (something he’d surely seen me do from earlier prototypes) and Reluctant Cook followed suit.

Because Reluctant Cook had never seen the interface before, Experienced Cook took a few seconds to explain keyboard navigation. This was quickly understood and accepted.

The Cooking Part

When cooking got underway, I noticed a few things that hadn’t occurred to me before because I had been participating:

  • Talking volume is unnaturally loud in order to get the signal across to the other party, but neither seemed to notice or mind
  • Whenever anyone leaves the frame, it creates some anxiety as you can’t tell where they’ve gone, how long before they return, etc.
  • Interactions (time between question and response for example) seem painfully slow when you are just watching, but again neither party seemed to mind and were mostly focused on just getting their messages across

Cooking went pretty well for the first few minutes. Experienced Cook had taken on the role of instructor and was showing off onion cutting technique, talking about ingredient characteristics etc. At this point, he had moved his laptop to the counter to zoom in on the cutting board. Reluctant Cook was paying close attention during these “demo intervals” and then going back to his work surface to try them out. There was a continual stream of advice and feedback between the two.

About an hour into the prototype, the video quality began to degrade significantly. Frames were freezing, audio was getting lost, and it just became unusable. Cooking came to a standstill. At this point, I intervened and suggested both parties hop on iChat Video Chat. Once they switched, cooking resumed. There seemed to be a sigh of relief on both sides, because compared to the OpenTok video, iChat was blazingly fast. I recall one of them saying “Seamlessness is nice, but image quality is more important.” Agreed!

They made it work with an iChat + custom interface hybrid... the best of both worlds!

Some favorite quotes from throughout the process:

  • “This is actually kinda fun, guys.” -RC
  • “Can I just eat the bacon? It looks so good.” – RC, after frying bacon
  • “First cut your onion in half along the equator.” – EC
  • “Oh god, this smells awesome.” -RC, while chopping onions
  • “I didn’t know what garlic cloves were! I had to bring a friend from work who literally pointed out what all the things were.” – RC
  • “It should smell pretty good” -EC, on putting the onions in the hot pan. “Yeah, it smells AMAZING.” -RC

Total cooking time was about 2-and-a-half hours! By the end, everyone was hungry, but I was impressed that neither party complained that cooking took too long. They seemed to be mostly having fun, talking about other things, goofing off, etc. RC also took time to give me direct feedback on my thesis, which I’ll discuss in my next entry.

The Eating Part

At the end, we served up three bowls of soup, and we all ate together, with Reluctant Cook on the other end of video chat. Here is the view from his end:

Like with Prototype 2, there was that feeling of “togetherness,” although this time we didn’t have Time Zones to contend with. My favorite part?

“Dude, this tastes AWESOME.” – RC

He later explained that he had been sick all week, and had been ordering soup from area restaurants. None of it, though, compared to the soup he had just tasted. (At this point, EC and I were too proud of RC for words. Not bad for a first-time cook!)

Conclusions & Next Steps

The biggest lesson I took away from this is that you do not compromise on video, period. Once video started to freeze and stutter, cooking just stopped dead in its tracks. I had desperately hoped that OpenTok would suffice despite not being the best, because I was so focused on the idea of having a nicely integrated video chat experience. But in doing so, I allowed my optimism to cloud my judgement. That’s a lesson for the ages: sometimes you have to “kill your darling.” My hope is that the platform will get better over time as the technology improves, and then I really can embrace it for this project, but for now, I really do have to look elsewhere.

Fortunately, elsewhere doesn’t seem too far off. The second thing I learned was that coupling my custom interface with another video chat solution worked surprisingly well (Probably because, in this case, both participants were tech-savvy and both happened to be on Macs). Setup was surprisingly quick (actually faster than setting up the Flash for the custom interface…) and the video quality was clearly superior. That in mind, I wonder if I should actively make that the standard way of doing things from here on out? So that, instead of spending any more time trying to include seamlessly integrated video chat embedded right in the interface, I allow participants to use their video chat method of choice?

This probably changes a lot of what I do next. There are new questions to answer, like how to make that dual setup process as smooth as possible? Additionally, this probably means I will not be able to launch this as a fully-functioning alpha product, and instead should position it as an advanced prototype. This is because, in the end, I still think an embedded video chat would offer the best experience, especially to less-techy users who don’t want to fiddle with a second program. But the writing is on the wall: it’s isn’t going to happen, not with my current resources.

Instead, I should take Reluctant Cook’s advice. He said that technology advances so fast these days that video chat is practically a problem that will solve itself. Instead of worrying about that, I should focus on other possible features that would make this a truly compelling product, especially those revolving around the actual topic of food and cooking.

And this brings us nicely to my next entry, which is Reluctant Cook’s feedback… :)

  1. Tina,

    Congratulations on the progress you’ve made so far and being able to kill your darling.

    Please clarify for me, if you end up using iChat or another video chat service, will you have to run your interface separately along side of it? Will the interface for instructions/ingredients communicate between the participants what step they’re currently on or some other info? Namely what will your service provide beyond 2 people cooking remotely and using iChat to see/hear each other?

    Also, as I briefly brought up today, what is the bigger picture of your thesis? You have a very well-defined problem and you not only know what the solution is, but you started building it, What can you explore beyond cooking? Will this innovate communication in general? Is there a way or a plan or even a desire to monetize this service? How will people become aware of it? What are the touchpoints for its participants? Who could you partner with to build it or scale it? (yes, our service design meeting this morning is still fresh in my head!)

    If you’ve gotten this far already, I’m looking forward to what you’ll have in May.

    –Chris

    - Chris Cannon (Nov 15 at 6:55 am)
  2. Nicely done. It must have been satisfying to see your product fulfill its intended goal.

    I do see one barrier in the photos above: how do you prevent water/oil/foodstuff from getting on your laptop? Do you count on users adding to their list of chores, wiping down their laptop whilst washing dishes?

    @Chris, I wonder if Tina needs any conceptual/theoretical/bigger-picture-type backbone to her work. If you had asked me at the beginning of the year, what is the goal of an MFA thesis? I would have unequivocally stated: to contribute to the domain and advance the field. However, part of our DNA, by way of co-chair Steven Heller, is the idea of “Design-as-entrepreneur”; Tina is living up to this mantra in its most unadulterated form. On the other hand, my work is on the other end of the spectrum—there is nothing entrepreneurial about designing futurescapes.

    I do think you’re onto something; Tina, is there something more to the service beyond the web site?

    - Michael Yap (Nov 15 at 7:28 pm)
  3. Hi Tina,
    Exciting project! I think that one of the things you picked up on when discussing video quality is that this has to be an effortless experience, and this point extends beyond video feed. You’re trying to recreate an experience that the user is at least somewhat familiar to your user–and, I think, specifically the sense of closeness that cooking with someone else creates. This is a big task, and probably harder than introducing the user to an existing experience because of the preconceptions they’ll bring to the project of what cooking with someone is supposed to feel like.

    Anything that is awkward, stutters, or otherwise breaks the illusion can disrupt the experience. With that in mind, I would also pay very close attention to where the camera is mounted and focused, how the screen is positioned etc. You’ve obviously come a long way in prototyping the technology. Now I think we can also start to focus on prototyping the environment in which the technology will be deployed.

    - David (Nov 15 at 8:51 pm)
  4. @chris: “Namely what will your service provide beyond 2 people cooking remotely and using iChat to see/hear each other?” -> that is exactly what i will now figure out :) and i think the answers to all those other questions will reveal themselves…

    @michael: i think laptops are becoming more and more of a commonplace object in the kitchen nowadays so it’s not asking too much to bring it in. :) i remember reading on Apartment Therapy’s Kitchn sub-site that many experienced cooks actually consider laptops an indispensable kitchen tool, and have abandoned cookbooks altogether. I think one person wraps hers in Saran wrap to prevent meltdowns, but my sense is that people generally agree the rewards outweigh the risks.

    @david: the environment is a huge issue, especially given the small size of many kitchens and the large size of many laptops. it’s also something i have little-to-no control over, alas. i wonder if a simple way to still ‘design’ the environment is just to offer tips for a better experience, or have a “dressing room” screen to make people more conscientious of where their laptop is placed. people from earlier prototypes did not realize that they should place their laptop somewhere that affords everyone else a good view of their entire kitchen, not just their faces, so the experience was not as good. a “dressing room” screen (like Google+ Hangouts’ “check your hair” screen) could help prevent that.

    - tinabeans (Nov 15 at 9:31 pm)