This document is designed to provide a template for agreeing development deliverables with the client. It is structured to be a modular document where sections can be updated or removed depending on the requirements of the project. [1]
Our development approach is based on internationally recognised standards and best practice to create accessible, modular, scalable and performant code. By basing our approach on international standards we aim to develop an inclusive experience for all web users; where access to functionality and content is of primary importance and design is used to enhance that experience.
Access to the Web is as diverse as it's users and in providing support we aim to make Web functionality and content as accessible as possible. Providing support is not about forcing the same visual and behavioural experience across different browsers, where different browsers may have varying capabilities and users may have different requirements. To force a specific experience will prevent users accessing functionality and content.
To identify the level of support we can provide a browser, we grade browsers by the experience they are capable of providing the user.
Where requested we can also analyse client data and identify specific client requirements to modify the standard graded browser matrix.
Analysing client user data, through analytics software, we can create an interactive experience suited to specific user requirements. e.g. if the user base primarily uses modern browsers the designed experience can target advanced browser features.
A cut off point for support is recommended at < 2%. [2]
We understand that the client may have specific requirements for interactive development. e.g. support of a specific browser that may otherwise be unsupported or the use of a particular technology that have implications for the development process. [3]
Pages rendered in browsers with Grade A support will meet the functional specification, user interface specification and creative design. If a level one browser is incapable of meeting any of these criteria either the particular criteria will need to be altered to match the browser capability or the browser should be reduced to Grade B support.
Pages rendered in browsers with Grade B support will meet the functional specification. The majority of the user interface specification and creative design will be met dependent on the capability of the browser, if either criteria is a barrier to meeting the functional specification, the functional specification will take priority.
Pages rendered in browsers with Grade C support will meet the functional specification. The user interface specification and creative design will be used as guidance, meeting the functional specification and making content available takes priority.
Unsupported browsers will not be reviewed during development or quality assurance.
The graded browser matrix details browsers, operating systems and their support level during the development process.
- Firefox 15
- Windows XP
- Windows 7
- OS 10.7
- Chrome 21
- Windows XP
- Windows 7
- OS 10.7
- Safari 5.1.x
- OS 10.7
- Internet Explorer 9
- Windows 7
- Internet Explorer 8
- Windows XP
- Windows 7
- iOS Safari
- iOS 5.x
- Android webkit
- Android 2.x
Although browser implementation variations are negligible between operating system, they are included as guidance for quality assurance. [3]
Testing of particular operating systems will be against the latest non-beta minor version. [4]
HTML form elements are commonly rendered by the operating system rather than the browser for security reasons. As they are rendered by the operating system, CSS does not have full control of the element's styling. HTML elements rendered by the operating system are expected to deviate from the design due to this limitation.
CSS styling is the preferred method to allow the HTML element to benefit for operating system integration. If HTML elements rendered by the operating system are required to exactly match the design a JavaScript replacement of the element may be developed. [5]
Browser testing will be against the latest non-beta minor version. The version supported will be the version current quality assurance. [6]
Internet Explorer Compatibility Mode will not be specifically tested and development will force Internet Explorer to render in the latest browser version of the tested browser. [7]
Pre-release browsers may be developed for at the request of the client but development is only valid for the agreed version of pre-release browser. Although an indicator of support for the released browser version it is not a guarantee of support. Further development and quality assurance testing will be required. [8]
A non-JavaScript experience will be supported and tested as part of the development. The specific experience is reliant on exploration by information architecture and visual design, if no exploration is made available to development, the non-JavaScript experience will gracefully degrade to the functional specification. [9]
Testing of Flash will be against the latest non-beta minor version. [10]
Testing of Silverlight will be against the latest non-beta minor version. [11]
Managing project quality is important part of our development approach. We achieve this through quality control using recognised standards, best practice and quality assurance through dedicated testing.
We apply quality gates to our development by both automated and manually validating against international standards and best practice. These standards include:
- HTML validation
- CSS coding conventions
- JavaScript coding conventions
- Web Content Accessibility Guidelines (WCAG) 2.0
Automated testing in achieved through continuous integration during the development. Manual testing is achieved by peer review between developers during development and as a formal process with senior developers. Manual testing ensures that the spirit of the standards are met.
Quality assurance is achieved through the visual design and quality assurance teams. [12]
Testing is undertaken on each supported browser version with a native install of the specified operating system. [13]
Since the same browser is expected to provide the same experience between equivalent operating systems to streamline the testing process, testing is split in to primary and secondary phases.
Primary testing is engaged in during development to ensure Grade A support is achieved for that browser on an equivalent operating system.
- Firefox 17
- Windows 7
- OS 10.7
- Chrome 23
- Windows 7
- OS 10.7
- Safari 6.0
- OS 10.7
- Internet Explorer 9
- Windows 7
- Internet Explorer 8
- Windows XP
After primary testing has met it's success criteria, secondary testing is engaged for equivalent operating systems at Grade A support plus Grade B support and Grade C support supported browsers.
- Firefox 17
- Windows XP
- Chrome 23
- Windows XP
- Safari 6.0
- OS 10.7
- Internet Explorer 8
- Windows 7
- iOS Safari
- iOS 6.x
- Android webkit
- Android 2.x
Long term developments require a regular support review to maintain an updated and relevant browser capability.
Browser support should be reviewed at regular intervals. Interval length is dependent on project life cycle but should be agreed to as part of the support review process.
Changes to support will require an estimation of effort to manage implementation.
Supported browsers will be reviewed based on current site data and expected browser usage at the end of the project.
JavaScript library, framework or plugin version will also be assessed and updated during the review process. It is recommended versions remain current for performance and security.
Notes are for information only and should be removed.
- This section is for information only and should be removed.
- Specific requirements should be agreed to and documented before development begins.
- Browsers and operating systems not outlined in the matrix may be included by agreement with the client.
- If a particular operating system or version is required it should be agreed to and documented before development begins.
- This should be agreed to with the client and visual design then documented before development begins.
- If a specific version is requested it should be agreed to and documented before development begins.
- A change to this policy will need to be specifically requested by the client.
- Pre-release version to be agreed to and documented before development begins.
- If a non-JavaScript experience is unsupported this should be agreed to and documented before development begins.
- If required, version to be agreed to and documented before development begins. If there is no Flash development as part of the project then Flash should be declared as unsupported.
- If required, version to be agreed to and documented before development begins. If there is no Silverlight development as part of the project then Silverlight should be declared as unsupported.
- A dedicated quality assurance team should be provided to review implementation. The visual design team responsible for the design should provide secondary testing.
- It is expected that browsers such as Chrome and Firefox will use that latest version. However for a release cycle an identified browser version is required.