Thursday, February 23, 2012

Make a Better Restaurant Site

Screen shot of web site on my mobile that requires Flash.

Last night I had the pleasure of moderating a panel discussion for the Buffalo chapter of Social Media Club. The panel consisted of a food blogger, a restaurant review site owner, a restaurant / cooking school owner, and a local food writer / reviewer / event planner.

As I asked questions of the panel I held off on my own question about why restaurant web sites are so stultifyingly awful, only to find the question came from the crowd itself:

@SMCBuffalo if it hasnt been asked yet, what should restaurants be doing better on their own websites (ie. updating menu/prices) #BUFfoodies

This is a topic with which I have struggled mightily — not as a web developer, but as a consumer:

Hey #LocalRestWeek restaurants -- your Flash-only sites don't work on my mobile, which is where I make my eating decisions. You should fix.

On far too many occasions I have been away from a computer, armed only with a smartphone, trying to make a decision on a restaurant by looking up information online. On far too many occasions I have been unable to get directions, hours, a phone number, menus, or even see photos (it's good to know if I am under- or over-dressed).

This isn't much different from the days before smartphones when I visited a restaurant web site at my work computer and had to scramble to turn down its background music, or had to close the page because its massive Flash movie brought everything to a crawl.

I was pleased to see — no, pleased is the wrong word — I was grimly satisfied to see that all four panelists reacted immediately, passionately, and in near unison when I asked what restaurants can do to improve their web sites.

What Restaurants Can Do

The takeaway, before the discussion transformed into one about general expectation management, was pretty straightforward:

  1. Dump the Flash;
  2. Lose the background music;
  3. Forget the splash page;
  4. Get your menu current;
  5. Replace the PDF menu with HTML;
  6. Put the hours on the home page;
  7. Put the address on the home page;
  8. Put the phone number on the home page;
  9. Get some quality food photos;
  10. Don't waste my time telling me your ethos;
  11. Make sure it works on my mobile device.

None of this is new stuff. This is the exact same thing that many of us have said for years. There are comics about it, like this one from The Oatmeal:

The Oatmeal comic describing what it wants from a restaurant web site.

There is even a web site dedicated to expounding the right way to build a restaurant web site (yeah, it's kind of meta):

Screen shot of

When today I saw that the guy who built that resource was interviewed for .net Magazine ("Noel Tock on better restaurant websites," primarily to promote his product for building restaurant web sites), coupled with last night's food panel, I thought it might be about time to write something up.


What's that, your favorite restaurant doesn't have the budget to build a web site devoid of all those hyper-expensive features? No worries, those items I listed above can be done in plain HTML for free.

Don't have the skill? No worries there, either. With the small army of restaurant review and collection sites like Yelp, location-based services like Foursquare, the ubiquity of Facebook, and free services like Blogger, you can get the information out there for cheap, maybe doing nothing more than redirecting your own domain name to one of those platforms.

Sure there is a risk, but that's just about proper time management:

Managing Facebook alone could be a full time job for local restaurant owners. #BUFfoodies

As consumers, we should be willing to tell a restaurant when its web site sucks. When you make the reservation, when you pay your bill, when the manager is playing nice with the crowd. You may feel like you're being mean, but it's truly a very nice thing to do if you really like a place. Help them not suck in the one way where we can all coach them.


Some proof that I moderated last night and presented some stats (see the article linked above) about social media engagement with food retailers:

The restaurant association has found that social media has a place. Moderator, @aardrian. #BUFfoodies

Update: January 14, 2014

Web Standards Sherpa (yes, I am a writer for it, but not this piece) has some examples of good HTML for using on menus: Question about HTML for Restaurant Menus

Thursday, February 16, 2012

Buffalo Foodie Panel

Buffalo Foodie logo

In just under one week's time, the Buffalo chapter of Social Media Club will be hosting a panel discussion featuring local food bloggers, restaurant reviewers, and food business owners who have found success using social media. Here's the scoop:

Wednesday, February 22, 2012
6:00pm — 8:30pm

Artisan Kitchen and Baths at 200 Amherst Street, Buffalo, NY 14207
Go get your tickets now, before it's too late.

The panelists:

  • Christa Seychew: Food editor at Buffalo Spree, producer of Nickel City Chef series, and overall expert on local Buffalo food scene, which you can verify on her own site.
  • Donnie Burtless: Creator of BuffaloEats, one of the area's premier restaurant review websites.
  • Beth Manos Brickey: Creator of Tasty-Yummies, a popular blog featuring mouth-watering recipes and beautiful food photography.
  • Deborah Clark: Owner of Delish Cooking School and Pastry shop, and advocate for social media.

Two of our local food trucks, The Whole Hog and Roaming Buffalo, will be there to start serving tasty bits at 6pm and the panel discussion, moderated by yours truly, will start at 6:30pm. Get your tickets at You can also participate in the panel in advance by posing questions on Twitter using the hashtag #BUFfoodies.

You can get the full-sized flyer as a PDF and hang it around your office or on your fridge. Since the food photos are mine, I've already done that.

If you are a regular reader of my blog, you might recall my article from early January "Why All the Food Photos?" (also available at where I discuss how social media and food seem to have found a natural bond. This event will help bear out some of my assertions and give you a chance to hear it from the sources themselves.

Flyer for the event, including all the details listed above.For more details:

If you just happen to be curious about those lovely food photos in the flyer, I can tell you that the first image is from a local restaurant, the second image is from my own kitchen, and the third image is from a recent visit to Florence, Italy.

Thursday, February 9, 2012

Browser Makers Caving to Vendor Prefix Misuse

TL;DR: Help stop further erosion of an open web by removing our -webkit- only prefix reliance. Information on how to do this at the bottom.

Image of vendor prefixes in CSS source code.
Example of vendor prefixes in CSS for Webkit browsers (Chrome, Safari), Mozilla, Internet Explorer, Opera, and finally the standard from the CSS spec.

Vendor prefixes in CSS are those handy methods browser makers have of testing their implementations of new or modified CSS support out in the wild. A developer can play with how a browser handles rounded corners, for example, within a particular browser and that browser maker has a chance to hear back from that very developer. Ideally, this prefix is dropped once the browser maker chooses to claim full support for that feature of the specification.

In November I wrote Perplexing Prefixes, where I review some ongoing debates about the value and risk of vendor prefixes and where the trend is headed. There was discussion that prefixes are dangerous to the web in general and I didn't see just how true that was.

On Tuesday (February 7) the CSS Working Group (CSSWG) met to discuss vendor prefixes among other topics. This abstract from the CSSWG meeting notes lays it all bare:

Discussed problem of WebKit monopoly on mobile and the consequent pressure for other engines to implement -webkit- properties.

Reading further down into the section where they discuss vendor prefixes you can see that Microsoft, Mozilla and Opera are each considering supporting -webkit- prefixes in their browsers. Bruce Lawson explains the folks in the discussion for context: Search the minutes for "Vendor Prefixes". Florian is from Opera, Tantek represents Mozilla, Sylvaing is Microsoft's glamorous rep, and Tab is from Google. Glazou is Daniel Glazman and Plinss is Peter Linss, the two co-chairs of the Working Group.

tantek: At this point we're trying to figure out which and how many webkit prefix properties to actually implement support for in Mozilla
plinss: Zero.
tantek: Currently we have zero. Zero is no longer an option for us.
Florian, Sylvain: Zero is not an option for us anymore either.

Many years ago as Microsoft introduced new elements for its use (anyone remember marquee?), other browser makers had to consider building in support for that non-standard behavior. It is because so many web developers targeted IE that many of those sites from the past are so broken. It is because of this very focusing on one browser by developers that we see the constant call for the death of IE6, or constant comparisons to IE6 as a clear insult.

Today we have developers who are so enamored with iPhones, iPads, Google Chrome, and Android devices (all of which run the Webkit rendering engine) that they have started to repeat the mistake of designing for their favorite browser (a myopic view considering Opera is still tops worldwide). Now sites are filled with -webkit- vendor prefixes, ignoring the other three and ignoring the specification altogether. Other browser makers may already have support (or in many cases have had support for far longer) for many features that developers are putting into their code, but end users never see it.

It's no surprise that browser makers are considering supporting a proprietary prefix so that their browsers don't look broken. They are responding to the laziness of web developers who fail to include all the prefixes. Developers are learning from the laziness of all the evangelists making shiny HTML5 cruft that fails to include full lists of vendor prefixes. At this rate, browser makers may even implement support for marquee — apparently we just need to include it in enough demos, sites and Git repositories and we'll have it back.

Do you hope that WebKit will become the only rendering engine, and that the others will gradually disappear? 32% Yes, 68% No.

Do you purposefully make your web site _not_ work on IE6 or IE7? 17% Yes, 83% No.

Before you consider my opinion to be too far off base, consider the results of this question from the Quirks Mode reader poll: Do you hope that WebKit will become the only rendering engine, and that the others will gradually disappear? 32% of respondents said yes. I am going to suggest that if that number holds true to the entire web community, then fully a third of developers are either at risk of or are actively using only -webkit- prefixes in their work. As an aside, 22% of those respondents also intentionally make their sites fail in IE6 and IE7.


If you think this is a bad idea and you want to participate in keeping it from happening, here are some options:

  1. Daniel Glazman, co-chairman of the W3C CSS Working Group, is shouting for your help in his post CALL FOR ACTION: THE OPEN WEB NEEDS YOU *NOW*.
  2. Review your own web projects and either remove the -webkit- prefixes, or include those from the other browsers (-moz-, -ms-, -o-).
  3. Go to your favorite demo or project GitHub and fix the prefixes, using the method from Christian Heilmann's Pre-fix the web!
  4. Aaron Gustafson has set up a petition at Microsoft, Mozilla & Opera: Don't make -webkit- prefixes a de facto standard. If you have an account with, didn't deactivate like I did for spamming me, and think this might actually do something, then head over and sign.

Further Reading

Update: February 20, 2012

More articles have appeared, some of them taking a different view of the right way to address the overall issue instead of just freaking out about the browsers.

The W3C weighed in today, it's worth reading:

If you use vendor prefixes, haven't seen this handy chart, bookmarked it, and also had it laminated to your wall already, then you're scaring me:

Update: April 25, 2012

Update: July 31, 2014

Microsoft argues that "The Mobile Web should just work for everyone" and now supports -webkit prefixes (IE for Windows Phone 8.1 only). Shoe, other foot, and all that.

There are other announcements in the blog post, but the -webkit support is most interesting to the scope of this post.

Bruce Lawson (from Opera, the first browser vendor to support -webkit prefixes prior to changing its rendering engine to Blink) has written his take on Microsoft's announcement today.

There was also a Twitter chat today for Microsoft's IEDevChat account using the #AskIE hashtag and a few tweeters asked for more context: