After all the labor you put into designing an elegant site which allows users to readily follow the scent of information, all the work dedicated to developing effective semantics and separating your structure from design, it’s easy for you to still end up with a royally screwed up web site.
Designing interactions with your users and managing errors (expected and unexpected) are a critical part of best practices web development. It hardly matters at all whether somebody can find their way to the right information if they encounter so many problems along the way that they lose trust in your site or give up on their purchase out of frustration!
It’s not that difficult to keep user interactions running smoothly, if you just keep a few basic rules firmly in mind:
- Your users don’t care about error codes.
- Messages should tell people what to do next, not what they did wrong.
- Every action taken by a user should have a response.
- Users will do the things you can’t imagine them doing.
- If you’re going to require something, you better mean it.
Even the most static web site has interactive features. If your site has a single hyperlink, there’s interaction built into your site. A very small amount of interaction, granted, but there is interaction. The interaction information you can communicate using that single link is based on five specific states:
link: A link in it’s normative, unactivated state.
hover: The state of the link while a mouse-type pointer is hovering over it.
focus: In most browsers, the state of the link when focus is placed on the link by means other than a mouse-type pointer.
active: In most browsers, the state of the link while the requested action takes place.
visited: The state of the link after the action is completed.
HTML (HyperText Markup Language) doesn’t provide a lot of options by default, but these four pieces of information are critical to making basic interactions effective for all users. Simply communicating to the user that what they are doing has an effect is invaluable.
Similarly, providing interactive information when no interaction is possible can be very confusing. Simply put: if the user can do something with a control, give them information (scent, anybody?) which indicates that this area has a function. If the control is a link, you are able to ensure that it:
- has an appearance different from the surrounding text (blue, underlined,)
- provides information to mouse users that they are in a position to activate the control
- provides information to keyboard or alternative devices users that they have focused on the control
- indicates that you have performed an action, and that the link is activated
- indicates that the control has been used.
Now, from a practical perspective, this much information isn’t always necessary or helpful. For basic links, it’s rarely necessary to differentiate between
hover states and
active states. Because of flaws in Internet Explorer’s use of these commands, it’s frequently necessary to assign the same appearance to
Nonetheless, the basic principles at work in these five states are valuable, and can be used to guide your approach to interaction design. Simply keeping in mind that form inputs and script responses are not the only ways to communicate interactively with your users will help you shape the behavior of interactive pages.
The possibilities for errors in any complex project are endless, so I’m going to contain myself to a very simple example: a standard contact form. Possibly the most standard expectation for many sites is a means for the visitor to contact the site owner (or whatever appropriate person is involved.) Although providing a phone number and address is generally expected — it may not be the preferred means of communication for either party. Since email addresses are essentially a big, open invitation to spam, contact forms are left as the best method of defining a way for visitors to contact you.
The basic contact form I’m going to discuss is asking for four pieces of information: a name, an email address, a phone number (which is optional,) and a written message. It’s not a lot of information, but still leaves a lot of room for screwing up.
When creating a programming example of this form, all that’s generally covered is the basics: how to gather the information in a form and send it to an end user (usually, by email.) This is the core functionality of a contact form, so it’s reasonable that it’s the first thing to be covered.
This is only a problem if you stop programming before working through the rest of the scenario.
Depending on how it’s written, the program described above will do one of two things on being submitted: display a blank screen to the user, or show itself again, with the information submitted removed from the fields. Neither of these options are particularly palatable by themselves, but they each serve a purpose in providing best practice responses to the users.
First, let’s assume that the user is making a lot of errors. They’re putting a phone number in the name field, gave a web address for an email, and left out their message entirely.
Without any data checking, this message may simply be sent off: the site owner gets useless information, and the visitor wonders why that damned site owner never answers his email.
Obviously, doing a little data checking is good for more than just security: it helps make sure that you’ll actually get the information you needed from the form.
Now, having checked this information, we want to let the user know that something just wasn’t working quite right. But this is a crucial thing to do right — I’m sure we’ve all been to forms where one of the following happened:
- The error message didn’t tell you what your errors were, and requires you to use the Back button to return to the form.
- The error message doesn’t tell you the errors, and deleted all the work you did with the form.
- The error message tells you what errors you made, but doesn’t tell you that it also blanked the password field (which was fine.)
- The error message informs you of an error which you wouldn’t have made had the information been available before you used the form.
Ideally, if an error is made with the form, the response will:
- Identify which fields included errors.
- Return the user to the form itself.
- Retain any information the user supplied in the form.
If relevant, the response might tell you what was wrong with the data you supplied — but, ideally, this shouldn’t be necessary. To take passwords as an example, a response error might inform you that passwords are required to include a capital letter, a number, and a non-alphanumeric character. It may appear helpful for the message to tell you this — but in truth, the form should have already contained that information.
If you’re going to check data, you need to make a point to inform the user what data is required before they submit the form. With the wonders of AJAX available, it’s possible for a form to point out your errors as you make them: but you can’t count on the perceivability or availability of AJAX to your user, so this shouldn’t be the only means of gathering the information.
Information which should be made available to the user in advance includes any required formatting (999-123-4567); any required fields; any specifically forbidden information (profanity or HTML); or any specific requirements or restrictions on length (passwords must be at least 8 characters, message a maximum of 1000.)
Preventing errors before they are made is possibly one of the most important aspects of error management!
“Error management” is actually a bit of a misnomer, when you get right down to it. Above, I mentioned a scenario in which a form is submitted resulting in either a blank page or itself: while having the form re-appear following a user error is an absolute must, the blank page introduces an equally valuable scenario: the success response.
After all, “error messages” are merely a subset of all the responses a form might make — having a useful success message is equally important.
Obviously, a blank page is not a great success message. All it tells the user is that something happened — but what that was, who knows? An effective success response should clearly state to the user what happened with their request. Specifically,
- What information they entered.
- What information was sent.
- Whether the script believes the information was sent successfully.
- Whether they should expect any response, and when.
- If a response is expected, what to do if they don’t receive it within the specified time.
Whether the form is offered up to the user again following submission is going to depend on the context. Some forms (like a basic contact form) are primarily intended to be submitted only once in succession. It’s preferable, in my view, for these kinds of forms not to be displayed after submission. Other forms (like a photo uploader) may be expecting repeat use — it’s far more helpful to the user to allow them the option to upload a second image immediately following the first, without having to return to the form.
What about server errors?
Yes, obviously I haven’t addressed basic error messages such as a 404 “missing” error or other important messages from the server. This is a long article already, so I’ll be brief: provide a customized error message. Make sure that it includes pointers to key pages including the home page, site map, and search page.
It may seem like long-term administration is a completely different issue from best practices in web development. After all, administration is pretty far removed from doing all the design, configuration, and development work you’ve worked hard on!
However, you also need to acknowledge that the vast majority of the lifespan of most projects is the time after you’ve finished. Whether you’re going to be maintaining the site yourself, passing it over to an assistant, or passing it off to the client, there are a lot of things you can do to help protect the site.
For yourself, you can establish a style guide for the site: a list of pre-established styles and elements, what they look like, how they’re used, etc. For myself, I use a custom piece of database-driven software which ties a database of elements and script fragments for a given site to the templates for that site. This allows me (or anybody else) to readily browse either for the element I want or the appearance I want and grab the template code I need.
This kind of a tool helps you remember what you’ve done, even if you’re looking at the site a year down the road — and it can provide a guide for your clients or assistants to know what is expected for a given site.
When a client is maintaining the site, the best thing you can offer them (in addition to a style guide) is education and documentation: teach them what they need to know. Document everything they need to do. There’s absolutely no way you can truly cover everything, but you can certainly try.
In the long run, your site belongs to your client, and there’s nothing you can do to prevent them from screwing it up. However, the more you’ve done to make sure they know how to do things right, the better the chances are that they will.
This concludes the Best Practices in Web Development series. Although much has not been covered, those subjects will just have to wait!