The Scotrail service between Aberdeen and Inverness is currently disrupted by some improvement works to the line between Aberdeen and Dyce. Bus replacement services are in operation between Aberdeen and Dyce, with normal service between Dyce and Inverness. All because the line has been dug up in preparation for new dual tracks being laid.
But if you do a search on the Scotrail website for the next train north from Aberdeen you get this message:
“No services between these stations have been found”. One would assume that Scotrail isn’t running services from Aberdeen to Insch. The same thing happens for searches to all stations north of Aberdeen.
But if you search using the ‘Buy Tickets’ option you get a different result:
Same starting location, same destination, same time, different result:
Lo and behold – there are trains available!
Clearly there is a disconnect between the Next Train and Buy Tickets searches. Clearly the data exists, as you can book a ticket, but the format must be different enough that the Next Train option doesn’t recognise it. Timetables have been published which clearly show the bus times and train times to allow the planning of a journey.
As a regular train user the Next Train feature is really handy. But only if it is reliable.
Similarly, the platform arrival/departure boards at stations north of Aberdeen no longer mention Aberdeen, all trains lead to Dyce. If you are a local, know where Dyce is, and know about the bus replacement service, this is no problem. If not however it’s frustratingly difficult to confirm that you won’t be stranded in Dyce if you get on that train.
So is this the usual ‘complaining about public transport’ post, or is there a lesson in this for your own data provision?
I think there is. The root of the problem here is a rigid structure within the data which makes exceptions difficult to handle within the presentation layer. Indeed, making it necessary for the presentation layer to change in order to present the new data.
The Next Train function, the Departures boards, and no doubt other services, all fail to recognise the nuance of the bus replacement. There are two questions that can be answered:
- “can Scotrail get me to Insch?”
- “can I get on a train to Insch?”
With the answers to those being:
- “Yes, of course, but you’ll be on a bus for the first part”
- “No”
If Scotrail thinks of itself, behaves, and designs it’s systems as a ‘getting people to places’ company we get answer 1. If they are purely a ‘train’ company we get answer 2. Answer 2 isn’t wrong, but it isn’t useful in the same way that answer 1 is.
Future proof your data by considering the structure of your services – storing, and building services around your equivalent of “journeys” rather than “trains”.
Then you’ll be ready for your equivalent of flying cars (or replacement busses). More importantly, you reduce the risk that some unforeseen change will disorient and let down your users.
Code The City 