Old School Validation

As the web designer, it’s your job to craft the front end. Part of that is to make sure the data in your forms is valid. So you search the web for some examples of javascript that can be used to validate your form data. You may be looking for a way to validate your data consists only of numbers, a valid email, a US Zip code, a phone number or a URL. So in keeping with the great Internet tradition of “make it work”, you write some code to implement what you’ve found. After a couple hours, you get it working in your browser. Then you spend the next couple of hours testing it out on other browsers, and trying different data that you expect. If all goes well, you put it out on the web for your customers to use.

If you’re working on a team, you may have a PHP developer. She’ll write the code that captures the data, validates it, and stores it in the database. She may have done a similar process to what you just did. She may be using a code library that has done the heavy lifting for her. Here’s to hoping – Cheers! Her test data sufficiently passed the tests she thought up, and committed to subversion for the next website update.

If you’re working alone, you may have left that process for later, when you have more time. Besides, everyone has javascript. Validating before submitting is good enough, right?

What Could Go Wrong?

What’s wrong with the scenarios above? There’s a couple of things, actually.

In the event that you decide to use only javascript and postpone server-side validation for later, it’s easy to circumvent. The user can shut off javascript in their browser or, it could be blocked by a proxy or firewall. In any case, it leaves a gap in functionality. While it may not seem like a big deal, bad data is never fun to deal with.

If you have a PHP programmer on your team, you need to have good communication with her. Without it, each of you will arrive at different ideas of what is valid. This will provide a terrible UX, and lead to a frustrated customer, particularly if the server-side is more strict. If you do communicate well, and your code works identically, you still have the problem of synchronization. When something changes on the server, that same change needs to be made in your javascript. This violates the DRY Principle. So, what can be done? Let me show you a better way.

A Better Way

The solution is one of mindset. Progressive Enhancement is your friend. By doing the following you’ll create a better user experience, and save yourself a lot of time and frustration.

Start with HTML. When you layout your form, consider which fields are required. For each field that’s required, create the appropriate markup and css for an error message. Then talk with your PHP developer about your required fields and your expectations about how they should be validated. It’s up to her to create a function that examines all the inputs on the server. She’ll use that function to return an array of errors. It’s important that the validation logic to be in a separate function. She’ll repopulate the form with the pertinent error messages next to each field. The styles used will be what you designed earlier.

But wait! What about the Javascript validation? Ah, glad you asked. Well, it couldn’t be easier. Since you have validation working on the server, now we can make a better experience for those that have Javascript available. Instead of trying to duplicate the server’s validation logic on the client, use AJAX upon submitting the form. This way, you can prevent the submission of the form, if something is invalid. Not only will this reduce your workload, but it also simplifies your code. What’s awesome about this is that no matter where the request comes from, the answers will always be the same.

To see how this works, check out the add form on Cafe Workr to see it implemented in a live environment. In the near future, I’ll write a tutorial on the how to build this.

I’m happy to announce the launch of a new project CafeWorkr, a  website application for the nomadic professional and the university student alike.  The goal of CafeWorkr is to help you find a local cafe with wifi for you to do your work. CafeWorkr makes it easy to find the cafes closest to you. It uses the Google Maps API plus some custom mojo to make its search fast and easy to use. Just type in an address, an intersection in your city, or a zipcode .

CafeWorkr also keeps track of cafe hours, contact information, and tags for menu items, and ambiance. Making it easy to know when a cafe is open is important, so CafeWorkr highlights the locations hours for the current day. To give you an idea of where the cafe is located in the city, a Google Map is also provided.

The biggest challenge is information. I need your help in collecting the best information. How can you help? It’s easy. Just add 2 or 3 of your favorite cafes with good wi-fi. That’s it. Oh, and don’t forget to tell your friends about CafeWorkr.

Accessibility is a field of design that considers the user’s condition and enables them to access your website. Its rooted in physical reality – the reality of your customer. Some people get exposed to accessibility through Section 508 or WCAG to assist disabled users. It’s more than that though. Accessibility is about helping everyone, no matter where they are on the spectrum of ability, to access your site. Making your website accessible is crucial to your business going forward. To illustrate, check out how Accessibility relates to mobile web design, SEO, and Usability.

Mobile Devices

Life doesn’t stand still. People are on the move. More and more, people are using their mobile device to experience the web. As a whole, web users are goal oriented. Mobile users are even more so. Accessible web design shares a lot of best practices and concepts with Mobile web design. For example, providing text information for related image, video, and audio content is vital. Mobile users may not have the time or the bandwidth to watch a video. text is also easier to scan. Users that are hard of hearing would also have an issue. However, both user groups can get the information they need by reading the text.

SEO

Search Engines like Yahoo and Google also rely on text information. The way web pages are created and the content they portray make all the difference. When it comes to Accessibility and SEO, text is king. Pages that are well structured rank better. They’re also for easier for users, blind or otherwise, to navigate. In fact, you should think of a search engine as a blind user. When your website is developed for accessibility, the core of your SEO is done for you. This frees your SEO consultant up to focus on other activities like link buildling between your site and others, and analytics. So what’s the difference between letting an accessibility developer vs an seo consultant developer your website. The answer is focus. Accessibility is about people, and SEO is about machines. What do you care more about – people or machines?

Usability

Accessibility and Usability have a close relationship. Consider the baby boomer generation. Many of them aren’t disabled, but they need accessibility built into the websites they use. Without it, the usability of a website is lower. For example, they’re vision isn’t as great as it was 20 years ago. They need things like slightly larger fonts, and better color contrast. Many web designers however tend to use text that is too small, and colors with too little contrast, because it looks better to them. Help these users by keeping them in mind, and they might be your next customer.

Web Designers that take accessibility seriously provide a lot of value to your website and your business. They know the importance of it to your customers. By developing your website to be accessible, you’re getting the benefits mentioned above. Also, by developing accessibility into your site design, it’ll cost less to develop. Accessibility is about helping everyone access your website. Each person that uses your website is a potential customer. As I said before, making your website accessible is crucial to your business going forward. Consider that before your next website re-design

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.

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.

Why not just type accessibility? It’s used in contexts where character lengths are limited, like Twitter and SMS. On Twitter, you may see some permutations that have airport codes appended to it. For example #a11ybos and #a11ysea are hash tags used by a groups, in Boston and Seattle respectively, who are organizing an Accessibility Camp.

Why the weird abbreviation? A11y is numeronym. Other common numeronyms are i18n and L10n for internationalization and localization respectively.

When the context changes, the meaning can be lost or altered. Colors can have different meaning when the culture of your audience changes. The color white in western cultures is symobolic of cleanliness, the good guys, and brides. In eastern cultures, white is used for funerals. Imagine spending a day creating a beautifully vivid graph, then make some xerox copies on the office copy machine. Do you perceive the information the same way as before? not likely.

This isn’t unlike an experience for someone who is color blind. Being asked to make decisions without all the information is difficult for anyone. How can the situation be improved? Shape. In the graph example above, using a different type of line would help retain information. For example, using a green solid line and a red dashed line would allow the lines to continue to be easily distinguished from one another – even in black and white.

Shape is also used to create better buttons. The image above shows 2 sets of buttons. The first row of buttons is an example of something you dont want to see on the web today, 2 plain rectangular buttons – red and green – with no other information. One way to improve these buttons is to add shape, as seen in row 2 of the above image. By adding a check to the green button and an “X” to the red button, they are clearly distinguished from one another to a color blind user. Also more information is communicated as to what the buttons mean, even if you didn’t add a button label. The symbols on the buttons can also provide value to not-native speakers if they don’t entirely under the text label.

A third area where shape can provide value, is in your navigation areas. There are a number of beautiful modern website designs that use a unique indicator to designate the current page. This could come in the form of an arrow, rectangle, or other unique shape. In the example below, Untitled Startup uses an indicator to designate the current page. This a great technique to increase usability and accessibility since it doesn’t rely on color alone to convey information.

Color is a great tool to have in your toolbox, but it shouldn’t be the only one. The examples provided here are simple by design. Try experimenting on your future projects by working the use of shape into your design.