Posts Tagged ‘Masabists’

Masabists: Illustrating Gartner’s Q3 2010 Global Handset Shipment Report

// November 15th, 2010 // No Comments » // Mobile

This post originally appeared on the Masabists blog.

I created a quick infographic this weekend to illustrate the trends shown in Gartner’s recent Q3 2010 handset shipments report:

Gartner 2010 Q3 global handset shipments

The bluer a company is the more its market share is growing, the redder a company is the more its share is being eroded (even if handset shipments themselves are up) – which illustrates nicely the slow decline of the old guard, as a more diverse mix of companies invade the handset space. Fragmentation is here to stay.

Please comment on the original post

Passenger Focus Research Into Ticket Purchase Problems

// July 23rd, 2010 // No Comments » // Mobile, Usability

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.

Passenger Focus

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.

The application remembers recent journeys card-menu-with-visa

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):

2010 Passenger Focus queue times

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.

Masabists: NFC Roundup 2009

// October 25th, 2009 // Comments Off // Mobile

This post was originally featured on the Masabists blog.

After many trials, NFC has been on the cusp of launching in Europe for some time now. It is regularly brought up in conjunction with mobile ticketing, which has been one of the key use cases always quoted for the Felica NFC system available in Japan for some years now.

The potential is huge, and at Masabi we greatly look forward to the day we can start using it for transport ticketing – but where do we stand, in late October 2009?

UK Operator Support

O2 last did an NFC trial in 2008, and almost exactly a year ago they stated at a Mobile Monday NFC event that it had gone so well they were looking to run another trial at some point in the future. We haven’t had that trial yet.

A mobile phone feature requires operator subsidy to gain traction, because no manufacturer will foot the bill for the electronics on their own. Therefore, the number of NFC-enabled handsets currently available from each UK operator tells us a lot about where NFC lies along the feature adoption curve:

  • O2 – 0
  • Vodafone – 0
  • Orange – 0
  • T-Mobile – 0
  • Three – 0

Carphone Warehouse, the UK’s biggest indepedent high street retailer, also currently sell no NFC-enabled handsets.

NFC-Capable Handsets

GSM handsets with NFC launched by handset manufacturers:

NFC Predictions

Which year will NFC take off?

How big will the market be?

  • “by 2012, some 292 million handsets — just over 20 percent of the global mobile handset market — will ship with built in NFC” (ABI Research, Apr 2007)
  • Mobile phone based contactless payments will facilitate over $36 billion of worldwide consumer spending by 2011.” (Strategy Analytics, Oct 2006)

It’s easy to be cynical about 20% of handsets having NFC in 2012, as we start to roll into 2010 without any NFC handsets on sale – but once NFC handsets start shipping, how quickly could they be adopted?

Phone Feature Adoption Curve

In 2000 Sharp launched the world’s first camera phone, which was a bit of a novelty. By the end of 2003, 25-35% of handsets had some sort of camera on them. By 2007, M:Metrics stated that 75% of UK handsets and 51% of US handsets had cameras – 7 years after the first launch.

Arguably, cameras are a more obvious feature for a mobile handset than NFC.

The first handset commercially available outside Japan with integrated NFC was the Nokia 6131NFC, launched in 2007. At the end of 2009 we still have no operator subsidised NFC handsets, which suggests there is little chance of matching the camera adoption rate, with 25-35% at the end of next year.

From this quick comparison, we can assume that we are either still sitting before the start of the NFC adoption curve, or the NFC adoption curve is very much flatter than that of phone cameras – more like mobile TV, say.

Conclusion

When it comes, NFC has some great potential in niche markets like mobile ticketing. At Masabi, we’re greatly looking forward to it. But right now, as a company principally interested in mass-market technology, we’re not holding our breaths.

Please comment on the original post

Masabists: Hacking AdMob Stats

// September 3rd, 2009 // No Comments » // Mobile

This post was originally featured on the Masabists blog, and was voted joint top post in Carnival of the Mobilists #190.

Handset statistics are notoriously hard to come by – only the operators know what handsets are actually being used by all customers on their network, and they won’t tell. Every other purveyor of statistics has an inherent bias, which makes them more attractive for some analyses and less for others. For example:

  • GetJar make comprehensive statistics available for who is downloading applications from their site and have huge cross-operator volumes of downloads
    • …but many of these are downloaded via the web and synced through a cable, a highly unusual activity for most mobile users
    • …which puts a huge skew on the data – I’m pretty certain Amoi aren’t actually larger in the UK market than RIM’s Blackberry.
  • Bango publish a Top 20 handsets list every month or so, with a skew for their operator relationships
    • Top 20 is great but there are plenty of handsets below that which are still worth supporting
  • AdMob have some immensely detailed metrics reports, but again the operator partner skew was always very visible
    • I’m just not convinced that anything by ZTE is actually in the Top 10 most popular UK phones!
    • I’m also unconvinced that the iPod Touch is much more popular than the iPhone…

User Profiles

All of these statistics have great value, but none of these companies can actually give an overall picture fo the entire market. Each set will be skewed heavily based on the type of user attracted to the service and the operator relationships that service has. To find out the overall market picture fudge them all together and treat with care – but by profiling each site you can find out more useful information for specific needs.

AdMob, as the main provider of mobile web advertising, offer a very good view of the mobile data user, who would also be an obvious early adopter of any mobile service requiring net access, be it web-based or a networked application.

Traditionally, AdMob have just given a Top N list of device models and some aggregate manufacturer numbers, which were never enough to tell anything useful – their strong relationship with MVNO Three clearly led to some very obvious weird “popular” handsets showing up and called all of the data into question.

I had always dismissed them at this point and moved on. Fortunately, though, when you look inside the reports they publish per-operator statistics for each manufacturer – so we can actually derive some meaningful national conclusions!

Hacking The Stats

So – why hack? Don’t we have everything we need?

Sadly not – the July ’09 report is a very nice professional PDF given graphical summaries of the manufacturer breakdown per-operator, as a series of proportions in stacked columns:

AdMob handset statistics - UK operator split

Whilst it is flattering, as a Jersey boy, to see Jersey Telecoms given equal weight to Vodafone, I have a sneaking suspicion that the entire population of Jersey is equivalent to a rounding error when counting Vodafone’s UK customer base.

What we need is to convert these into national numbers, by weighting all of the proportions by the size of the operator. The only way to do this with the public information is to screenshot the graph from the PDF at the largest size you can get it, and count the pixels for every bar – tedious, but luckily for you I’ve done it for you.

Telecoms Market Research provide some useful figures from Q1 2008 for each operator (not up to date, but close enough for these purposes):

Once we aggregate all of these weighted proportions, we end up with the following rough proportions for manufacturers among early mobile web adopters:

Handset manufacturer proportions for mobile web users in UK June 2009, derived from AdMob statistics

It won’t help everyone, but hopefully it is of some use for anyone struggling for some statistics!

Please comment on the original post.

Masabists: Ticketing via Local Webapps

// July 31st, 2009 // Comments Off // Mobile

This was originally posted on the Masabists blog.

We’re finally able to show off some of the work we’ve been doing recently on local mobile webapps – interactive web pages which can be saved and run even when you’re offline.

Our mobile ticket sales app is now available as a local Java app for mass market handsets, and a local webapp for Android and iPhone – offering all the same functionality, security and slick branding:

Masabi Train Ticketing local webapp on an iPhone Masabi Train Ticketing Java app running on a Nokia N96

What Is A Local Webapp?

With the latest HTML 5 and Google Gears APIs support on Android, iPhone and Palm Pre, you can provide a fast multi-screen interactive app with local storage (to store tickets you have purchased), which behaves like a native local app and is accessible even when the phone is offline. Here’s how to store the app for later use on an iPhone – reached by clicking on the ‘+’ icon in the footer:

Why Webapps?

Traditionally at Masabi we have always written local apps in Java, because they offer the best mass market user experience for the sort of ticketing and financial services we provide; it’s only with the advent of handsets with fast, HTML 5-capable browsers that we have been able to explore the webapp route. We plan to use local webapps for many of our iPhone and Android products for two core reasons:

  1. With the proliferation of new platforms causing even more fragmentation in the mobile apps space, the Safari browser used on both platforms is actually the safest way to reduce fragmentation and streamline maintenance and development;
  2. There are some big advantages to the unrestricted installation of a webapp via the web, especially if your business model is not compatible with the rules or revenue shares of the relevant App Store; it can be hard to justify to a customer the extra expense of a dedicated app when you cannot guarantee the app will ever be allowed on the store or device.

Fortunately, it is easy to take a local webapp and wrap it up as a native iPhone or Android app, so we can make all of the services available through the relevant App Stores as well if that is what the users want.

It is worth noting that at Masabi we are producing free mass market services which pay for themselves through transaction fees, so the App Store’s billing system isn’t an issue for us – your mileage may vary…

Does It Feel Like A Normal App?

Webapps can very successfully replicate the look and feel of native apps, with quick scrolling between screens, button styles and the like.
Below are screenshots of the user selecting an option from a list, and a date from the calendar:

Selecting an option from a list on the Masabi Train Ticketing local webapp on an iPhone Picking a date on the Masabi Train Ticketing local webapp on an iPhone

These clearly follow the style and usability conventions of the built-in iPhone apps. With CSS targetted to the device through our DeployME server, we reskin the same application easily to adopt Android conventions and styling as well.

Please comment on the original post.

Masabists: Sony-Ericsson Handset Announcements

// June 1st, 2009 // Comments Off // Mobile

Note: this was first posted on the Masabists blog and featured on Carnival of the Mobilists 177.

There are a few interesting points raised in the technical details accompanying Sony-Ericsson’s recent announcement of the Aino and Yari handsets – app usability should improve, whilst Sony-Ericsson’s smartphone platform strategy is tending towards the Samsung “try ‘em all” approach…

Concessions to Usability

Most importantly for developers, the new handsets aim to reduce the permission dialogue hassle that users experience when running applications on their handsets. This is a huge bugbear which just adds user pain without really improving security – because users rarely read the (often opaque) language of the message, they just click and get annoyed at the jarring interruption in their workflow:

MIDP permissions dialogue

The absence of these interrupting dialogues in iPhone applications adds to their usability.  They have clear purpose, but MIDP has always erred too far to the side of caution, and allowed explanation messages to be written and translated by programmers not usability experts, to confusing effect. They simply annoy, and give the platform a slightly amateur feel.

Sony-Ericsson suggest that Unsigned apps will now show far fewer dialogues, and Trusted 3rd Party signed apps will be able to ask once and then never bother the user again.  This is absolutely excellent news because it eliminates a key barrier to regular app usage.

Sony-Ericsson says this is in line with recommendations in the MSA spec – an umbrella JSR mandating the support for a huge range of APIs adding up to a very powerful platform, which is now gaining a lot of traction. This is also a great thing, because it implies that Sun recognise the problem, and that other handset manufacturers may be following suit.

Whilst in general I am in favour of reudcing the permission overhead to a secure minimum, this can go too far.  I am quite worried about the idea that dialogues may not be required when implementing the upcoming Javascript APIs designed to allow webapps greater access to the handset hardware – the potential for malicious scripting is huge.

Hopefully Javascript will find a more sensible balance where MIDP at first did not, because HTML 5 is opening up some exciting opportunities. Given, however, that browsers shipping today appear to be replicating all of the proprietary manufacturer-specific API problems of early MIDP, I’m certainly not holding my breath!

Post-UIQ Smartphone OS Standardisation?

In the good old days, Sony-Ericsson were pioneers in the smartphone market with the P800, back when everyone thought a smartphone should be like a PDA.  Looking back, my gut feeling is that on every subsequent revision UIQ (a UI layer built on Symbian) dropped further and further from the leading edge, striking an unhappy balance between mainstream usability and PDA power. UIQ finally went under when Nokia took Symbian open source without them, leaving Sony-Ericsson without a smartphone platform.

This is roughly the point when Sony-Ericsson launched the Xperia, a Windows Mobile handset that was very interesting, though ultimately didn’t fully live up to expectations.  A lot of effort was put into encouraging developers to build panels and things (proprietary UI extensions), but to the best of my knowledge they haven’t announced any more Windows Mobile devices – and hopefully they’ll stay that way.

Subsequently, Sony-Ericsson stated they would be focussing on the Android platform for future smartphones… and then announced two S60 handsets.  They have dropped hints that Android wasn’t to displace other OS platforms, but can a company in Sony-Ericsson’s state really support simultaneous development on two or three smartphone OSs as well as their (actually very good) proprietary feature phone OS?  Note that smartphones are only around 13.5% of current world handset sales (although at the lucrative end)…

Please comment on the original post.

Masabists: Interesting Blackberry Factoids for Developers

// April 22nd, 2009 // Comments Off // Mobile

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

We’ve just had a great chat with the extremely helpful RIM Developer Relations guys, and some things came out of it which we were only slightly aware of. None are secret, just buried in spec documents and forums, so I thought it would be worth putting them up on the blog in case they are helpful to other developers:

Applications Permission Manager

Since Firmware 4.2.1, there has been a manager object which can not only tell you what the current API permissions are for your app, but allows you to display the device’s application permissions dialogue with your favoured settings pre-populated, which the user can then choose to save if they are comfortable with them.

Used correctly, this is a great way for the app to discretely flag how the user can make their life easier, without being too intrusive. We’re all about removing pain in a secure fashion, and love this! There are some pointers in this presentation, and from there you can dig into the relevant API.

Device Upgrades can Migrate Applications

A user can migrate their applications to a new device alongside their contacts, mails etc. On the face of things this is very useful, but it means your app’s cod files must be as happy working on a scrollwheel Suretype device with a 240×260 screen (eg. 7100) as they are on trackball QWERTY devices with 480×320 screens (eg. a Bold).

This could have real implications for games, which often use large graphics scaled and optimised for a particular screen size. It also impacts some strategies for providing UI movement and widgets across different keyboard and scroll/pointer types on fully branded Canvas-based applications.

The application’s RMS memory migrates with the app, and applications can query the device to find out its unique ID and specification, so if this is a huge problem you should always compare IDs at startup and issue an upgrade so that the user picks up a more appropriate cod.

The Storm’s Touch Screen Prefers Native Applications to MIDlets

If you want to provide proper support for the Storm’s touch UI, you’ll have to do it with a native UIApplication instead of a MIDlet. The MIDP Canvas touchscreen API is not expressive enough to handle the two levels of click used on the Storm.

Newer Blackberries Can Read Custom Jad Parameters

A huge bugbear with Blackberries before was their inability to read any parameter from the jad – this made the provisioning of unique information at installation time all but impossible. The MIDlet.getAppParameter() method simply returns any value stored in the Manifest at compile time, but nothing added in the jad afterwards.

Since firmware 4.3.0, this now works – and RIM are very good at providing clear User Agents identifying the device and its firmware when browsing (unlike some others), so you can make this call at provisioning time.

There’s also a great tutorial on Blackberry vs. MIDP code signing (PDF). I hope some of that information is of use to people – the guys from RIM were extremely helpful and we certainly were very happily surprised how much we got out of the meeting.

On an unrelated side-note, we’ve started Twittering – we’re just restricting the company tweets to information relevant to mobile applications, security and transport so if any of that is you’re bag feel free to follow us!

Please comment on the original post.

Masabists: Transcoders round 2

// February 13th, 2009 // Comments Off // Mobile

Note: this post was originally written for the Masabists blog, and was nominated Post of the Week on Carnival of the Mobilists #161.

It has been incredibly busy pre-MWC and so I have not yet pulled together our research into mobile browser handling of SSL certificates (as promised when I described transcoders). However one piece of news inspired me to write an addendum – Novarra, a transcoder vendor, have now started offering a version of their transcoder for laptops using 3G dongles. Bill Ray isn’t certain about all the details, and Novarra still haven’t replied to my previous request for information so it is difficult to confirm anything, but I’ll restate the problem now and draw some possible conclusions from that.

The problem as it stands: transcoder vendors want to rewrite content to improve performance and accessibility of sites accessed through “mobile” connections. To do this for secure HTTPS sites, they insert themselves into the transaction quietly, breaking end-to-end encryption and creating a potential security hole – though if they are doing their job correctly it should be hard to exploit. More details here.

The transcoder vendors are asking the W3C to approve a new best practices guide which states that they will be allowed to insert themselves into an HTTPS connection, but if the server has set a special HTTP header they will immediately stop and allow end-to-end encryption to resume. If you’re interested in the politics WapReview have an excellent post covering them.

On the face of things the proposal sounds eminently reasonable. It isn’t.

One year ago Netcraft reported that there were 2,451,780 sites on the web responding to SSL (HTTPS) requests, 794,008 of which certificates verified by trusted third parties such as Verisign. Growth was nearly 40% year-on-year at that point, so we can assume there are at least 3m sites today, 1m of which are serious about their security.

There are approximately 5-15 transcoder vendors (that’s an educated guess – there are more than two and I can’t imagine there are as many as 20).

The vendors believe that for security to be guaranteed, the best thing to do is that they break the existing standard, and all 1m (or 3m) sites on the web must change their server configuration if they want to continue being secure. This agreement will be made by a committee of a few dozen people at W3C – no word yet on how widely it will be publicised, but the people publicising the process so far are largely outsiders who don’t like the sound of it.
Many might not care, because they don’t support mobile handsets directly and don’t plan to in the near future. The move to broaden transcoding into laptop connections may make those people think twice, especially when you consider that in the future WiMax and LTE will start to offer true broadband over the air and the entire nature of the internet connection industry will change and become more wireless.

It seems common sense to a layman: the 3+ million e-commerce sites, corporate intranets etc should be allowed to remain secure without having to change all of their configuration; the dozen or so transcoder vendors should honour the existing system. If it is neccessary to transcode HTTPS connections, this should be an opt-in service decided by each and every site, who should be given full explanations of the (minimal?) risks – because they have the burden of care to their users, adherance to banking/privacy regulations, etc.

Let’s hope the W3C make the right decision, but if you are concerned about this maybe it’s worth publicising it widely just in case?

Please comment on the original post.

Masabists: NFC – One Day It’ll Be Great

// October 15th, 2008 // Comments Off // Mobile

Note: this post was originally written for the Masabists blog, and featured on Carnival of the Mobilists #146.

Currently there are two potential candidate technologies for scanning an electronic ticket held on a mobile phone – 2D barcodes (visual scanning) and NFC (wireless scanning). From Masabi’s point of view they are interchangeable – just connection technologies for our ticketing services, which can support either – but MoMo London’s NFC event this week provided some very interesting confirmation that barcodes will be ruling the roost for some time.

The event had a great mix of speakers, covering the full breadth of the technology from potential use cases right through to a speaker from O2 covering their recently concluded London-based trial. Telefonica/O2 have been the most agressive European operator backers of the technology, and their trial stats were very positive on the surface, but they didn’t stand up to much scrutiny.

The headline 80+% approval ratings all came from Londoners who had been given free handsets that they could use as Oyster cards (for travel on the Tube), with free credit to get them started – I’d certainly be very happy with that! The majority of the UK population – and the majority of the European and world populations – haven’t been obliged to use a widespread NFC-based network every day for several years, so it is unlikely that these interest levels could be replicated elsewhere.

The most telling thing about Claire from O2′s talk, though, was that the trial was so successful that O2 now had enough data for… directing another trial, at some point in the future. Moreover she stated that O2 had decided they were not interested in taking any revenue share from NFC payments, whilst acknowledging that they as the operator would bear the brunt of user support costs for on-phone NFC payments. Does that setup make O2 likely to spend money rolling out a service which will then cost them more money to run, with no revenue upside?

Just to confirm this pessimistic view, Claire declared that O2 would only consider a commercial launch in partnership with all operators, offering a wide range of NFC-enabled devices. However consider:

  • Currently only Nokia have an NFC handset on the market (a niche mid-range feature phone);
  • That handset isn’t widely available through operators on contract;
  • No other major manufacturer has announced an upcoming NFC handset;
  • Handset manufacturers will only increase the cost of a device by putting NFC into it if the operators ask them to – clearly, they aren’t.

Claire’s tone of voice seemed… cautious when she suggested that analysts reckoned it might get big in 2012. Even if we ignore the impact of potential world recession on the technology industry, that seems optimistic:

  • New handsets take time to design and new features require new skills to integrate into hardware and firmware;
  • There is a clear lag between handsets first arriving in the shops and those same handsets becoming widespread, as users usually only upgrade at the end of a contract;
  • Handset upgrade cycles are slowing down as operators try and encourage customers onto 18 and 24 month contracts, instead of the more usual 12 (Orange recently offered me a massive discount for just such a move when I upgraded to Nokia’s flagship N96, which contains every feature under the sun – except NFC).

Going mainstream in 2012 suggests a lot of new NFC handsets will be commissioned, designed, manufactured and shipped out in volume by the start of 2011, just over two years from now… possible, but unlikely.

So is NFC living on perpetual limited-scale-trial life support? That may be the case for on-handset NFC, but James from Mastercard hinted at the real future of the technology – already hundreds of thousands of normal credit and debit cards have shipped out NFC-enabled, even if their owners don’t have any idea what that means.

It is not a huge leap of the imagination to see NFC as being “cheap enough” to just implement in next generation card processing terminals, so the natural upgrade cycle of those terminals leads to a widespread “stealth” deployment of NFC processing capability – without requiring retailers to actually pay out for a massive infrastructure upgrade so soon after Chip and PIN was introduced. Once the technology is out there, it may start to be understood and used, and once it starts to be used the added advantages of NFC on handsets may be compelling enough – and cheap enough – for a mass market roll out.

Until then, we’ll stick to a two pronged approach: 2D barcodes for our mainstream ticketing solutions, and limited scale NFC deployments where the handsets and infrastructure are available.

YourRail ticket sales app YourRail ticket sales app

National Express East Coast ticketing app National Express East Coast ticketing app

Please comment on the original post.

Masabists: Judging When An mPayment Makes Sense

// April 24th, 2008 // Comments Off // Mobile, Usability

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.