What I Want in a Recipe Blogging Platform

After spending years subsisting on the food from Google cafes and fast food restaurants, I finally got into cooking my own meals - and I can't believe I didn't discover the joys of cooking before. Right now, I'm mostly following other people's recipes from their personal blogs (which I've aggregated in this portal), but I've started to experiment with my own variations and concoctions as well. Both to share my newfound love of cooking and to document my experiments, I decided I should start my own food-centered blog.

Before I could start my blog though, I had to pick a blogging platform. Given the number of food bloggers out there, I assumed there'd be one platform that stood above the rest and was the go-to for food bloggers - but alas, there wasn't. Of the 100 blogs that I subscribe to, 52 use WordPress (either .com or .org version), 34 use Blogger, 1 uses Tumblr, 1 uses Posterous, and the rest are custom built sites. Of those platforms, the only one that offers any food-related functionality would be a WordPress.org installation with recipe-related plugins, but given that a Wordpress install involves money and technical knowledge, it's unlikely that many of these amateur recipe bloggers would be using that.

Instead, each of these bloggers start with a generic blogging platform and do their best to munge it into a recipe blogging platform. Some get quite far, some not at all, and many end up somewhere in the middle. It's not a good situation for recipe bloggers - they have to spend time re-inventing the wheel when they could be spending that time making delicious food - and it's not a good situation for their readers- they must struggle to make sense of the different user experience on each recipe blog.

This is why I think the web needs a recipe blogging platform. Based on my experience as both a consumer and producer of recipe blogs, here are the features that I would want:

• Recipe Index: The traditional way to browse a blog is to scroll through the most recent 10 posts, click, scroll through next 10, and so on. This is a bad way to browse recipes. Instead, users want to see a recipe index, typically broken down by meal types, like this one (which includes a legend) or this one (which includes photos). The platform should auto-update the index every time an author posted a new recipe, and the categorization would be based on post tags.
• Recipe Microformats: Google now shows some recipe results using "rich snippets", based on microformats or microdata that it finds in the HTML when it crawls. Many big sites have adopted these formats, since it's easy to apply across their database-generated recipe pages, but most amateur bloggers don't have the technical know-how or the time to work out the HTML each time. The platform should include a widget (like this Chrome extension) for inserting a recipe with structured information, and make sure it adheres to the SEO best practices.
• Printable recipes: It seems like a simple thing, but across all the blogs, I see readers constantly asking for an easy way to print just the recipe in a post, so they can sit it next to their stove while they cook. The platform should stick a "print" button on each post that formats it cookbook-style.
• Recommended Cookbooks/Gear: Some recipe bloggers include a page or link to an Amazon store with their favorite cookbooks or kitchen accessories. It's a great way for them to share what they themselves use, and to make a bit of extra revenue off their hobby. The platform should faciliate that.
• E-Book Generation: Once a recipe blogger builds up a sizeable collection of recipes and readers, they might want to generate an e-book of their recipes, like the reader-created cookbooks from Mark's Daily Apple and they may want to monetize off that e-book. For whatever reason, people will pay for the same content that's available online for free when it's in an e-book form, presumably because it's easier to consume or appears more professional, and if people will pay, then recipe bloggers should be able to take advantage of that. The platform should have a way of generating e-books (or even real books) and making it easy to purchase them, perhaps through Lulu.
• Food-related Themes: As we've learnt on the web, everyone likes to theme their web presence. When I searched on both Tumblr and Blogger, I found close to 0 food themes, and had to go for the "nature-y" themes instead. A recipe platform should be filled with themes that make your mouth water and fills you with dreams of bacon fairies.
• Step-by-step Photos: Many recipe bloggers include photos that show each step of a recipe, in addition to the final result, like in this recipe. The platform should make it easy to include these in the formatted recipe wizard and it could provide a slideshow-like view of the recipe, similar to what's offered on instructables.com.

The platform could also do more in terms of community - making it easy for readers to find other blogs they might like, making it easy for people to comment on recipe posts with links to their own variation, and perhaps bringing in ratings & reviews for the recipes.

This platform could either be a brand new platform, or it could be a bundle of recipe-blogging tools that can complement existing blogging platforms. A brand new platform would have more flexibility in its functionality, but it would also need to re-create the functionality already mastered by existing platforms and it would need to offer migration tools, whereas a set of complementary tools could start being used today by existing and new recipe bloggers. The best thing could be a hybrid of both options.

Since recipe bloggers at least start off as hobbyists (and many remain that way), such a platform or set of tools should start off as free or affordable, and offer premium features (like the e-book generation) for the more invested bloggers.

I'm a web developer myself, so I could go ahead and make this platform tomorrow, but I'm not sure it's what I want to spend all my time on and I think it deserves to be worked on by a fully invested team for a good amount of time. You can't just throw a blogging platform out into the world, abandon it, and expect it to flourish. A blogging platform is all about the users, and when you create a webapp that is user-powered, you need to spend time listening to your users, improving it to better meet their needs, and growing the user base.

So why have I written this post? I'm hoping that either 1) someone is already working on this and will take my feedback into account, 2) someone will be inspired to make this their baby, 3) someone will tell me this already exists. Now, I'm going to sit back and wait for one of those three to happen...and maybe cook some recipes in the meantime. :)

The Developer Support Handbook (aka How I Did My Job)

When I started at Google, I was among the first handful of people in the Developer Relations team (then called "Developer Operations"). We were new to this area at Google, but I'd say that the whole tech world was fairly new to it as well. Web APIs were just becoming a big thing, and web companies were just learning about how to support and grow the diverse community of developers using their APIs. We didn't have much of a precedent about how to do our job, so we made stuff up along the way and iterated on whatever worked. There is still experimentation going on, but much of how Google works with developers today is based on learnings from those early times (where "early" equals a mere 4 years ago - the web world moves at a rather fast pace).

As I once said on Twitter, my personal policy is to "document the f*k out of everything." I like to document things - particularly processes - both because I am forgetful and like to have a reference to remind myself how to do things, and because I am a huge believer in sharing knowledge. When you share your knowledge with the world, you potentially make someone else's life easier and you also make sure that you're not the single point-of-failure for that knowledge.

So, a few years ago, I started documenting (nearly) everything that I had learnt in doing developer support at Google, figuring that both future colleagues and even non-Googlers might be interested in the learnings. As it turns out, there was a lot in my head that I wanted to get onto paper, and the documentation turned into a multi-chapter, multi-section affair, covering topics like documentation, forum support, issue tracking, communication, and nurturing top developers. You can read it all online at developer-support-handbook.org, and if you want, you can even check out its RST source and build it using Sphinx.

I am not particularly proud of the handbook as a writing piece - I had never written anything so long before, and I found it quite difficult to keep a consistent voice and format, and to present the information succinctly. But, I do think the handbook does a good job of showing what "developer support" really entails, and gives you an idea for the kind of debates you'd face in such a role. If you only read one part of it, please read the introduction, as it outlines the guiding principles behind the recommendations in the handbook, and behind the way I did my job. (Hint: The #1 principle is to care about your developers. :)

I have since moved on from developer relations at Google, but as a developer myself, I still care deeply about how companies treat their developers and I hope to see more people talking about what it means to have well-designed APIs and to support thriving developer ecosystems. For example, Christian Heilmann put together the fantastic Developer Evangelist handbook during his time at Yahoo!, and it covers how to write great code samples and give great talks. I hope to see more writing, talks, and even conferences happening in this area in the future. Developer Relations is a tricky mix of communication and technology, and it deserves a closer look.

Sightseeing in Sydney: What to See, Eat, Drink, and Yell

When I used to live in Sydney (way back 1 month ago), I often gave sightseeing tips to visiting Googlers, and I figured I'd share some of them here:

• Visit the aquarium: There are lots of weird Aussie animals, like dugongs, sidenecked turtles, and platypi. It's a good option for a rainy day.
• Go "gold class" at the movie theater: It's a pricier ticket to sit in a special theater with a small number of plush throne-like seats and waiters that bring you drinks and snacks. It makes you feel damn special.
• Take walks: You must do the classic Bondi to Coogee walk (watch out for the cemetary on the way, & skim the waters for dolphins). But there are tons more cool walks to do around the rather long and windy coast of Sydney. I recommend taking the ferry up to Watson's Bay and following this path. It takes you past the suicide cliff, then winds through an eerie forest with huge spiders, and ends up at a cute little beach.
• Taste wine: I didn't like wine before coming to Australia, but after being properly introduced to it by the Aussies, I now love it. You should try wines in the restaurants, but you should also tour wineries. From Sydney, it is a short trip to Hunter Valley for some pretty good wines. I took this van tour with a few friends.
• Eat at the Sydney fish market: Go in the morning or at lunch, order some oysters and raw fish, and eat it outside. Warning: you must defend your food against the seagulls. They are fierce.
• Try traditional "Aussie" foods: eat something made out of kangaroo (like a burger, which is fairly common), eat wedges with sour cream & sweet chili sauce (at any pub), tim-tams (if you like sweets), oysters, and savory pies with mash and peas (most famously served at Harry's Cafe de Wheels).

Oh, and my final tip? When you see a drunk Aussie walking down the street, yell "Aussie, Aussie, Aussie" at him (pronounced "Ozzie, ozzie, ozzie"). If he's a proper Aussie, he'll respond back with a raucous "Oy, oy, oy." Works nearly every time, and it always cracks me up.

StartupBus: What I Learnt & What I Loved

I've participated & organized in many different programming events over the years, but nothing as crazy as StartupBus, an idea dreamed up by Aussie Elias Bizannes (who I met at StartupCamp, a similar event). Across the country on March 8th, a mix of developers, designers, & business dev'ers boarded buses headed to Austin, Texas. We pitched ideas on the morning of the first day, formed teams over lunch, and spent the next two days coming up with a prototype. When we arrived in Austin, just in time for the start of SXSW interactive, selected teams got to pitch their startups at the semi-finals (our team SpeakerMeter made it there!) and the finals (but not there), hoping to interest VCs in the potential success of their startups.

It was an incredible learning experience to be a part of StartupBus, and a great way to enjoy a different side of SXSW.

What I Learnt:

• It's good to go slow.

  When you say "make a startup in 48 hours", the typical reaction is "wow, that's not much time." But actually, we're really only coding the prototype, and most programming events these days are shorter than that. When you're not worried about fully working functionality or doing things "the right way", you can actually build quite a lot of functionality in that amount of time.

  So, in fact, I felt like we were going at a much more relaxed pace on the StartupBus than at typical hackathons, and I appreciated that pace. It gave us time to actually think about what we were doing, time to debate the business plan, time to have long discussions with Xero's designer Philip about the idea, and time to completely revise the interface after that discussion. It also gave us time to take more leisurely meals, where we could get to know eachother more. (Remember: we were strangers, and now we were people spending 3 days squished next to eachother on a bus. Bonding's a good thing.)

• It is difficult to make webapps without a good internet connection - for more reasons than you'd think.

  I knew that we'd be driving through uninhabited desert for most of the trip with questionable WIFI, so I tried not to propose a startups that would be too reliant on internet resources - but that's hard to do, there are few web startups these day that don't build on existing data and services. Our startup brought in Twitter and SXSW data, so we had to test that functionality at high connectivity times.

  But I realized that I use the internet for much more than just connecting code to external websites when I'm building a webapp - I use it extensively for documentation and for problem-solving. Normally, a framework question can be answered in just a few minutes with a Google search, but with flaky wifi, that seemingly quick process can take minutes on end. If I was doing this next year, I'd download all possible framework documentation to disk, and maybe also download all of stackoverflow. :)

• Market research - even the most unscientific & untargeted - can be damn useful.

When we stopped by in Santa Monica, the conductors gave us a challenge: walk around the streets and record video of at least three market research interviews with strangers. This admittedly freaked me out; I am quite shy by nature and hate to impose myself on other people - approaching strangers to ask them questions is the epitome of what I am afraid of doing. But, it's a part of the startup experience, so I grabbed my more balls-y teammate and hit the streets.

We had multiple folks turn our requests for an interview done, but we actually had just as many people stop and chat to us for several minutes. They were all university students (I guess they're all happy for an excuse to postpone doing assignments), so they were not a diverse market segment or even our target market segment, but they still gave us great insight into the design and intent of our startup. In fact, if I'd really listened closely to them, I might have pivoted the startup into an entirely university-oriented one - but I stuck with the original goal of solving my own problem, not theirs.

Now that I see the utility of just a bit of market research, I'm working on a survey to send out to our target market, and we're going to use the results of that survey to figure out our next steps. (Yes, I'm still working on our startup idea, as one of my numerous side projects.)

• There is a difference between making a webapp and making a startup.

  I love making webapps - it's so easy these days to create something out of nothing (well, where nothing = existing libraries, frameworks, and APIs), and it's easy to share your creation with the world. But a webapp alone is not a startup. A startup is a team of people trying to make a product (often a webapp) that will gain users & be profitable in some way - and those last two parts are not trivial. So we didn't just spend time on the bus coding, we also spent time marketing (tweeting & blogging), doing the market research, coming up with a business plan, and drafting our pitch.

  In retrospect, we probably could have done more of the startup stuff and less of the coding, and been more successful in terms of our visibility. It's easy for anyone to make a webapp, but it's hard for webapps to gain users that they can then be profitable from, and StartupBus is a great opportunity for potentially useful webapps to gain press and users as a result.

  I went on StartupBus partially to figure out if I want to enter the startup world, or if I am content to stay in the webapp world. I still haven't quite figured that out, but at least I'm very aware that there is a difference between them.

What I Loved:

• I am now a part of the StartupBus community - and hopefully always will be.

  The StartupBus founder, Elias, always likes to say that StartupBus is not so much about the actual startups made, but about the community that forms as result. The 3 days on the bus and 5 days at SXSW are an excuse for like-minded hackers & entepreneurs to get to know eachother over a common experience. At SXSW, even if I didn't technically know someone, I knew I could approach them if they were wearing their StartupBus badge. Now, going forward, we feel comfortable approaching each other for business advice, for a place to crash during other tech events, for co-founder possibilities, and of course, just for hanging out.

  Regardless of what I decide about the startup world, it's great to be a part of this incredibly passionate & intelligent community.

Similarity Web 2.0: Remaking My First Mashup, 5 Years Later

One fateful summer five years ago, I accidentally stumbled upon the world of Web APIs - starting with the Amazon E-Commerce API. I was supposed to be working on a research project, but I couldn't resist the potential of the API. Amazon's catalog & functionality at my fingertips? And I could do whatever I wanted with it? I just had to play with it.

So I made my very first mashup: the Similarity Web. It's an app that uses the Amazon ItemLookup & SimilarityLookup API calls to let you find a book & visualize the web of books similar to it. It was a fun little app, and it even made me some money in referrals - especially after marketing guru Seth Godin linked to the "Purple Cow" web in his blog. Unfortunately, as it happens, Amazon deprecated the version of the ECS API that I was using, and the app stopped working. It's been on my to-do list for the last few years to revive it.

Well, thanks to my former employer, I found an excuse to do just that. Google is holding a contest for free I/O tickets, and a few Fridays ago, they held the App Engine contest. After I made it through Round 1 (deploying a Fibonacci JSON-RPC service), I was presented with the Round II challenge: make an app that uses one of their more advanced APIs - blobstore, task queue, pipeline, mapper. I knew that I could use task queues in a couple different ways in Similarity Web, so at 5pm on that Friday, I started remaking it from scratch and at noon on Saturday, I submitted the fully functional remake.

Much has changed in web development in the last 5 years - both in what I personally use and what the world uses - so I thought it'd be interesting to compare the technology stack for each version of the Similarity Web.

Hosting	LiquidWeb (shared hosting)	App Engine
Backend Language	PHP	Python
Amazon API	Raw HTTP calls	Bottlenose wrapper library
Data Storage	Filesystem	Non-relational Datastore
Data Format	XML	JSON
Frontend Language	Pure JS	JS + jQuery
Visualization	Flash (AS2)	JavaScript InfoVis Toolkit

The general trend? The app is built on more scalable infrastructure, more web-friendly formats and standards, and more pre-existing libraries; it was faster to develop and works in more environments than before. Web development is getting better and better. Oh, and yes, I did get a Google I/O ticket! :)