App Equality

When developing apps across mobile platforms, there should be no devices left with a poorer UX.

Article No :650 | April 5, 2011 | by Steve Workman

In the early years of Apple's surge in the market, the App Store was the only game in town, and developers came to the platform in the thousands. Since early 2010, around the release of the Google Nexus One, the Android platform has been a competitive option in the smartphone market thanks to improved platform maturity. Initially, the number and variety of apps in the Android Marketplace did not make for a compelling experience, but developers have slowly made their way to the platform, which now has over 250,000 apps available.[*] Many apps on the Android Marketplace are reproductions of iPhone apps, and there are more and more apps making the jump to the platform. The App Store's days of total market dominance are numbered, but this can cause problems: when an app is pushed from platform to platform, the experience can take a few knocks on its way over. This article will show the differences in apps for multiple platforms, and explore ways to create a consistent user experience in mobile apps.

Platform Differences

Take, for example, the Facebook app for both iPhone and Android. They claim to have identical functionality, but depending on your device and operating system version, the app can have major differences. On Android 2.2, the home screen only shows the news feed, friends, photos, inbox, profile, and notifications; on the iPhone, it shows all of those as well as places, groups, events, chat, and notes on a second screen, with the option to customise it. The Android 2.3 version is closer to the iPhone experience, yet uses different icons for notifications, and labels messages as the "inbox." These differences may not seem so big on the latest hardware, but over 60% of all Android users are still using version 2.2[*] and the iPhone version of Facebook has had all of the functionality since version 3.0 in 2009.

When developing apps across mobile platforms, there should be no devices left with a poorer user experience. The Android platform is rapidly eating into the iPhone's market share, and this will continue as devices become cheaper. What this means for developers is that Android may become the primary focus of many mobile development houses. Nokia's support for Windows Phone 7 may help it gain significant market share, but it is unlikely to be many developers' first choice platform for apps.[*] There are, of course, other platforms: RIM's BlackBerry, HP's WebOS and MeeGo, as well as the feature-phone operating system Symbian. These platforms should not be dismissed and if a product wants maximum reach, it should have an app for all of these platforms.

There's really no reason why experiences should be different across any of the platforms. Each is now mature enough to meet the needs of the user, and developers now have well-tested tools to create these apps. Every platform can list items in a table, but the Kindle app for Android has a different, more beautiful look-and-feel because of its use of the iconic Kindle image in the table's background. Transitions are smoother than on the iPhone and icons for books are larger and more legible.

Kindle on Android 2.3 (left) and iPhone 4.3 (right)

Apps do not have to look exactly the same across all platforms. For example, Foursquare for Android has tabs at the top of the screen, rather than at the bottom as on the iPhone. This is taking cues from the native experience and building upon learned patterns to produce a natural user experience for users of that platform.

Levelling the Playing Field

As a developer, I can see two ways to create a consistent user experience across mobile apps:

Invest more time and effort into matching functionality and experience for the different platforms. This may involve redesigning some screens to fit with the platform's styles and unique features and to bring them to life.

Develop the app as a web app. The Web is a great leveller on mobile devices; all major platforms (apart from Windows Phone 7) come preinstalled with browsers based on WebKit. They all support the latest HTML5 features such as app caching and local storage for creating web apps that work completely offline, and are beginning to make use of hardware acceleration for transitions, canvas, and SVG graphics. All of the latest mobile browsers now have basic support for touch events so gesture-based experiences can be created.

Web apps also have a discoverability problem, as they are not available through native app stores for the different platforms. This is a key part of the customer experience of an app; having to download an app from somewhere other than an app store is not consistent with expectations for apps. But there are ways around this; PhoneGap, for example, is a web app packaging solution for native apps, but it doesn't support all major devices at the moment. The W3C is working on a widget packaging specification, which creates downloadable archives of web applications that can run offline. RIM have implemented this in their WebWorks platform and Opera in their browser extensions platform, though it is clearly not ready for large-scale use as Mozilla and Google have both implemented different specifications for their browser extension stores.

For app equality, HTML5 and the mobile web are a great step forward. As technology develops, and feature-enabling standards are ratified , true user experience equality between native apps and the Web can be attained. After that, for a great experience, the choice is mobile web.

My thanks go to Emily Farley and Emily Toop, whose phones appear in the images used in this article.

About the Author(s)

Steve Workman is a Consultant at PA Consulting Group in London. He started designing and building web sites in 2003, and he's been trying to make the Web a better place ever since. Steve is an organiser of the London Web Standards group, setting up educational events for like-minded people in the London area. You can follow him on Twitter @steveworkman.

Comments

June 1, 2011

- AIR for iOS now available: http://www.adobe.com/products/flash-builder.html

- To me the question of should apps match platform UI conventions or not has two legitimate answers:

Navigation conventions must obviously match (hardware vs. onscreen back button, onscreen controls placement etc). But as for the sheer look of the widgets, it is my opinion that you as a developer may choose which approach suits you best.

Let's take for granted that android users don't want the iOS look and vice versa. That leaves you with two options; either you closely match the UI guidelines of the respective platform (both AIR and web apps offer platform-specific css), or you develop your own unique visual style. The latter approach is what users already know from web sites and web apps today.

Both approaches are valid, and it really depends on your brand and your target group. If you ask me you don't need a super-consistent UI at all on platforms other than Apple's. Windows and Linux users are used to skinning, and Android comes in different visual flavors like HTC sense and so on. It's only Apple who think their UI is so super cool that they retain their exact same UI even in the Windows versions of iTunes, Quicktime Player and Safari.

Anyway, the difference between users of different platforms is soooo much smaller than the one between users from different cultures, I can tell you as a European guy. It would be both ethically and financially more attractive to take that into accout, but I fear this would take another blog post...

I'm in agreement Sean C above, that the opposite argument makes far more sense: The user experience for each platform should be as different from one another as the platforms themselves are different from each other.

Sean C cites the "back button" convention, which is a perfect example. If you create a dialog box with a on-screen back button in it for your iPhone app, and then use that same UI element on your Android version of that app, you're telling your Android user to adapt to a convention they are not used to. And the inverse is impossible, because iPhone doesn't even have a hardware back button. Basically, one *has* to make the app different across platforms in order to make it as easy as possible to use by users of each platform.

But it's not just the interaction design that differs across platforms. The whole visual aesthetic of the apps, and the tastes and cultural/stylistic leanings of the users themselves, is different. Android has a brand aesthetic that is different from Apple's, and their respective audiences expect these user experiences to be consistent with the aesthetic of the platform they have invested in.

One example: The Android version of the Kindle app that you cite. You say "the Kindle app for Android has a different, more beautiful look-and-feel because of its use of the iconic Kindle image in the table's background". I'd argue that the Android version is not "more beautiful" with the background image, but is actually more cluttered, needlessly busy, and IMHO a little corny looking. But it is definitely consistent with most other Android user experiences, where both functional and decorative UI elements tend to fill every empty space around and within whatever you are looking at. This is in contrast with the iPhone version which is simple and straightforward (some would say boring and dry, some might say elegant and focused), which is likewise consistent with Apple iOS design conventions. I am pretty confident that most iPhone users would prefer the background-less version.

As for "feature parity", where all platforms have the same feature set, I'm not sure why that needs to be true. Why should it matter to a user of Platform X whether a user of Platform Y has more or fewer features than they have? It seems like this is the business's prerogative to choose what to build into their various platforms. Is this an ethical question to you?

Thanks for your comments John, hopefully I covered the third with the PhoneGap argument. AIR is a great technology, but not supported by the iPhone, and I doubt it ever will be. The iPhone takes a large proportion of app mind-share in the western world and I'd have reservations about creating an app or website that doesn't work on the iPhone.

A colleague of mine has pointed me to a very recent article by Facebook on their new mobile web site: http://www.facebook.com/note.php?note_id=10150122073713920 developing for the lowest common denominator and writing the same code for multiple different device capabilities. Well worth a read.

"As a developer, I can see two ways to create a consistent user experience across mobile apps:"

There are three:
o write in native-code for each device, with parallel testing, support, and maintenance costs, and distribute via app store;
o write in HTML for each device's browser, with lower testing/support/maintenance costs, and distribute as webpage;
o write in a bridging technology such as Adobe AIR, with even lower testing/support/maintenance costs, and distribute via app store.

(The question about "app equality" is an interesting one... in thinking about equal experiences for diverse audiences, this is similar in ways to questions about accessibility and globalization/localization. Figuring out the true audiences and their eventual needs is often quite tricky. And "Sean C" raises a parallel problem: should the app look the same across devices, or the same as other apps on each device? That's even trickier! ;-)

Thanks for the interesting article, Steve. I agree that no device/OS should be left with a poor(er) user experience, but different OS, and even different versions of the same OS, offer different opportunities that I think designers should know how to leverage, even if it means that e.g. the Android version of the Facebook app ends up being different than the iOS version. Also, unless an Android user also uses an iOS device as his second device or switches from one to the other, differences between apps on the two platforms don't really matter much from a comparison standpoint to the actual user.

Also, I notice one mistake in the text. You state that Symbian is a "feature-phone operating system". That's not true, however. Symbian is very much a smartphone OS. Nokia's Java-based S40 is the operating system that they use in feature phones.

What's happening today is that the applications with the broadest platform support (like facebook & gmail), also have a great mobile web experience. I personally believe that the mobile web should be your first focus & when you have established a great piece of experience on the web, you should move on to native apps.

About using html5 for native apps trough frameworks like phonegap, please read this article:
http://welcome.totheinter.net/2010/08/07/user-experience-vs-user-expectations/
Short recap of this article:
Users have high expectations on native apps, but it also has a good ux.
Users have lower expectations on web apps, so the limited ux of the mobile web is taken for granted and the user is easier satisfied.
But if you package a web app as a native app, the expectation rises, but the ux stays limited. resulting in dissatisfied users.

Since this article was written, Facebook have updated their app for iPhone to version 3.4. This adds some features that aren't present in the Android app, such as the Places map view. However, the label for "Inbox" has now changed to "Messages", matching the latest Android version.

Clearly there is some fragmentation here, but I don't believe they should hold a release back for a platform, as long as the other platforms receive their update quickly.

A number of people have commented that the version of Facebook labeled as 2.2 is quite an old version of the app and it simply needs to be updated. However, the app came pre-installed on an Android 2.2 HTC Desire which was purchased brand new less than a month ago. Since then, there have been no notifications that there is an update available, or that the user has simply not been encouraged to get the new functionality. To the owner of that phone, that's what Facebook is. Perhaps in this rapidly moving app market, developers should consider an update model similar to Google Chrome, where updates are installed in the background, meaning everyone will be up to date and have the same functionality.

With regard to different platforms having different interactions and visual languages, I completely agree. However, very few companies have the funds to build apps that work across all platforms, taking on their features. Mobile web and PhoneGap is a great way to extend the reach of your app without spending a lot of money.

In designed across multiple mobile phone platforms, I have found the opposite to be true. Each platform (iOS, Android, WP7) has its own design ethos and best practices. An iOS app should have a back button in the top right, where as Android has a back button and stands for the design principal of show content not navigation. On the Facebook app, notifications look different because of the differences in visual language on the platforms. As an Android user, I would be disappointed in the developer if I were forced to the interface of an iOS device.

Additionally, the heart of your argument, is based on the Android 2.2 Facebook app being the image on the left. My device is a Droid X, running 2.2, and my Facebook app is the image in the middle. I imagine the image on the left is outdated, or for 1.x devices (~10%).