Our first WebOS app has been released into the wild!

TheTicketApp is a somewhat lush app for the HP TouchPad, which exposes the inventory of theatre seats LastMinute sell: up to a few minutes before a performance starts, you can dive in and grab a ticket.

We've worked with the team at LastMinute Labs for the last three years, and it was they that put together the back-end and did the initial mobile-web version of TheTicketApp (which launched in January of this year). Our brief was to tie into the existing back-end, and present a user interface that played to the strengths of WebOS.

Despite being our first WebOS product,in terms of process it was pretty well by-the-book. HP supplied us with a tablet quite early on; this might seem like an obvious first step, but some of our work with pre-release hardware has involved not seeing real kit until near-launch, and it's always nicer to be able to play with physical stuff. This time around, we could fiddle with the rather fresh and spangly device, run through other apps, and generally get used to the flow and metaphors of the UI. Then it was the usual story: work up a set of wireframes, double-check against the capabilities of the platform, and progressively fill in the visual detail. We're quite familiar with the LastMinute brand, so were comfortable taking it to a new operating system and form fator.

The JavaScript toolkit we used to develop the app, Enyo, supports the WebOS metaphors (like the sliding panes). Our dev team were divided: some felt that it's quite nicely architected but documentation was lacking, others the precise opposite. But we're all happy with the end result, and are already working on a second app which pushes Enyo a little bit further...

You can find TheTicketApp in the TouchPad App Catalog. Thanks to the team at FP who delivered this little bundle of joy: that's Doug Hoskins, Trevor May, Dominic Travers, John Revill, Ben Carias, Paul Welsh, and Cori Samuel. At LastMinute, Dave Slocombe kept us on-track with the product vision, and Richard Lewis Jones held our hands with the API. Pramesh Chauhan at HP provided phenomenal support - his 4 minute turnaround for a support request is the best we've seen...

Last week was my upgrade birthday. Having spent a year on the iPhone 4 I thought I'd try Android for a while, and ordered a Samsung Galaxy S2 from Orange.

The device lacks the heft and solidity of an iPhone and feels quite plasticky. Not having tried to smash it yet, I'm not sure how resilient it is, but it gives the impression of being a little fragile. The large screen is bright and clear. I think it's the main reason text entry on the device is better than on any other Android phone I've used: the keys are a little larger.

The software I'm less keen on, and I think the root cause here is the ease which which OEMs and operators can customise Android. It seems to allow the mobile industry to more easily commit the same crimes which left room for iPhone to succeed: exposing internal politics as end-user choices, bundling unnecessary or unreliable products, and reskinning the product to follow brand guidelines at the expense of usability.

Specifically:

• On first start I was asked which home screen I want to use - Samsung or Orange? At this point I had no idea what the trade-offs were; it's instant unnecessary confusion, spraying the internal politics of the mobile industry into my eager eyes.
• Once I'd chosen Orange, I couldn't add a home screen calendar widget. I had to switch to the Samsung home screen to do this. Instant disappointment: Orange had removed a feature I had used elsewhere, wanted and loved.
• The themed icons were either clear but ugly (in the case of Samsung) or unclear but visually appealing (in the case of Orange). I'd like to have seen handset themes implemented as on Symbian Series 60: enabled by default, but easily (and completely) removable by the user.
• Neither icon set was consistent with my experience of Android on other devices. Android isn't new any more, and it's advertised as a feature in its own right for handsets sold on the Orange shop. If Orange customers are buying Android phones because they're familiar with it, changing the top level of the UI (where most of this familiarity resides) is unhelpful and confusing.
• The device came bundled with a huge number of apps (about 40), many of which I'd no desire for (Social Hub, Music Hub, Readers Hub, Games Hub, AllShare, Kies air). I'm prevented from uninstalling these apps, perhaps in the hope that their constant presence on my phone will force me to begrudgingly use and then love them.
• There were at least three app stores on the device: the Android Marketplace, Orange App Shop, and Samsung Apps. The Orange App Shop refused to start until I disabled Wi-fi; I would imagine this will leave some customers suspicious about data charges.
• I never managed to get the Orange Maps app to work; it crashed every time I launched it - a massive failure of QA. I'm also deeply sceptical that it'd be better than Google Maps. If it isn't, bundling it has been a waste of Orange's effort and my attention.

More positively, I thought the Orange Wednesdays app (not one of ours, I hasten to add) was excellent, tying into a wonderful long-running campaign and genuinely useful. Orange aren't short on other such products and campaigns.

Music syncing seemed to work OK once I'd downloaded DoubleTwist. I was pleasantly surprised to see 1Password available for Android too - it's one of my frequently used iPhone apps. At the same time, OmniFocus is sadly lacking - and this alone may be what prevents my moving from Apple in the near future. Where's the equivalent for Android? Where are the apps which are both unique to the platform and so strong you don't want to leave?

So, thoughts on how devices like this should be customised:

1. Ensure any theming can be disabled and bundled applications removed or hidden;
2. Ensure any bundled apps work well - there's no excuse for first-run crashes;
3. Decide whether the device will be OEM-branded or operator-branded and stick with it - don't try to do both;
4. Don't go to the expense of bundling apps which duplicate functionality available elsewhere (email, maps, search, app stores);
5. Do bundle apps which you can do better than anyone else, and support your activities elsewhere (e.g. Orange Wednesdays);
6. Look to useful platform- or network-specific apps for locking customers in;

So, we're reviewing the data from our Glastonbury app and it's thrown up a few surprises which I thought I'd share here.

The overall download numbers were excellent. We've had over 100,000 so far across iPhone, Android and Qt; and we were featured in the editorial sections of all three app stores. We smashed through the targets Orange set us; and, having been briefed by Orange at the start that they wanted to reach beyond festival-goers, we were very pleased to notice the many reviews and tweets from users who downloaded and used the app without ever making it to Somerset.

As I've mentioned before, we knew that battery life and connectivity are at a premium for festival-goers, so we put a lot of work into ensuring the app could work offline. If it could get a connection, it'd use it to check for line-up changes and news, but if it couldn't, the app would still work.

This means that we can't track usage of the app directly by looking at connections to the line-up-serving back-end. But we think we can see relative interest over time. Here's a graph of traffic to the app over the month around the festival:

You can clearly see peaks in the individual afternoons, then a huge spike when the full artist line-up is released, and mounting excitement as the festival approaches. Friday night is our highest ever traffic, but Saturday and Sunday don't exhibit the kind of tail-off I had expected from dwindling batteries and ever-more-careful use of mobiles. It looks like those chill'n'charge tents got some heavy use :)

Other surprises? We could see twice as much per-user activity from Android users as from iPhone owners, although overall iOS downloads were about 4 times higher. Both of these surprised me: I'd have expected activity to be roughly equivalent, and there to have been more Android downloads given the growth of the platform over the last few years.

And on the fluffier end of things, we were touched by the number of people who returned to their app store after the event to leave a post-mortem review. That's really sweet; almost as sweet as reading tweets like this one, from several users who became quite emotional at the thought of deleting our little app:

Update: a great comment from Ged Byrne (see below) had me looking into traffic by platform over time... and noticing that Android users are slightly more active in general, but their activity dropped off over the four days of the festival much more slowly than that of Android users. I'd agree with Ged that this is down to Androiders being able to change batteries (a suggestion from the office was that they might be more accustomed to killing apps and reducing battery drain too).

Design Communism: "The Browser Ghetto is effectively a subpar OS with it’s own incompatible user conventions. What is needed is a deep integration of mobile technologies into the OS of a phone, done in a way that works across multiple platforms. This is where my design communism comes into play. Both Apple and Google seem unlikely to consider this. Their fear is that doing so would cede much of their app market away, turning their handsets into commodities. A naive form of capitalism dictates that they keep control and not embrace any approach that gives away their lock in."

Another FP product slips out of its berth and into an app store today - we've just launched "AA Breakdown & Traffic", a product for the AA targeting modern Nokia devices (N8 and similar).

It's a straightforward app to get you help when you're on the road. So there's a few use cases we cover:

1. If you've broken down and you're not quite sure where, the app will report your location into the AA before you call them - so they know exactly where you are, and can get a patrol to you as quick as possible. This is a great reassurance if you're an AA member;
2. The AA publish a pile of authoritative traffic information, which you can see overlaid on a map, or browse by road name; so before you set out on a trip, or during your journey, you can see where incidents are and avoid them;
3. Owning a car involves keeping track of due dates for your MOT, insurance, and (if you're a member) your AA membership. The app has a handy little reminder feature, to make sure you don't miss any of these... and links through to the AA mobile site to help you buy insurance if you need it;

You don't need to be an AA member to use the app, and it's a free download from the Ovi store.

We built it using Qt and QML; it was actually the first Qt app we worked on at FP, but the Glastonbury app we launched earlier this month made it into the store quicker. You can see a lovely video about Roadwatch - starring Jeff Triner of the AA (and our customer) and Doug Hoskins, the Lead Developer from FP, over here.

Also from FP: John Revill and James Hugman worked on building the app, Trevor May designed it, Ben Carias and Paul Welsh tested the beast, and I acted as Product Owner (doing a little bit of discount usability testing in the process, which I might write about separately). A team at the AA provided the back-end services which we tied into.