Who doesn’t love going out to dinner at a restaurant? Especially a new one. It can be fun, relaxing, even romantic. Before you can have that experience, another one usually happens first – the restaurant website. You explore the restaurant website to check out what it’s all about. You discover their physical location and hours of operation, find their contact information, peruse the menu and perhaps some photos. Ideally, you’ll be able to do this quickly and easily. However, most restaurant websites are far from ideal. Sometimes you can’t find what you need. When you do find it, you’re sometimes disappointed. We’ll review some of the common usability sins that users experience on restaurant websites.

Bad Menu Presentation

The first of these sins is the presentation of the menu. So many restaurant websites wrongly use PDF files to deliver the menu content. The advantage of this approach is that it’s easy for the website owner to provide menu updates. The problem with it is that it ignores the customer experience. While it technically delivers the content, it forces the customer into a slow, ungraceful process. The customer should not have to open a separate application just to view the menu. Instead, keep the content in simple html. When your website should be built on content management system like WordPress or Drupal, the menu, and the rest your website, is easy to update.

Additional unfortunate consequences occur when the user visits the restaurant website on a mobile device. A downloaded PDF file consumes far more bandwidth than the equivalent html page. This is bad for mobile users on a metered data plan. Mobile users also have problems displaying standard sized documents within the limited screen dimensions.

What makes a good menu? To start, all the text should be in html. It’s easy to update, accessible to the widest audience, and browsers allow users to scale the text to the size they need. The essential content of any menu are the name and price of the item. A description and a photo would also be helpful to include can add value for the customer, but they’re not required. Some may disagree, but as far as usability goes, name and price are the only requirements. If the size of your menu is too big, you may want or need to organize the items into groups. The threshold is around 10 items. You may have some natural groupings. Product type is the most way to organize. The types of products will depend upon the restaurant. A burger joint would have burgers, side orders, and drinks. A cafe has coffee drinks and tea drinks. An Italian restaurant might have pizza, pasta entrees, side orders, and drinks. This is best done using the heading elements (H1-H6). Not only does it divide your page into logical sections, but it increases the accessibility of your website.

Unnecessary Use of Flash

The second sin is the unnecessary use of flash. One could also say abuse of flash. It can be implemented in a variety of ways, and not all of them are good. It’s usually used for an image gallery, a site intro screen for the rest of the site, or sometimes flash contains the entire site. You’re probably wondering “what do you consider critical information?” Think of it this way: if you couldn’t see it, would you miss anything? Use the Firefox add-on Flashblock to help visualize what’s it’s like to view your site without flash. When it’s used for an intro screen, it’s seen at best as annoying by repeat customers. At worst, it diminishes the customers view of the restaurant even more when it can’t be skipped. Don’t put any barriers in your customers way. Instead, remove barriers to improve your customers experience.

It’s easy to see why restaurant owners are impressed by flash. It looks nice when slick animation is applied to nice photography. However, there are few cases where flash can provide value to restaurant websites. Most of what flash is being used for nowadays for restaurants can be done with javascript. Using javascript frameworks like jQuery make it easy and faster than using flash.

Think of flash as a spice and not an entree. If you do that, you’ll make the right decisions.

Hiding Location Information

The third sin is hiding information. It’s amazing how often its difficult to find simple information like the restaurants phone number or hours of operation. It shouldn’t be hard to find your information. To make things easy for potential restaurant customers, it’s best to keep to the venue information – physical location, hours of operation, email address, and phone number – together. More importantly, you should expose it as early in their experience as possible. Where on the website should it be presented? depends on the quantity of physical locations.

When there is a single location, the venue information should be on the homepage above “the fold”. Even better, include a photo of the restaurant exterior. Doing this will help your new customer identify your restaurant when the arrive in your neighborhood. It can also be helpful to add the information to every page by including it in the page header. This will make the customer’s experience painless, and they’ll thank you for it.

When there are a multiple locations, you have a couple of options. First, you can list them all on the homepage when you have 10 or less. It also depends if you have location specific features or not. If you have location specific information, it’s best to create a unique page for each location and link to it from the homepage. The Cherry St Cafe does a great job of this. When you don’t have location-specific information, it’s best to have a single page that will list them all. Kidd Valley provides a good example. Their menu is consistent across all of their locations. With this type of consistency across locations, it’s easy to add another location.

Flash is not a bad technology. It can provide a lot of value when used correctly. However, it’s usually not the case when dealing with restaurant websites. This article exposed some common problems for customers of restaurant websites. What drives you crazy about restaurant websites? Please leave a comment.

Usability Consultant Jakob Nielsen published a proposal to stop password masking, as he believes it causes reduced usability. Password masking is the automatic process of displaying asterisks or bullets instead of your typed characters. Nielsen supports his arguments by offering research from his mobile usability study.

The venerable publication A List Apart, published an article in their 300th issue that discusses Nielsen’s concerns. The author Lyle Mullican offers two potential solutions, complete with Javascript code and explanation. The first solution provides a switch that allows the user to show and hide their typed password. The second allows the most recently typed character to remain visible momentarily before becoming an asterisk. Mullican’s examples are good for explaining how it would work. Mullican himself wrote “Note that this code is only intended to demonstrate the concept, and the process might be improved by using a JavaScript framework such as Prototype”.

Nielsen raised several issues but doesn’t spend any real effort proposing a solution. Of the 2 that Mullican proposed, both will likely be used, each with varying levels of success. One reason for this is designer preference. Each designer will decide what they like better. Another, more significant reason is implementation. Some will use plugins for their javascript frameworks, like Prototype or jQuery. Others will write their own, which will ultimately provide an inconsistent experience across websites. If you don’t think so, consider form validation. Every web developer has unnecessarily written their own email validation function.

The ideal solution would be to update HTML5 to include an improved password input element. This would offer the most consistent experience available to every website user. Of the two solutions demonstrated by Mullican, using a switch to show/hide the password value would be the preferred implementation. It’s more accessible to users that react more slowly, and offers every user more control over their experience. While the current password input has its problems, people understand how it works. So for the time being, your best bet is to continue using it. Hopefully with HTML5, the situation will improve.