Thursday 30 August 2012

Tips for Android Tabs

Tabs are one of the most used and also most useful UI components of mobile UIs. They provide quick and easy access to different parts of the app. On Android apps tabs come in many forms. In some cases the tab design is copied from other platforms and in some cases they're using an outdated design of old Android versions. While it is understandable that there are so many different implementations due to the fact that Android design wasn't well defined at the beginning. This situation has now changed and there is a guideline for tabbed UI design.


In this article I wanted to take a look at the current state of tabbed UIs and give some tips how to keep the platform consistent.


Tabs Still Go to the Top

A year ago there still was some discussion whether or not the tabs should be on top or bottom. I think that this discussion is now over. Tabs go to top. There are few reasons for it:

  1. Natural hierarchy of things go from top to bottom. Tabs are headers and higher in information hierarchy than content on a screen.
  2. More complex apps need more than one level of navigation. Having tabs on bottom will cause confusion to users  when it comes to navigation hierarchy.
  3. Users scan a new screen from top to bottom. They will understand your screen hierarchy better when tabs are on top and have a better sense for location.

Recently updated Eurosport app provides us a great example of the points above. Take a look at the screenshots below. The left one is from their old app and the right one is the new one. Navigation hierarchy in the old app was more than just confusing. Firstly, it looked wrong (more about tab style below) but it is also very difficult to understand how the two tab bars relate to each other. In the new version there's no chance place for misunderstanding the structure of the app.



Tab Style

Style of tabs in Android is pretty distinct from other platforms. This design was introduced to the platform first in version 3.0 but even on older OS versions the old tab style is starting to look dated and out of place.

Here's few thoughts about Android tab styling:

  1. Android tabs only rarely have icons. They're most often presented as text. There's a good reason for this. It is difficult to come up with descriptive icons for all the possible navigation option. Text is often much better.
  2. Android tabs aren't square buttons. As they mostly contain text a lot of screen real estate can be saved by squashing them a bit.
  3. Visual style of Android tabs is flat. There should not be any glossy or reflection effects.

See these two examples of Android tab styles. On the left one of the rare occasions where the tabs contain icons. This is the default Android phone app on 4.1. In general I would advice to avoid icons unless you are sure that your icons will portray the function without a doubt.

On the right you can see the Foursquare app that uses text in tabs.


The easiest way to ruin your app's look is to imitate iOS's glossy square tabs. These apps need a UI refresh (Spiegel Online & PC-Welt).


Color choice for tabs on Android is limitless. By no means should all tabs be black background and blue highlight. Your apps brand can be visible in the tab color selection!

Tabs Are for Navigation, not for Actions!

Tabs are meant to be used to navigate between screens in your app. Don't use them to trigger action. For actions use action bar. Here's another unfortunate example of very bad design from the Spiegel Online app. Part of the tabs are actually actions (like sharing) that don't take the user anywhere else in the app. This is confusing and misuse of the tab component.





A Tab Must Always Be Selected

Unfortunately, the Spiegel Online app has done wrong pretty much all that can be wrong with tabs. Not only do they look wrong, are in wrong place and mix navigation and actions they are not activated correctly.

If your app uses tabs one of the tabs must always be selected when the tabs are visible. There can not be a situation where the tabs are shown to the user but use isn't on any of the pages the tabs lead to! When user navigates deeper to the app you should hide the tab bar. A tab bar without a selected tab will make your users feel lost.


Tabs & Back

On Android we always need to be careful with the back stack and function of the back button. Moving between tabs is not considered changing pages. Most apps on the platform do not add tab changes to back stack and neither should you.

There is a good reason why changing tabs does not go to back stack. The users don't feel like they've left the screen when they change between tabs. While there definitely is a possibility for confusion the best guess is to treat screens with tabs as a single screen.

To enforce the feeling that all the tabs are on the same screen you should not use the default animated activity transitions between the tabs (users associate them with moving deeper into the app). The tabs are side by side and any animations used should reflect that. The best animation is sliding animation. This also encourages users to use swipe gestures to move between tabs.


Swipe!

Tabbed UIs are great if navigating between tabs is effortless. While tapping the tabs is OK swiping between them is even better. For swipe gesture users won't have to reach to the top of the UI. Swiping is also more satisfying and natural for us. The page behaves how we intuitively expect. On Android expect this feature. All tabbed UIs should always support swipe gesture!


Scalability

Tabs scale up to tablet UIs very nicely. If you use them in combination with the action bar the APIs even take care of the scaling for you. When there's enough room on the action bar the tabs are moved there to save screen space. The Google I//O app is a great example of that.





Conclusion

Tabs are great if implemented correctly. It is a relatively simple UI component but it is also very easy to get them wrong. Follow the guidelines and your app will look and function great. Your users will instinctively know how to navigate in your app.


(c) This article originally appeared on androiuipattens.com blog by Juhani Lehtimäki. Fully copying without permission is prohibited. 

8 comments:

  1. You wrote: "you should not use animated activity transitions" - I think you need to remove the 'not'.

    Also, there's and error at the second sentence of the 'Scalability' section.

    I really like your blog, thanks for writing it!

    ReplyDelete
    Replies
    1. Hey Ran,

      Thanks. No I mean that the the default animations should not be used. I reworded it a bit to make my point clearer. I fixed the other typo :)

      Delete
  2. "A year ago there still was some discussion whether or not the tabs should be on top or bottom. I think that this discussion is now over. Tabs go to top."

    It depends on the type of application, its design, and the content of the tabs. Avoid generalizations, please.

    I'm the author of an app that is in the top 25 of its category, with 4 text tabs on bottom (nothing looking like iOS tab). I do not get a deluge of emails from confused users because of that. I do not either get angry emails stating they HAVE to be on top.

    Swiping for navigation can be a nice addition, but with the advantage of making swiping unusuable for anything else in the content area.

    ReplyDelete
    Replies
    1. Hey,
      I'd love to look at the app more closely and can't really comment directly about your case. However, I maintain my point. I believe that even in your app's case the UI would be better with tabs on top. Platform consistency is important and should be the default position. As with everything with a good reasons guidelines and conventions can be broken.

      Not getting angry emails from users is no evidence of good UI. Users are not designers. They won't give you feedback about that. What you could do is to run usability testing comparing two solutions.

      To me it is more important to start to get consistency to the Android platform and I rather put in a strong recommendation than a thin comment in issues that can have strong implications for the whole platform. Tab location is a very prominent issue in UIs and I'd like to see it unified and only broken when absolutely have to (although I can't think any situation where that would be a must).

      Delete
  3. Great tips, I've had problems lately creating tabs for Android but will try this.

    ReplyDelete
  4. Good article - thanks for sharing! Rounds out the advice for tabs I've picked up elsewhere. While I agree that platform consistency is important, I could be persuaded that certain apps are better served with tabs at the bottom. Some designs just work despite bucking the trends and guidelines, and I fear the day where everyone follows all the guidelines to the letter. Where's the fun in that? :-)

    ReplyDelete
  5. on the second line you wrote:
    "They provide quick and easy access to different parts of the app."
    Later, on Tabs&Back you're saying:
    "...the best guess is to treat screens with tabs as a single screen."

    I am confusing, how should I treat "different parts of the app" as "single screen"?

    ReplyDelete
  6. where is the code ? less talk, more code.

    ReplyDelete