Android tips and tricks: swipey tabs
Continuing the series on the more interesting UI pieces of the new Android Market client, today i want to talk about swipey tabs – the name that we use for the top-level browsing container for each media vertical:
Aligning the device clients with the web version of Android Market, we wanted to expose additional lists (such as “Top new paid” and “Top grossing”, for example). The approach we took with the Honeycomb tablet client did not scale well. There, the landing page for the specific media vertical (apps, books, movies) is a sectioned list, each section displaying the name of the list and a few top entries in that list. While this gives a quick overview of the available sections, our usability studies have shown that we needed to rethink this approach.
As a landing page, swipey tabs combine content of different types – top-level categories, featured listing with variable-size cells and multi-column grids for each listing. To switch between the tabs, simply swipe left or right. The screenshot above shows the “Top grossing” list in three different locations, and it’s about time to take a closer look at the pixels:
- No matter how long the tab titles are, the fronted one is centered, the left one is aligned to the left edge and the right one is aligned to the right edge. This may come at the expense of uneven white space around the fronted tab as can be seen in the bottom row.
- A certain minimum distance between two adjacent titles is preserved. This may push the side titles beyond the edges. Take a look at the side titles in the top row and the right title in the middle row. For most titles this shows enough of the text to hint at the content of the adjacent tabs – while preserving the designed gap between the titles.
- Translucent fading close to the edges hints at additional content. This is combined with clickability of each title – which was the main feedback from internal usability studies. The swipability is not an inherently discoverable interaction model, and practically all participants expected to be able to click on a tab to select it.
- The fronted tab uses the same foreground color as the tab underline. This creates an additional, yet not very distracting, connection between the content and the tab title.
- The fronted tab title takes at most 60% of the full width. This allows scaling the component down to various screen sizes without depending on any particular hard-coded pixel size.
- Only the fronted title is ellipsized. This is particularly useful when the long title is on the left (look at the bottom row in the screenshot above) – continuing to ellipsize that text would be very unhelpful as we would display a couple of characters and then the ellipsis.
- As each tab title is a TextView, we get the ellipsing “for free” by specifying the correct layout bounds and letting the framework code figure out the rest. This also gives us an option to mark it to marquee if we decide that it’s better for usability. Finally, having tab titles as TextViews allows full support for accessibility (focus / press highlights, clicks, navigation via d-pad / nav ball).
- When the tab is fronted (keeping it at most 60% of the available width).
- When the tab is on the left of the fronted. It is aligned to the left edge unless it’s too long and gets too close to the left edge of the fronted tab. In this case this position is offset to maintain the minimum gap between the titles, effectively cutting off leading characters.
- When the tab is on the right of the fronted. It is aligned to the right edge unless it’s too long and gets too close to the right edge of the fronted tab. In this case this position is offset to maintain the minimum gap between the titles, effectively cutting off trailing characters.
- Other (centered) – when the tab title is not showing at all. In this case the title span is horizontally centered above the tab content, with full width.
- Tab is in the dead center – just use the fronted interval
- Tab is moving from center to left – interpolate between fronted and left
- Tab is moving from left away from the screen – interpolate between left and centered
- Tab is moving from center to right – interpolate between fronted and right
- Tab is moving from right away from the screen – interpolate between right and centered
Note that when tab is moving from center to either left or right, we’re effectively also interpolating the tab title width. Extra long titles get ellipsized when displayed in the center; but they do display all characters on the sides (so that the left tab can display the trailing characters for better discoverability). So, if we have a long tab title on the left and we swipe it to become centered, it gets gradually less width as it gets closer to the center.
In addition to determining the position of the title, we also interpolate the foreground color and the underline alpha. Note how the “Top free” title in the screenshot above fades from olive green to light gray as it is moving away from the center; in addition, the thick underline below it starts fading out as well. As the “Top grossing” title gets closer to its final location, it does the fade from light gray to olive green to indicate that it will become the selected tab. In fact, we missed the matching fade-in of the underline which should look like this in the next version of the Market client:
The algorithm described above has an interesting side effect during the swipe – different titles move at different velocity. There are four titles involved in each swipe – the one that disappears from the screen, the one that moves from the center to edge, the one that moves from the edge to center and the one that appears on the screen towards the edge. The first and the last move much quicker since they have more distance to “cover”. The middle two move slower, conveying the tab selection change and highlighting the importance of these two tabs (among the four).
Stay tuned for more.
