A Strategic Guide to Browser Interoperability

When building sites, the tendency we have is to use familiar tools. The idea is that the more comfortable we are with our development environment, the more effective we'll be in cranking out content and source code.

One of our most important tools is our Web browser. It tells us how we're doing, whether our code works, and more importantly, whether our pages look good. Overall, the Web browser is one of our primary testing tools. But for this role, we can't just have one, we have to have several. So how do we effectively strategize mixing various browsers? Step right this way, and I'll share a few tips.

Know Your Audience

If you already have a Web site up and running, your log files will make it easy for you to know who your audience is. Most Web servers save accesses to your site in a log file—typically derived from the W3C draft ELF, or Extended Log File Format. This log file includes significant information regarding your incoming visitors, including the user agent for the software used to access your site. This agent can help you identify incoming spiders and index crawlers, but it's also valuable for knowing the types of browsers being used to view your site.

You can analyze this log file using any number of log analysis tools, or hook up with a counting service to provide you with analysis of statistics. Either way, you'll need a tool that tells you what browsers your site should be able to handle. Without this, you'll either exclude a significant percentage of your users, or waste time on browsers that simply aren't pointed at your site with any frequency. Note that some browsers—at this point, namely Opera—can spoof other user agents, so you may not get an accurate representation of all browser types.

"With new browsers come new features, but also new bugs and incompatibilities."

To whom do you want to target your site? The easy answer to this is: most of your users. You'll have to decide what your cut-off point is. Do you want to be Lynx-ready? Do you want to support bleeding edge? Are you willing to risk that the 15% you exclude aren't a critical part of your audience? There are a number of things to consider.

Do I Support Old Browsers?

If you decide to include support for old browsers, you can expect the following:

• You will have increased maintenance costs as you duplicate some functionality to ensure that it's displayed properly. Examples? Fancy JavaScript and DHTML interfaces and effects—e.g. client-side hierarchical trees for navigation—will need to be duplicated in a more classic form for the unsupported browsers.
• Your site may be a lesser experience for those individuals using leading edge browsers. Unless you want to maintain duplicate versions or portions of pages, you'll have to keep some features reduced for the sake of compatibility.
• You'll be fighting a losing battle as new technologies emerge. Already you can find many Web documents that are XML-based, or that rely on Flash or plug-ins, and so on. If you're in a position where you're competing with other sites, you'll have to weigh the benefits of broad compatibility with an inability to adopt new technologies.

If you decide to exclude support for old browsers, you may hit the following snags:

• You may exclude key demographics. This may include schools, public libraries, Internet cafes, new users, users with disabilities, and Internet users in foreign countries. To explain a couple of these: New users typically stick with the browser software on their PC or that supplied on their ISP's CD-ROM; foreign users may use foreign-language browsers which can be behind in versions; public libraries and schools often don't have the latest software, nor do they have computers with sufficient power to drive the latest operating systems and browsers.
• You may have the temptation to implement unnecessary features in your system. There's some benefit for certain types of sites to stay simple, low-bandwidth, and compatible. One of the great appeals of many of the successful sites out there is the fact that they're simple, inoffensive, and accessible. A site like Yahoo wouldn't benefit from twice the download size and 85% of the available users. Instead it goes for as close to 100% of the users as it can, and keeps the experience as lightweight and efficient as possible. This makes sense for Yahoo, but not for all sites.

Do I Support Macintosh? Unix?

On the Web, Windows makes up the dominant percentage of users. It'd be nice if testing your page with IE 5/Windows meant that it worked on IE 5/Macintosh, but it doesn't. If you want to support multiple platforms, consider the following:

• Testing will increase significantly. You're not testing several browsers on one machine, but testing several browsers on a few different machines. Your greatest risk right now is between IE on the Mac/Windows, but you should test Netscape on at least one Macintosh and UNIX machine to convince yourself that your pages work. This is particularly true where you leverage more complex capabilities—NS LiveConnect, Java Applets, or detailed use of DOM/CSS.
• Your test bed is more costly—rather than being able to do your development on one machine with a few browsers, you'll need to access multiple machines. Most developers don't own separate machines for testing on Solaris, HP/UX, Macintosh, Windows, and Linux.
• You exclude technologies such as ActiveX and some plug-ins.

On the other hand, excluding non-Windows OS testing could be a real mistake:

• You may be losing users who have an interest in your content. Schools have a disproportionate number of Macintosh systems. System administrators and Web developers are represented by a high number of Unix machines—compared to global Internet averages.
• Don't assume that your site is only for Windows users. For example, if you run a Windows 2000 "Tips and Tricks" site, you may not realize that many system administrators are Unix and NT administrators who work predominantly from their Unix machines.

Should I Integrate Complementing Technologies?

More and more sites on the Web are Flash-optimized and can be quite visually impressive. Plug-ins and helper applications that supplement the browser's capabilities make streaming content much more available. ActiveX controls and Java Applets can create powerful and full-featured Intranet portals and dashboards.

These new capabilities create a much richer experience for users when implemented properly. But this isn't always the case. For example, for each excellent Flash site, there are a number of cumbersome and awkward Flash implementations. Also, streaming content sites frequently supply multimedia that requires more bandwidth than your ISP, your connection or the network path between you and the host can provide.

If you're going to rely on applications or plug-ins to extend your site's capabilities—Adobe Acrobat, Real Audio, QuickTime, Winamp, Windows Media Player—then you have to consider the following:

• Will my users be interested in higher bandwidth offerings?

• Can my network and hosting model support higher bandwidth offerings?

• What platforms am I excluding by offering these multimedia options? Can I make it easier for them to find the right applications, viewers, and plug-ins?

• Could I accomplish an equally effective and impressive GUI without relying on yet another technology?

• Am I willing to test this plug-in/app on multiple applications and configurations?

• Am I creating an additional maintenance effort for myself—such as requiring PDF/HTML synchronization or Flash/HTML synchronization?

Do I Support New Browsers?

It's important to keep an eye on your users to see how fast they're adopting the new browsers. With new browsers come new features, but also new bugs and incompatibilities. Another disadvantage of early adoption is that you'll find less support in the form of answers and help when you run into problems. The newsgroups and support forums are an invaluable resource when you hit JavaScript, XML, HTML, Java, or other snags. If you encounter a problem with one of the new browsers, the odds that someone has already answered your question go down depending on the newness of the browser.

On the flip side of all of this, if you don't test with the new browsers, you won't know what advances or problems are coming down the pipe that you should be considering. New code and content that you're writing may be going in the wrong direction. For example, if you're working with JavaScript code you'll need to consider the huge differences between Netscape 4.x and 6.x due to the new Gecko rendering engine.

Know Your Tolerance For Defects

Here's an important question to ask yourself—just how many bugs are you willing to tolerate on your site? It may be easy to say, "zero," but you'll have a hard time keeping that promise. Certainly, you can run Linklint or a similar tool to ensure that your links are intact, but Linklint doesn't catch bad queries or missing includes—all of which can create an HTML page that's not a 404 unless you handle them specially.

"A Web design company had better not have bugs and broken links on its site if it expects to impress potential customers."

If your Web site caters to a small or informal audience, your bug tolerance will be much higher than if your Web site is your corporate statement. A Web design company had better not have bugs and broken links on its site if it expects to impress potential customers. The number and type of defects you're willing to tolerate will determine the complexity, cost, and frequency of your testing.

Regardless of your type of site, you should also realize that defects can significantly deter the quality of your site's reviews. Do you know what type of browser Yahoo reviewers use? How about ZDNet? What about Open Directory Project editors? I assure you that a buggy site will not get good reviews—if a reviewer happens to use Opera, they'll expect good sites to look good in Opera.

Conclusions

I've raised a number of questions here, but many of them are left open and not fully answered. The type of site(s) that you run will largely determine the scope of your testing and support. Some may aim for close to 100% support, while others will focus on an OS or browser.

In keeping with the spirit of the Web and the Internet, I'd like to say that we shouldn't exclude anybody, but I know that's not feasible. A number of forces are at play that keep any one standard from being unilaterally adopted. Until then, we have to decide how large an audience we want to support, and how far we'll go to support them. In an upcoming section on browser testing methodologies, I'll outline some strategies that you may wish to consider when deciding how far and how deep to test your Web systems.

Steve has been working with Internet and related technologies for over a decade. His primary "off-hours" hobby can be found at lookoff.com, a repository for Internet and researching information and resources.