Once I have added favouriting, it occured to me I could make Departure Board much more powerful and intelligent by automatically loading a favourite board when it is nearby. This feature could also be used with the Apple Watch glance to make that much relevant and useful.
For example, if my daily work commute is from Station A to Station B and I live 2km from station A and work 2km from Stations B.
I can set up my favourites as:
– Station A departures: calling at station B
– Station B departures: calling at station A
and enable automatically load favourites (with a distance > 2km) in the extras menu.
This will mean that when I am at home and load Departure Board I will be within range of one of my favourites and Departure Board will show that favourite and like wise when I am at work.
After releasing Departure Board, I made the decision to not work on it over the first six months and gauge the commercial potential of the application in the market. In the first three weeks after the launch of Departure Board, I have had a lot of feedback from users requesting a couple of additional features beyond the simple initial release; primarily:
Filter by calling point.
The reason behind this was because many stations in the UK have a lot of service running from them all the time. Therefore to view their journey options the user would need to scroll through a long list of mostly irrelevant trains. A filter by calling point would remove all of these trains from the list, only showing the suitable ones.
Quick access to stations that are not your local station was another highly requested feature. Many people who commute into big cities seem to work away from the train station they commute into. Therefore a list of favourite stations was requested.
In 2012, I started this project by searching for a suitable API to provide the required train data. I found a few options only, but none were suitable. They either provided unreliable information or required me to run a server parsing a huge amount of train movement data, which is outside of my skill set.
Over the following years, I kept an eye on the available APIs and in September 2014, I discovered the newly released Live Departure Boards Web Service to access real time train information from Darwin by National Rail Enquires. This API was perfect; a light weight web service that I can query and retrieve the necessary train departure information.
There was also a lack of train apps that supported some features in iOS, particularly Today view and URL Schemes.
With an ideal data source found, I spent the next four months creating the initial release of Departure Board including the Apple Watch component. It was ready to go in January, but I was still waiting for access to a train stations list from a third party before I could release the app. Once I had access to the source and Apple started accepting Apple Watch apps, I submitted it to the App Store. On 10th April 2015, Departure Board went live on the App Store.
Departure Board, by design, is a very simple application. The design philosophy for the application is a departure board that loads instantly based on your location.
The idea came to me in 2012 during my weekly return commute from Merseyside to the Furness peninsula in Cumbria. It frustrated me that whilst enjoying a coffee or sitting in one of the lounges, I had to keep moving to see the departure board. I checked every train app in the App Store and they all solved this problem. However, they require many taps to load the local departure board; by the time, I had done this (3-10 seconds), it’d be easier to just go and look at the board in the station. I saw this as an opportunity to make a new train application, that loads the local departure board instantly.
To fulfil this opportunity with sufficient differentiation from what was on the market, I challenged myself to make an application that can load the local departure board in under a second. I hoped this would be achievable as the process is straight forward:
1. Retrieve the user GPS coordinates;
2. Look up the local station;
3. Retrieve the departing train information from a suitable API;
4. Parse the information;
5. Display it to the user.
My main concern were with how fast step 1 and 3 would be. If it took longer than one second to load the board, I felt that the design philosophy would not have been acheieved.