Difference between revisions of "Tabs"

From perpendicular angel knowledgebase
Jump to navigation Jump to search
(Created page with "<h1><a name="Tabs-Tabs"></a>Tabs</h1> Read <a href="https://scratch.boomi.com/styleguide/#tabs" class="external-link" rel="nofollow">Tabs</a> on the Style Guide.  Note: Thi...")
 
 
(4 intermediate revisions by the same user not shown)
Line 1: Line 1:
<h1><a name="Tabs-Tabs"></a>Tabs</h1>
[[Category: Containers]]
Read <a href="https://scratch.boomi.com/styleguide/#tabs" class="external-link" rel="nofollow">Tabs</a> on the Style Guide. 
Tabs are a set of containers that allow a user to view related content in a non-serial way. 
Note: This page describes in-page <a href="/display/ux/Navigation" title="Navigation">Navigation</a>, not global navigation. 
==Use when==
Tabs are a set of containers that allow a user to view related content in a non-serial way. <h3><a name="Tabs-Usewhen"></a>Use when</h3><ul><li>You have two or more related concepts that can go under a central header. The tabs should alternate between views within the same context. This is the single most important point of the information architecture of tabs - it is the reason they exist.   
<ul>
<ul><li>Ideally there's a sibling relationship between the tabs, such as three views of a set of data. </li></ul></li><li>The information on the non-default tab can be skipped or ignored with no consequence to the user. </li></ul><h3><a name="Tabs-Don%27tusewhen"></a>Don't use when</h3><ul><li>You are designing a serial process. Use the <a href="/pages/createpage.action?spaceKey=ux&title=Wizard+Framework&linkCreation=true&fromPageId=24413608" class="createlink">Wizard Framework</a> instead.</li><li>Users need to compare the information you're displaying. They shouldn't have to flip between tabs to complete a task. </li><li>All of the information must be viewed together and cannot be ignored or skipped. (People will scroll down long pages, we promise!) </li><li>You have more information than will fit on one row. If you have >1 row of tabs, see the UX Team for an alternate solution. </li></ul><h2><a name="Tabs-"></a><font color="#000000">'''Behavior'''</font></h2>
<li>You have two or more related concepts that can go under a central header. The tabs should alternate between views within the same context. This is the single most important point of the information architecture of tabs - it is the reason they exist.   
Tabs have three states of interactivity:<ul><li>'''Selected''': The tab the user is currently viewing. Only one tab can be Selected at any given time.   
<ul><li>Ideally there's a sibling relationship between the tabs, such as three views of a set of data. </li></ul>
<ul><li>The default selected tab should be the most critical information for the user to view. Ideally, it's also the leftmost tab.  </li></ul></li><li>'''Enabled''': Other tabs in the tabset that the user can access, but that are not the default tab. They can take focus, be clicked, be tapped, be activated with the keyboard. On activation, they become the Selected tab. </li><li>'''Disabled''': The tab can not be interacted with in any way. Disabled tabs should not have a hover state or any other affordance that implies they're enabled. (They should, however, still be read out by a screen reader, which should mention that they're disabled.) </li></ul>
</li>
These states have been designed to align with <a href="/display/ux/Accessibility" title="Accessibility">Accessibility</a> standards.<h3><a name="Tabs-Whenaretabsenabledanddisabled%3F"></a>When are tabs enabled and disabled?</h3>
<li>The information on the non-default tab can be skipped or ignored with no consequence to the user. </li></ul>
'''By default, a tab should be enabled at all times unless the UX Designer has specified a situation where we want it disabled.'''
==Don't use when==
<ul><li>You are designing a serial process. Use a wizard instead.</li>
<li>Users need to compare the information you're displaying. They shouldn't have to flip between tabs to complete a task. </li>
<li>All of the information must be viewed together and cannot be ignored or skipped. (People will scroll down long pages, we promise!) </li>
<li>You have more information than will fit on one row. If you have >1 row of tabs, choose an alternate solution. </li></ul>
==Behavior==
Tabs have three states of interactivity:
<ul><li>'''Selected''': The tab the user is currently viewing. Only one tab can be Selected at any given time.   
<ul><li>The default selected tab should be the most critical information for the user to view. Ideally, it's also the leftmost tab.  </li></ul></li>
<li>'''Enabled''': Other tabs in the tabset that the user can access, but that are not the default tab. They can take focus, be clicked, be tapped, be activated with the keyboard. On activation, they become the Selected tab. </li><li>'''Disabled''': The tab can not be interacted with in any way. Disabled tabs should not have a hover state or any other affordance that implies they're enabled. (They should, however, still be read out by a screen reader, which should mention that they're disabled.) </li></ul>
 
==When are tabs enabled and disabled?==
A tab should be enabled at all times unless there's a really compelling reason to disable one.  
 
In the general case, if a user does not have access to a tab (because they don't have a high enough level of security, for example), the tab should not display. 
In the general case, if a user does not have access to a tab (because they don't have a high enough level of security, for example), the tab should not display. 
In some specialized cases (such as a read-only view of a page) we may want to show a user what tabs are available without allowing them to actually view the tab, in which case the Disabled state would be used. This is very rare -- as of 3/2/2017 we're not even sure if we have any. <h2><a name="Tabs-Styles"></a>Styles</h2>
 
We currently have three styles of tabs:<ul><li>'''Standard''' - Standard tabs display using the default text color in semi-bold, and a Dell Blue bottom border. The display does not change on hover. </li><li>'''Enabled''' - Enabled tabs display using the Link Blue text color in normal weight, and no bottom border. On hover, the tab displays using the Dell Blue text color in normal weight and a Dell Blue bottom border. </li><li>'''Disabled''' - Disabled tabs display using #757575 (not finalized) text color in normal weight, and no bottom border. The display does not change on hover.  <span class="image-wrap" style=""><img src="/download/attachments/24413608/tabs.png?version=1&modificationDate=1488480934000" style="border: 1px solid black"></span></li></ul><h2><a name="Tabs-Additionalreading"></a>Additional reading</h2><ul><li><a href="https://www.nngroup.com/articles/tabs-used-right/" class="external-link" rel="nofollow">Tabs, Used Right</a> by Jakob Nielsen of the Nielsen Norman Group. </li></ul><div class="wiki-content"><!-- wiki content --><h1><a name="Tabs-Tabs"></a>Tabs</h1>
In some specialized cases (such as a read-only view of a page) we may want to show a user what tabs are available without allowing them to actually view the tab, in which case the Disabled state would be used.  
Read <a href="https://scratch.boomi.com/styleguide/#tabs" class="external-link" rel="nofollow">Tabs</a> on the Style Guide. 
 
Note: This page describes in-page <a href="/display/ux/Navigation" title="Navigation">Navigation</a>, not global navigation. 
==Additional reading==
Tabs are a set of containers that allow a user to view related content in a non-serial way. <h3><a name="Tabs-Usewhen"></a>Use when</h3><ul><li>You have two or more related concepts that can go under a central header. The tabs should alternate between views within the same context. This is the single most important point of the information architecture of tabs - it is the reason they exist. 
<ul><li>[https://www.nngroup.com/articles/tabs-used-right/ Tabs, Used Right] by Jakob Nielsen of the Nielsen Norman Group. </li></ul>
<ul><li>Ideally there's a sibling relationship between the tabs, such as three views of a set of data. </li></ul></li><li>The information on the non-default tab can be skipped or ignored with no consequence to the user. </li></ul><h3><a name="Tabs-Don%27tusewhen"></a>Don't use when</h3><ul><li>You are designing a serial process. Use the <a href="/pages/createpage.action?spaceKey=ux&title=Wizard+Framework&linkCreation=true&fromPageId=24413608" class="createlink">Wizard Framework</a> instead.</li><li>Users need to compare the information you're displaying. They shouldn't have to flip between tabs to complete a task. </li><li>All of the information must be viewed together and cannot be ignored or skipped. (People will scroll down long pages, we promise!) </li><li>You have more information than will fit on one row. If you have >1 row of tabs, see the UX Team for an alternate solution. </li></ul><h2><a name="Tabs-"></a><font color="#000000">'''Behavior'''</font></h2>
Tabs have three states of interactivity:<ul><li>'''Selected''': The tab the user is currently viewing. Only one tab can be Selected at any given time. 
<ul><li>The default selected tab should be the most critical information for the user to view. Ideally, it's also the leftmost tab.  </li></ul></li><li>'''Enabled''': Other tabs in the tabset that the user can access, but that are not the default tab. They can take focus, be clicked, be tapped, be activated with the keyboard. On activation, they become the Selected tab. </li><li>'''Disabled''': The tab can not be interacted with in any way. Disabled tabs should not have a hover state or any other affordance that implies they're enabled. (They should, however, still be read out by a screen reader, which should mention that they're disabled.) </li></ul>
These states have been designed to align with <a href="/display/ux/Accessibility" title="Accessibility">Accessibility</a> standards.<h3><a name="Tabs-Whenaretabsenabledanddisabled%3F"></a>When are tabs enabled and disabled?</h3>
'''By default, a tab should be enabled at all times unless the UX Designer has specified a situation where we want it disabled.'''
In the general case, if a user does not have access to a tab (because they don't have a high enough level of security, for example), the tab should not display. 
In some specialized cases (such as a read-only view of a page) we may want to show a user what tabs are available without allowing them to actually view the tab, in which case the Disabled state would be used. This is very rare -- as of 3/2/2017 we're not even sure if we have any. <h2><a name="Tabs-Styles"></a>Styles</h2>
We currently have three styles of tabs:<ul><li>'''Standard''' - Standard tabs display using the default text color in semi-bold, and a Dell Blue bottom border. The display does not change on hover. </li><li>'''Enabled''' - Enabled tabs display using the Link Blue text color in normal weight, and no bottom border. On hover, the tab displays using the Dell Blue text color in normal weight and a Dell Blue bottom border. </li><li>'''Disabled''' - Disabled tabs display using #757575 (not finalized) text color in normal weight, and no bottom border. The display does not change on hover.  <span class="image-wrap" style=""><img src="/download/attachments/24413608/tabs.png?version=1&modificationDate=1488480934000" style="border: 1px solid black"></span></li></ul><h2><a name="Tabs-Additionalreading"></a>Additional reading</h2><ul><li><a href="https://www.nngroup.com/articles/tabs-used-right/" class="external-link" rel="nofollow">Tabs, Used Right</a> by Jakob Nielsen of the Nielsen Norman Group. </li></ul></div>

Latest revision as of 13:50, 1 June 2020

Tabs are a set of containers that allow a user to view related content in a non-serial way. 

Use when

  • You have two or more related concepts that can go under a central header. The tabs should alternate between views within the same context. This is the single most important point of the information architecture of tabs - it is the reason they exist. 
    • Ideally there's a sibling relationship between the tabs, such as three views of a set of data. 
  • The information on the non-default tab can be skipped or ignored with no consequence to the user. 

Don't use when

  • You are designing a serial process. Use a wizard instead.
  • Users need to compare the information you're displaying. They shouldn't have to flip between tabs to complete a task. 
  • All of the information must be viewed together and cannot be ignored or skipped. (People will scroll down long pages, we promise!) 
  • You have more information than will fit on one row. If you have >1 row of tabs, choose an alternate solution. 

Behavior

Tabs have three states of interactivity:

  • Selected: The tab the user is currently viewing. Only one tab can be Selected at any given time. 
    • The default selected tab should be the most critical information for the user to view. Ideally, it's also the leftmost tab.  
  • Enabled: Other tabs in the tabset that the user can access, but that are not the default tab. They can take focus, be clicked, be tapped, be activated with the keyboard. On activation, they become the Selected tab. 
  • Disabled: The tab can not be interacted with in any way. Disabled tabs should not have a hover state or any other affordance that implies they're enabled. (They should, however, still be read out by a screen reader, which should mention that they're disabled.) 

When are tabs enabled and disabled?

A tab should be enabled at all times unless there's a really compelling reason to disable one.

In the general case, if a user does not have access to a tab (because they don't have a high enough level of security, for example), the tab should not display. 

In some specialized cases (such as a read-only view of a page) we may want to show a user what tabs are available without allowing them to actually view the tab, in which case the Disabled state would be used.

Additional reading