Browsing Challenges
More of a challenge is posed by the rapid evolution of browser technologies and their usage. Data.gov.uk reports (March 15) that the most common browsers accessing its sites are Google Chrome (49%), Internet Explorer (23%), Safari (12%), Firefox (11%) plus 13 commonly-used other options including Microsoft’s new Edge offering. This was a big change in usage from a year earlier when Government Digital Service analysis showed Chrome usage at only 27% whereas Safari usage had peaked at 25%. For digital services providers, the implication of these rapid changes in customer browser behaviour is that they will need to constantly update their services, potentially resulting in higher costs.
This constant change and range of code versions also throws up a number of technical challenges:
-
TESTING – Testing the plethora of new software releases (Google Chrome issued eight new versions in 2015 alone!) and identifying which features different browsers actually support
-
STANDARDS – New browser versions often don’t implement the standards (which standards?) correctly which results in a faulty user experience when it comes to, for example, tables, drop down menus or text encoding
-
LEGACY BROWSERS – Many users will be using older browsers (Data.Gov.uk site usage shows over 70% of browser versions are more than a year old) and public sector departments often have standard desktops using older technology
-
END OF LIFE – Older browsers present challenges when vendor software development support ends. This can cause issues such as keeping up to date with which browsers support the latest security certificates at any given time.
-
RESPONSIVE DESIGN – Users access the internet with a variety of devices -from desktops to mobiles with different sizes in between. Varying the design in direct response to the size of the device being used is a considerable task, especially when some browsers such as older versions of IE struggle with HTLM5 specifications for example
-
AGILE – Re-use of existing development code can be another challenge. Browser changes often entail additional new code development to ensure a good responsive user experience across multiple platforms. The result being higher development project costs and longer project timescales.
A Few Suggestions To Ease The Pain
At Toplevel, we would ordinarily recommend leveraging the functionality of a development platform like our Outreach product rather than embarking on a bespoke development to address the issues around building crossbrowser solutions. However, if you are committed to the latter route, here are a few suggestions based on our experience to help your developers avoid some of the pain when developing for multi-browser environments:
HTML5 & IE
There are some parts of the HTML5 spec which older Microsoft IE browsers (e.g. IE8 and under) do not handle well. IE can completely ignore parts of your HTML code, due to the mismatch in coding specifications. An example of this is where the header, footer and nav tags do not get read properly and cause issues with the Document Object Module which can lead to garbling of the page’s structure or even for code following the tags to not get rendered at all. Numerics are another common issue; ‘order numbers’ can appear as a phone link on mobile devices.
OUR TIP
The best way to address this is to use a shiv (JavaScript code which can fill in the blanks) such as HTML5shiv.
Feature detection vs user agent handling
User agents which provide information such as the browser type, version and operating system can be an unreliable way of tracking the support and capability the end user's browser might have. First, it may not accurately determine the browser that is being used. Second, even if the user can identify the browser, they still have the difficulty of figuring out what features that browser might not support and handling them for all the different browsers.
OUR TIP
Feature detection libraries are a great way to quickly determine what is and isn't supported in the various browsers; these do all the grunt work for you in bringing up the other browsers to HTML5 standard (or as close to it as possible); we would suggest trying Modernizr or HTML5 Boilerplate.
Compatibility testing
OUR TIP
There are a number of useful sites that allow you to quickly view your site in a wide range of browsers. One that we use is BrowserShots (browsershots.org), although you will need to ensure that you have public facing internet access.
CSS style variation
Browser incompatibility is often caused by browsers having different internal CSS styling, for example form elements such as search boxes and dropdowns often appear differently.
OUR TIP
One way to address this is to use a CSS file such as Normalize.css or HTML5Reset to 'reset' this internal styling and standardise styling across browsers.
Handling of tables in responsive mode
When content is required to be side-by-side by using two or more columns, the multiple columns will need to collapse into a single column when the viewport changes to a smaller screen size. This can cause the content to jump from one place on a page to another and become out of context, which can confuse the user.
OUR TIP
Browsers handle the transition of re-sizing content differently, so it’s important to plan how the content will shift as the size of the browser reduces and expands in size. We suggest a progressive enhancement approach. This means designing first for the most limiting form factor (e.g. text browsers, or more relevantly, mobile phones) to ensure it looks good on those. Then building on top of that for more advanced features, like better user experience on larger screens.
Invalid HTML/CSS
Invalid HTML or CSS can sometimes be handled automatically by browsers such as Chrome and Firefox. However, not all browsers will be able to do this.
OUR TIP
Check code for validity using guides such as W3C Validator, which will identify specific problems in your code base. Clearly, best practice is to use tools such as W3C Validator as you go along. However if you have complex projects with multiple developers and fundamental errors in the way code is written, this can (and does) result in fundamental re-writes. In this scenario it may be worth looking at a mobile development platform where issues can be addressed by simply changing the wrapper.
Text encoding
Browsers can vary in how they determine the text encoding of a page, which can result in certain characters becoming garbled. A particular example of this is the pound sign, which has a different representation in iso-8859-1 (Windows) and utf-8 (Most other platforms) encodings.
OUR TIP
The best way to avoid this is to enforce an encoding in a meta tag in the HTML, as well as using problematic characters in their escaped form (escaped characters usually start with & and end in ;) such as the pound sign (sometimes represented as £ instead of £) which means it won’t get garbled.
Accessibility
Clearly visual browsers are not the only way to access your website. Employees or citizens may be utilising a screen reader (such as NVDA or JAWS), or even a text-based browser such as Lynx or WebbIE.
OUR TIP
Features such as images, dynamic elements using JavaScript and tabulated data should have extra handling for non-sighted or partially sighted users such as adding alt tags, utilising ARIA roles and attributes to indicate whether an element is dynamic and the state it is in, and properly structured table data so that it is interpreted and read correctly by the screen reader). A couple of other areas to watch out for in our experience;
-
Safari and screen readers - Safari can struggle with handling markers for page identifiers and can mismatch elements such as radio groups.
-
When Javascript is disabled for text based browsers this can add a lot of work to create fall backs for dynamic content. Again a platform development approach may be a good option here.
Testing
Software updates for browsers and mobiles are relatively frequent, for example there were eight versions of Google Chrome released last year and the May release included an XML object change that resulting in a general error message.
OUR TIP
Regular test across all your browser types and review forums to see if there is publically available information on issue and fixes. The other option would be to utilise a development platform that picks up and addresses these issues automatically.
4
Alternatively, An Out Of The Box Solution Could Be Easier...
If a bespoke development approach sounds like a costly and time-consuming challenge, one option may be to use an Agile development platform like Toplevel’s Outreach COTS product to simply standardise user experience across all your browsers with less time and cost and address many of the issues we talk about above!
Outreach is browser-independent, provides open source extensions (including a GOV.UK toolkit) and supports all common browsers out-of-the-box, reducing testing and development effort as well as time to deliver.
Our R&D programme keeps us up-to-date with browser developments on desktop PCs and mobile devices, whilst responsive design themes allow the system to tailor/ rescale the user experience to the device type. Capabilities in many new browsers have allowed us to create a mobile data collection module which allows data collected to be stored on the device for later encrypted uploading.
In terms of legacy browser support; this extends back to 2001 and includes:
-
Internet Explorer version 6 and upwards, Firefox 1.5 and upwards and Google Chrome (any version).
-
Browsers that support HTML 4 / XHTML 1.0 and CSS, including Safari on the Apple Macintosh, Unix / Linux and mobile browsers including Dolphin on Android tablets and smartphones, and Safari on Apple iPad.