dConstruct this year was a chance to see Bryan and Steph talk, and as usual I found their presentation fascinating and thought-provoking. One of their themes was to call for a "useful unfinished-ness" to products (slides 29-44):

"Issuing your customers with something that is rough, incomplete, and possibly even substandard seems counterintuitive but there is growing evidence that people don't necessarily want the perfect product, they prefer to deal with something ragged around the edges that they can adapt or improve."
- Loose, by Martin Thomas

This got me thinking as to how, in mobile, this useful unfinished-ness might be manifested; sidestepping the native/web debate briefly, how we could build mobile apps that allow themselves to be adapted or improved? I thought it'd be worth listing methods I can think of; can anyone think of more?

1. Intents (Android only) - OpenIntents has a good list from third-party apps, Google publish a list for their apps;
2. Downloadable SDKs, e.g. Facebook or OpenFeint;
3. Custom URL schemes (Android and iOS), there are a couple of databases here and here, in combination with the canOpenURL call (on iOS) and I suspect some variant of isIntentAvailable on Android (tho I'm not 100% sure of the latter);
4. Opening the source; not ideal as it'd likely mean third parties have to build a new copy of your app and distribute it; but it felt remiss to leave it off the list;
5. Web services, so the data your app uses can be pulled in from a variety of sources;
6. Push notifications or other messaging from outside your app (e.g. SMS), which your app can pick up on and react to;

Anyone think of any other sneaky waves of plugging mobile apps together?

Alex Craxton asked a question on Twitter, around how quickly users do or don't upgrade their applications. Quick as a flash, Mr Hugman had dug out the relevant graphs from our analytics of The Guardian Anywhere. The following two graphs show the transition between two minor versions of the product - from 2.15 to 2.17 (2.16 was a very short-lived version we rolled out a bug fix for):

Ramp-down from 2.15:

Ramp-up from 2.17:

They're plotting the number of synchronisations we've had from each version, per day. We typically see one sync per active user per day.

The Guardian Anywhere currently has 36,440 users with active installations; given that by the 8th August we had 29,745 syncs from version 2.17, this equates to 81% of our audience upgrading to the latest version within 5 weeks of launch. Hope that helps, Alex!

TechCrunch have been running a story about Diary.com adopting HTML5 for their mobile efforts. I found it quite a strange article, and it plays to some of the scepticism I've been experiencing recently around HTML5 as a nirvana for cross-platform app development.

To me, the article reads like a sequence of arguments against taking such an approach:

• Performance problems: "The performance of the Diary Mobile App… was the biggest challenge", "it wasn’t easy, performance was a huge issue at times it took days to figure out, and simple things like too much logging and poorly constructed ‘for’ loops actually made our app unusable during our journey."
• Reliance on third-party toolkits which are outside your control: "Sencha Touch is quite a beast and we’ve had to patch quite a lot of it to make it more performant and apply bugfixes", "we had some serious issues with the performance of Sencha Touch on some of the input fields that we had to provide fixes for"
• They ended up having to do native development anyway: "We built two Phonegap plugins; a Flurry API PhoneGap plugin for iOS (to be released open source in the future, and another to use the Local Notifications on iOS (also open source plans)"
• …and it sounds like they had to build a new API to service the back-end of the app (which admittedly they can probably reuse elsewhere): "We built an entirely REST API for which the app communicates with to make it as efficient and fast as possible"

This doesn't sound like an easy route out of the pain of cross-platform native development to me. Hats off to the Diary.com team who've made this work - HTML5 clearly hasn't provided a simple solution to their problems. And from a quick look at the reviews on the Android marketplace, end-users are reporting sluggishness in the app (something we've noted they really care about) and the lack of a native look-and-feel (see screenshot, right).

I don't mean any disrespect to the diary.com team by pointing this out - they've clearly done a great deal of hard work in getting this product out there, and put a lot of effort into working around the limitations of HTML5 as far as they could, but despite this effort these limitations are still noticeable. And it's not just diary.com who seem to have experienced this - the FT, who've blazed a trail with their web apps for iOS, haven't launched a web product on Android yet: which doesn't suggest there's a great cross-platform story here.

How much of the current enthusiasm for HTML5-on-mobile is driven by wishful thinking on the part of the industry? It doesn't seem to offer much to end-users, who are often the ones funding the content with their wallets or eyeballs, and who are increasingly choosing to access mobile content through apps, not the web.

I can't help but think back to all those companies offering "write once, port automatically" solutions for J2ME a few years back. I've yet to see one which demonstrated that it could do the job well beyond a certain, simple class of applications, and I'm starting to feel the same way about HTML5 for mobile. In particular I think the cost of porting is being underestimated (just as it was for J2ME) - web-on-iOS might be performant, but getting it going beyond Apple kit takes time and effort. To be fair to the diary.com team, the reviews I can see on the iTunes App Store are broadly positive - suggesting that on Apple devices HTML5 is a stronger contender, but weakening its case cross-platform.

I really really really want a pony, but that doesn't make it right for me to saddle up Mr Falletti and ride him around the office. And the fact that we want or need an easy way to do cross-platform apps doesn't mean the web will give us one. I'm leaning towards the same view I had with J2ME: you'll need a mix of techniques, tools and experience to do this well, you can't avoid dealing with the underlying platforms, and silver bullets are in short supply.

Thanks to James Hugman for his contributions to this post.

Our Guardian Anywhere product has been in the Android Marketplace for nearly a couple of years now, and every so often I run through the feedback. It tends to be positive: the 1,116 ratings we've had from the 64,300 downloads to date have averaged at 4.5 stars out of 5; but we've also had a few hundred reviews of the product written, and I wanted to see what might be lurking in these.

The Android Marketplace doesn't let you programmatically download reviews, but there's an excellent unofficial project which you can use to grab them. An hour or so playing with that gave me a nice dump of reviews which I could throw into a Google spreadsheet.

Once there, I started to look through them to find patterns. Where a review mentioned something specific which we could address or add as a feature, I recorded it, leaving me with this list:

• Fatal error
• Speed of downloading content
• Reliability of downloading content
• Tablet version
• Missing stories or sections of content
• Improved sharing facilities
• Use of storage, or desire to install to SD card
• User interface issues (often fonts)
• Battery life worries
• Old content
• Videos, podcasts or multimedia
• Changing intervals between downloads
• Crossword

I matched this list against all reviews, and against those from the last 6 months (we've made quite a few amendments and improvements to the product over the last couple of years, so really old feedback may already have been addressed). The top 5 items from the last 6 months are:

1. Download speed (23% of coded comments)
2. Use of storage (23%)
3. Fatal error (15%)
4. Download reliability (15%)
5. Improve sharing (8%)

...and from the lifetime of the product:

1. Download reliability (31%)
2. Download speed (25%)
3. User interface (12%)
4. Use of storage (10%)
5. Fatal error (9%)

What have I concluded from this?

1. In terms of what users most readily ask for, speed and reliability are more important than additional features;
2. We successfully addressed many of the UI concerns in early version of the product (only one review in the last 6 months mentioned the interface);
3. Android app downloaders are particularly concerned with how their on-device storage is used;
4. Multimedia, crosswords or other advanced features were surprisingly rare requests;

I've also been going through the analytics we have installed in the product; not in detail yet, but I can see that in the last month we had 828k page-views of articles, and just shy of 55k views of a photo in the last month. On average users are spending 6 minutes on each article, which feels high.

The Guardian Anywhere has a couple of alternative means of navigating stories: "Picks", which is an automagically generated set of personalised articles, based on your reading habits; and the "Tag Cloud", a list of all tags from current articles, sized according to their popularity. Picks is generally more popular, with 23k visits last month compared to 7k for the Tag Cloud. My gut feeling is that we should drop the tag clouds and do a little more with Picks - perhaps highlighting when it's activated and encouraging users to go there.

And from the Android market stats, I can see that our users are slightly more likely to have recent versions of Android (87.6% have Android 2.0 or above compared to 80.6% of average users of news apps) and are, as you'd expect, UK-biased (72.7% in the UK compared to 4.9% of most news app users).

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...