Weeknote 3
This weeknote is 3 days late. Oops. And, unsurprisingly, the first thing I have to report is that I am waaaay off my development schedule. Well… about a week off. But it feels like a lot, especially given that everything was so tightly planned to begin with. Aaah!
…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:
- It felt all too tempting to just skip on to the next step.
- 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!
