On 28th October, the consultation period ends for the Department for Transport's paper Developing a strategy for smart and integrated ticketing, which is effectively1 the latest round of defining the ITSO specification.
ITSO was formed to build and maintain a specification for secure 'end to end' inter-operable ticketing transactions. Specifically they mean smartcard ticketing, although this doesn't seem to be a perfect solution. There are three main areas which raise serious questions for me about the ITSO specification as it stands (v 2.1.3), which are Usability, Commercials and Security.
In this post I will focus on the usability issues which arise from smartcard ticketing, which are not ITSO-specific.
On the surface, smartcard ticketing seems like a brilliant solution for the end user - anyone who has used London's Oyster Card system will know that catching a bus has never been simpler, or quicker now that you don't have to join a queue of people fumbling for change. However, transport in greater London is very simple, and so are its pricing structures. For a full UK-wide, multi-mode ticketing system there are bigger problems that need addressing.
The first problem that a smartcard ticketing system must face is how a customer gets his ticket onto his smartcard. Suggestions I've heard for this:
- use a vending machine, and swipe your card at the end to pick up your ticket
- buy from a teller, and swipe your card at the end to pick up your ticket
- buy from a conductor, and swipe your card at the end to pick up your ticket
- buy on the internet, and swipe your card at a ticket machine in your departure station to pick up your ticket
It's not clear how any of these options is quicker or more convenient than buying a paper ticket.
Traditionally, the details of a transport ticket are printed on the ticket itself. This simple system allows the holder to instantly check where there ticket will take them, how much it cost, whether they have a seat reserved and other pertinent details. An e-ticket on a smartcard has no such simple access - a separate electronic device is required to check details of a ticket, or even to check it actually exists. I asked a representative of ATOC how they planned to counter this, and the answer is primarily 'a piece of paper with the ticket details printed on it', and in future, NFC phones. For more info on when NFC will realistically be available, read our post on the subject. For now, the public will have to settle for a paper ticket in addition to the smartcard ticket whose aim is to replace paper tickets.
Often people will own more than one transport ticket at any time. How does the smartcard, or the device reading your smartcard, "clip"* the correct ticket? How would the customer check that the correct ticket has been clipped? Similarly to journey details, without an easy way for a customer to interpret his smartcard it becomes very difficult to manage.
* Tickets must be validated and marked as used by an inspector, conductor or ticket gate
One of the biggest complaints that passengers on UK rail make is the length of the queues. As shown above, smartcard ticketing does little to tackle this, and until the advent of NFC-enabled mobile phones, it might be possible that smartcards could increase queuing as concerned travellers ask ticket inspectors to make sure they are travelling on the correct ticket that is saved on their smartcard.
So what problem does ITSO smartcard ticketing actually solve? The only benefit would be to allow better tracking of individual passengers through the system. This would allow better understanding of how our public transport system is used, and therefore offer ways to increase efficiency. This passenger tracking could equally be achieved using barcodes in place of smartcards. Paper barcodes solve issues of ticket selection and viewing journey details. Transferring the same barcodes to mobile allows for simple ticket purchase with immediate delivery, so solving the other usability issues as well.
ITSO will be the standard for smart ticketing in England and the UK, ensuring that the local schemes are interoperable with each other.