But the more I code, the more I’ve come to realize that that there is probably a false dichotomy here. I find that coding, as a brain-requiring activity, is far from the antithesis of design. Nor can it be considered a “non-designerly pursuit” as designers might see it. Instead, I’ve come to see coding as a form of design.

I subscribe to Paul Pangaro’s definition of design as simply making purposeful decisions. And coding, especially in the early stages of a project, feels a lot like just that: you have to do things with intent, you have to be very methodical and critical about why you are doing things a certain way, why you are using x technique instead of y, even down to why you are naming certain variables the way you did. It’s because the decisions you make now will impact what follows—and you also suspect that these things aren’t easy to change later, so you’d better put some good thought behind it.

So, in short, coding does a good job of putting you in a very purpose-driven, very “designerly” frame of mind. When I’m coding, I find myself constantly asking myself things like, “Are you sure you want to call that database collection ‘recipes’? Or maybe we should use a different word because that’s not what the site is about…” Asking these questions gets me to consider possible outcomes, determine strategy, and clarify goals. And the amazing part is, these seem to be the same things that wireframes, userflows, and comps were made to do, too…

The ‘recipe’ database question was actually something I chewed on for a very long time as I stared at my code. And through all the marathon staring sessions, it finally hit me that I do not want to use the word ‘recipe’ at all on the website (that is, unless absolutely necessary, to refer to an actual recipe). Not only are there enough recipe sites on the web already, recipes are really not what the Hotpot experience is about. Rather, it’s about an intimate shared experience with other people, built around food-as-social-object (or rather, food-prep-as-social-process). The recipe, insofar as it’s a standardized, formalized and usually terse set of instructions for getting from point a to point b, misses the point entirely. With Hotpot, it’s not so much about the “How?” of food, as it’s about the “Who with?”

I decided to name that database collection ‘meals’ instead. It connotes togetherness, conversation, shared experience… all those things I strive to create for the users of Hotpot.

Perhaps I could have arrived at the meals-not-recipes conclusion some other way, through more traditional design means like a competitive analysis or through making charts like this. But at the end of the day, I still managed to make that decision, while actualizing that decision in the form of written code too.

That was a pretty simplistic example of code catalyzing design, but there are others too. Like figuring out data hierarchy leading to the idea of capturing and presenting a timeline of cooking memories, similar to the one on Path. Or discrepancies in logic leading to the realization that ‘badges’ (awarded at the end of cooking to an awesome partner) play a fundamentally different role from ‘stamps’ (added during cooking to mark a notable occurrence)—they were originally thought to be the same thing.

Could it be that coding isn’t all just about executing a pre-determined plan, thought up while ‘designing’, but that it actually is a part of the design process? Perhaps this is not the case in big honking companies that believe in employing people just to be code monkeys, but when you’re on a small team of multi-disciplinary members, or you are on a solo project, I think writing code could totally be part of the designer’s toolkit. It’s a great way of coaxing the brain into a sharp, questioning state, so one can be intentional and purposeful with every move; in other words, so one can design.

• 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…

Hardly a week passes in Designerland without this phrase (or some form thereof) being uttered. And yet, I haven’t talked about the target audience for my thesis yet. I haven’t been avoiding the question so much as wondering if it’s possible for an audience to emerge, organically. After all, Facebook was intended for college students; it tapped into the collegiate desire for hallway gossip. Who knew that today, everyone from grandmothers to business directors to taco shops would be using it for essentially the same thing: getting information about other people?

I wonder if the idea of defining your audience too clearly limits you.

That said, it’s still important to have some idea of the type of person who would use an online, video-based social cooking service. So here goes, roughly:

My audience consists of home cooks and friends who have an internet connection and a webcam.

There, I’ve gone ahead and put some (somewhat tautological) limits on my audience, and a rather hard one at that: a technological constraint. Now the big issue that emerges is this: will my audience have to be within a certain socioeconomic class to use this thing I make?

If the answer is yes, I can accept that.

The question of food and cooking as it relates to poverty is complex. It’s not merely about lacking a fully-equipped home computer; it’s about not even having a home kitchen, or heating, or pots and pans to even cook with. And what about the money to buy food? To make choices? What if you live in a food desert and don’t have the mobility to reach slightly further afield for even a fresh head of lettuce? Policy, geography, distribution… those are all things that affect food issues for those who are less well-off. It is far from a simple matter of consumer choice (and by simple, I actually mean difficult-enough-as-it-is). These things would be a whole ‘nother thesis. A whole ‘nother 100 theses, in fact. I am comfortable with not spending this one year tackling those issues, because I have the rest of my life to.

Problem solving requires outlining the problem clearly, and therefore deciding which problems not to solve. For my MFA thesis I’ll tackle the problem of convincing non-cookers to cook, paving a road to more conscientious food consumption habits.

And if that means my audience needs to have webcams, that’s where I’ll start.