Some time ago, I ran across an interesting post on Clients from Hell:

Website user who couldn’t find an article emailed our help desk. We sent him the link to the content he couldn’t find.

Client: “Please change the letters in your email to blue, so I can click the link.”

Clients from Hell

While this was intended to ridicule a misunderstanding — that the client couldn’t click the link unless the letters were blue — it does stand to illustrate a real problem with usability. Even though there may be relatively few people who actually experience the exact problem above, there are undoubtedly many people who could fail to realize that text is a link when it doesn’t conform to their expectations.

It’s not just whether or not your links are blue — there’s also an issue with internal consistency. If you’ve made a decision that links will be something other than blue, people can learn that. But you may want to consider being internally consistent with that change — I’ve seen many web sites where different areas of the page change the coloration of links: sidebar links are gray, body links orange, footer links black, etc.

Regions of the page specifically dedicated to navigation can frequently get away with alternate appearances, but having a different link scheme all around the site is very likely to just confuse. Inconsistent coloration, inconsistent use of text underlining, or minimal hover or focus changes can all serve to reduce the usability of your web site in significant ways.

Do links need to be blue? No, not really. If you insist on always having links blue you’re going to limit your design options in more ways than are really likely to be beneficial. However, if blue links won’t compromise the design, there’s really no reason not to use them.

Keeping basic usability in mind at every stage of design is just a good idea — at least, if you’re going for a successful web site!

Whenever somebody tells me that they really don’t see the point in doing usability testing on their web site, I can’t help myself from asking why. Let’s be honest here — what’s a really good reason for skipping usability testing? The first thing that comes to my mind, of course, is because you’ve just finished a major usability review. I can understand wanting to give it a skip if you’ve just gone through the usability testing process!

But, surprisingly, that’s not the response I actually hear from people. Actually, the most common reasons are very simple:

1. I’ve never had a problem with it
2. Nobody’s every complained about a problem

Unfortunately, both of these justifications are problematic. They really aren’t a good reason for passing on usability. See, usability isn’t just about whether or not something worked; it’s also about what happens when a process doesn’t work out. It’s not about whether you made it through the process, it’s about how easy it is to make it through process. You’re pretty well guaranteed to be out of the running in testing your web site — because you actually know how your web site is supposed to work.

If you know that a field takes a particular data format – say, a five-digit postal code – then you’re going to tend to provide what you know the web site wants. It’s what happens when you don’t already know the system which is more educational.

This is certainly a frustrating aspect to usability – no arguments there. But you can’t escape it: if you have inside knowledge about a system, you’re just the wrong person to test it. Obviously, this means that problems that other users have are an important element to pay attention to.

However, a lack of reported problems is not at all the same as not having problems.

Nobody’s ever complained about a problem with your web site? That’s not a certainty of any sort. It could be a different kind of issue — rather than having problems which are very clear cut, such as an inability to enter an international address, you may be experiencing time-out frustrations or issues with a particular payment type being rejected. Or perhaps the problem is actually with the ability to report problems — maybe you haven’t provided an obvious means for people to contact you. Perhaps there’s actually a problem with your contact method itself — negative evidence is essentially worthless. All you can conclude from an absense of complaints is that nobody has delivered a complaint to you. You don’t know that they didn’t try, and you don’t know that they didn’t have a problem.

And finally, having a problem isn’t exactly what usability is trying to fix.

Your users may not be having any problems — they don’t have anything concrete to complain about. However, because your purchase process is onerous, a large percentage of those who begin the purchase fail to complete it. They may not have had an actual problem — they just decided that using your web site was too much work.

Maybe they’re just lazy — but if you’ve got lazy prospects, your site needs to work harder at keeping them around. Don’t let your web site slack off.

The worst thing I can say about John Rhodes is that the writing coming from his usability blog has been alarmingly infrequent in the last couple of years. 13 posts in the last 12 months just doesn’t really cut it!

Thankfully, the reason for his blogging silence is pretty straightforward: he’s been writing a book. Sweet!

The book is entitled “Selling Usability,” which is a bit of a misnomer, since the subject of the book is perhaps more accurately described as “Making Usability Happen, Despite the Regrettable Lack of Understanding on the Part of Your Managers.” To be fair, that would be a pretty unusable title.

It’s clear within the first 20 pages that John and I share a core philosophy concerning the application of usability: as much as you’d like people to buy in to the core ideals of user experience, you need them to buy in to making the change. By hook or by crook, making the change is what needs to happen in the end.

You can only teach those who are willing to learn; but you can guide anybody to the right decision if you use the arguments they understand and care about.

Selling Usability: User Experience Infiltration Tactics is a guide to convincing decision-makers towards user-experience focused decisions by using business-focused arguments and tactics.

“Selling Usability” is about communicating effectively.

John’s writing is frank and clear. He writes in a casually persuasive voice which quickly drives through the description of a problem into the analysis of why this is a problem — and how you might start to solve it.

This book is not about usability. You’ll learn a lot about understanding and communicating the user experience by reading this book, but it’s not going to teach you how to study user interaction.

Buy it now. You’ll learn more than you think you will, no matter your background.

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.

Interaction Design

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:

1. link: A link in it’s normative, unactivated state.
2. hover: The state of the link while a mouse-type pointer is hovering over it.
3. focus: In most browsers, the state of the link when focus is placed on the link by means other than a mouse-type pointer.
4. active: In most browsers, the state of the link while the requested action takes place.
5. visited: The state of the link after the action is completed.

HTML 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 active and focus states.

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.

Error Management

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.

Site Administration

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!

You could say that this part of the series is really breaking the concepts of information architecture down into components immediately relevant to web development. Practically speaking, I’m going to cover the necessities of navigation design, the concept of “scent of information” and the question of design “noise.” (Canonicalization was supposed to be covered in this part of the series, as well, but I’ve moved it.)

Navigation design is obvious: the primary organization of all aspects of site navigation. This is an area of web design and development where it’s very easy to go massively and devastatingly wrong — like most best practice concepts, avoiding the pitfalls is 90% of the battle.

“Scent” refers to information design which provides “clues” to help show the user where they are, where they’ve been, and how to get where they need to go. Planning your site should include careful planning to think about these processes.

“Noise” is a term I’m using to describe the opposite of “scent.” Noisy elements of design are those elements which detract or distract from a user’s needs. They may generate confusion or prevent users from following the path of action they need.

Navigation Design

Navigation design has two parts: organizing the documents and sections of your site into links, and generating the visual and interactive method which will be used to access that navigation. It’s important to do this in the correct order — and this is the point in the development process where you simply need to know the scope of content on the web site.

It’s neither necessary nor desirable to actually know every single item which will be on the site. In fact, it’s usually not even possible. A website should grow after it’s initial development, so you should always provision for the addition of future documents. What you need to know now is as much as possible about the documents which will definitely be on the site.

To get started, ask your clients for this information:

• A list of content categories,
• A list of representative content titles and summaries,
• A list of additional features which will require access.

Ideally, you’ve already got a lot of this information from the contract phase. But, if not, now is the time to get it.

For the first steps in navigation design, you’re going to focus exclusively on the content and features.

The organizational needs will be different from site to site. Obviously, a site which is focused primarily around a specific tool will need to primarily concentrate on getting people to that tool. Text content, such as help files or related articles, will automatically be relegated to a secondary position in the navigation. In general, however, this article is dealing with text and content oriented sites: sites which need to communicate certain types of information to users.

A classic method for categorizing documents is to perform a simple card sort. You can perform this test with as large or as small a test group as you feel comfortable with. Restrict users to people who have a reasonable chance of being able to use the information — you may not want to use your grandmother to sort documents on structural engineering. (Depends on your grandmother, naturally.)

Ultimately, you may want to perform two separate card sorts: an open sort (with no established groupings) and a closed sort (using the client’s requested groupings.) For the sake of brevity, I’m assuming that you’ve worked with the client to refine the requested categories.

The guidelines for the process are simple: write the document titles (and brief descriptions, if the title is ambiguous) on index cards. Give people a pile of cards (usually between 30 and 100), and ask them to sort them into groups of like items. This is an excellent way to gain insight into how potential users of the site might expect to find information.

A card sort certainly shouldn’t be your only method to find a logical navigation structure, but it will provide valuable clues concerning what might be expected by visitors. You should also realize that disagreement between sorters doesn’t mean that you need to pick one option: it may simply mean that additional lists of information using different sorting mechanisms may need to be available.

Your ultimate goal in sorting information is to avoid requiring users to look in more than one place: the apparent likelihood that a given document will be found in one category should always lean in one direction.

The second step is relatively simple: building and designing the navigation. Best practices pretty much insist on accessibility and the use of web standards to construct navigation. I’ve written an extensive article on accessible navigation design already, so I’m simply going to refer you to that article for this section.

Scent of Information

Providing a strong scent of information is a good follow up to categorizing your information. Having spent all this time filing information away, I’m sure you noticed that some information just flat out belongs in more than one place. A classic example (for almost everything, actually) is the iPod. Is it computer equipment? Is it audio equipment? What about entertainment equipment?

Ideally, you want to provide enough information about your categories to help users visit the right category first — and not by using the site-cluttering cop-out of putting your items in all relevant categories.

Seed your navigation with extra information

When there’s a possibility of doubt, one of the first steps you can take is to add information which describes your category. Instead of just listing “Computers” in the navigation, say “Computer: Laptops, monitors, mice, keyboards.” You can’t (and shouldn’t) list everything in the category, but providing a representative sample can help users target their navigation more accurately.

Provide navigation to related information

A second method you can use it to provide links to related information. When you have a site set up where there’s a possibility of confusion, you should be able to identify most of these potential problems in advance. Using the same example, you may want to provide a link to iPods and digital music players if somebody is browsing under sound cards or audio software.

Use descriptive linking

A link which tells you precisely what it links to is far more valuable than a generic link text. It’s more likely to attract the eye, more likely to result in an action by the user, and will help your users quickly target the right document.

It’s not just for accessibility that you want to avoid repetitive or meaningless link texts. From a usability or marketing perspective, the right words can make all the difference.

Use meaningful trigger words

What behavior do you want to encourage? When somebody writes “Click here,” they are obviously interested in the short term: they want a click. If somebody writes “Read ‘The biography of a whale’ Now” they’re asking you to read the document. Similarly, using words like “Buy,” “Explore,” or “Hire,” you’re providing a specific, task-oriented clue within the text of the link. Because of this, the user knows better what to expect when they follow the link — and are more likely to follow the link they really want first.

Or, thinking persuasively, are more likely to want what you’re trying to offer. It goes both ways.

Design Noise

On the opposite side of the coin from scent, we find noise. Bad information, information pollution, stink — whatever you might want to call it, the end result is the same. This is information which leads the user the wrong way.

Identify your primary goal

If you’re a sales-oriented site, the strongest scent should be provided to guide users to products and along the purchase path. You may want to provide a lot of essential and valuable information about your products, about your business, or about the industry you’re working in — but if information isn’t your primary business, you should let these parts of your site take somewhat of a back seat.

Link to your documents accurately and understandably

Make sure that whatever you’ve used to link to a page is accurate. If you’ve stated that an article contains certain information, or has a certain product on it — it bloody well better! This seems like it should be obvious, yet I can’t even begin to count the number of times I’ve found myself following a seemingly valuable link just to be stymied by the document itself.

Following a related logic, you should be careful to link the document in a manner which is readily understood. If you’re providing a tool for people to estimate what the salary for their desired job should be, don’t link it using “Proximal Salary/Earnings Indices by Region.” Instead, link to it saying “What should you earn where you live? Find out here!”

Using easy language may sometimes be less precise, but will almost always be more useful.

Don’t try to give everybody everything at once!

Too much information crammed into a finite space means only one thing: you don’t know what your users need. And as a result, your visitors probably only need one link — the back button in their browser.

The reason for information organization, at heart, is to reduce the problem of information overload. It’s certainly possible for people to find information given a page of 700 links, but is it an efficient way of working? No. Ultimately, it’s far faster to follow two or three links with a strong scent than to have the possibility of offering a single-click path to information.

Additional Resources

• Information scent: helping people find the content they want
• Deceivingly Strong Information Scent Costs Sales
• Card Sorting: A Definitive Guide

Web Development Best Practices: Part 4 (published on Wednesday, September 3rd) covers semantics, separation of structure from content, and the fundamentals of universal design for the web.

The whole world of spam is an accessibility nightmare. The concept behind web accessibility is to ensure that users can access the complete functionality of your web site — but how do you cope with the fact that spambots will happily take advantage of any hole you leave?

Comment forms, contact pages, email addresses and enrollment forms. All methods of giving critical access to previously unidentified users — and all in positions where you just need to find that crucial differentiation between real people and robots.

When you’re talking about functionality which is locked behind a log-in form, there’s not really a huge amount of trouble in defining the security/accessibility conundrum. Require a good, secure password and you’re pretty safe. People with disabilities, for the most part, can use a password field just as effectively as anybody else. Once you’re behind that iron curtain, you can usually stop worrying about the distinction: everybody who has access to your private functionality is a known user. They’ve identified themselves, provided credentials which grant them a certain degree of access, and you can stop worrying about them.

But your front door can be a big problem.

You need to create a doorway which will allow visitors you don’t already know to reach you. They need to be able to contact you in order to initiate business, or enroll in your program, or at least create an account with your site. It’s therefore absolutely critical that you create a form which can be accessed by anybody.

But you still only want people using your form. Robot visitors rarely pay the enrollment fee, so they’re not exactly welcome visitors in every area of your site. You certainly don’t want to be thanking them for contacting you with an offer to enlarge your anatomy!

Spam protection and accessibility have inherent conflicts of interest: the formar goal attempts to prevent a form from being used, the latter promotes it. The two goals aren’t actually antipathetic of each other, but getting the two goals to work collaboratively does require a detailed understanding of what the issues are.

Stopping the Robots

One of the most common solutions to the spam problem is to prevent a problem which a computer can’t solve. The most obvious solutions (pictures of animals, pictures of people, etc.) are inherently flawed because they require specific pieces of information in order to solve. They’ll require correct spelling in the correct language with knowledge of the subject depicted. Although most visitors may be able to identify an elephant, some visitors will inevitably (and correctly_ identify it as an elefant.

Presumed knowledge is a barrier to both humans and computers.

This is what has led to the numerous garishly blurred and colored text images you’ve undoubtedly had to interpret. Computers can use character recognition to examine images and identify the text, so the presentation is warped to decrease the likelihood of recognition. Of course, this also decreases the likelihood that humans will be able to read the image. Humans with disabilities? No chance. Either you include an alt attribute, making the solution trivial for a computer, or you leave it out — making the solution impossible for somebody with a visual disability.

Thus was born the audio CAPTCHA. However, audio CAPTCHA requires specific technology — an audio format must be chosen, and an audio player provided. Additionally, computers are capable of recognizing audio excerpts in much the same way they can recognize images. As a result, the audio output is distorted. I’ve listened to audio CAPTCHAs, and all I can say is that I hope others have better luck than I do. I’ve never passed one.

And, of course, neither of these methods will provide access for anybody who is both hearing and visually impaired.

There are numerous other examples of attempts at accessible CAPTCHAs. Most of them depend on the fact that while robots may be text-aware, they are not necessarily capable of following instructions provided in text. Simple question & answer bot-blocking techniques like:

1. Write “human” in the field below.
2. What is 3 + 4?
3. Is fire hot or cold?

These simple questions can slow spam — these can be considered generic spam prevention methods. They will stop almost all spam which is not specifically targeted at the form. However, if any programmer decides that they want to write a bot to attack your site, it is a trivial problem. Simply put, these kinds of questions generate security through obscurity.

A second class of bot-blocking techniques are found in more complex question & answer sets:

1. Write “red” in the 2nd text field on the left.
2. Enter your name in the 3rd row, 2nd column.

These programmatically variable questions may also slow a bot, but can also be incredibly challenging — if not impossible — for a human visitor who is not using an visual browser with an output equivalent to the instructions.

Tricking the Robots

Now, robots aren’t terribly intelligent. Usually, their decision making skills are fairly limited. As such, it’s not terribly difficult to simply deceive them. These methods may have some effectiveness at slowing down bots:

1. Required selections on option menus. Not that a specific option is required — just anything available in the menu.
2. Honeypots — fields which should not be filled in, but probably will be by your average bot in it’s quest to cover all it’s options.
3. Limited length fields — if you set this client-side, using the HTML maxlength attribute, a bot can easily limit it’s own input. However, if you set it server-side (at a safe margin for real users) you can stop a few bots which get over-eager.

Mike Cherim has valuable tips on these techniques in his article Protecting Forms from Spam ‘Bots, so I’m not going to elaborate on these points excessively. Again, however, these are all valuable methods within the “security through obscurity” school of protection — no serious protection against a motivated spammer.

Mike’s secure and accessible contact form makes use of a wide variety of techniques and provides thorough accessibility, so if you’re looking for a simple contact form which will block generic spam, it’s a great option.

Behavior Detection

This is a complicated area, which I’m not going to delve into in any significant detail. Primarily because I’m not really qualified. However, it’s an important category of spam control, so it’s worth an overview.

The principle of behavior detection is based on one core observation: bots don’t behave like people. People are, for the most part, a complex blend of random behavior and systematic exploration. Bots are generally much more absolute. When you observe a web site “user” visit every single navigable page of your site at 30 second intervals, that user is clearly not human.

Although the actual interpretation is significantly more complicated, the challenge is simple: look for patterns. If a user’s time on a site matches a mathematical pattern, that’s a signal. The Bad Behavior package works (at least partially) on this general logic: search for indications about the user or user-agent and identify signals which suggest non-human activity.

Requiring Specific Capabilities

Some spam solutions make the choice that they will require specific capabilities from the visitor in order to allow them to make contact. The WordPress comment spam plugin WP-Spamfree takes this strategy. The first layer of protection for this plugin is to require that any visitor trying to submit a comment have support for Javascript and for cookies enabled.

Immediately, this strategy eliminates the vast majority of bots — and a small minority of humans.

Conclusion

I’m not aware that there’s any solution which has 100% success at differentiating humans from bots. Any barrier put in place to spam will also create a barrier for somebody. However, this is a decision that must be made for any site: when you’re receiving thousands of spam messages a day through an insecure contact form, is it better to stop the occasional human or massively reduce your daily spam-killing time commitment?

Ultimately, there isn’t a real answer. Spam is too great of an issue to simply ignore. However, any time you create a CAPTCHA — of any sort — just remember this: provide an alternative. If you provide a phone number to those who have failed your little test, they may be able to reach you. If somebody needs to reach you, make it possible: even if they’ll have to write you a letter in order to post a comment on your blog.

Here’s the first clue: it’s not creating a pixel-perfect replication of your ideal version of a site in all browsers.

In fact, cross-browser compatibility ultimately has very little to do with what a web site looks like, and a lot more to do with how it functions. It also has relatively little to do with browsers, and perhaps could better be explained as multiple user-agent compatibility.

“Compatibility” (in this context) is not a term which means “looks and behaves identically” — instead, it may be better described as “performs equivalently under alternative conditions.” But developers and designers tend to most immediately seize upon appearance as the guiding line for cross-browser compatibility.

Of course, let’s be honest: there are a lot of very good reasons for this. Completely disregarding what we may know about the behavior of a site, clients tend to be very visually oriented. They pop their new site open at home one day during development and notice a whole variety of differences which they’re suddenly concerned about. If you’re lucky, they’re opening up Internet Explorer 6 after you’ve gone through the painstaking process of correct its inability to cope with standards-compliant code, rather than before you’ve gotten around to it. That can be awkward…

Another good reason is that despite what I’ve stated above, making the design behave more-or-less identically between different browsers is actually quite desirable. From a usability perspective, a seamless change in interactivity between different user-agents is very desirable. If you’ve ever tried to guide somebody through using a website which delivers a different experience to their browser than to yours, you are intimately familiar with one reason it’s a very bad idea.

But the absolute key to cross-browser compatibility is simply functionality. A lack of cross-browser compatibility doesn’t mean that something looks different; it means that it doesn’t work.

And a good thing, too. Otherwise, compatibility would be pretty well impossible between desktop browsers and mobile browsers.

With web design, it’s occasionally entirely possible to make two browsers render a design exactly the same…if you assume certain factors will remain constant, such as the user settings described in my last post. If any of those have been changed, everything pretty well goes out the window. As desirable as it is to make your designs look as similar as possible between the various desktop browsers, it always has to be acknowledged that there are limits.

There’s nothing at all that you can do to actually guarantee the same view for everybody; instead, you need to guarantee an equivalent view for everybody. Equivalent in that they will be able to get the same information and use the functions of the site to perform the same actions.