Server side usability
How to make web servers behave
Most usability professionals don't have a driver's licence
to servers and are not aware of the steps that can be taken to make
them behave in a user-friendly way. In this article, we'll take a look
at how to avoid that server technology becomes an obstacle to usability.
Successful design pays attention to detail, since small matters can
ruin the user experience. But some of the more technical aspects of
running a website are often overlooked, forgotten, or ignored by usability
professionals, because it's way out of our league.
In the following, you'll find a number of tips on how to improve usability
on the server side. I won't dive into the technical details on how to
set up servers to behave in a more user-friendly manner, since it differs
from server to server. Most of the tips in this article require basic
server settings, and server administrators should know how to do it.
Make the "www" prefix optional
When you type a domain name such as "www.guuui.com" into your browser's
address line, you can mostly leave out the "www" part and just type
"guuui.com". But sometimes it doesn't work. Instead you get an error
message saying that the page cannot be displayed. Some people blame
their browser for this error, but actually the server administrator
is to blame. To support the domain name shortcut, the server has to
be told to resolve to "www.guuui.com", whenever a user asks for "guuui.com".
Be sure to support the "www" version also.
Support "www" prefix typos
A common error when typing a domain name into the browser is accidentally
typing "ww.guuui.com" or "wwww.guuui.com". Again our server administrator
can contribute to the user experience by spending a few minutes setting
up the server to accept "w", "ww", and "wwww" typos.
Support domain name typos and spelling errors
The domain name for a company such as Bang & Olufsen is hard
to guess and hard to spell. Is it "bangandolufsen.com", "bangolufsen.com",
"bang-olufsen.com", or maybe "bando.com"? And is it spelled "olufsen",
"olufssen", or "olufson"? Even though I'm Danish and should be able
to spell the name, I always get it wrong.
As far as I can see, B&O managed to register "www.bang-olufsen.com"
and "www.bangolufsen.com". Lots of other close variants have been registered
and populated with substandard content (I can't recommend visiting any
of these sites). The lesson here is that professional organizations
should register domain names that people might type by accident, when
trying to find their sites. Otherwise, someone else will take advantage
of the fact that people make typos and spelling errors.
Support erroneous country codes
It's also common to mistype country codes. Danish people are used
to type ".dk" in the end of a domain name and do so by accident when
trying to reach ".com" sites. Professional organizations should register
their domain name with all available country codes. If they don't, others
Use tidy URLs
URLs are often very long and littered with strange and extraneous
characters. Apart from being ugly and intimidating, such URLs are hard
to read, hard to type, and impossible remember.
In printed material, you may want to direct users to a product section,
an advertising campaign, or a newsletter. This is practically impossible
with long dirty URLs.
The only purpose of messy URLs is satisfying some tedious technical
requirements of the underlying systems. But the mess can mostly be stripped
from the URL by setting up servers properly.
such as Apple, Macromedia, and Microsoft, use short, guessable URLs
to direct customers to the main sections of their sites. If you want
to know more about Macromedia Dreamweaver, type "macromedia.com/dreamweaver"
in your browser, and you will be taken to the Dreamweaver product section.
Type "macromedia.com/download" or "macromedia.com/downloads" and you
will be taken to the Downloads section. This way you don't necessarily
have to start your navigation from the front page, and it makes it
possible for the companies to promote the sections in printed material.
Don't leave users in a dead end when a page cannot be found
A survey by
404 Research Lab reveals that 40% of users "weep uncontrollably"
when they encounter a "page not found" error. 37% hit the back button.
To comfort unfortunate users, and help them find what they were looking
for, you should design a custom error page. Guide people in the right
direction by providing a site map, a search form, and other means of
helping them out of the dead end.
To minimize page not found errors, you should monitor your server
logs. If you notice a lot of failed requests to nonexistent pages, make
sure to fix it. If the requests are caused by bad links from other sites,
contact the sites' webmasters and ask them to correct the links. If
the requests are many and from multiple sources, consider setting up
the server to redirect people to the correct location.
was originally developed on a Microsoft platform and had the ".asp"
suffix at the end of every page URL. It was then moved to a PHP platform,
where page URLs end on ".php". It would be disastrous if all links
from search engines, other sites, and peoples' favorites would result
in a page not found at guuui.com. Therefore requests for ASP pages
are redirected to their PHP ditto.
Alert users when a server error occurs
What can go wrong, will go wrong, and sometimes servers encounter
serious problems. When they do, we should tell people that the site
is experiencing technical difficulties and apologize for the inconvenience.
The only advice we can give users in this situation is to try again,
and return later, if the problem persists. Server errors are often temporary
and will be alleviated after a short delay.
Servers run into problems for a number of reasons. But since the directions
we can give users are the same and we don't want to bore people with
technical details about why the error might have happened, it's adequate
with one generic server error page.
As with page not found errors, you should monitor your logs for server
errors. Look for response codes beginning with the digit "5" (e.g. 500,
501, 502, 504, and 505). If you notice a sudden increase in the number
of server errors, make sure that someone looks into it.
Have a "We are updating" page ready
Sometimes a server error doesn't happen by accident, but because the
server is down for maintenance. Instead of showing a server error, you
should have a "Sorry, we are updating the site" page ready. Redirect
all traffic on the site to this page during the update.
Text: Henrik Olsen