One of the most exciting things about Web development is the incredible speed with which we developers can generate rich, useful and complex applications without diving into the low details that many C/C++, Visual Basic, Delphi and other developers must address. Having worked with all of these environments, I'm still amazed by how quickly the Web can be used to deploy cross-platform, useful and very functional applications.
However, this capability comes with a price. Visual C++ 6.0 developers can write applications that are only supported on Windows 95/98 and maybe NT/2000. Conversely, Web developers are expected to write applications that work on Macs, Unix, Windows, and under Netscape, IE, and Opera. This would be fine if all of the browsers for those operating systems behaved the same way—but they don't. In order to write effective Web sites that display properly under a large number of environments, certain measures need to be taken.
Many Web developers have written pages that look great in a specific browser—but look terrible under different resolutions, operating systems or browsers. A bit of planning can go a long way, and will hopefully keep you from cursing IE/Netscape/whatever two thirds through your development cycle when you start to evaluate your pages under a different browser.
This article discusses steps that can save you development, rework and testing time. I'll admit that I don't always practice what I preach. In many cases I wish I had, when I'm well beyond the point of no return with my code and a rewrite simply hasn't happened. In other cases, I have decided against taking some of these measures simply because I have a very clear picture of the browsers that are hitting my various sites. In other cases, Intranet or corporate work mandates specific browser versions—making the problem quite a bit easier! You'll have to decide which of the following are relevant, but I recommend considering all of them before starting a new site.
Agree on Your Circle of Support
It's no small task to agree on the types of computers and browsers that should be supported. See the "Browser Coverage" discussion elsewhere on this site. This decision should be made early on, rather than left to the end where you're more rushed and have fewer options available.
Pick Your Browsers
Agreeing on browser support will require a good understanding of the browser options and users hitting your site. Unfortunately, when starting out a site there typically aren't log files that you can analyze because there are no pages or visitors! The next best option is to look at global browser averages—the browser marketshare chart on this site. These are a good starting point, and can help you decide what percentage of your potential audience you want to support. A future article will discuss some of the variances in browser percentages that you may see depending on the type of Web site, but the "Browser Coverage" article outlines a few issues.
Pick Your Resolution
Which resolution should you choose: 640x480? 800x600? 1024x768? Decide up front what you want to support, and stick to your decision once you've decided. My personal recommendations on this topic are as follows:
- 800x600 is a good compromise. With 640x480, your whole site design will probably suffer and be less effective for most people. Even a simple sidebar or navigation bar will probably be 150 pixels wide at a minimum, leaving inadequate space for content.
- Don't size for a fixed width. Your site should look good at 800x600, but don't restrict it to 800 pixels in width or you'll annoy users who run their browsers full-screen at 1024x768 or higher. Your site shouldn't even be fixed to a minimum of 800 pixels in width, so that it can collapse down to 640 pixels or less without looking too bad.
- Consider putting optional content outside of the dimensions you wish to support. If you need to put ads or low-priority info on your site, place it on the right side outside of the width that you have decided you'll minimally support. Studies show that users are drawn to ads and important notices on the right side more effectively than those buried on the left side bar.
- If you want pages to make a statement, assess them based on what you see at the top in the minimum resolution you want to support. In other words, if you want to support 800x600, assume that you have roughly 750x520 pixels to grab the reader before they decide to leave.
- Not all resolutions correspond to the same amount of content. Versions of Netscape will render fonts smaller for a given pt/px, and the Mac will frequently render differently than Windows. It's not safe to assume that 800x600 on your Windows machine under IE5.5 will look the same as an 800x600 user running NS4.08 on a Macintosh computer.
Set Up Your Test & Development Environment
Once you've decided which browsers you want to support, you have to be able to see what they are seeing. It's too hard to aim for compatibility based on what you read and feedback you receive. You need to be able to test your pages periodically using the environments that you wish to support.
Unfortunately, this is easier said than done. Consider the following in setting up your test environment:
- IE4 and IE5 can't be installed at the same time in the same environment. Consider separate boot partitions for each, or try the IE4 Compatibility mode which can be installed as an option for IE5. However, IE4 and IE5 are reasonably consistent in rendering and only generate problems if you use features supported in IE5 but not IE4.
- If you develop for NS4.0x, you'll generally find good compatibility with the whole NS4.x family.
- Netscape allows you to install separate versions concurrently within the same environment if you save them to different directories. This is a great feature compared to IE installations which are tightly coupled to the operating system.
- Netscape compatibility is pretty good across platforms, although sizing and fonts display differently across operating systems.
- NS6.x isn't backwards-compatible with NS4.x for some common features. Check out the Detailed Browser Chart for more information.
- Opera can be installed along side other browsers without problems.
Most sites will probably need to test with Netscape 4.08, Netscape 6.0, IE5.x for Windows and IE5.0 for the Mac. I usually test with the first three, and check with IE5/Mac and IE4/Win on a periodic basis. By following some of the steps in this article, you can reduce your testing frequency on the less common platforms.
Make Feedback Easy
You'll be more likely to receive feedback if you make a "Contact" link easy to find on each page. You should avoid "mailto:..." if possible, because this engages the user's email and requires their personal email address. Instead, consider a contact form where they can send comments via forms through CGI/PGP/etc without requiring an email address. This is easier and anonymous, and can still let the users supply email addresses if they would like feedback. The more fields you place in this form—browser, version, OS, time, URL—the better. And by clicking on the contact form, the receiving page should be able to catch the HTTP_REFERER environment variable to log what page they came to the contact form from—giving you a hint as to where the bug/problem may exist.
Summary
Web sites don't have to be buggy, and cross-browser development doesn't have to be painful. If you can incorporate four key steps into your development process, your sites will be more robust, more compatible and written more quickly. These steps are 1) planning, 2) testing, 3) reducing written code and 4) knowing your audience. Following these steps takes time up front, but pays off significantly in the long run. |
Effective Cross-Browser Web Development
