A while ago, I blogged about the vast levels of complexity we faced digitising the application process for Emergency travel documents. Today I’d like to look at a little more detail at one of our responses to that: building a data-driven application and how we control what is displayed.
In my earlier blog, I talked about the many different factors which we had to deal with: some consulates could accept digital applications and some couldn’t, some could accept payment and some couldn’t, some could accept online appointments and some couldn’t; and so on.
However, as well as the complexity, the situation is very dynamic. Even before taking into account that countries change whether or not they accept Emergency travel documents, we ourselves wanted to roll the system out gradually: we needed to have consulates not accepting applications one day but accepting them the next.
The Foreign Office does not have an in-house development team; and with the ground changing so often, we didn’t want to pay an agency every time we needed to make a change.
A data-driven application
We needed a creative solution to all these problems, and this came in the form of data. It’s not a radical idea to have a data-driven website, but we were sensible enough to specify this right at the start. Our supplier Kainos really engaged with this requirement, coming up with much of how it would work themselves.
The outcome is that the FCO controls what is essentially an extremely large set of comma separated values. When we want to update the application, we make a change to a value and upload the file to the application – and the change is made immediately. At the top of this post you can see me removing our office in Orlando from the system: with the file uploaded, Orlando is removed straight away from the list of options users can select.
This is achieved at no cost other than our staff time, and with zero downtime for users – we can upload it while people are applying and they don’t lose their application data. The process takes about five minutes.
Dealing with local variability
To add to the complexity, although the format of Emergency travel documents is set by international agreement, some countries require their own forms to be completed before a document can be issued. In Malaysia for example, in some instances you need a special pass from the Malaysian immigration department.
To deal with this, we have some space in our file where local information can be put. We wouldn’t show everyone this information; it wouldn’t even show up if you were just changing plane in the airport. This information would only be visible if you needed it, ie if you are getting your document issued in the British embassy in Kuala Lumpur.
And when a user selects Kuala Lumpur, when they reach the submit page it reads:
One step which we didn’t take was to design and build an administration site, allowing FCO staff to update the site via a user friendly interface rather than having to edit a csv file. Our decision process here was fairly simple: we preferred to save the money. And here we really do need to thank our supplier Kainos who helped design the file and made a very clear way to upload it.
The truth is: the solution is brilliant. We have already made at least 40 updates to the configuration file, turning posts on and off, correcting text, and making the application process clearer. Rolling the application out worldwide was simply a matter of changing a lot of ‘n’s to ‘y’s in the database and re-uploading the file. No expensive and slow change requests were made, we did it all ourselves.
The other part of the truth is: we have got it slightly wrong. You can cause problems with parts of the system if you make a mistake: I did this myself by uploading the wrong file in a daze when coming back from the dentist (this was thankfully in our private beta when very few people were affected). We now have various defensive procedures to stop this happening again, but looking back we got wrong some of our analysis about how often things would change and the levels of risk attached.
However, this configurability is a key part of Emergency travel documents online, and it has already proven itself to be crucial in supplying our users with accurate information.
There’s plenty more to come on this project; shortly I’ll write on a particularly interesting piece of functionality, third party payment.
Follow Phil on @philbuckley5