Masabi

NFC Roundup – 2009

Tom Godber — Thu, 22 Oct 2009 14:19:11 +0000

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:

Nokia – 3 commercially available, first in 2007
Samsung – 1 named prototype in 2006, others hinted at
LG – 1 prototype
Sony-Ericsson – 0
Apple – 0
RIM – 0
Motorola – 0

NFC Predictions

Which year will NFC take off?

“NFC use will start to accelerate ” – predictions for 2008 (Nokia blog, Jan 2008)
“In the US, expect 2008 to be the year that NFC breaks out” (NFCNews, Dec 2007)
“2007 will be critical for NFC technology” (ABI Research, Apr 2007)
“The momentum behind NFC is growing rapidly.” (NFC Forum, Feb 2007)

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.

Århus Mobile Ticketing Workshop slides

Tom Godber — Thu, 08 Oct 2009 13:56:00 +0000

Giacomo’s talk a few weeks back at the Mobile Ticketing Workshop in Århus, Denmark went down extremely well, rounding out an interesting discussion on the ins and outs of mTicketing. You can see his slides here:

Mobile Ticketing Workshop 2009

View more presentations from Masabi.

The ability to take payments from the customer and initiate the ticket sale from the mobile was cited as a key feature by a lot of attendees.

Thoughts on ITSO part 1: Smartcard Ticket Usability

Alex Anderson — Tue, 06 Oct 2009 15:56:00 +0000

On 28th October, the consultation period ends for the Department for Transport’s paper Developing a strategy for smart and integrated ticketing, which is effectively¹ 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.

Usability

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.

Ticket purchase

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.

Journey details

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.

Ticket selection

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

Queues

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.

Masabi at Aarhus Mobile Ticketing Workshop

Tom Godber — Tue, 22 Sep 2009 23:24:00 +0000

My colleague Giacomo will be presenting and taking part in a panel today on Mobile Ticketing at the Aarhus School of Business in Denmark. Drop by if you’re around, and check back here later in the week if not for the slides! Related posts:Århus Mobile Ticketing Workshop slidesMasabi to Present at Mobile Monday EstoniaÅrhus Mobile [...] Related posts:

Masabi speaking in Seoul next week

Tom Godber — Fri, 04 Sep 2009 11:00:00 +0000

Ben Whitaker will be speaking alongside Nokia at the Mobile Content Conference & Awards 2009 in Seoul, Korea next week (September 9th-11th). His talk is titled “Mobile Commerce meets the Real World in Ticketing”.

If you’re at the show, or indeed in Seoul at the time, and want to talk mobile ticketing then get in touch and he’ll be happy to meet you!

Hacking AdMob Handset Statistics

Tom Godber — Thu, 03 Sep 2009 17:34:00 +0000

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:

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:

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

3 Job Vacancies: Mobile Tester, Server Dev and Mobile Dev

Ben Whitaker — Mon, 17 Aug 2009 09:05:00 +0000

Firstly: NO AGENCIES OR RECRUITERS!
(We are interested in pro-active candidates who are motivated enough to find us by themselves.)

Masabi are currently on the lookout for three new members of staff to join our team – a tester, a junior mobile programmer and a more experienced server programmer.

Skills we look for in every candidate: passionate, clear thinking, flexible, confident working in small teams, fluent in English, and London-based, you’ll have a desire to be both critical and receptive to the input of other team members. Masabi offers the ideal candidates an exciting work environment with plenty of opportunity to excel in an exciting growing business solving a clear customer need with a working revenue share business model.

The three jobs currently available are as follows:

QA GURU
We need a tester with experience across the full range of mobile devices, testing consumer-focused applications on real handsets and online simulators, as well as related web resources. We view a testing mindset as pretty opposite to a developer mindset and are really interested in someone who actually wants to work in QA, with a pedantic perfectionist attitude, who revels in finding problems and obtuse bugs whilst having the skills to explain exactly how to reproduce them, on which handsets, without bruising egos. We’d also love it if you’ve experience with automated server testing, and have ideas on how you’d like us to develop our funky internal mobile testing system.

JUNIOR MOBILE DEVELOPER
A Java developer with a Computer Science degree and passion for programming, wanting to learn about creating beautiful usable products to solve real world problems on mass-market mobile phones. Blackberry and Windows Mobile programming experience a bonus.

SERVER DEVELOPER
A flexible J2EE developer with experience using Spring, Hibernate, JMX and creating interactive web front-ends, who is happy to work with various databases and webapp containers. Of great value: an understanding of secure systems, broad experience and flexibility with maintaining working servers, and skilled at working with remote teams from partner companies deploying products.

To get a better idea about what we do and how we do it, read blog.masabi.com, look through our flickr feed, and our website.

Candidates selected for interview must have excellent English skills with the ability to think concisely and communicate clearly with others, which will be tested at interview.

Again, please, NO AGENCIES! Really. We mean it.

If you’re confident you’re not an agency and are in fact the perfect candidate for us, please email a full CV with salary expectations and details on all relevant work permits to jobs@masabi.com

p.s. for those that want to see the office that you might be coming to work in:
Photos:
Exterior
Interior, Interior again
Ed pretending to do testing

(map shows it has great access to food heaven at Borough Market, Tube stops at Borough, London Bridge and Southwark, and commuting access from the Thames Water Taxi, and trains from Waterloo or London Bridge stations)

Ticketing via Local Webapps

Tom Godber — Fri, 31 Jul 2009 16:27:00 +0000

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:

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:

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

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.

StreetVendor – Mobile Financial Services platform

Ben Whitaker — Thu, 30 Jul 2009 09:38:00 +0000

Today we put out a press release about StreetVendor, the product we’ve built together with financial services and international payments experts Mi-Pay.

The press release can be found if you click here, and to accompany it there is a video interview below:

Screenshots of StreetVendor, showing both Arabic and English Script:

StreetVendor is available in many languages including complex scripts such as Russian, Simplified Chinese and Greek. (This is never as easy as you might first expect when it comes to mobile development for multiple handsets)

Like most Masabi products, StreetVendor has been built to work on old and new handsets, including 7 year old handsets, right through to the latest smartphones. This makes it easier to source suitable handsets cheaply in areas that you wish to operate in.

The encrypted SMS back-up system enables reliable comms from anywhere in the world that you can get SMS reception, and without needing any local integration.

Most importantly – this means that from one central server you can roll out your new Remittance or Financial Services anywhere in the world that you comply with banking regulations, and can get SMS.

New authorised agents simply need to find a supported colour screen mobile phone, and load the software onto their phones just once using any install method from PC cable, WAP, Bluetooth or old fashioned CSD download. Then the rest of the application’s work can be safely performed over SMS or any other available connection.

(Of course, all communications over SMS or GPRS are protected by EncryptME’s 1024bit RSA and 256bit AES security)