Jarad Light — Front-end Developer
Jarad is a proud son of Surrey and chooses to leave the City of Parks only when he needs to come to work or when he feels the call to travel to exotic Asian destinations.
When discussing a project with a client, we find it is important to ensure that all parties involved understand what browsers will be supported, and what happens on those which are not.
Clients may have a general understanding of what browser support entails, but it can lead to incorrect expectations about what a project's supported browsers are. Even if browser support is well understood there are many variables between platforms, features, fallbacks, and more that should be discussed at the outset of a project.
If browser support is not discussed and agreed upon, a number of problematic events could occur through the course of the project:
Let's go over some talking points we use when discussing browser support use in client meetings, and then outline some base browser support tiers.
How can we determine what browsers a project should support?
At Fuse, we start with a baseline of support which we feel covers most projects. It doesn't have to fit every project, and probably won't, but having a starting point saves us from recreating browser support tables every time and can be tailored to suit the project specifications.
Some things to keep in mind when discussing browser support with a client:
Important factors in determining browser support include the following:
When available, be sure to review the analytics data for the client's existing project. As browser usage varies between industries, companies, and individual websites, getting the most accurate data possible about the client's specific project is critical to making informed decisions about browser support.
For example, if less than 1% of the visitors of a current site use an obsolete browser, is it really worth the client's money to support it? Similarly, if the analytics shows that a large percentage users are using an older browser, how should an important modern feature in the project specification be handled?
Complex or modern features are often difficult and sometimes impossible to implement in some browsers.
What features are present in the project specification? How critical are these features and how many of them are there? Are fallbacks or enhancement features for a technology available and/or appropriate?
If there are not enough resources (time, money, developers) to support a feature set on an older browser then priorities may have to be adjusted based on the project's feature requirements and tempered by realistic application of available analytics data. Inversely, a project with a larger budget will have more room to improve support on older browsers, but may still have to compete with other development requirements for additional resources.
Should a client request an outdated or obsolete browser be supported, we should determine why they find support for that browser to be important. Sometimes it is simply that they want to have their site be usable by as many users as possible, but do not understand the amount of resources required to support it.
This is an opportunity to discuss the budget implications and the facts about their users. If the client would still like to support an older or unsupported browser, then we can make modifications to the base browser support tiers (and budget), discussed in the next section.
Determining a base browser support system allows for a solid starting point during browser support discussions with a client. This base level of support should be used as an outline and can then modified if necessary for each project. This system was inspired by BBC's Browser Support Standards, but modified in order to be a more flexible starting point for use on a per-project basis.
The four support tiers are outlined below. All browsers should be categorized into one tier.
The page should appear and function as outlined in the design documentation, mockups, prototypes, etc.
With some reservations, the page should fully work in this browser. All content is readable, interactive elements work as outlined in the project specification, visual flourishes appear as intended, and so on.
As there are always browser inconsistencies, and because it is possible that specific issues cause problems with one or more features of the site, it is not possible to guarantee a 100% identical experience across all browsers. However, affected browsers in this tier will include a workaround, fallback, or alternative to alleviate issues as much as possible.
The browser is able to render the page in a reasonable manner, but will not likely be able to include all features.
Where necessary, fallbacks are used in place of incompatible effects, cosmetic flourishes, and other elements and effects not critical to the consumption of the page content by the end user. Fallbacks and alterations may range from exactly matching the behaviour of a supported browser to being completely omitted, and depends largely on the feature in question.
This browser is unable to render the page due to one or more technical limitations.
Efforts will be made to provide a visitor using this browser to view content in a reasonable, basic format. Any enhancements past a basic presentation of the content requires a separate audit and estimate.
This browser is not considered at any point during the course of the project.
An obsolete browser is not supported in any capacity. Clients wishing to support an obsolete browser to any degree must inform the developer before project work begins.
It is important to have a game plan for browser support when starting a new project. Clearing up any misconceptions on the subject early on helps to avoid any potential misunderstandings during the development process. The suggestions above are not a hard and fast rule, and should be adjusted to fit your team and client projects.