Articles Tagged ‘Android’

So, you want an app?

Earlier this year, I was lucky enough to meet Josh Clark at FOWD. I’d been reading his articles about flagship apps and content first, and I was very keen to have a chat with him about a discussion I’d had with a client. I had been discussing which platform they should be targeting, and depending upon who I was talking to at the client (and their opinions on the goals of the project) the decision on a choice of platform was different.

Josh, and his mobile vs native talk, positioned this decision as an “audience/content/budget” question, which matched the conversations I’d been having with my client. At the end of his talk I said to Josh, “this would make a great flow-chart, like that one that Jessica Hische did!”, “Yeah, that’d be awesome!”, said Josh.

I’m very pleased to say, that after some delay, it’s ready for public consumption.

So, you want an app?

With a lot of help from my company and colleagues Ed Hartwell-Goose,  Fin Edridge and Simon Dring we made an interactive flow-chart to guide our clients, other industry professionals and their clients through the minefield that is choosing the platform for your app. We called it, “So, you want an app?”.

It’s still a simplification of the whole process but, in researching it, three things became abundantly clear:

  1. You must know your audience – there are no exceptions to this. People use different phones for very different things. Blackberries are used by teenagers for BBM and by corporations because of it’s security and low data usage; iPhones are very high-end consumer devices; and Android phones are thought of as being for very technically minded people, but they’re also entry-level smart phones. Picking a platform without knowing what your content and its audience is a recipe for disaster.
  2. Your content needs to be simple to access – all end-points on the flow-chart will need some form of content platform behind them to drive engagement, re-use and to keep the app up-to-date. If you’ve got an old CMS, you may have to build a light-weight web service to let your app access the content easily, quickly and efficiently. People use apps to get at content, and whether they’re a game or social media, your content is king.
  3. You cannot do this half-heartedly – and by that I mean you’ve got to have a decent budget. Also at FOWD, Matt Gifford was joking that the £50 website was now a £75 website; apps are suffering this problem. Apps are viewed as small, simple bits of functionality that you can knock-up in a weekend; this is simply not true. Apps are often full-sized websites with the added complexity of fitting the core content onto a tiny screen, but since they look small clients think they’re easy to make and do, and are therefore cheap. Stories in the news of 14-year-olds making games in the app store top 10 aren’t helping either. Start with a 5-figure sum, and keep going upwards if you want your app to really succeed.

I also mention PhoneGap a lot in the flow-chart, and that’d because I genuinely believe it’s a great solution to the “discoverability” problem. This is where you have a mobile web site that isn’t getting enough exposure as people think of “apps” as items in the “app store”. PhoneGap fills this hole nicely, and gives you access to device hardware as a brilliant bonus. The tools are easy to use and PhoneGap Build now takes all of the hard bits of building for Blackberry and Windows Phone away.

Still, there are gray areas in the platform selection process, especially when it comes to tight budgets and enterprise apps. If there’s only one thing you take away from this tool it should be this: Content is King, know your audience and how they will use your app. The rest flows from there.

You can find the tool here: www.paconsulting.com/so-you-want-an-app – I’ll post the full poster version here when it’s completed.

Please, let me know what you think, and let me know if you use it for a client as well, share your stories and share the tool with your friends.

 

Droid Doesn’t do tablets

No Android on tablets As a developer and iPhone fan, nothing pleases me more to say that Android has caught up with the iPhone. Android hardware has been great for a while, the Motorola Droid and Nexus One being the first in a wave of great devices, but the software hadn’t been right. Android took its sweet time to develop but finally has all the great features iPhone users have enjoyed since the iPhone 3G and more (wi-fi hotspots for example).

Thing is, the iPhone, and iOS, has moved on.

Since the launch of the iPad, every Android-lover has been waiting for a tablet with Android on it. They want the brilliance and openness of Android on a more useful (day-to-day) form factor. To those people, I say wait, it’s not ready yet. In order to put iOS on a tablet, Apple had to fork the code base into two versions, iPhone 3.1 (later 4.0) and iPad 3.2. To date (though that may change at the September 1st event), these two branches have not converged, nearly 9 months later. Apple did this for a very good reason: the native controllers and views are not suitable for tablet devices and new paradigms needed to be created.

The SplitView Navigation controller

The SplitView Navigation controller, necessary for much of the good UI interaction on the iPad. Courtesy of Apple

Android tablets, on the other hand, are content with throwing the same old mobile-centric code at tablets. For example, today Archos unveiled five new Android 2.2 devices from 2.8″ to 10.1″ and Samsung is about to unveil their Galaxy tablet which is a 7″ Froyo device.

So, why isn’t this a good idea. For one, the Android developer API says it doesn’t support screens larger than 4.3″. That should be a pretty good first clue. Take the iPad HCI guidelines for a second clue. It states that full screen transitions are bad, interfaces have to be tailored to the device, and you have to do more than just blow up the interface to twice the size. Take a look at how iPhone apps look on the iPad for that one.

iPhone app on an iPad

iPhone app on an iPad, now think of an Android app, just blown up.

Truthfully, the current Android SDK just can’t cope with the demands of a tablet UI. Little things like smooth transitions when rotating to big things like having universal apps which cover multiple screen sizes well. Android has support for multiple screen sizes, but it relies on relative positioning for this and is an inelegant solution compared with Apple’s interface builder.

A bigger screen will accentuate the differences in the quality of iOS and Android apps. If you have a mediocre Android app and put it on a tablet, it’s going to look poor, but put a mediocre iPhone app on the iPad, and it’s at least usable. Take a look at this video of a $50 Android tablet from India Do you want a UI like that on your tablet? Didn’t think so.

So, my advice, is wait. Wait until Android 3.0 (Gingerbread) comes out in Q4 this year, then wait until 2011 for some good hardware. 3.0 has set precedent by disallowing vendor customisation, forcing a much-more Apple-esque standard set of controllers which will suit more purposes. Acer and Motorola have already announced that they’re delaying the launch of their Android tablets until 3.0 is available.

Still, when that time comes around, the second generation iPad will be out, and then Android will be playing catch up again.

Update: Just seen the ViewSonic ViewPad 7, a 7″ Froyo tablet. Take a look at the video in the link: it’s full-screen all the way, sluggish and, I quote “a plastic rebadge me-too Android tablet”. When you’re watching the video, think about how that’s going to work on a tablet the size of an iPad (or the Archos 101 for that matter). It’s not going to be pretty.