How best to determine browser support?

At Ecce Media we mostly build things on the web. Meaning we mostly build things that are rendered by the browser. The choice of which browsers being used is therefore left to our customers’ customers.

Fine-tuning a design to function consistently well across all these different browsers, devices and screen sizes eats up a decent chunk of a project’s budget. That’s true on pretty much any project.

Cross browser support has been a hurdle since the earliest days of designing for the web. Automated tests, build processes and device labs have modernised technique, but the underlying issue still remains.

So what browsers should your website work on?

In an idealised world, all of them. In reality, with finite budgets and an ever increasing list of browser/device combinations there’s going to be a cutoff point. The question is: how do we best determine this cutoff?

Some clients will have already defined this in their brief. But if this hasn’t been clarified there are a few common approaches to take, each with their own pros and cons.

The hard and fast list

Here you spell out a whitelist of browsers that you support. Sometimes this list might be company wide policy, spanning every project you work on. Periodically you will need to review this list and update your policy.

Upsides

• Easy to establish a standardised process/workflow amongst your team
• This list of browsers (and policy) is easily conveyed to clients

Downsides

• Doesn’t address specific project requirements well. Some clients, like local governments are forced to use ancient versions of IE which could easily be outside your preferred whitelist
• Project documentation and contracts could become out-dated if not updated with policy, leading to increased admin per project and client

The two back rule

A variation on the hard and fast rule. Here you specify support for only two (or whatever number) versions back from the most modern release of each browser. You may change the number of versions you go back on a project by project basis.

Upsides

• Easy to establish processes and maintain using build tools like post-processors with this type of machine-readable rule
• Easy to define as a rule in project documentation
• By its nature it keeps you working with only the most modern stack

Downsides

• Hard to convey what this support actually means to customers. They’re unlikely to ever know what version of a browser is currently supported as part of their contract with you
• This still doesn’t cater for clients whose target audience can’t (or won’t) update to modern browsers

The metrics approach

I hadn’t heard of this method until a recent episode of Shop Talk Show. Here the rules you set out are actually usage metrics. For example you only state support for browsers used by more than 10% of site visitors. You’ll then delve through their analytics to establish which browsers meet this threshold.

Upsides

• Best targets the specific requirements of your client and their project. Potentially leading to less ad-hoc support issues

Downsides

• More time consuming to define and keep up to date
• Impossible on a new site — or one with no previous analytics
• Harder to convey this level of support to the client without more involved communication
• The limit on browsers supported becomes indistinct. Some usage thresholds might yield a list of browsers far longer than the first two options

So which wins out?

As with anything web design, it depends™. Picking an option that exactly fits the usage requirements with cold, hard metrics seems the obvious winner. But it does come at additional cost, the sort of cost that some clients are less keen to spend budget on. The fun comes with conveying that benefit to the client.

Which approaches do you use? Did I miss anything out?

Originally posted on eccemedia.com