Case Study - Myfoodbook

"myfoodbook is a recipe and cookbook destination where you can create your very own personalised digital cookbooks using recipes from top food brands, combined with your own ideas.
The myCollections iPad and iPhone cookbook series make it even easier to use online recipes in the kitchen. Inspirational ideas are combined with handy features including large text cooking mode, voice control page turner, cooking timers and easy ingredient references." - myfoodbook

 

The Brief

Create an app that provides its users with curated cookbooks based on sponsorship, themes, and seasonal events.

The budget for each book was initially 2~3 days, depending on length.

 

Quick Overview of My Roles

  • Oversee the creation process of each book
  • Coordinate with the myfoodbook team to manage and curate book content
  • Run the Ruby back-end to generate the skeleton of each book
  • Create hand-crafted elements and pages (cover, sponsor ads, features, products)
  • Create app assets (iTunes screenshots [5 screenshots per iDevice, so around 25 to 30 total each book], covers, thumbnails)
  • Troubleshoot each book and do QA
  • Proof each book and setup descriptions and push notification
  • Maintain and update the Ruby code
  • Maintain and update the front-end code: HTML, CSS, and Javascript
  • Propose and add new features, often times requiring new code

 

The Challenge

Each 'book' is curated by the myfoodbook team from a collection of over 40 sponsors and 1000s of recipes. Using the Oomph publishing platform, each book can contain over 200 recipes alongside ads, product pages, and custom features.

This was around the time when digital publishing was still relatively new, with the only other alternative being Adobe Digital Publishing Suite (DPS). To create a single page, a designer would normally need to use a template within InDesign, and then manually enter in all the different bits of information.

Even with InDesign's catalogue automation, it was too unreliable and proved to be a nightmare to manage. Imagine hand-crafting and managing over 200 recipes? If a sponsor all of a sudden wants to change 'Tomato Sauce' to 'Rich Tomato Sauce', you'd have to manually edit all of them and re-export.

To add to the challenge, the pages had to be interactive as well. Each recipe contains interactive popups, conversion charts, cooking timers, and voice control. These features require the designers to manually place invisible 'hotspots' based on the placement of each recipes' elements, otherwise they would not function at all.

 

The MVP (minimum viable product)

Working with the developer, we created myfoodbook ver. 1. We used a combination of Ruby and existing Oomph capabilities to create a system that was around 20% automated, and 80% designer-crafted. The Ruby backend would access myfoodbook's database and grab the necessary recipe content. The content was then placed inside the app directory using one of many predetermined templates. For example, if a recipe had 3 components and 8 steps, the system would pick the template for that specific combination.

While this system had worked and earned myfoodbook a Finalist spot in its first year of release, it wasn't viable in the long run.

  1. It was hard to update and maintain the templates. Whenever you have so many variables, if something changes, you'll have to not only spend a lot of time updating them, but also making sure they don't BREAK.
  2. When the client came back with copy changes, that meant we either had to re-do the whole book, or manually go in and edit each recipe.
  3. We ended up spending over 50% of the time fixing things and debugging, and ended up wasting a lot of our budget.
  4. As the books were not published on a set schedule, the timetable can get quite chaotic. Sometimes there might be a short turnaround (< 4 days), or there might be several books within a single week.
  5. There were too many limitations, and it wasn't really given room or opportunities to scale.

 

The Solution

The team in charge of myfoodbook consisted of one developer, and two designers. I was the main designer in charge, I was tasked with the creation and QA of each book with the other designer helping out on custom feature pages.

During that time, the client pressured for lots of changes to the recipes and general structure of each book. This meant that often times we'd have to either run the Ruby scripts a few times, or manually edit all the recipes. I had to do mostly the latter.

I found out about Applescript right around this time, it's basically a Mac-exclusive script that allows users to manipulate Mac OS files. What a godsend. I started learning how to write Applescripts, only to run into a brick wall. It turned out I also needed to learn programmer LOGIC.

For example, a simple task such as 'Create an empty folder inside X directory' had to be rewired to:

  1. Tell Applescript WHAT to use, in this case, I needed to specify the Finder.
  2. Tell Applescript WHERE X directory is. In this case, it was something like '~/Users/Will/Public/Documents/Myfoodbook/ChristmasIssue/FolderA/FolderB/FolderX'. I had to manually connect all of these directories together, and run a function to make it an accessible location.
  3. Tell Applescript to run another function, within the Finder function, to create an empty folder.
  4. Oh, you'd also have to do step 2 again, except for the new folder.
  5. Now you can run the script, but if something goes wrong, you'd have to delete the folder and start all over again.

Now imagine doing that for more complex tasks, oh, the horror!

I was a total newbie to programming, so whenever I had the spare time, I would sit down with the developer (when he wasn't busy) and try to soak up as much knowledge as possible. Eventually I got to a point where I could almost reliably code by myself, and I wrote about 10 different Applescripts for different situations.

When iOS7 came out, the team figured that this would be a good opportunity to use the new budget to create a more efficient back-end. It was also around this time that I was comfortable enough with coding — having been updating the company's Wordpress website — that I started to write HTML, CSS, and a bit of Javascript.

Since the back-end was using Ruby, I got piles of programming books off O'Reilly. I figured it was best if I at least knew how to maintain or update the relevant code, if for example I needed to update a template. I ended up re-working all of myfoodbook's static templates into a dynamic HTML templates, using a Ruby templating 'gem' (add-on).

I also went above and beyond and created an iPhone version of the book as well (iPhone magazines/bespoke apps were rare at the time). The client was so happy she sent the office a whole pamper package.

 

The Final Product

Over the next couple of years, I'd make changes to the general structure of the myfoodbook app, update the templates, and write scripts for the InDesign part of the hand-crafted pages.

In the end, we were able to achieve a system where initially it took over 3 days to create a book, to now, where it can take less than an hour with a trained designer.

Myfoodbook continued to be one of the company's biggest clients for many years, and have published over 50 different books (circulated). You can find the myfoodbook app on the App Store, where it receives a consistent 4.5 star rating from its users.

 

My Roles

  • Oversee the creation process of each book
  • Coordinate with the myfoodbook team to manage and curate book content
  • Run the Ruby back-end to generate the skeleton of each book
  • Create hand-crafted elements and pages (cover, sponsor ads, features, products)
  • Create app assets (iTunes screenshots [5 screenshots per iDevice, so around 25 to 30 total each book], covers, thumbnails)
  • Troubleshoot each book and do QA
  • Proof each book and setup descriptions and push notification
  • Maintain and update the Ruby code
  • Maintain and update the front-end code: HTML, CSS, and Javascript
  • Propose and add new features, often times requiring new code
William Cai