Many companies are converting their iOS apps to Android nowadays. However, simple one-to-one conversion of the UI might cause problems to the potential users.
I don't believe that inter-platform consistency between an app's different versions is as important than consistency between apps on a single platform. Not many users use multiple different phones at the same time. This post describes five simple rules how an iOS app can be made to fit into the growing Android app crowd.
1. Use top tabs
Google recommends that tabs in Android apps placed on top part of the UI instead of the very bottom.
There's a very good reason for that recommendation. Take a look at the following pictures.Both of them features app called runtastic. Their Android port keeps the UI virtually unchanged and causes problems to big portion of Android users. Many Android phones have the 4 (or some 3) required Android buttons right on the screens bottom edge. Having your app's navigation immediately adjacent to the buttons will inevitably cause users to tap the navigation buttons from time to time.
Foursquare port does a good work moving the navigation tabs to higher and avoiding the same problems as runtastic has.
 |
| a slide from Roman Nurik's GDD 2010 presentation |
There's a very good reason for that recommendation. Take a look at the following pictures.Both of them features app called runtastic. Their Android port keeps the UI virtually unchanged and causes problems to big portion of Android users. Many Android phones have the 4 (or some 3) required Android buttons right on the screens bottom edge. Having your app's navigation immediately adjacent to the buttons will inevitably cause users to tap the navigation buttons from time to time.
Foursquare port does a good work moving the navigation tabs to higher and avoiding the same problems as runtastic has.
On the left: iOS version. On the right: Android version.
2. No back button in UI
All Android devices are required to have a back button and user's have used in using it. There's no need to add a back button to the UI.
Don't do this:
 |
| A bit embarrassingly this example is from Android Central (an awesome source for Android news) app. |
3. Use Android platform icons
Android platform provides icons for most common actions. One of them is share. Allrecepies uses an iOS icon (top right corner). There's a well established "share" icon for Android seen for example in the default gallery app. It is freely available to use in every app.
On the left: Wrong. On the right: Correct.
4. Use Android's intent APIs
One of the most powerful features of Android platform is the intent API. It allows apps to extend other apps' functionality by offering access to their features. Probably the most common way of doing this is the share function on various apps. An app can chose to share text, URL, image etc. Other apps can then register to listen to intents that they can handle.
Apps should not implement their own interface for sharing through Facebook, twitter etc. If the app just let's the Android handle the share intent user can use their twitter etc app of choice. This way is much more convenient to users.
On the left: Wrong. On the right: Correct.
5. Consider using Action Bar
Action bar has become a single most easily identifiable feature in Android apps. Using it will instantly brand the app as an Android app. Users are used to the concept and it can improve app's usability. However, as always UI components should only be used if it makes sense.
 |
| Evernote uses Action Bar pattern successfully |
Conclusion
Simple one-to-one conversion from iOS design is usually not enough to create good user experience. However, the changed required might not require too huge amount of effort and will be rewarded byt much better user satisfaction.
Good post and very nice recomendantions. I only disgree with the third topic. I think by using the same icons and symbol we limited the creativity to design new interfaces.
ReplyDeleteHey cafeinterativo,
ReplyDeleteThank you for your comment. I see your point but I think you can still be creative but use consistent symbols to describe functions that spread across the the whole platform. I think I feel strongest about the "share". But you're right that creative freedom is important and exceptions to the norm should, of course, be allowed but they should be very carefully considered first.
Disagree on tabs on top.
ReplyDeletePhones are getting larger. Take for example HTC DesireHD (non-hardware buttons at bottom, right under the screen).
The screen is so large I can't reach the top-left of the screen with the thumb of the hand that's holding the phone.
(some phone are smaller but at the same time people with smaller hands than mine do exist as well)
So it would be better to have tabs at bottom than on top in many cases.
Keep up the good work.
@Stefano Correct. But that's just for large screen models. Finding a compromise would not be easy.
ReplyDeleteGreat tips. Others may include making use of the long-press vs swipe-to-edit. Considering the effect of true-multitasking (not iOS 4 style) with regards to resuming application state as this has a big impact on some apps. Re-architecting user journeys to avoid the pervasive UINavigationController pattern (and deciding whether to use ActivityGroup). Avoiding rounded-corner table layouts, even though this can look great, it speaks more to iOS, Android tends to have views flush with the screen edges from what I have observed so far.
ReplyDelete@Stefano I think you have a very valid point there but still I see more devices that are affected with the possible button mispresses than large screens. I wonder if it would be a good idea to define a different layout for a larger screen phones?
ReplyDeleteThere might be some ways to reach a middle ground. For example the foursquare app doesn't move the tabs all the way to the top (although they're basically just wasting the top bar space... but that is another topic).
@Richard Thanks for a great comment! Those are definitely points worth noting when doing a conversion.
ReplyDeleteAs android user I hate when someone ports iPhone UI as is.
ReplyDeleteI have 2 more ideas.
Designers shouldn't use arrows on the right of ListView items, it looks as in iPhone.
Quick actions should appear under the selected item, but not as in current version of Twitter.
@vmakeev Thanks for the ideas, I agree. I actually wrote about the quick actions in twitter few days ago. I think it is disaster.
ReplyDeleteHi, i'm a follower of your blog and my question may seem dumb, but how do you take a screenshot of an android phone running app and how can you record a video.
ReplyDeleteThanks in advance,
Hey Zuka,
ReplyDeleteIf you don't have a rooted phone you need to connect your phone to a computer with the Android SDK. The SDK has a tool for taking screenshots.
Video is not currently possible.
Check your use of apostrophes!
ReplyDeleteThanks for your comment. It would be more helpful if you would point out some mistakes I made so I could fix them and learn from the mistakes. As a non-native English speaker apostrophes are very difficult to get right. My native language doesn't use them at all.
ReplyDeleteIf the bottom tab bar creating issues, then there shouldnt be any UI controls on screen bottom.Is that the case with default apps like dialer, contacts etc?
ReplyDeleteStop talking BS.
Matt, you bring out an interesting point (although "stop talking BS" isn't the best conversation starter). I think, however, that there's a difference between apps whose users use navigation a lot and the phone dialer where the navigation is actually pretty insignificant part of the app. I think Google has done bottom tabs in the dialer exactly for the same reason I explained in my post. Placing for example "dial" button at the bottom would be a disaster.
ReplyDeleteI decided to include the top tabs argument in my post based on Google Android dev advocate presentations and based on anecdotal evidence. There's certainly much room for discussion.
Mobile devices have a hot area i.e. the bottom left hand corner (when the user is right handed) and this space should be used for the most frequently selected options. The least used buttons should be on the bottom right. The iOS twitter app does this well with delete on the bottom right and tools to post tweets on the left.
ReplyDeleteDesigners may consider including a setting to adjust the navigation for left handers but this may require the user to undertake an additional cognitive load to compensate for the change.
A mobile experience should be the opposite of a desktop experience i.e. content up top and navigation on the bottom.
I understand the concern people raise about users accidently hitting physical hardware buttons by mistake but I don't think it is a valid concern. Users are more coordinated then designers believe.
@Adam Lewkovitz
DeleteI hadn't considered that, but I wonder if it's actually counter intuitive. I'm right handed, but mostly use my phone in my left hand. And I think that's what I have seen most right handed people do. How about you? Even if it's the other way around, I wonder if that might actually make it a worse choice for people using the phone with their left hand.
Hey Adam,
ReplyDeleteThank you for your comment! I think tabs deserve a proper discussion. I think you have a solid point and good argument here. I'll write another post soon about this I just want to dig in deeper to it first.
"A mobile experience should be the opposite of a desktop experience i.e. content up top and navigation on the bottom."
ReplyDeleteNo, a mobile experience should be consistent across apps on the platform. Android, via patterns like the action bar, tends to use top-navigation more than does iOS. You are welcome to question whether Google is promoting the proper navigation position. However, SDK app developers will be better served maintaining fidelity with the platform and other apps, so that users have a consistent UX.
Thank you all for your notes. I created another post about the top / bottom tabs issue: http://www.androiduipatterns.com/2011/07/tabs-top-or-bottom.html
ReplyDeleteGreat article and great comments. Subscribe.
ReplyDeleteReally a good article. Thank you
ReplyDeleteThe problem with the buttons and the tabs at the bottom has two root causes: First the need for buttons on an otherwise all-touchscreen device, second capacitive buttons.
ReplyDeleteThe first one may be an heritage from the early Android prototypes that looked like Blackberrys. Why buttons at all when there is enough screen estate to show everything on screen? Seems like Google agrees as with Honeycomb there is no need anymore for buttons on devices (will certainly be the same for phones with the unified v4) and the button (action) bar is ... at the bottom of the screen. Certainly it is not a good idea to add tabs directly above this bar.
Most casual users don't find actions that are "hidden" behind a menu button. If you want an action available not only to power users, give it a dedicated button or at least an on-screen menu button (like "Actions"). No need to deal with users that miss functionality (and downrate your app) just because they can't find it.
Capacitive buttons are just a bad idea at all, combining the bad of virtual buttons on display (no haptic feedback, no resistance) with the bad of physical buttons (not context sensitive, can't be removed). The Android buttons add as extra annoyance that some functionality can't be disabled. So when you are playing a game and accidentially touch such button everything may be gone. It is much better when you have a device where the buttons are actually physical buttons (like the first Samsung Galaxys, i7500 & i5700). Sadly this obviously doesn't fit with the marketing departement (and physical buttons are a little bit more expensive). Luckily Google is de facto removing these buttons. (And glancing at the competitior they want to remove the only button at their device, which is a good idea imho.)
One can feel that Android's UI was designed by engineers and is still evolving, an iterative approach. But there is only one chance to make a first impression.
his,
ReplyDeleteThank you for your very well thought out comment. I very definitely agree with you.
I think, as you said, that ICS will no longer require physical buttons. Some manufacturers will probably keep using them anyways but I hope that majority will abandon them. A physical menu button that sometimes is enabled and sometimes doesn't' do anything clearly doesn't make sense.
@his
ReplyDeleteBeeing positive about migrating to software buttons you missed few cases:
- hardware button for camera trigger
- volume rocker
- orientation-lock button
2nd and 3rd are rather an addition but imagine when you want to take a picture but you dont clearly see the screen (akward angle, sunlight), how would you then hit software button that triggers shot?
@Adam: "I understand the concern people raise about users accidently hitting physical hardware buttons by mistake but I don't think it is a valid concern. Users are more coordinated then designers believe."
ReplyDeleteI disaggre/disgrre/disagreee; some of us are not more coordinated. For example, one of my biggest complaints about the Droid design is that with the keyboard extended it is very hard to hold the phone without hitting the "back" hardware key with your thumb.
Thank you very much for this wonderful article.
ReplyDeleteThank you. Very helpful guidelines and having used both platforms I totally agree. Intents remain an extremely powerful facility that iOS is sorely missing.
ReplyDeleteThanks for article. Actually, I considered how to make a good app for elderly person. The first thing I confused is, the elderly person can use back button/menu button as well? I predicted they always focus on the screen. Therefore, is it better to design back button/menu tab on the screen, which more like as iOS designed?
ReplyDeleteHi Fishman,
ReplyDeleteI believe that back button on screen san be unnecessary even in that case. If they use Android as their daily device I would imagine that they would be able to handle the back button too. An on-screen back button might even be more confusing to them. But I think you should definitely do a user test with your target user group. Give them your app and see how they perform tasks. If it becomes clear that they have problems with phone back buttons you should add an on-screen one and try if it helps.
Thanks your advice. Human Computer Interface is really artistic for me!
ReplyDeleteAge old problem, just on a new class of device.
ReplyDeletePC apps ported straight across to a Mac or Linux that then look/act like you are still on a PC rather than the new OS are a frequent occurrence, although less so as time passes.
I'm sure the same will be true on phones as well.
I guess you need to decide if you want an imperfect port, or nothing at all.
The nothing at all route frequently happens in the PC to Mac/Linux space, so I would think that something is better than nothing.
Hey Paul,
DeleteYeah nothing new...
I'm not sure if "imperfect port, or nothing at all" applies here though. In most cases building the Android app right is actually a lot less work than trying to make it behave like iOS app. Sharing, for example, takes exactly 2 lines of code to get it right while the tight integration can take hundreds and need hours of QA.
Excellent guidelines which i was unidentified about transformation from ios to android operating system.We like to try on that.
ReplyDelete