Differences between revisions 3 and 4
Revision 3 as of 2010-12-02 02:54:10
Size: 2949
Editor: shoobe01
Comment:
Revision 4 as of 2010-12-02 05:25:58
Size: 4415
Editor: shoobe01
Comment:
Deletions are marked like this. Additions are marked like this.
Line 8: Line 8:
Tabs are real, even if not looking like their machine-era counterparts, need to follow the same principles: Tabs are real, even if not looking like their machine-era counterparts,...

...
need to follow the same principles:
Line 17: Line 19:
High level vs. lower level (top nav vs. section or even in-page navs)... Tabs may be used across the site, application or process, as an indicator and access point to the highest level of navigation available without exiting. Or, they may be used within a single page or page template to provide access between broadly equivalent types of information without logically leaving the page.
Line 19: Line 21:
All visible vs. not-enough-room (e.g. USAT scrolling tab bar)... All the available tabs should whenever possible, be visible at all times. However, this is often not possible due to labels being too large for the screen. Tabs which do not fit may fall off the sides of the screen, and those that fit will appear as focus shifts. In the most extreme case, only a single tab will fit the screen, and sideways scrolling is required to see any other tabs.
Line 25: Line 27:
Touch and pen will directly interact with tabs. However, this can be a problem as the tabs must be correspondingly larger to allow for the touch target. Again, unless the labels can be small enough or the device is large, tabs may not be the best option. Touch and pen will directly interact with tabs. However, this can be a problem as the tabs must be correspondingly larger to allow for the touch target. Again, unless the labels can be small enough or the device is large, tabs may not be the best option. For cases where not all tabs fit on the screen, scrolling (by dragging) may allow browsing of the whole tab row.
Line 27: Line 29:
For tabs that do not fit on the screen. For any selection mechanism, selecting a tab when the tab row does not entirely fit on the screen will cause the tab to become centered immediately. If not technically possible, it will assume the centered position when the new content loads.
Line 43: Line 45:
Clever solutions for space rarely work. A second row of tabs always is perceived as subsidiary to the top row, and is not read as a second row of text would be. Clever solutions for space rarely work, so follow best practices and existing working methods before attempting to develop your own solutions. A second row of tabs always is perceived as subsidiary to the top row, and is not read as a second row of text would be.

Avoid using tabs for both high-level and in-page navigation. If needed, differentiate the two in some key way to express the hierarchical difference.

When tabs are used within a page (such as providing a switch between overview, detailed specifications, and reviews), avoid refreshing the entire page. Logically, and by convention that users are familiar with now, this should only load the requested information, and leave the rest in place, without even flickering.

All these not so much sideways and "at the same level" and view switching - solutions to tabs not fitting, like USAT scrolling the tab bar. Note that tabs are terrible because text is horizontally inefficient

Problem

Lateral access, bunch of directly equal levels of information at the IA...

Solution

Tabs are real, even if not looking like their machine-era counterparts,...

...need to follow the same principles:

  • Clearly label what is inside them.
  • Indicate when you have the one you want selected, or open.
  • Make sure all tabs and labels are visible at once, or it is clear there are more to be seen if you try harder.

Variations

Aside from graphic design distinctions, there are basically two axes upon which tabs may vary:

Tabs may be used across the site, application or process, as an indicator and access point to the highest level of navigation available without exiting. Or, they may be used within a single page or page template to provide access between broadly equivalent types of information without logically leaving the page.

All the available tabs should whenever possible, be visible at all times. However, this is often not possible due to labels being too large for the screen. Tabs which do not fit may fall off the sides of the screen, and those that fit will appear as focus shifts. In the most extreme case, only a single tab will fit the screen, and sideways scrolling is required to see any other tabs.

Interaction Details

Scroll and select: usually used so page contents are vertical only, tabs are horizontal keys anywhere on the page. If the page interaction is more complex, or uses a free-roving cursor, tabs are not suggested... tabs that don't all fit will work just like those that do, and scrolling reveals the next one. WAIT: Two ways to work, scroll to see page, or scroll to select then OK to see page... I /think/ the latter even when tabs not visible is suggested, to avoid accidental loss of data or context...

Touch and pen will directly interact with tabs. However, this can be a problem as the tabs must be correspondingly larger to allow for the touch target. Again, unless the labels can be small enough or the device is large, tabs may not be the best option. For cases where not all tabs fit on the screen, scrolling (by dragging) may allow browsing of the whole tab row.

For any selection mechanism, selecting a tab when the tab row does not entirely fit on the screen will cause the tab to become centered immediately. If not technically possible, it will assume the centered position when the new content loads.

Presentation Details

Tabs really only work well when arrayed horizontally, or when all are on one row. Vertical tabs of any sort are rarely are understood by the user to be tabs, so will not be discussed here.

Try to get all tabs visible. However, tabs are a troublesome item as they are usually labeled with text. Text is an inefficient user of horizontal space, so it is easy on a small mobile device to run out of room with only one or two tabs. Alternatives are to use... SIDE SCROLL??? think nokia single-visible as well...

When only one or a few tabs are visible, assure the tab paradigm is clear, and it is obvious the tab is not just a page title, but is one option of many to be chosen from.

When scrolling through the tab list, make sure a visible but non-selected tab is different from the selected one, even without comparison, so that users do not mistake it for the page Title.

Circular lists are strongly suggested when not all tabs are visible,...

Antipatterns

Clever solutions for space rarely work, so follow best practices and existing working methods before attempting to develop your own solutions. A second row of tabs always is perceived as subsidiary to the top row, and is not read as a second row of text would be.

Avoid using tabs for both high-level and in-page navigation. If needed, differentiate the two in some key way to express the hierarchical difference.

When tabs are used within a page (such as providing a switch between overview, detailed specifications, and reviews), avoid refreshing the entire page. Logically, and by convention that users are familiar with now, this should only load the requested information, and leave the rest in place, without even flickering.

Examples

Tabs (last edited 2011-07-31 20:36:48 by shoobe01)