This post is part of a series on mobile user interface design patterns, excerpted from Designing the Mobile User Experience, John Wiley & Sons, 2007. This second set of patterns will address screen design for mobile applications.
Tabs are a common mechanism used to arrange more controls than can fit on a single page. Common desktop examples include Windows preferences dialog boxes and Apple.com or Amazon.com web sites.
Design
No changes from desktop tab navigation: what works on the desktop works on mobile, if on appropriate devices.Restrict the number of tabs to that which will fit in one row on the screen.
Applicable Devices and Platforms
Stylus devices.Tabs are also acceptable when all of the following apply:
- a scroll and select device
- with 4 way navigation (including left and right)
- a platform with access to left and right controls
- a platform that allows vertical scrolling to go line-to-line and not just control-to-control
- a platform with focus control
- initial focus is placed below the tabs
None of the major browsers support all of the above. MIDP 1 doesn't support it. MIDP 2 can, but will have to be designed very carefully and tested on all devices.
When Used
Same as desktop tab navigation.Rationale
Same as desktop tab navigation.The limitations on scroll-and-select devices arises from the small width and the need to scroll past each of the tabs individually. The experience can be replicated on many desktop sites: try using a site with only tab, shift-tab, letters, numbers, and enter/return. No mousing allowed. Tabs become quite tedious, as do left side navigation.
A mobile implementation of tabs doesn’t have to be as functional as a PC implementation, nor can it typically be (no touch screen, no room for text labels, not room to stack tabs etc). Rather simplicity is key here due to the limited UI.
Implementations of tabs on mass market phones tend to use icons instead of text to distinguish the different tabs (see e.g. Sony Ericsson). That way more tabs can be placed horizontally. E.g. on a 176 by 220 display at least 5 tabs fit this way, with margin, still being easy to comprehend.
J2ME Polish has TabbedForm, which can be applied to both MIDP1 and MIDP2. I haven’t seen any example of how it actually looks on a phone (maybe I should build an example). TabbedForm seems to only support text labels, which is a limitation.
There’s a way to effectively use text labels by showing something like this:
[[Current Tab]]]]]]
Hence only hints about the other tabs. The drawback is that you don’t see the labels until you’ve selected a specific tab, but on the other hand the labels can be relatively long.
I’m not a fan of hinting at other tabs. If the basic tab concept is a valuable organizing mechanism for the application, I’d much rather see a drop-down list. This, with a single click, displays all tabs. It also can be quickly skipped.
My biggest reason for avoiding tabs on a scroll-and-select phone (i.e., most mass-market phones) is the sequential access. I have to scroll through all the tabs to get to the one I want. The exception, as discussed in the bullet list above, is when I have more control over the screen than is true in most cases – focus starts below the tabs. On web sites in particular tabs mean either taking up the top line of the (small) screen with “skip to content” or requiring the user to scroll through all the tabs before getting to content.
I did have one design in which I used side tabs in a Java application. Each tab had a graphic and a number. The number provided direct access to the tab. Each tab contents were limited to roughly 3 times the height of the tab window, and the user could scroll through the content and go to the top of the next tab’s content by scrolling down again. This use of tabs, not covered in this design pattern, took advantage of the phone’s characteristics.
What about vertical tabs, that show up with a click?
The left of the screen is a margin filled with icons one on top of the other, and on the touch of a button, this margin uncollapses, and the text of each tab shows up. It would be as efficient as a drop down list, though would match the intuitive tab attachement as an extention to the “sheet” of the page.
I’d definitely concurr the number thing—with one question: would you reorder the tabs, having the more recently viewed on top? Basically, the same way Windows does when switching between applications with Ctrl+Tab?
The vertical tab idea is interesting, and I’d like to see it in practice. I have concerns about how it would work on a scroll-and-select device, requiring the user to go to a specific location on the screen – this is the precise use of mechanisms like the Options menu on Nokia devices. On a stylus device, however, I can see that it is a useful mechanism. Careful to make the tabs look like something other than a toolbar!
I would definitely avoid reordering the tabs. One of the benefits of tabs is that they provide a known location on the screen to look for access to specific information. If you move them, you create extra work for the user. Of course, in the design I worked on there was a distinct character of the information being displayed that really lent itself to this ordering. Also the numbers should be consistent with the tab order, but accesskeys should definitely be consistent between pages.
Could anyone can post few screen shots of Vertical/Horizontal tabs implemented?
Thanks
Unfortunately, I only have stuff I’ve done for clients who were under NDA.