Technical & Quality Standards
Overview
This document details the technical and quality standards applicable to apps listed in the Directgov | innovate space ( http://innovate-apps.direct.gov.uk ). These standards are a 'light touch' version of those applied to applications and information resources included on the main Directgov platform ( http://www.direct.gov.uk ). It is expected that developers of apps for innovate will ensure that their apps materially comply with these standards. Because of the innovative and sometimes experimental nature of innovate apps, some leeway is available, as necessary and appropriate.
Failure to comply with any of these standards may result in an app being denied inclusion in innovate; or, if already included, being removed. Any questions or concerns about these standards should be directed to innovate.direct@directgov.gsi.gov.uk.
Suitability for Inclusion
The app should have one or more of the following attributes to make it suitable for inclusion on innovate:
- Makes use of publicly available government or public-sector data
- Provides government or public-sector information or services that are not currently provided by Directgov or other official government sites; or provides them in an innovative or superior way
- Demonstrates an innovative technology, technique, service, or medium of interest to Government, other public-sector organisations, or the community of open-source developers around government and the public sector
Editorial Standards
Introductory Text
The app shall have introductory text describing the function, purpose, and proper use of the app.
Proper Usage
All text in the app shall conform to standard English usage for correct spelling and grammar.
Comprehensibility
Where possible, text content should avoid unnecessary jargon – and endeavour to enhance the usability of the app.
Design Standards
Branding
The app shall be visually branded as 'Directgov | innovate' as described in the 'Style Guide for Developers' document.
Fonts and Typography
The app shall use fonts and typography, and text/screen colour combinations, that leave the text legible.
Appearance
The overall effect of page layout and design, colours, typography, and images shall result in an effect of basic attractiveness. This overall effect shall not clash with the branding, as above.
Markup
Document Headers
All pages rendered by the app should include a valid HTML header, with the following elements:
- An XHTML or HTML doc type declaration
- Title
- Links to external stylesheet(s)
- Links to external javascript file(s)
(Styles and scripts should, yes, be included in linked, external files, where at all possible.)
The following elements would also be nice to see in the header if possible:
- An XML version tag with character encoding
- An XML namespace declaration in the opening HTML tag
- Suitable meta tags such as:
- title
- keywords
- language
Links
All links across the app should work; and their appearance and function (e.g. opening in same or external windows) should be consistent, to aid usability.
Validation
Both your X/HTML and CSS should validate according to your version declarations, using these W3C Validator services:
- http://validator.w3.org/, for X/HTML
- http://jigsaw.w3.org/css-validator/ for CSS
- If your app is intended for use on mobile devices, also http://validator.w3.org/mobile/
Accessibility
The app should endeavour to achieve the highest level of accessibility that is consistent with the proper and intended function of the app. Specifically:
W3C WCAG 2.0
If at all possible, the app should try to conform to the W3C WCAG 2.0 Level A requirements as described at http://www.w3.org/TR/WCAG/. (This can be checked using an online web accessibility evaluation tool such as WAVE from WebAIM.)
The following accessibility checkpoints should be achieved:
- Foreground colour(s) and background colour(s) should provide sufficient contrast
- All images – particularly any images used for navigation – should have descriptive alt text
- Forms should include legends and fieldsets if possible
Browser support
The app should be fully usable, and render reasonably attractively, on the following browsers:
- Internet Explorer 7
- Internet Explorer 8
- Firefox 3.5
- Safari 4
On the following platforms:
- Windows XP
- Windows Vista
- Mac OS X 10.5
Browser support beyond that is encouraged, but is at the discretion of the developer. Where possible, app functionality and appearance should degrade gracefully on unsupported platforms – ideally presenting a message that the app is not usable with the user's current browser and suggesting an upgrade and a link thereto, but at least not blowing up spectacularly.
Usability
The app should be intuitive and amenable to proper and successful use by the target user demographic, without outside technical support. The app should include sufficient documentation, help text, or other help functions to ensure that it can be used successfully.
Contact Information
Every page or screen of the app must contain a link to contact information for the developer or developing organisation.
Infrastructure
Availability
Your app should enjoy reasonable uptime: 95% or better during business hours.
Capacity/Response Times
The server upon which your app sits should be able to support the level of traffic it will attract. Response times should be two seconds or less. (Of course, if your app attracts inordinate attention, an adjustment period to deploy more server resources may be necessary.)
Security
Your app must adhere to reasonable best practices for computer and network security. This includes:
- Running the latest secure and stable versions of relevant software such as
- Platform OS: Windows XP or Vista, Linux or other Unix flavour
- Web Server: Apache, MS IIS, or other
- Scripting language: PHP, .NET, or other
- CMS or CMF: Drupal, Wordpress, or similar
- Configuring your platform and software in standard 'hardened' configurations, where possible
- Writing your application according to standard security best practices for web applications in your environment
The security and integrity of the app is the responsibility of the developer. Government web sites are probably higher-profile than you think; and security breaches or 'hacker' intrusions are extremely damaging to public faith in digital government. Please take careful steps to avoid any such incident.
Terms & Conditions
If there are any terms or conditions attached to use of the app, these must be listed, ideally on a separate page/screen. These terms must include a link to the Directgov | innovate Apps Agreement and Terms of Use at http://innovate-apps.direct.gov.uk/terms.php. If your app has no particular terms or conditions, it must in any case link to ours.
Collection of Personal or Identifying Information
If your app sits on one of our servers (for instance this one), it must not collect and store any identifying personal information from users. (There are very specific accreditation rules for government servers holding any personal information.) This rule precludes any type of user registration; though it does not preclude maintaining session or state information. It also does not (necessarily) apply if your app is on your own server and you are a not a government employee or department.
Copyright
None of the material presented by the app (text or image), or software components included in the app, should breach or infringe any copyright held in any country. The developer of the app will stipulate this before the app is published on innovate.
Other Standards
Directgov | innovate may impose additional standards to those enumerated here. It is asked and expected that the developers of apps for innovate will work with innovate staff to address any additional standards issues that innovate staff may raise. Directgov | innovate reserves the right not to publish apps that do not meet the standards set out here, or that do not meet additional standards as set out by innovate. We thank you for your kind cooperation.