Differences between Android and iOS UI conventions

Android phones and iPhones are selling like crazy. Smartphone market has more than doubled in one year because of these two sky rocketing platforms.

iOS got a head start of few years before Android matured enough to catch up and eventually fly past in market share and sold devices. In that time the iOS app market grew to unrivaled numbers. Most companies still write their apps first for iOS and then later convert them to Android. I wrote a post titled 5 tips for converting iOS UI to Android some time ago but I think this subject deserves another look.

In this post I'll point out some differences between user expectations on iOS and Android. I also want to show an example good and bad iOS to Android app conversion.


Platform UI convention differences

I recently looked into using PhoneGap to build a cross platform app. PhoneGap allows developers to encapsulate their web apps to native application package to many different platforms. The app is built once and the packaged and distributed to Android, iOS and others. 

In my opinion this is inherently bad idea. Users expect applications to work on certain way on their platform of choice. I made this small table highlighting some of the differences. There are many more.

User action		*
Device Shake	N/A	Undo / Redo
Swipe in table view (=iOS list view)	N/A	Reveal table item delete button
Touch and hold on list view	Quick actions menu appears	N/A
Touch and hold on editable text	Pop-up menu with copy-paste options	to display a magnified view for cursor positioning
Scrolling scrollable area beyond limits	Borders highlight	Bounce effect

(* iOS Human Interface Guidelines)




Example, excellent port, Evernote
I've used Evernote as example in this blog many times. Their app versions are exceptional on many platforms, not just Android and iOS. It is worth checking out their Android and iPhone versions.

Everything from navigation structure, UI style and patters to OS integration are build from ground up in both versions. The app looks and feels right on Android and iOS.


Example, failed port, ZombieBooth
ZombieBooth is technically impressive app. Its face recognition algorithm works pretty much perfectly. It also has reasonable entertainment value :)

Unfortunately the user interface has not been implemented according to Android standards.


Problem - non-responsive UI
This is not really as much a problem related to porting but a general problem of the UI. This app has two types of non-responsiveness in the UI. Firstly when the app launches it takes seconds before the landing screen loads. This implies that the app does something in the UI thread that is shouldn't.

Second problem that makes the UI non-responsive is that when the app is generating a zombie it shows a blocking progress dialog that cannot be dismissed. Pressing back should always cancel a long running operation!

Problem - no context menu
The app plays sound effects when displaying the generated zombie. Only way to turn the sound off is to press volume down which will turn down your generic media volume setting down. I'd expect the app to have a control for turning off the effects using Android menu button but the app doesn't respond to the menu button at all.

Problem - activity stack and on screen back button
The app uses on screen back buttons. Usually using on screen back button isn't a big problem as long as the physical back button behaves as expected. In this case the app fails to do so. Pressing physical back button on most screens exits the app instead of returning to the previous page.

Problem - strange sharing implementation

I recently wrote a post about how using Android intents extends app functionality if done correctly. This app implements sharing in a strange way. Taping the share button brings up this strange menu with three options. "Email photo", "Save photo" or "Cancel". This menu implies that the app developers tried to implement identical functionality on this app version as on the iOS version. This kind of menu is not needed for Android. Firstly, on Android we don't just email photos but also share them to twitter, Facebook, etc. Secondly, a cancel button is not required as back button functions as a cancel in all cases.

After selecting "Email photo"  the app shows a popup telling that it has saved the image file on sdcard. User doesn't need to know this information. It is more likely just going to confuse the users. User also needs to press "OK" before the actual Android image sharing dialog is shown.

Problem - hiding status bar
The app hides Android status bar when launched. This should never be done unless there's a very good reason to do so.

Conclusion
It is great to see companies finally stepping over to the Android Market. It would be even greater if the companies would study and use the platform before jumping into porting the apps.
At least in the company I work in most of the designers use iPhones as their personal or company phones. Before you start an Android project make sure to get the designers exposure to Android platform. Otherwise you'll end up with an Android app that looks and behaves like an iOS app.