Transport for London (TfL) is overhauling its website estate and building a HTML5 site that can be used on any mobile device, which will be integrated with Google Maps and built on top of a single API to aid external development.
The project has been running for approximately ten months, where the development team has ditched the traditional waterfall approach and adopted agile methodologies, with a public beta site expected to launch in the next two months.
TfL’s public facing site is actually made up of a collection of 70 different websites, which it hopes to eventually consolidate down to ten, in a bid to increase functionality for users and reduce costs for the organisation. It currently has eight million unique visitors to the website each month.
Phil Young, TfL’s head of online, said that website is looking very outdated compared to other modern sites on the market.
“In terms of online, the last major refresh of our public websites was 2007, and in the internet world that’s a long, long time,” he said.
“If you look at our internet properties today, they are looking aged. The tools themselves are good, they are well used, but they are not integrated with each other.”
He added: “This means that if you are planning a journey, then you want to get a fare for that journey, then you want to buy a ticket for that journey – that’s three different websites, three different user experiences and multiple log-ins. We don’t make it as easy for customers as we would like to.”
Young said that TfL had built the site using responsive design, which means that users will get a ‘brilliant mobile experience’, and the site will be optimised for all screen sizes. He also said that it will be personalised using cookies and localised to deliver ‘significantly better mapping’.
Currently, TfL uses a number of different mapping platforms, including Navteq, Bing, Ordnance Survey, CloudMade and Google. However, these are all being consolidated so that the organisation’s mapping is based off of a single Google Maps API.
“In terms of localisation, obviously mapping is huge in transport. At the moment we have five different platforms, so we are giving customers a really inconsistent experience across those platforms – you have got something different on journey planner to what you have looking at buses,” said Young.
“What we are doing is bringing all of that together onto the Google Maps API and using that to drive really good user experiences that are completely integrated. For example, we will have a new feature called Nearby, which will allow you to view on a Google map all of the transport assets around you – how many bikes are in the docking station that’s just down the road, the departure time of the next bus, the next tube etc.”
“By developing across multiple platforms, we were increasing our development time, as well as our development costs.”
The new site will be hosted on Amazon Web Services and it is expected that the final live product will launch this calendar year, after testing and feedback during the public beta.
TfL is also building the new platform on top of a single API. Previous sites had used data sources from across the business, which meant that different sites would interact individually with those services. However, it is now using an API to build a single data model to create a reference architecture that is consistent.
Young said: “We built that for ourselves so that we can build on top of it in a consistent way, so stations, stops and river piers, for example, are all described in the same way from a data point of view.
“This means that we can develop quickly on top of a solid base, and we can also make a single API available to developers externally so that it’s much easier for them to make products on top of it.”
TfL hopes that this single API will encourage the external development of ‘multi-modal’ apps. Because of the complexity of data streams at the moment, most externally developed apps focus on one mode of transport e.g. buses, trains, bikes. However, Young said that this should allow developers to integrate all of these into a single app.
Finally, Young explained that his team had ditched the traditional waterfall approach to development and adopted agile methodologies, so that it can react quickly to market changes.
“In this space you have to be incredibly agile to move with devices, to move with consumer trends, and we have been playing catch-up quite considerably. We’ve had to operate in a different way to developing these products and so we adopted an agile methodology to support this,” he said.
“We are working in multi-discipline teams, in very short sprints (2 weeks), to enable us to see a finished product at the end of each sprint. It’s a harsh process, but the product has to reach market quickly so that customers can start to receive the benefit.”
He added: “We have moved much faster than we ever would have using traditional waterfall approaches.”