Keep users happy by using savvy scripts
Serving user needs
Developers can rely on a variety of techniques to meet the needs of all anticipated users. The no-pain and no-gain approach: design to the lowest common-denominator user, restricting or leaving out technology that might cause problems for some visitors. Some sites list on the entry page which browsers and technologies are required to fully appreciate the Web site — with links so visitors can download any needed accoutrements.
Before you do any scripting, it’s important to understand both the intended audience for your site and the proposed content. You and your development team must carefully study any available demographic information and server statistics that will help you know what to expect of the target audience — the browsers, operating systems, monitor resolution, plug-in technologies they are likely to have, for instance. (See “The rock bottom lowest-common-denominator”.) Then you can determine how to meet the needs of that audience by providing the best possible visual and technical experience. (See “Route for technology, not content”.) Delivering the design and technology with consistency and clarity follows from there.
Understanding site content demands that you sit down with the client, organization, or colleagues involved and study the mission of the site. Having specific goals helps you to define what kind of options you will need to script. For example, if you anticipate a lot of Internet Explorer-centric DHTML on the site, but you need to support users without IE, you can plan for a script that routes non-IE users to a more accommodating page.
The rock-bottom lowest-common-denominator
Once you’ve clarified the site intent and audience and made your basic design decisions, you can turn your mind to what kind of detect-and-route scripts you’ll need. For instance:
• Does your site design used fixed tables to hold design elements securely and specifically in place? In that case a resolution-detect script will be very helpful for you.
• If you’re making extensive use of cascading style sheets (CSS) and dynamic HTML, routing by browser will help your audience members enjoy your site — no matter what browser they’re using.
• When you’re interested in delivering strict HTML 4.0 or browser-specific technologies such as ActiveX components, browser detect-and-route is invaluable.
• Browser detects can help ensure that site visitors who don’t have a necessary plug-in can be sent to a page without the technology that requires it — or to a page where information on the plug-in is available.
Once you know what scripts you need, you decide whether to write your own or to adapt existing scripts (see Resources).
Route for technology, not content
There’s a danger in assuming too much about your audience: you might assume incorrectly and cause user frustration. I have seen Web sites that put barriers around content with overambitious routing scripts. Consider the visitor who, using a Windows machine at work, is looking for information about the family’s Macintosh computer at home. If, as the site developer, you assume that someone using a Windows machine wants only information about Windows, you’re overstepping the line. Aim for serving your visitors, not tightly controlling their experience. Guide your visitors based on what they can support technically, rather than making guesses about what content they want.
Finding scripts or rolling your own
The choice to select prewritten scripts or develop your own really depends on your needs, your time, and your skills (or your team’s). If there’s something suitable out there that is freely available (see Resources), why reinvent the wheel? You can always adjust the existing scripts to meet your needs. On the other hand, if you have very specific requirements, you may need to custom code your detection scripts.
Next, I’ll take you on a brief tour of detect-and-route scripts so you can get a taste of what these scripts can do for you.
Detecting the details
The script begins by detecting the Operating System and stores that information so it can be used later, as shown in Listing 1.
Listing 2 shows the part of the script that defines variables that assign information from the browser to the script results.
Listing 3 collects additional information that’s available only from 4.0 browsers. It’s a sniff for more detailed information. (Cookies respond only to Internet Explorer 4.0 browsers and above, and the CPU test returns an unknown in Navigator.)
To test the script, add the contents of Listing 4 to the body of an HTML document and then view the HTML document in a variety of browsers. I’ve included some HTML to make the resulting code attractive (and legible in the reduced image used in Figure 1 and Figure 2).
The whole script within the context of a complete HTML document appears in Listing 5.
Figure 1. This is what you see if you load the test page with Internet Explorer on a Windows 98 PC
Figure 2. Compare the results of loading the test page with a Mac of recent vintage running Netscape Navigator
Routing by browser type
One of the most common uses for these detection scripts is to route different pages for different browsers. The very simple script in Listing 6 sniffs for Netscape or Internet Explorer and allows you to redirect to a page specifically designed for one browser or the other. This makes it possible to use browser-specific technology when your audience would expect it without making other users feel left out.
Here’s how to make it work:
• Design a page for Netscape Navigator. In the example script, I’ve named it nn_index.html.
• Design a page for Internet Explorer. I’ve named it msie_index.html in the example script.
• Create an index page with the sniff-and-route script included, as shown in Listing 6. Leave the body of the index page empty.
When I loaded the index page of my sample site with Microsoft Internet Explorer, it sent me immediately to the IE page, shown in Figure 3.
Figure 3. Thanks to the script in Listing 6, the index page sent me to this page that fits the browser I used to test it.
Matching pages to display resolution
If you’d like to test and route for screen resolution, the script in Listing 7 does the trick. Of course, first you need to create pages for the different screen resolutions you plan to accommodate. You don’t need to identify the resolution-specific pages by name — the script automatically handles that. Then create an empty HTML document with Listing 7 in the head portion.
In the opening body tag of the HTML document, add the following statement.
Save the page as a default or index page. Then test the script by changing your screen’s resolution several times and reloading the page each time. Using this script, you can create designs optimized to the resolution dimensions of your audience.
Testing your scripts
Finally, it’s important to deliver your scripts cleanly, and with consistency. Whether you write your own scripts or choose them from a library, test them vigorously in a variety of browsers and with several types of computers in order to ensure that they’re working well.
• Consult current general browser usage and technology statistics
• Find a detection script:
• At the DevHead library
• At Developer.Com, which includes some browser detect options
• At Code Archives
• Learn to code your own detect scripts with Joe