According to my thesis calendar, this week’s goal was to get as far as I could in building the cooking room interface. Here’s what I’ve worked on:
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!
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)
- 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…
- got the template set up!
- designed the database “schema”!
- figured out how to generate the page dynamically by pulling all the content from the database!
- also, the page is adaptive yo (its contents fit whatever window size you have)
On Thursday, I met up with two of my SVA classmates (and former teammates of Team Awesome): Dave Bellona and Chris Cannon. We wanted to get the band back together to bounce thesis thoughts off one another. This semester so far has been a rather solitary journey, so this session was a much-needed chance to hear some peer feedback and share insights.
My advisor David has suggested that I explore a more drop-in based model so that there’s less of a barrier to just cooking with someone via video. My instinct, however, was that the service needed to be more invitational, at least at first. I would then build in more drop-in features in later releases. I had given some reasons for this instinct, but I still felt I wasn’t getting to the core of it. Thanksfully, Chris and Dave were very helpful in getting me to think through why I’ve chosen to go down the invite-based path, as opposed to the drop-in path. We wrote this down on the whiteboard:
And it all became clear. (Go Team Awesome!) The important part is “curated and exclusive.” But not exclusive in the sense of elitist, rather more the sense that you’re sharing these highly personal, intimate cooking experiences with people that matter to you. And these people are almost always handpicked, not chosen at random. Therefore the invite model makes sense.
Additionally, reviving a thought I had last semester, I want to reframe cooking as an occasion instead of a chore. Because you’re setting aside a bunch of time to do this normally rather mundane thing, I want you to look forward to it, and to not think of it as mundane. When you get a Hotpot invite in your email, I want it to be like receiving a letterpress announcement for an upcoming dinner party, with its accompanying sense of anticipation and delight.
All these things reinforced my decision to build an invite-based system for my prototype. While I’m still very open to the idea of a drop-in feature in future iterations, I think it would be good to focus for now. Feature creep is the bane of getting things done.