Strategies to avoid data entry duplication between PDF vs. website (e.g. restaurant menus)

Question

I'm building a website for a restaurant. They have a downloadable PDF version of their menu (which is what the "real-world" menu is printed from), but we also want to have a text-based version of the menu on the website (because it's the 21st century and you shouldn't have to read a PDF when browsing a site like this).

I'm hoping to avoid -- or minimize as much as possible -- the potential problems with maintaining data in two places (one in the PDF and one on the website).

In an ideal world, we'd build a custom dashboard interface for managing menu data, with a fully-normalized schema, and from that data we'd automatically generate the PDF and the website versions of the menu (and come up with a very expensive and flexible visual design for the PDF menu that takes into account all future permutations of data that may be contained within it -- because the visual layout of the PDF menu is very important, since that's what the "real-world" menu is printed from).

But, since the budget is not unlimited, I'm trying to think of other ways to accomplish this goal. Are there any compromise solutions or "this gets you halfway there" kind of things I could do? Obviously I'm not expecting a perfect and cheap solution, but anything that minimizes the double-data entry to the extent that it's not so much of a chore would be really helpful.

Answer 1

How "designy" is the menu? That is to say, how elaborate is the placement of the text? My immediate thought on this problem is that if there's the least little bit of creative license in the menu (ie, certain items being different from other related items), then just maintain it in two locations.

As programmers, we tend to default to thinking about uniform data being rendered through templates/repeaters. If there's 7 entrees, then of course we can just define a template for an entree and push them through to it! WRONG. Today, the chef wants the salmon to get indented and bolded on the menu with a little fish by it, but the hamburger needs to pop over to the left to make room for the big capital letter on the next line ... and so forth and so on.

Furthermore, you have very real problems when it comes to physically printing a menu that don't exist from a data perspective. Like the number of pages. If you just have repeating sections that fill the page from a datastore, there's no good way to guarantee against page breaks. If the restaurant adds 6 entrees, they'll probably play around with the formatting of the entree section to keep the menu roughly the same overall proportion.

Before programming, I used to be in the printing world, and I saw quite a lot of menus being fiddled with and tweaked by graphic designers constantly. There's actually a whole field of psychology on menu item placement and pricing!! Here's an interesting article on the subject: http://rrgconsulting.com/psychology_of_restaurant_menu_design.htm The short version is that the design of the menu effects consumer choice greatly. Meaning that as different entrees become attractive to management as their profitability changes, the restaurant will want the design to change to accommodate this.

So you have two options: build a system by which items are stored in a data source, with options for virtually every possible design configuration, and print the PDF from that. Or just tell the chef that when he/she changes the menu PDF (from Word, or whatever), that they must change the textfile/CMS that powers the website at the same time. The former is going to be very expensive and will take a long time to perfect, and the latter is fast, cheap and takes the responsibility off you.

So can you implement a perfectly designed Menu Generator that allows for great flexibility in the PDF output, while keeping the website up to date at the same time? Sure! But is there any hope of it being cheap or fast? Not a chance in hell.

Answer 2

When you look at this from a content management point of view, the content is leading and it should be stored in some form. The design or layout of that content is a second thing, and then both the PDF and the website can be considered a different design or layout.

So separate your content and your design, and then make sure that your content is stored in a single location. Then both the PDF and the website will need to be generated from that single content location.

A simple way of achieving this is by choosing a CMS (Content Management System) for the website, preferably one that can generate both HTML and PDF, so you don't have to do anything extra there yourself.