09. Open standards

9. Use open standards and common government platforms where available.

Link to corresponding item in JIRA: https://jira.informed.com:8443/browse/FCOLOI-162

Questions

• Are you locking yourself into any proprietary solutions where an open standard is available?

• Service adopts common Web Standards (e.g. HTTPS, HTML, CSS)
• Data persisted in an open format (Open Source RDBMS)
• Service adopts an open service orientated architecture, modular by design and built using open source technologies.

• What does the system output to the users and in what format?

• No data-sets as such.
• An HTML cover page is made available to help users when sending in their documents.

• Describe your use of common government platforms.

Common platforms

• Describe the integration mechanisms with any external systems.

• SOAP and REST web service integration with (easily changed to other providers).
• Resilient Message Queue (RabbitMQ) to manage interactions with back-office case management system.
• WFS-G address look-up service

• What common user needs does your service meet and what are you reusing from across government to help meet that user need?

Common needs

• What data do you hold and what is your open data responsibility?

• The legalisation service holds limited data regarding applications for legalisation (Names, addresses, numbers of documents legalised) - data persisted until legalisation process completed.

Evidence

Service Manager able to:

• explain how they are avoiding locking themselves into any proprietary solutions where an open standard is available.
• explain what the system outputs to users and in what format.
• describe their use of common government platforms.
• describe the integration mechanisms with any external systems.
• explain any common user needs their service meets and what they are reusing from across government to help meet that user need.
• explain what common data they hold and their open data responsibility.

---

Open standards

Informed Solutions to add some info here on tech platforms

Common platforms

Platform	Our response
Verify	We engaged with the Verify team during discovery and confirmed that at this stage it does not meet the user needs of this service as it does not 1. Verify a business, as opposed to an individual, 2. Verify a professional qualification, such as a notary, 3. Support a lower level 0/1 verification per CESG GPG 43 (as opposed to level 2) for this service - where the user need is retrieval of commonly used details rather than identity verification per se. 4. Fit well with 'agent' applications where the person filling in the form is not the actual applicant. We also tested verification concepts in focus groups and questionnaires, with mixed results. We have confirmed with Janet Hughes that there are no immediate plans to pursue organisation verification, and also that the team does not expect to develop the basic identity trail any further for the next few months. We will continue to monitor this area but at present the service does not fit the user needs.
Payment	The FCO has fed into payment GAAP discussions in particular, meeting twice with Edward Upton and sharing detailed figures on our card transactions, refunds, rejection rates. We have since met with Till, Ashley and team, and Till has visited the corporate services centre where the postal applications get processed. We are looking at integration from our caseworking backend initially, and then in future (Barclaycard Smartpay contract runs to end 2016) our front end
Notify	We currently use Sendgrid for most transaction notifications. We will review this and plan to switch to Notify once we have confirmed what we can and can't do
Customer care	The FCO has also fed in call volume and call category data to Edward Upton for the customer care strand of GAAP.

Common needs:

Need	How are we addressing consistently with rest of government
Payment	Building on pre-existing work. We have sought to use payment patterns but have been limited by Barclaycard on this e.g. only one configurable piece of text; unable to pass in card choice when the card saving feature is enabled
Eligibility checker	Starting point was pre-existing smart answer work. We are improving it to address usability issues of standalone answer (see baseline usability research). Asking users to actively tick/select the document they are sending in is focusing them on the most important detail, and especially helps with those who scan the page and don't read the explanations
Finding things and filtering	As part of the document check service, users need to find their specific document(s). After consultation with Ed Horsford (UX) and Stephen McCarthy (research) at GDS, we identified commonality with "finder" services such as business finance finder, contracts finder, air accident reports, competition and markets authority cases, etc. We adopted the faceted search design pattern and put it forward for usability testing in sprint 3, replacing the prior browse category/browse A-Z tabbed experience we had tested in sprint 2. While this was an improvement at the time, in later iterations we tested a simpler search without the faceted categories and this met user needs best on speed and satisfaction.
Summary screen	Inspired by design hackpad patterns originally, then more recently the officially published pattern - we changed our edit links to match this (originally we used descriptive links like the MoJ prison visits example). Our alpha prototype was sent to Tim Paul, Head of Interaction Design at GDS to feed into his work on formalising the summary page pattern
Postcode /address lookup	Based on the lasting power of attorney example from the address lookup pattern on the design hackpad. In terms of the specific address service provider we used G cloud to find a service that is compliant with relevant international standards such as OGC-WFS-G. We are using GB Group.
Country type ahead pattern	Based on design hackpad discussion. Work in progress still. We have also sync'd up with changes the ETD team are making based on sharing lessons with lost and stole passports team (e.g. synonyms for country names)
Confirmation pages pattern	Originally based on design hackpad, Register to Vote pattern. Now based on the officially published pattern
Names	Only asking for "Full Name" at points where the LO do not need to distinguish first/last name e.g. in address
Account management	We are following the design hackpad patterns for account management as we develop the business options. For example, we are following the advice to ask a question to ask whether a user has an account, rather than side by side sign in and register options (which we had early on). We are also following guidance on signing out (confirm it and offer chance to sign back in), forgot password, etc