There were both successes and failures. First, the successes:

• People responded very positively to the playful visual design, including several fully grown men with luxuriant beards. I win!
• People largely understood the core concept and expressed enthusiasm for it.
• For the most part, people had little trouble completing key tasks when asked to: sending an invite, viewing one, responding to one, navigating to a cooking room, etc.
• The code I wrote didn’t completely splatter everywhere as soon as someone tried using it.

But there were some failures, too:

• The biggest failing was that, despite expressing enthusiasm towards the concept (“I want to try this!”), few people actually got as far as sending an invitation, and fewer still made it to the cooking stage. As I soon realized, it’s a lot to expect, but there may also be some flaws in the userflow. I’ll write more about this in the next post, as well as make some guesses as to what needs to be done to fix it.
• One or two people had some confusion over whether the cooking happens concurrently, so I need to be a little more explicit about the “real time” aspect.
• OpenTok sound quality was terrible for the first live cooking session done by independent testers (But to the testers’ credit, they figured out a way around it by just calling each other on the phone while cooking).

There were a host of small bugs too. Those are to be expected, and are relatively easy to fix.

Overall, actually seeing Hotpot live in the real world has been completely eye-opening. As I alluded to in my last post, you just can’t argue with a live prototype. It shows you how things really are, regardless of what you steadfastly believed in design fiction land. The real challenge now is how to interpret and implement changes by the thesis deadline, which is fast approaching. That will be the ultimate game of prioritization.

…Breathe deeply.

Okay. I’ll be okay.

So here’s a quick ‘lil update on my thesis adventures this week:

Advisor meeting

Though I usually meet with David on Fridays, we shifted things around this week to meet on Monday. I got lots of feedback on the cooking room interface. The main thing was that I needed to put more thought into how people were going to approach the little prompts and questions I had written into the recipe. They felt too discursive, not fun enough. Plus asking people to type out all their thoughts mid-sautée seemed a bit of a stretch.

David also re-emphasized the need to get the cooking interface exactly right, as it is the only piece that can exist autonomously and still provide value. Makes sense. So, although my schedule said this week was supposed to be spent on developing the homepage and recipe pages, I decided I would spend more time hacking away at it. That was what I ended up doing all of Thursday through Sunday.

Rethinking parts of the cooking experience…

I’d always known, just from being a cook, that the actions involved in cooking are not evenly distributed across time. There are bouts of frantic prep, scrambling to throw things into the pan before the oil burns, and then there are stretches where you’re just waiting for water to boil or for the quiche to bake. My previous iteration of the recipe instructions took into account these patterns and prompted people to answer questions or jot down notes during periods of low activity.

There were 2 problems with this:

1. It felt all too tempting to just skip on to the next step.
2. As David pointed out, the prompts were kind of boring.

I hit upon one simple way to solve #1: call out these little resting points by making them into their own distinct steps. This would focus the user’s attention on a fun little diversion while they’re waiting around, instead of tempting them to just go out to the next step.

#2 is a much thornier problem, mostly because ‘boring’ is subjective. But I can still take a best stab at avoiding it, because we can all agree that boredom is… boring.

But first I wanted to figure out my goals for adding more interactivity to the cooking interface, so I made a little list and then prioritized them (below, gray stickies). I also wrote down all the litte ideas for “interaction hooks” that have been floating around my brain (below, red stickies). Some of them came from classmates, some from my advisor. I then grouped them by the type of goal they helped achieve.

However some ideas related to more than one goal, so I tried organizing them a different way:

That gave me a better idea of which ideas worked best for achieving my goals. Finally, I weeded out the ideas that seemed weakest, and put the remainder in order based on completely unscientific reasoning. But reasons, nonetheless.

Now I have little bit more clarity about what I’m to do. Obviously I can’t implement all or even half of these ideas. But now I have a list I can refer to when I’m stuck going around in circles about what to implement.

I don’t feel as if I’ve reached a point of Exactly Right-ness yet, but I’m certainly glad I spent more time and thought on it. Perhaps I’ll never get it exactly Exactly Right through designing and redesigning it. So I need to just finish it up at some point, then get it out there to some real people.

Socket.io!

This is fairly exciting: I got Socket.io working this week! It required some fancy server architecting and adding another server, Tornado, on top of Flask. Now my tech stack is even taller and stacky-er. Thanks to my unofficial coding mentor (and boyfriend extraordinare) Yang Yang for helping me with the stackiness. It basically blew my mind.

Some background info: Socket.io is a real-time communication library that uses a protocol called websockets. Unlike HTTP, websockets allows the server to push info to the client without the client speficially asking for it. What that means, in plain English, is I can create custom real-time interactions for the cooking rooms beyond the video screen. Woohoo!

With that, I quickly got text chat and the recipe step indicators out of the way, as they are fairly uncontroversial and useful features to have.

Then I spent the entire weekend playing around with ways of adding badges and cooking notes. I didn’t do wireframes, just quick pencil sketches followed by code (I guess I just like sketching in code better than in pictures?). As of 5am this morning, I got cooking notes up and running, but I’m not totally satisfied with the visual layout of it yet… need to work on it more. Badges are on the way.

Interface tinkering…

Last week, I had felt unsatisfied with the placement of the ingredient pane. It covered up the recipe text awkwardly and I felt that it really wasn’t needed. After careful thought, I decided to make a judgement call. I would make the ingredients into a step—the first step of the recipe. And I would remove the need to return to it throughout cooking by repeating the ingredients and their amounts in the steps where they’re needed. This felt much more fluid.

All this made me realize that I’m not really writing a recipe anymore… I’m writing a script. It’s linear and directed, and there is a greater degree of handholding. But that’s okay if I want my audience to feel comfortable cooking for the first time. As for the advanced cooks who want to tweak and deviate from the prescribed path, they can still do that and even mark out their decisions in the cooking notes. A recipe is always just a suggestion. But here, it’s also a guided tour.

 Team Awesome meeting 2

Feedback this week also focused on the cooking interface. It addressed mostly ways in which I could add value. One suggestion was allowing users to tweak the recipe on-the-fly and then, at the end of cooking, compare it to their partner’s version to see how they cooked it differently. Also, during the critique, my classmate Cooper Smith (newest member of Team Awesome) observed that I seem to be limiting myself design-wise by considering the technical constraints too much. This warranted a lot of thought, which might go in another blog entry someday.

That’s about it for week 3. Whew, I need to write shorter weeknotes!

Tips for Success:

• Resist the urge to accept feedback, no matter how respectable the source, without first understanding how it relates to your goal.
• Resist the urge to brainstorm quick solutions while receiving feedback. This is essentially doing the above.
• Unless the feedback totally and definitively invalidates your goal, never change your goal to adapt to the feedback. That’s backwards.
• Always have a good reason for everything you decide.

Disclaimer: Instructions are based on the personal experiences of a 25-year-old grad student only. Not backed by scientific studies or certified Kosher. Batteries not included. Revisions welcome.

Further Reading: Feedback and the Creative Process by Cassie McDaniel

Recipes!

Over the weekend, I found 3 lovely recipes that I want to use in this first prototype. I chose them because they’re simple, seasonal, healthy and relatively quick—perfect for someone who’s new to cooking, but also creative enough for a more seasoned cook.

I still need to contact the creators of the recipes to get permission to use them, but for now tentatively, they are: Lemon Garlic Kale Pasta, Tuscan White Beans with Spinach, Shrimp and Feta, and Apple Cheddar Quiche. (If any of the original authors are reading this, would you be willing to donate your recipe to a Master’s Thesis prototype? Credit will be given, of course!)

The first thing I did with these recipes was rewrite them to fit the prototype. I split up all the steps into smaller discrete actions so it would be easier for multiple cooks to follow along. I changed the ingredients list so that it more resembled a shopping list, moving the implied prep to the steps. For instance, “1 cup chopped onion” became “1 onion” and the chopping became part of step 1. 

I also added “Foodnotes” which are little prompts that invite you to pause and savor the experience of cooking, and “Protips” which are handy hints to help more novice cooks with some of the trickier steps. The idea for these came out of Clint’s feedback last semester. I’m hoping these two things will also inspire conversation about the food at hand. Perhaps participants can exchange their own protips, or come up with evocative ways to describe the aromas before them. Who knows!

Technology Stack!

Here is the final technology stack I’ve settled on for the backend:

• Python (that’s the computer language I’m writing everything in)
• Flask (a super-lightweight Python web framework)
• MongoDB (a non-relational database that stores everything as in Javascript Object Notation, a.k.a. JSON)
• Jinja (a Python templating engine that works with Flask, used for creating HTML templates)

Additionally, I’ll be using the OpenTok API to handle video streams.

Whew! It’s a lot of proper nouns. Admittedly, it’s a little overwhelming at first to learn all of them. They all have separate sets of documentation, and even just settling on which ones to use can be a bit of an ordeal. But once you get everything set up, it’s surprisingly smooth to work with all of them. And what’s nice about web development now as opposed to 10 years ago is that 1) You have options beyond PHP and 2) helpful frameworks and libraries galore!

As for the frontend, there are some neat tools I’m using which are worth a mention:

• SASS (which is way to write CSS but with a more powerful syntax)
• Compass (built on top of SASS, it’s a CSS framework that lets you quickly generate cross-vendor CSS rules with one line of code, among other neat things)
• and of course, the wonderful JQuery

As part of the getting-started process, there’s inevitably an hour or two spent putting everything in place. I set up a Github account to host my code. Despite initial fears about people laughing at my newbie-code (it’s okay, you can laugh—laughter is healthy ), I’ve decided to keep it open-source. You can see the project in progress here!

Cooking Room Interface!

Okay! Here’s a sneak-peek at what it currently looks like:

Still got lots of kinks to work out, like:

• the chat isn’t functional… yet
• I dislike where the ingredients panel lives—it covers the recipe steps when it’s open
• still figuring out how a user’s response to a Foodnote gets processed by the server and displayed back on the page… some AJAX magic has to happen, but there are Mysterious Bugs holding me back…

In the weeks that followed, I had a chance to think long and hard about this. I also had some really good conversations with my thesis group leader, David Womack. He said the following:

The magic for me is being able to meet strangers and share this really intimate experience of cooking together. I would want to automatically be able to find cooking buddies based on foods I like, things we have in common, etc.

Thinking back to the story of Vera and Fred, my idealized cooking buddies, this is exactly the hope I inadvertently expressed in this story. This project is not just about the act of cooking together in real time. It’s about who you’re doing it with: whether it’s a friend who lives far away or a stranger you form a connection with, it’s the people who make it so compelling.

A fellow student, Kristin Breivik, also disagreed to some extent with Paul’s assessment. She says:

There is so much around [the cooking experience] to even get people to go to the cooking part. You need to get people excited from the very beginning. and once people get to cooking, it might not even matter if the technology sucks.

She brought up a good point, because I realized that when Clint and Yang prototyped together, Clint was adamant that we actually cook despite initial technology troubles on both ends. This may have had to do with all the built up anticipation, prep and “framing” I had done beforehand to get him excited. So even though conditions weren’t ideal, they persisted and found a way to make it work, and the reward was an incredibly satisfying experience for both of them. Clint, reluctant cook that he is, was even enthusiastic about doing it again. And again I think the fascination was in the interaction with Yang, another human being, not with the “cool” technology that made it all happen.

Of course, this doesn’t mean I should completely disregard the technology driving the cooking experience, but I think it’s clear by now that it doesn’t have to be my one and only obsession. In any case, now I think it’s time to gather together all I’ve learned into one big ball and roll it out the door.

Which means: this week, I will be making wireframes! Stay tuned!

I recall back in October, I had described my thesis idea to him and he said it would be a miracle if it could get him to cook. Now it’s November and he has officially cooked! Not only had he cooked, he enjoyed himself! So this first bit of feedback is very encouraging and gives me even more momentum to push forward. But there is a lot of work ahead, too:

Clint noted that one of the reasons this worked so well was that he happened to be cooking with someone with endless reserves of patience. Because he was a first-time cook, he had to be walked through the recipe step by step. He wondered if other, more experienced cooks might get impatient or bored. Is there something I could design so that people with different experience levels can all have fun and not get bored? Or would the inherent sociality of the experience ensure fun, no matter what? It would be good to test this out with more prototypes where there is that student-teacher dynamic.

He also noted opportunities to incorporate more “mindfulness prompts” into the experience. For example, on a certain step, text could appear saying “Now smell the onions as they are frying—doesn’t that smell great?” Perhaps people could tag steps with certain sensory words as they go through. All this would allow everyone to enjoy cooking as a sensory experience, rather than just the tedious following of instructions.

The language of the recipe itself could be tweaked a bit, too. I had used the standard, rather terse and formal-sounding recipe language, albeit lightly reconfigured for maximum helpfulness for novice cooks. Clint pointed out that it’s pretty soulless, and could be pushed even more to sound like it has a personality. It could even include reasons for why a certain step is what it is: “Now you are adding chicken broth to start turning this into soup.”

There is also the possibility of a metaphor for the entire interaction: “everyone throwing their ingredients in the same pot.” This could give rise to a special visual treatment of the interface, or influence the service’s content/features.

At some point, the conversation turned to game mechanics and badges. Clint’s reaction initially was one of guardedness, as we all know what empty meaningless gamification looks like (and it ain’t pretty). But in this case, if the badges could actually stand for something meaningful, it could be super gratifying for the user. We discussed the possibility of awarding badges every time you have a cooking session, so what they represent—good times with friends—would give them positive meaning. Also, the idea of letting friends award one another badges (“World’s Most Patient Teacher,” “First Time Cook,” “Master of Bacon”) could be lots of fun.

He concluded his feedback with advice to focus on the aesthetic layer and the charm, not the technology. “Technology will catch up; don’t worry about the video quality too much.” And I think this is true. Part of what made the evening so fun and engaging was that cooking is actually a very charming activity when done with friends. I definitely need to focus on what would enhance this quality more.

Whew. A lot to chew on. So to speak.

In any case, all this feedback made me realize that I had gotten very caught up in the technical implementation of things for the past few weeks, and now it’s time to zoom back out again and reconsider the reasons and meanings behind what I’m doing. What value am I creating, really, beyond just a suggestion for a new way to use video chat? How can I take it to new places?