Correct use of technology is not necessarily given in today’s Web sites. Shifting
standards and browser problems are partially to blame, but there are many
other problems that are due simply to developers’ lack of knowledge of best
practices. many of the best practices that should be employed in Web
building are presented. The focus is mostly on core technologies, such as URLs, HTML,
relevant to site design and user interaction. This is by no means a complete discussion,
as each of these technologies warrants a large book of its own. Needless to say, what is
presented represents the most important issues, which should not be overlooked during
Before addressing specific site building best practices, we must acknowledge a few
golden rules of Web development that any pragmatic Web designer should follow.
First, users won’t always place blame correctly. While that little display problem
or error message might really be due to a non-standards–compliant browser, will
users blame the browser vendor or the site owners and designers? It is unlikely users
will blame the browser, unless they are savvy in Web development practices.
Rule: Users often don’t blame browsers for site errors—they blame sites.
Regardless of who made the mistake, users do not want to be impacted by problems.
They are at your site to accomplish a goal, not to fight with error dialogs or address
This leads us to our second golden rule of Web best practices.
You might call this the “no exposed wiring” rule. Users don’t want or need to see
the behind-the-scenes operation. While some visitors schooled in Web design might
be impressed or curious to see your site’s plumbing, for everyone else, exposing such
things may cause users to be confused or to proceed with great trepidation. They are
leaving the correct construction and setup of the site to us; if we appear to break this
trust, they are unlikely to like the site.
However, don’t assume that just because users think a site works properly, that
it is necessarily a good one. Far too often Web designers are bending rules, creating
work-arounds, or just plain ignoring various Web specifications. Base cases are tested,
but extreme cases may be ignored or skipped. Something that looks right isn’t necessarily
right—you have to verify and test things. Know your site’s tolerances. If it is impossible
to build the site to fit all situations, define what situations it will fail under and make sure
everyone involved understands the limits Don’t wait to try to explain to a client or boss
why your site broke under some browser; address it up front. Finally, remember that
quite often people don’t necessarily notice a poorly constructed building until it topples
to the ground in an earthquake, and it is the same with Web sites.
Verify correct execution, and openly indicate limitations.
When mistakes in site construction do happen—and inevitably they will in such an
emerging field—acknowledge the problem and figure out how to address it. Do not try
to shift blame to tools or the medium. Skilled painters don’t blame their brushes, nor
should you blame your WYSIWYG editor because it generated faulty code. Either stop
using the editor, learn how to use it correctly, or fix any mistakes it makes. Also avoid
blaming the medium. The Web, with all its delivery problems, is what we have. Again,
the painter does not blame his canvas or his paint. Last and most important of all, do
not blame the users. While the painter screaming at people who don’t understand him
might be put up with as a temperamental artist, an engineer who berated his customers
for not knowing how to use his product would probably just end up out of a job. Web
sites aren’t art projects; they marry engineering and design, so tread carefully before
you start blaming users for not having the appropriate browser, connection, or the
sophistication to use your site properly. Address the problem and fix it to their liking.
We work for our users, not the other way around. The customer (or, more appropriately,
visitor) is always right—or at least must always feel right!
Browser Best Practices
The first aspect of Web technology to consider is the browser. As it is the interpreter of
our site, it is very important to understand a user’s Web browser and what capabilities
it has. The two most common browsers at the time of this book’s publication are
Microsoft’s Internet Explorer and Netscape’s Communicator/Navigator product.
Other browsers, such as Opera, are used, but not to the degree of the two most popular
browsers, so browser compatibility doesn’t seem a big deal to some designers. However,
there are numerous versions of each of the common browsers as well as betas—not to
mention just plain vocal users who might use something outside the mainstream and
then complain about compatibility. To address the problem of browser compatibility,
designers tend to take one of the following approaches:
■ Ignore the problem and assume everybody has the most common browser.
■ Warn the user that the site requires a new browser, but leave it at that.
■ Allow the user to self-profile and choose a version of the site that suits his
or her browser or situation.
■ Automatically detect and update pages to suit the browser and technology
■ Degrade seamlessly to the user’s capabilities.
To ignore the problem is not reasonable, unless you are running in a closed
environment like an intranet, or possibly an extranet, where you can define what
browsers the end users must have in order to use the site. On a public site using this
approach, visitors outside the browser range may have a poor experience, so often
users are warned through a message indicating technical or browser requirements:
Warning users of browser requirements is not necessarily the best approach, but
if you take it, clearly indicate the requirements and help users to find out how to visit
the site properly. If the visit will be catastrophic using their browser, you really should
lock them out of the site.
A slightly better version of the browser warning approach is to offer choices to the
user, rather than simply warning them. This might be called self-profiling, because you
ask users to make a choice based upon their particular browser version or technology,
as illustrated in Figure 16-1. However, be careful with self-profiling, since you are
asking the user to make a choice, and a wrong choice may result in a poor viewing
experience. Further, understand that self-profiling may require that parallel sites for
different browsers be created and maintained.
It is obviously better to sense or address user capabilities directly and to custom tailor error messages or pages to the user, but carefully consider the implications of
doing this. Browser sensing isn’t always easy, and it may require a great amount of
conditional logic or multiple versions of the same content. With browser sensing taken
to extremes, one could imagine a dozen different versions of a site, running in parallel.
Browser Detection Basics
If you decide to go down the browser detection route, you need to decide first what
you want to detect, what you plan on doing once you detect something, and finally
how you are going to perform the detection