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
Diagram 1 - Distribution of users per Reckitt branded websites, % (last 6 months period)
Diagram 2 - Distribution of sessions per Reckitt branded websites, % (last 6 months period)
Browsers' support level
Reckitt’s services must be universally accessible. In short, our digital experiences should work on every browser or device that our users access it on. However, it is accepted that the experience will vary according to the technical capabilities of the browser and device.
Not all browsers will render web pages in the same way, and that is ok – but critical content should remain available and functional. 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).
Inspired by Browser support standards by Aviva and statistics provided above, Support matrix was built.
Browser | Priority level |
---|---|
Chrome | A |
Chrome Mobile | A |
Safari | A |
Safari Mobile | A |
Android Webview | A |
Safari (in-app) | B |
Samsung Internet | B |
IE | B |
Amazon Silk | B |
QQ Browser | C |
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.
Level A: Fully supported
· Real world testing is required.
· All content must be available.
· Layout must comply with the creative design.
· All functionalities must be available and work as intended.
Level B: Mostly supported
· Real world testing is required.
· All content must be available.
· Layout may degrade from design, looking professional but not identical
· All functionalities must be available and work as intended.
Level C: Partially supported
· Must be tested, but a mix of real world and automated/emulated tests are acceptable
· All content must be available.
· Layout may degrade from design, looking professional but not identical
· Core functions must deliver the same outcome, but can be delivered in simpler ways.
Level D: Not supported / Untested
· Testing is not required.
· Design and functionality relies on strong progressive enhancement to deliver a base experience without the need to test.
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.