Planning for and Managing Browser Support
- Setting a browser support policy
- Maintaining a browser support policy
- Summary
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Once upon a time, the Web was littered with sites boldly proclaiming “Optimized for Browser X” and “Sorry, only Browsers X and Y are supported”. It took a while, but Web professionals helped tear down these roadblocks by demonstrating that broad support for browsers meant more business and more engaged users. Most businesses have learned to like Firefox, Safari, Opera, and Chrome as much as they once liked Netscape Navigator and Internet Explorer.
But with a flurry of new browsers hitting users’ computers and mobile devices this year – including Internet Explorer 8, Firefox 3.5 and 3.6, Safari 4, Opera 10, and multiple releases of Google Chrome – everyone involved with the Web has had to scramble to ensure that their sites are compatible with the latest and greatest. This has left many Web professionals and business teams wondering, “What browsers should my site support?”
Yes, these are the times that try the patience of Web designers, developers, quality assurance analysts, customer support specialists, and – most of all – our users. Web professionals who’ve been around this block before know enough and can improvise a plan for supporting new browsers, but still, many don’t prepare a formal browser support policy until it’s desperately needed.
There’s no time like the present, so let’s get started!
Setting a browser support policy
Browser support policies vary from site to site, company to company. It’s important to come up with a policy that reflects what your users expect support for, as well as what you and your Web team can support.
While some Web site owners assume that the whole world uses the same browser that they do, and couldn’t fathom using or supporting any other browser, we Web professionals know better. However, we also know that there are limits to supporting different browsers, so supporting every single browser ever made is also not practical. So where do you start?
Know your audience
If you already have a site up and running and are trying to start a browser support policy, you should focus on making the best experience for your existing users. Finding out which browsers are already being used to access your site is the best way to determine which browsers you need to support. Usually this data can be obtained by reviewing your site’s log files – a rather messy affair to do by hand. However, there are a variety of tools which can more easily crunch the numbers for you.
One popular log file analysis package is AWStats. Many web hosting providers include this software in their control panels, or you can download and install it yourself. AWStats will examine your Web server’s log files and give you a breakdown of which browsers were used to access your site. An example of its browser report is shown in Figure 1.
)
Figure 1. AWStats Browser Versions screen.
If you don’t have the ability to install or run a log file analysis tool on your server, you may want to look at a hosted analytics solution instead. Both free and paid solutions are available, and implementation is as easy as calling a third-party JavaScript file on each page of your site.
Google Analytics is a free and easy way of getting started. Once you sign up for an account, you’ll be given some JavaScript to embed in your site’s pages; the scripts will run when users access your site and will send information about the user’s browser back to Google. An example of a Google Analytics report is shown in .
)
Figure 2. Google Analytics Browser Overview screen.
These tools will give you reports for any amount of time. You will need to run one quarterly report for the past three months to set a baseline of browsers used and their overall popularity; then run a monthly report for each of the past three months to take note of any trends, such as adoption rates of a new browser.
If you’re starting a new site and thus don’t have any visitor data to analyze, you may want to refer to some of the Web-wide metrics reported by sites like TheCounter.com and OneStat.com. While your site’s statistics will surely vary from these averages, they’re a decent place to start.
Narrowing the list of supported browsers
Ask an uninformed Web site owner which browsers they want you to support and you’re likely to get a response of, “All of them”! But most Web professionals know better than to agree to fully supporting all browsers on all platforms.
Sure, you could spend hours searching blogs and articles for techniques to make every design feature or behavior work identically across browsers and platforms. You’ve probably tried this once or twice, just to test your chops, right?
But, as your stats will likely show you, users will ping your site with about 20 to 40 different browsers (between versions and platforms) per month – for large portals, this number is easily over 200 browsers per month! (Did you even know there were so many browsers?) Realistically, you want to be putting effort in to the browsers most commonly used by your audience.
For example, if 30% of your users are still on IE 6 and only 5% are on IE 8, you still need to code some of your features for and test against IE 6. On the other hand, if you have only 2% of IE 6 users, you may be able to sunset support for that browser.
Ultimately, which browsers you decide to support is up to you and your Web team – but I suggest starting with the browsers which make up 80-90% of your audience. This will likely include some versions of Internet Explorer, Firefox, and Safari. Still, even this mix of browsers can be difficult to support, so how can you narrow that list further?
Browser ‘support’ is not always equal
Assuming your site is already built to follow best practices such as POSH and progressive enhancement – concepts explained in this chapter from Adapting to Web Standards – your content is likely accessible to most or all browsers in common use. However, your design or scripted behaviors may not look or work as expected across all browsers and platforms, and this is the cause of most browser support grief.
For years, large sites had internal or unofficial policies regarding differing levels of support for browsers. These were based on the age of a browser, the number or percent of users on a browser, or the set of features supported by a browser. Yahoo! let the cat out of the bag a few years ago when it publicly documented its Graded Browser Support policy.
Today, it’s much more common for smaller sites to do the same. This allows Web professionals to invest their time more wisely – no more investing 80% of your work to support 20% of your users.
For example, if you use rounded corners extensively in your design but have a small IE audience, then you can consciously decide to limit design feature support for IE, and just use the CSS border-radius property for the browsers which support it. Or, even if you have a large IE audience, you can stick to the border-radius method and message IE users to upgrade to IE 8, or use an alternate browser, for a more refined experience.
Documenting your browser support policy
If your browser support requirements are fairly simple, you may be able to get by with a short statement, such as the following:
All content, design, and behavioral features of this site must work without issue on Internet Explorer 7 and 8 on Windows, and Firefox 3.x on Windows, Mac, and Linux. (Feature support on other browsers and platforms may vary.)
Large, feature-rich sites and Web applications will typically have a much more detailed browser support policy, like the matrix in Figure 3.
)
Figure 3 Detailed browser support matrix.
Ultimately, the way in which you document your browser support policy is up to you – just make sure the documentation is detailed enough for everyone to set expectations on how their work will be impacted and understand how users will be impacted.
Also, be sure to communicate the policy to your peers and your boss (or client) and take the time to answer their questions, so that everyone is on the same page. Of course, you’ll want to message users as well, so plan those workflows and designs carefully! In particular, if you need users to upgrade for better feature support, take the time to carefully craft messaging and support documentation – otherwise your users may stop visiting your site and could seek out a competitor’s site.