Member in the Spotlight: Innovations in online services at Transport for London
Redevelopment of online services
TfL launched its online services in 2007 and currently has around 13 million visits per month. While the online services are visually the same, they are in fact made up of 60 different websites which are not talking to each other. This situation does not meet the customer need for seamless mobility and therefore TfL will launch a single integrated user interface in 2013 based on API.
Using the principles of ‘responsive design’, a single website will offer services based on device capabilities to desktop, tablet and mobile devices. This means there will no longer be separate sites for mobiles and desktops. Currently, TfL has a dedicated mobile site which offers selected information services. However, mobile customers are demanding the same services as desktop users. Furthermore, the demand from mobile users is increasing rapidly and TfL expect requests for information services from mobile and desktop users to reach parity within the next 12-18 months.
Journey planner
Journey planning accounts for around one-half of all web visits. The current TfL journey planner is an example of a silo solution since it is not integrated with other relevant services such as Countdown (real-time public transport information) nor fare information (http://www.tfl.gov.uk/tickets). TfL is renewing its Journey Planner and the new tool will be built using an API. As well as developing desktop and mobile Journey Planner tools, any developer can interact with the API in order to build an application. TfL acknowledges that the online community has the capability to come up with new and creative solutions and is therefore making its APIs available to enable this (see next point).
Regarding social media, TfL has been a relative latecomer. Its experience has shown that Facebook is currently less useful for customer interaction but could be a useful tool for campaigning on travel behavior change. By contrast, TfL’s Twitter feed has huge potential to interact with passengers, especially for dispatching information on disruptions. Previously, the Twitter messages were automated feeds of tube disruptions, which did not sit well with customers who felt that the human dimension was lacking. The automated feeds are now filtered and retransmitted manually.
Open data
Transport for London started to publish data several years ago after a review of the national context and trends towards open data. Until then, application developers had been ‘screen scraping’ TfL’s journey planner. By making some feeds available, TfL expected to reduce the need for ‘screen scraping’ and to encourage creativity among the online community. The launch of the online data feeds fundamentally changed the nature of the relationship between TfL and the developer community; a relationship of greater trust has now been built and developers are now even providing constructive comments on the quality of the data supplied by TfL. TfL now operates on the principle that all transport data will be published where technically, legally and commercially feasible.
The first feeds were static (eg, bus stop location, timetable, etc) but the developer community is more interested in dynamic information (traffic information, bike availability at Barclays bike hire stations, etc). Whereas static data is easy to provide as it is a simple file on a server, dynamic data is more complex as it requires far more infrastructure and, in the case of TfL, can involve contractors. TfL is using cloud infrastructure through the creation of APIs for dynamic data. However, the cost of this infrastructure is not negligible (costing several hundred thousand euros), which implies a significant investment on the part of the transport authority. Furthermore, there may be issues with the capacity and stability of the different cloud infrastructures on offer.
One of TfL’s most popular APIs is TrackerNet which provides dynamic Underground departure times and status (stations open, escalators/lifts closed, line disruptions, etc). There are also APIs for the Barclay’s cycle hire scheme and the Countdown (real-time bus information) API will be launched by the summer.
Several of the potential concerns with regards to publishing transport data have thankfully proven to be unfounded. Firstly, the possible drop in online traffic due to the proliferation of syndicated (developer community) services has not happened. Secondly, user trust in the data quality of syndicated services is rising due to the market’s ability to weed out the poor developers. Finally, the cost of purchasing the syndicated applications is very low and therefore uptake has been high.
To access the APIs, developers must simply register with TfL. Currently, there are around 3000 registered developers and hundreds of applications for all devices and platforms. Developers are not allowed to use TfL branding; however, TfL is reconsidering this as it now has more confidence in the market and would now like to see a benefit. TfL is considering setting up an ‘application garden’ for all TfL-powered applications provided by registered developers. Within this application garden, TfL may also promote those applications of high quality which support its priorities and policies.
Many of the APIs are related to public transport and other mobility services. For what concerns road traffic information, TfL’s online services are not always the main source for drivers because many drivers are less aware that TfL operates the roads, TfL is working hard to change this and are also working closely with the satellite navigation providers to syndicate disruption information.
Further information
For more information about London’s online services, please contact:
Phil Young, Head of TfL online, email: philyoung@tfl.gov.uk
Phil will join the Polis TE&M WG meeting in London on 12 April to present some of the items in this article.