Case Study: Flight Plan Guide + Errors

11 January 2014

Reading time ~4 min | Categories: case-study  web-apps 

Version 1.0 of the tool was so popular Eurocontrol decided to expand the app's remit. They wanted to add a section allowing users to explore errors they could expect to receive if the Flight Plan had been incorrectly filed.

Screenshot of the Flight Plan Guide Database Application v2.0.
Screenshot of the Flight Plan Guide Database Application v2.0.

You can view the current version at: http://contentzone.eurocontrol.int/fpl/

Screenshot of the Flight Plan Guide Database Application v2.0 at a small screen resolution.
Screenshot of the same Application on a small screen.

Spec

Eurocontrol came to me with a general requirement to add an Errors section while retaining the version 1.0 features. I was asked to write the spec. I presented them with 2 detailed options, outlining the costs and benefits of each.

  1. Adapt the current desktop and mobile applications to the new requirement.
  2. Redsign from scratch, creating a responsive site and doing away with the need for dual applications - I had learned a wee bit more about responsive sites by now!

All good websites should continue to evolve and my client, in their wisdom :-), chose to make the application responsive.

Solution

The new application is based on the 'Flat' design concept. I like this because it improves performance in the browser and can make for a very clean interface as long as everything is given appropriate space and balance.

I created a responsive design that would work on phone screens as well as desktops.

I refactored the JavaScript to make it even more efficient and tried to use native JavaScript instead of jQuery wherever possible.

On the details page I also added a 'step through' feature to allow users to step through the list of items they had filtered down to.

Screenshot of the Flight Plan Item detail page at a small screen resolution.
Screenshot of the Flight Plan Detail page with step through feature on a small screen.

Technical

I used jQuery Mobile for the interface as this is touch optimised and a better choice for a responsive design.

Offline is still achieved via HTML5 appcache: the manifest.appcache file is dynamic, written in ASP.NET. It queries the database for the last change time and date. This time and date is written into the appcache file as a comment. Therefore, if the appcache file changes in any way, this triggers a reload of the content to the local browser (using a JavaScript checking function in the browser).

This has the added benefit of improveing performance as new assets are only downloaded if there is a change on the server.

This approach can only be used for relatively small datasets as all the content has to be loaded onto the client side.