And in addition to coding these past few weeks, I’ve also jumped back into… visual design! Yup, turns out I still get to exercise my design chops, after all.

My handy dandy development calendar tells me that it is now the end of March, when I’m supposed to be launching my prototoype to a small group of trusted test users. Actually, that was supposed to happen today. You can probably tell from the lack of fanfare round these parts that this has not happened.

It has not happened because the prototype is not ready; by my own estimation, I am about a week behind. (Considering the nature of software development, it’s a small miracle that I’m only a week behind. But I shouldn’t let myself hear such things. Shhh.) Because there are still a bunch of things to iron out, such as last-minute bugs and interface styling, I’m giving myself this one extra week to, as they say in higher education, haul ass.

This pegs the final, decisive, non-tentative prototype launch date at next Monday, April 2, 2012.

(I really would have loved to have it happen on April Fool’s Day, but I’m going to really need those extra 24 hours.)

So what have I been up to in Weeks 7 and 8?

Github tells a good story:

That would have been an even longer image had I been a good developer and committed more often…

Code aside, I’ve also been busy turning things like this:

Into this:

There are more redesigned pages, but to be perfectly honest, I’d rather be working on the rest of the things on my to-do list:

… than taking more screenshots to post here.  Because if all goes well, in a mere seven days, any able-bodied and willing person will be able sign up to be a test user and see them not as screenshots but as an actual, working site!

And with that, I’m off to make sure that this actual working site has a good chance of coming into existence.

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.

This has proven somewhat difficult, being a designer and whatnot, but it’s necessary. All too often I get the temptation to work on all things at once: front-end, back-end, UX, branding, content, etc. I guess, in some ways, this could turn out more efficient, kinda like a product team with extraordinarily awesome communication & coordination skills. (Good to know I am great at talking to myself.) The downside is that my sanity takes a hit. Being 10 people at once is fun, until it starts keeping you up at night. (Can’t sleep… keep hearing voices in my head… and it sounds like a product manager arguing with the UX lead.)

So. I’m coding back-end, which means parts of Hotpot look like this right now:

Beautiful, isn't it?

I just have to keep telling myself it will all get done in due time. And using Trello to keep the other members of my one-person product team at bay.

Trello is awesome.

The time for Deep Pondering is over, and implementation is in full swing!

This week is spring break, and I’m spending every day coding as fast as I can. Pieces are are coming together: creating invitations, replying to invitations, user accounts & profiles, viewing and selecting recipes, joining cooking rooms, and a snazzy new homepage! The goal is to get as close as I can to a finished MVP by the end of the week. Then next week will be applying the final polish, fixing bugs, and general developmental housekeeping.

And, with all luck, we will have a funky little working prototype to play with in late March!

I am excited, but let’s use all that excited energy to get coding, shall we?

So, back to work I go!

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

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…

OpenTok Redux!

I had a realization: if I limit the # of participants in a cooking session to 2 in the prototype, then I can utilize OpenTok’s P2P technology, which means faster streaming and high quality. Would this be as good as Google+ or iChat? I put this to the test. The answer, for now, seems to be a tentative yes. The picture quality was good with a ~1 second delay, comparable to Google+ Hangouts. I also used Speedtest.net to note my connection speeds, and compared them to the other times I ran cooking prototypes with Google+ Hangouts— they were the same.

So… is it worth it to limit participants to two for the prototype? I decided, yes. In fact the experience seems to be way better when fewer people are in the cooking session. Even three feels a tad awkward because there is a slight feeling of “third-wheel-ness” and five borders on chaotic, though fun. Besides, all you need is two people to understand the point of what I’m trying to build.

This means, for the time being, I can consider OpenTok my video platform of choice for the prototype. Which means I don’t have to come up with some convoluted strategy for getting people to run both Hotpot and another video chat service at the same time. Hooray!

Diagrams!

Last week, I went to Staples with the intention of buying a $1 pack of notecards, and returned with $30 worth of Stickies. Oops.

What resulted was this:

User stories

And this:

user flow + wireframes = wireflows!

Having everything laid out on a wall was incredibly helpful in organizing my thoughts and making the task at hand seem finite. Of course, there were still millions of details to be worked out. But now things can at least proceed in an orderly fashion, one hopes.

Wireframes!

The next step was to turn the thumbnail Sticky note wireframes into higher-resolution digital wireframes. I downloaded Balsamiq Mockups, which is a tool that’s “so freaking good” (claims the site, accurately) for rapid-sketching wireframes on the computer. Its imprecise, hand-drawn lines resist efforts to obsess about things that don’t matter, like making everything line up perfectly.

I then mocked up each page, one at a time. Here are some wireframes for the “room” that people will cook together in:

Once I had all the pages in my userflow mocked up, I was ready to start coding again. This time, I admit, I felt less frantic and more sure of what I was doing as I sat down to the keyboard.

Advisor Meeting!

The thing that stood out to me from the meeting was David’s warning to not spend too much time working on the parts of the project that aren’t unique or innovative. For instance, coding a login/user registration system. So the challenge for me going forward is balancing my desire to learn how these things work (i.e. build them from scratch myself) and not letting that get in the way of thinking about more interesting, interaction design-y things. Something to keep in mind.

I started diagramming conversations:

… and imagining what a good user profile for cooking would be:

… and even started coding a rudimentary profile creation page (unstyled, beware):

The undercurrent to all of this was a certain antsyness to just get something out there. I really wanted to give my potential audience something to do as I worked to get things ready. I was thinking back to the advice our department chair Liz had given me in the Fall semester: don’t put up a LaunchRock-esque “coming soon” page—give your users something to engage in right away, rather than just a newsletter signup field. This made sense, and after giving it some thought, I decided the thing I would allow new users to do was to establish an account and fill out a personal profile. That way they can start checking out the other people on the site. And when the site launches, they’ll already have friends on the service who they can cook with right away.

But as I got closer and closer to actually putting up a page where people could sign up to fill out a profile, I got embroiled in this tangle of worries: privacy issues, community building, setting the tone, communicating with users, how to position the project… And that’s when I posted my last entry. I was getting carried away by all that needed to be considered and studied and worked out and made.

Eventually I took a deep breath and realized: I was confusing where I wanted to be with how to get there.

Meaning, I want my thesis to be so many things so quickly that I wanted to jump right to where I wanted to be, but in doing so was ignoring all the foundations I had to build to make it there!

So I got out an empty page and wrote this on it:

That really puts things into perspective.

Looking at the first sentence, I now realize that Paul Pangaro’s advice about where the core of my project lies is still right on: the real-time cooking part. Even though eventually I want the project to answer all these other challenges like getting strangers to meet, facilitating culinary exploration, etc, those things all fall under the phrase “in the process.” This means they would result from, but definitely not exist without, this concept of cooking together in real-time. When all is said and done, I still have to work out the conceptual core first.

So I’ll back up, take a deep breath, and start in the center. Then slowly, one ring at a time, work my way out. And the entire time, I’ll keep the big picture in mind:

Here’s the new plan: In the coming weeks, I will be focusing on building rings 1 and 2, getting it working, and getting people to try that out. And if all goes well, I can begin to mockup and prototype rings 3 and 4. However, if I run out of time to build out the entire circle, that’s okay too. At least I’ll have a solid foundation built and working! Besides, who says one’s thesis project needs to end in when you graduate?

Server-side programming… now why would a designer ever want to learn that? True, the likelihood of this ever becoming a selling point on my resumé is rather slim. For me, it just comes down to the fact that I want to know how things work under the hood. And I have 6 more months in school. As long as I’m here, I’m going to learn as much as I can without having to give a good reason for it. Ha!

So on that note, I installed Flask, a Python web micro-framework, on my web server. Python is a super awesome, easy-to-learn programming language. It runs on computers installed with an interpreter (a program that runs code you write), and you can build desktop apps this way. But on the web, you need an extra layer of code to handle HTTP requests (the dominant protocol that entities on the web communicate with) so you can do things like serve up pages to a browser—that’s where this framework comes in. In the case of Flask, it’s designed to be very lightweight and easy-to-use, hence the “micro.” (If none of this makes sense to you, you can ignore this paragraph. I am mostly explaining things back to myself to make sure I understand stuff. )

Anyway, I still mostly have no idea what’s going on (my plan for learning so far involves reading things on the internet, especially Flask documentation), but so far I have learned how to create a system for letting the other participants know what step you are currently on. Basically it works like this: every time you switch to a new step, the webpage sends that info to the server, and the other participants’ webpages grab that info from the server. Then Javascript (jQuery) is used to position your colored dot next to the correct step on their screens. Here’s what that looks like:

Lines 29-48 do the voodoo

Just kidding. Here’s what that actually looks like:

Woo hoo, it works! Here, both "I" and my cooking buddy are on step 1; my cooking buddy is represented by a green dot.

Exciting, eh? Yeah, I thought so too.

At this point in the game, I’m definitely feeling a bit overwhelmed. I’ll be both coding and designing and testing (and doing homework) at the same time! Aaaahh! Some part of me says this is pure insanity and I should just hire a developer. Some other part of me says to ignore that voice and go forth and do it and everything will be okay.

You can probably guess which part I will end up listening to.

Some background: the experience I’m trying to create is online cooking with friends. The core of this is high-quality, browser-based video chat—essentially, something like Google+ Hangouts. However, I want to build a custom site and interface. Unfortunately, the Google+ Hangouts API is too limiting, so I turned to other solutions.

This weekend, I’ve been playing around with a free API called OpenTok (http://tokbox.com/) which is basically what I want: a flexible and easy way to embed real-time video chats into a webpage. However, after testing all weekend, I’ve noticed that it has 1-2 seconds more lag than Hangouts. Those precious few seconds are the difference between an almost naturalistic video chat experience and a socially awkward, far less usable one.

Because of this, I’m also open to the idea of alternatives. If you have any suggestions, please send them my way! Ideally, the video chat provider will:

• be browser-based (because I like the open platform that is the web)
• be relatively low-cost (~ $50/month), freemium, or free
• have the best video/audio quality and speed possible