The technology behind the mobile ticketing structure of thetrainline.com

Today we may consider a cardboard ticket an outdated proposition – but the invention of the Edmondson ticket machine in the 1830s for issuing pre-printed tickets was so successful it became used around the world and survived for 150 years. Magnetic stripes were introduced on train tickets in the 1980s nearly a decade before they became widespread for airlines.

More recently, developments have been on three parallel fronts – smartcards, predominantly for the commuter markets; e-tickets, for customers to print themselves focused on advance purchase markets; and mobile tickets, which have the potential to address multiple markets.

The focus on early ticketing processes was very much around controlling fraud, by both staff and passengers – the latest generation of innovations however put convenience and the customer at the heart of the proposition, albeit fraud management remains an integral requirement.

Mobile app from thetrainline.com

Over the past four years at thetrainline.com, we have piloted a range of mobile propositions, the most successful being our iPhone application. Launched in October 2009, this has attracted over 600,000 downloads (roughly 20% of UK iPhones) and already accounts for over a third of all timetable enquiries handled by thetrainline.com on some days.

This autumn we will build upon this success to launch our new generation of mobile products. At the centre of this will be thetrainline.com’s mobile application – allowing customers to check train times and fares, buy tickets and have them delivered to their mobile phone.

The timetable format on thetrainline.com’s iPhone application

Developing products for mobiles opens up a range of new opportunities, and new challenges.

Building technology for the user

One of the initial challenges is deciding what the product offering is going to be. The temptation is naturally to try and imitate the website experience, and adapt it for smaller screens and absence of mouse/keyboard – indeed there are software products available that will do just that – however, we’ve taken a more holistic approach.

The main users of our website can be stereotyped as organised people planning ahead – often looking to find the optimal trade-off between time of travel and price of ticket. This is why the core of our website is a matrix of train times and fares. A mobile user however is much more likely to already be en-route to the station, and travelling within the next couple of hours – their only practical choice to make may be between standard and first class. As such the mobile experience will be very different to the website, but by setting sensible defaults we can offer a very simple and intuitive booking process.

We also recognise that, for some people at least, mobile commerce will be a step too far at the moment. Nonetheless, these same people will be perfectly happy to use mobile applications to check train times, or recall details of itineraries that they’ve already booked on their computer. So we were keen to ensure that we offer something for these users too – partially as a useful value added service in its own right, but also because through regular use of the application for obtaining information, their confidence in using mobile applications will grow, and eventually (we hope) they will also be happy to buy tickets on their mobile.

Mobile app vs mobile website

The implementation of such a mobile application raises many technical challenges. One of the first decision points was whether to build mobile applications, or to build a mobile website. We’ve decided to do both, but to focus the bulk of our effort on the mobile applications. The mobile website provides a good back-stop for the widest number of users – but lacks the personalisation and close integration with functionality on the phone that can be achieved through applications.

We are also very aware of the problems of intermittent network coverage which can result in a poor customer experience when browsing the mobile web on the move and this was something we specifically wanted to address with the mobile application. For example, in our iPhone application you can download and store full seven day timetables onto the phone, so even in the depths of the Underground you can still check train times. Our next generation of applications will have the ability to communicate entirely over SMS text messaging for where GPRS/3G data coverage is unavailable, or unstable.

Designing a responsive app

The next challenge is the shear diversity of applications required. Unlike designing for a computer, which is likely to have a screen of a predictable size, almost certainly accompanied by a mouse and keyboard, using a largely technology agnostic web browser – mobile phones come in many different form factors, running many different technologies. Aside from the obvious issue of screen size, phones may or may not have keyboards, which may be numeric or alphanumeric. They may be touch screen, but is that touch and swipe, touch and pinch, or just touch and tap? They might have ‘soft-keys’ or maybe a tracker ball or wheel. Then there are the user interface conventions – iPhone users probably recognise that a small blue arrow means ‘more options’ – but this would mean nothing to a Blackberry user.

Some software vendors claim to have packages that can automatically generate an application for multiple platforms – this is true to an extent, but to really succeed beyond the pure technical layer, thought and time need to be invested in each representation of the application. With new phones coming on the market daily, really embracing mobile is not for the faint hearted or the under-resourced. The feature-rich capabilities of devices such as the iPhone and some Android phones mean that their users are more demanding, and these platforms justify ‘flagship’ applications with additional features and closer integration with the built-in capabilities of the phone.

There are of course some elements of the work that are common. For instance, we have built a set of mobile web services for our applications to connect to. These provide all the necessary timetable and fare information to the application – and are optimised both technically and in terms of content structure for use by mobile phones.

Aiming for data accuracy

Mobile users have demonstrated a strong need for very accurate data. We rely on Network Rail in particular to provide accurate timetable information, and mobile users are quick to spot (and tell us) when the data is not right. Location data also demands much higher precision – while industry data feeds contain approximate grid references for most stations, these are often too approximate for someone using a GPS enabled phone to navigate their way to the station entrance.

It’s not all challenge – there are upsides for mobile products too. Aside from the portability and convenience, perhaps the two biggest opportunities are personalisation and location awareness; combining the two allows us to offer features such as ‘next train home’ giving users who have personalised their application access to train times without any keyboard input.

Clearly a huge opportunity is to actually deliver the ticket to the phone itself. For almost all tickets and routes we’ll be able to deliver a collection reference for the customer to pick-up their tickets at the station, but the real power of the mobile proposition comes on routes where Train Operating Companies (TOCs) are willing to accept barcode tickets.

We have already lead the way in allowing customers to print their own tickets for bookings made online, and the standards put in place for these e-tickets always had mobile tickets in mind. The sale and ticketing process are in many ways the same as a printed ticket. The fares come from the same place, the seat reservations are made in the same National Reservations System, and settlement records are sent to RSP to ensure payment of the relevant parties. The main difference is that instead of printing a cardboard ticket, we generate a barcode. A 2d-Aztec barcode to be precise. This contains all the key details about the booking (route, ticket type, discounts, etc) and summary information about the passenger. Most of the barcode is encrypted using public-private key technology – giving a high degree of confidence in its authenticity even when it is used in an offline environment. We are fortunate that the industry in the guise of RSP had the foresight to define an industry standard barcode several years ago, which means that interoperability between TOCs and equipment manufacturers is much easier to achieve. As such, both major gate manufacturers now offer options for barcode readers on their gates (which work surprisingly well) and there is an ‘off-the-shelf’ upgrade path for users of Avantix Mobile.

In their basic form, barcode tickets have been limited to advance purchase train specific products, with no refunds nor changes. This provides adequate mitigation against the problem of cloned tickets. However, to allow full flexibility of barcode ticketing, such as flexible travel times, refunds and amendments, there needs to be a sharing of data between retail systems and ticket inspection systems. One approach would have been to build a central validation data base of valid tickets – but this was quickly discounted as there wasn’t appetite from the industry for investment in another central system procurement.

Instead we have built a solution based upon exchange of messages between retail systems and inspection systems – this is common for both ‘print your own’ e-tickets, and mobile tickets. Retail systems such as ours generate ‘e-ticket booking messages’ which are distributed to relevant inspection systems using a look-up based on the route travelled. Some inspection systems, such as Avantix Mobile, use their own intelligence to push a relevant subset of these messages to relevant inspection devices to allow inspection against cached data in areas of no connectivity. Should a ticket be cancelled or changed, the retail system simply sends an ‘e-ticket cancellation message’ to the same inspection systems. The inspection systems reciprocate by returning ‘e-ticket inspection records’ containing the date/time and approximate location of any ticket inspections. There may be multiple legitimate inspection records per journey, so this also has to be allowed for.

This has much in common with the concepts used by ITSO – and indeed in the long-term it is conceivable that ITSO becomes the backbone for such communication, albeit for expedience this has been avoided for launch.

There is further cross-over with ITSO and smart card on the horizon in the form of NFC phones. Whilst barcodes have generally performed better than expected, to address issues such as cross-London travel and high through-put gated stations, NFC offers an attractive alternative to investment in barcode readers. The same application that receives and renders a barcode ticket could, in future, receive the same ticket and render it as both barcode and smart formats for different uses.

Whilst some train companies have been able to see the commercial benefits that mobile ticketing will bring for them, others have found it more difficult to justify the commercial case. Some issues are familiar, such as the difficulty in justifying investments (such as barcode readers) in the final years of a franchise – others are more unique. For instance, retailers currently pay a service charge to train companies each time a customer collects their tickets at the station. This in turn is used to pay off the investment in and for the maintenance of the ticket machines that provide this capability. If there was a sudden and dramatic migration from station collection to barcode ticketing, some train companies fear that they would face a gap in their income. Some train companies have significant franchise obligations to invest in smart card ticketing and are reluctant to back multiple technologies, particularly if it is not included in their franchise requirements.

Despite the challenges though there is a growing momentum behind barcode tickets, and mobile applications in particular that few are able to ignore. The coming together of working technology and a real customer appetite to use mobile phones for day-to-day transactions, mean that this time the age of the mobile ticket really has arrived. Next time you find yourself presented with a queue at a booking office, simply pull out your mobile phone, click ‘next train home’ and sail past the queues with your barcode.

About the author

Richard Rowson is the Product Development Director for thetrainline.com, responsible for the ongoing enhancement and innovation of products in both consumer and business markets. In four years at thetrainline.com, Richard has overseen the transformation of the company’s proposition – launching customer centric propositions such as Best Fare Finder and ‘print your own’ e-ticketing, and is now driving a major push into mobile products. Richard joined the rail industry 10 years ago as part of the team establishing Qjump.co.uk (later acquired by thetrainline.com) and has worked with a variety of train companies, and National Express. Prior to joining the industry, Richard worked at British Airways and for technology consultancy Detica.