This post originally appeared on the Masabists blog.

Earlier this week Passenger Focus, the UK’s official rail watchdog, released their annual Spring Passenger Satisfaction Survey, and the press release focussed on some very interesting insights into the reasons why UK rail passengers shun automated ticket vending machines.

At Masabi, Passenger Focus’s earlier research into ticket maching usability was a key influence in the User Interface design of our mobile phone ticket vending app, and it was encouraging to see this new research appears to validate our approach. The report shows that users choose humans over machines for the following main reasons:

1. “Incomplete ticket restriction information”
2. “A barrage of information and choices”
3. “Bewildering jargon”

“As a result some passengers would rather queue to speak to a member of staff, buy more expensive tickets than they need to or just give up and join the ticket office queue.”

Ticket Sales Usability

The UK has evolved a particularly complex fare structure, so a certain amount of complexity is innate in the system. The trick is to remove as much as possible, allowing the passenger to make an informed decision based on price and/or time preferences, without any arcane rail fare knowledge – I can say from personal experience that most ticket machines really do handle this badly.

By fusing real timetables with fare selection, the Masabi mobile rail ticketing app allows the passenger to visualise which trains each ticket will be valid on very rapidly, whilst also including a more detailed concise restriction description than most in-station vending machines. Timetables indicate which operator runs each train, a key point of confusion when many tickets are tied to a single operator.

The application can also adapt to the user, remembering favoured journeys and previously used payment cards (securely stored, and only reusable by re-entering the CVV number on the back). This personalisation helps eliminate the myriad of destinations thrown at the user of a vending machine, most of which will be totally irrelevant.

Queues

This year’s survey also looked at queue times in a number of regional stations – contrasting to last year, which focussed on the largest stations, almost all in London.

The industry lays down a maximum acceptable queue length of 3 minutes at off-peak times, and 5 minutes during peak times. Many stations, big and small, are still failing to meet these standards (click on graph to see a larger version):

Mobile ticketing offers a solution to this, providing a superior ticket purchase experience combined with informative timetables – all of which can be tested risk-free whilst queuing for a window or ticket machine.

Please comment on the original post.

I’ve been using the latest update to the Skype Windows client for a while now, and in general I think it’s a very nicely evolutionary improvement to the UI – I’m very glad to be rid of the 20-30 chat windows I used to have scatterred around the place.

There is one ‘feature’ that annoyed me though – you could resize the window, but a chat would always be 410px wide – something easier to demonstrate with a picture and some super-professional captioning in red:

Suddenly our team’s development productivity dropped – after upgrading Skype, you could no longer meaningfully drop a stacktrace into a chat and get any feedback that wasn’t along the lines of “that’s a mess, I have no idea what you’re sending me”.  Lots of people I know had got seriously frustrated about this.

After a quick chat with the Skype support team (based in Hungary, if anyone’s curious – unlike the dev team who are in Estonia, and sponsoring our latest MoMo Estonia meeting) I discovered that this is in fact a feature designed in.  If you want to enlarge the text you can, but only by dragging the left or right side of the text field at the bottom of the window wider – logical, in a way, but completely unintuitive as I know a lot of technical users who got annoyed but did not work this out.

I can’t quite say why Skype felt the best default for the app would be to create lots of dead space, rather than just reflow the text as the window was resized as it used to, but I’d strongly recommend them to reconsider that choice in future!  In the meantime, the best workaround is to maximise your Skype window and drag the text field out to full width – the chat will now resize when the window does.

Note: this post was originally written for the Masabists blog.

The clip starting at 10:00 in this video (courtesy Ketai) starkly represents why many mPayment schemes will not succeed – simply because you can do something doesn’t mean you will or should do it.
mPayments will certainly work, if they offer a significant benefit to the user over all alternatives, and are sufficiently easy and obvious that the user will think of attempting them. In many implementations I have seen, this is sadly not the case. Cash or cards are just easy natural payment systems, so the phone should only be brought in where these alone are not possible.
To succeed, the payment system needs to take the minimum of clicks and be resilient to error. It needs to interface seamlessly with the vendor/machine, just like a credit card terminal does in a shop – and just like dropping a coin in a slot does. If either of those is a viable alternative and the ease of use does not match them, you’re toast.
This suggests that the most fruitful targets are payments for less tangible things you can predict you need whilst on the move – like tickets – where there is huge benefit in the convenience of eg. not queuing behind ten slow people for a machine which may be out of change when you reach it, whilst your train is pulling out of the station. You could even buy the ticket with your phone after boarding the train, an option which has disappeared on many UK trains in recent years.
Having selected a ‘mobile friendly’ payment, you need to work out what the best platform is for taking it – which involves weighing up a number of factors:

• For a small rapid payment with limited options that can absorb a 30-60% margin, Premium SMS (PSMS) is king
  • The response can even include simple barcodes, though not the complex ones likely to become standard in most applications;
  • For anything more complex, margin sensitive or larger than a few pounds/euros/dollars PSMS cannot be used.
• The mobile web implemented well will offer rapid access for a user
  • It can have big problems for multistep payments when the user is on the move (flaky connections, no on-client validation etc)
  • There are also security concerns with some handsets/networks;
• For regular payments a thick client offers big advantages if it is written to work for the whole mass market
  • Greater ease of use eg. with on-client validation, interactive help etc;
  • More resilience to poor connections;
  • Lower data costs.

Even with a good target service, success is not guaranteed – the process still needs to be smooth and just work, something sadly lacking for so many reasons in today’s mobile experience. To quote Andrew Orlowski on the Register:
“Today’s mobile hypesters who confidently predict the web going mobile, forgot that the web competes with local knowledge. It’s almost always quicker (and more fun) to be prepared in advance, or ask someone, once mobile. You can ask someone next to you, or you can call a friend: either is quicker than tapping away on a phone. Mobile surfing was crap when it was WAP, crap now it’s an XHTML browser, and will be crap when it’s an AJAX Widget.”

mPayments are not for everything. Before embarking on a trial just place yourself in the shoes of a user and ask – why does this make my life easier than the alternatives at my disposal? Only continue if you can answer that question honestly. We’re currently getting great feedback from rail ticketing and parking trials and we’re pursuing a number of other clear business cases with our partners – but we’re steering clear of Coke vending machine purchases as coins look set to have some life in them yet!

Please comment on the original post.