Browsers' usage statistics for Reckitt brands' websites
Here below is attached an overview of browser usage by Users & Sessions across the top 20 or so Reckitt sites (representing almost half of all traffic). This is from 1 Sep 2021 to now (almost 6 months). The raw data is there as is a pivot.
Attachment 1 - Statistics overview
Browsers' support level
All browsers should be “supported” but the level of support is not universal. Tiered support model is suggested (Fully, Mostly, Partially, Untested) (there is a difference between supporting and testing proactively).
Basing on Browser support standards by Aviva and statistics provided above, Support matrix was built.
Browser | Priority level |
|---|---|
Chrome | A |
Safari | A |
Android Webview | A |
Safari (in-app) | B |
Samsung Internet | B |
Edge | C |
Firefox | C |
Opera | C |
All other browsers and earlier versions of those specified above | D |
“Priority level” definitions
The rating system that defines the level of browser support has been created to define what level of testing is required.
Priority level A – Fully supported
Testing is required.
All content must be available.
Layout must comply with the creative design unless there is a technical need not to do so.
All functionality must be available and work as required.
Priority level B – Mostly supported
Testing is required.
All content must be available.
Layout does not have to look identical to creative design (ie, degradation of visual appearance is acceptable).
All functionality must be available and work as required.
Priority level C – Partially supported
Testing is required.
All content must be available.
Layout does not have to look identical to creative design (ie, degradation of visual appearance is acceptable).
Core functionality must be available and work as required, however it may function in a more basic manner and enhancements do not need to be available.
Priority level D – Not supported
Testing is not required.
Note: “not supported” does not mean the browsers are blocked in any way, it simply means they are not tested (thus unsupported browsers could work as well as a priority A browser).
Key takeaways
At the top end, the design and functionality should mirror expectations, then with less important browsers we can deviate on design but still offer the functionality, then we compromise the functionality down to base and then there will be a bunch of browser variants that aren’t specifically tests but at the very worst, serving only HTML should still provide base level value.
Regional differences should be taken into account ( for example, QQ browser doesn’t show up much on a global scale, but it can represent 10%+ of traffic in some markets (China/India) etc).
We don’t need to support browsers to a strong extent when their manufacturers don’t support them already (e.g. IE. Base experience only).
Including JAWS into support will require having a license.
Regarding overall browser support, as we are to use progressive enhancement approach with the semantically correct HTML first and CSS on top, then we need to have basic support for most of the browsers.
Regarding screen sizes, we probably should define breakpoints rather than names of the screen sizes. . Screen dimensions are only one attribute.
We need to design with minimal breakpoints and breaking based on the content, not the device.