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.