Headers are containers attached to the top of a page that house product-wide or global actions and navigation, as well as user preferences and branding.
A header container can be 48, 56, 64, or 72 px tall. It can be a UI theme agnostic from the page’s theme.
On desktop, headers use a page-theme medium divider below the header. For example, if your header is lightest theme and your page is light theme, use a light theme medium divider to separate the header from the page. On mobile web, headers use a page-theme small divider.
Your header can have either branding or a home icon (in the form of an action button) on the left side of the header.
If your header needs to show the document name, or have a control for switching between multiple documents, use either plain text or a quiet picker with an icon.
You can include search functionality in your header.
If there is a top level action that applies to any page in your product, you can put one button in your header between search and actions. Because the placement and persistence of the button gives it extra visibility, we recommend using a primary button here, though a CTA button is permissible.
Clicking on the search icon will expand it out to a full search field. If tabs or document name are present, these disappear to make room for the search field.
If there are no tabs or document name, keep the search field expanded in the center of the header by default.
Action button groups can be divided by small dividers. Place global/more permanent actions on the right side, and transient/contextual actions on the left. Actions can collapse down to a tool with hold affordance.
If your page is using a 12 column fluid grid, the components inside the header should line up to the columns, respecting the outer gutters. In this example, the gutters are 32 px wide so the header content is inset 32 px as well.
If your page is using a 12 column fixed grid, the content is a max width of 1280 px. In this case, the content inside the header would also have a fixed width and line up to the columns.
Note that with a small viewport, you should switch to using mobile-scaled components.
Responsiveness will depend on the use case, and it should be decided which components are more important than others. If, for example, the button is more important than the document name, then the button could stay and the document name be removed instead.
The individual components in the header would collapse according to their behavior guidelines. Tabs would collapse down to the tab overflow style. Action buttons collapse down to a “more actions” icon button, and could include the search functionality on small screens.
Make sure that if you remove items from the header, you do not remove them completely. Retain the functionality by collapsing into the more actions menu.
If your use case has the need for a maximize UI control, place the maximize icon to the furthest right of the header, with a small divider to separate it from the rest of the items.
The header should always be sticky on the page. It should not be able to be scrolled out of sight.
Browser-based applications must account for UI that are handled by the OS elsewhere. Web app headers should include clear branding and access to help, notifications, and user settings. Web headers should use the "header" element in HTML 5 and the "banner" landmark role.
The “traffic lights” in MacOS that are used to close/minimize/maximize the window are positioned at the far left of the header. They should be vertically centered in the header. Branding should not be present in the header bar on MacOS unless the product name is shown. Dividers below the header should be medium thickness (2 px). The product name is not shown when the document/project name and/or switcher is used. Note that the application name is aways shown in the MacOS menu bar immediately to the right of the Apple menu. Learn more about MacOS window anatomy.
The minimize/maximize/close buttons are always displayed on the far right of the header. The application icon is always displayed on the far left of the header bar, and this representation takes the place of a spelled-out product name. The app icon is immediately followed by the application menu items. Learn more about Windows’ page layout.
Use the iOS header with a few changes. Change the font to Adobe Clean, and change the colors to match Spectrum. Tabs can become sections in an iOS tab bar at the bottom (skinned with Adobe Clean). Branding should not be present. Home icon functionality and search could collapse with the other actions into a more actions menu.
Use the Android header with a few changes. Change the font to Adobe Clean, change the colors to match Spectrum. Tabs can be either be tabs at the top, below the header, or an Android bottom navigation bar (skinned with Adobe Clean). Branding should not be present. Action buttons would collapse down to a hidden actions menu. Search can either be hidden in the hidden actions menu or stay exposed. Do not add a drop shadow to the Android header.
Although most pieces of the header are optional, do not change the placement of the components if they are included in your header.
Search fields in the header should search product-wide, not search across products.
If your product has no tabs or document name, keep the search field open rather than collapsing it down to an icon.
Every product should either have a home icon or branding. It should not have both. If there are no tabs, and you have a brand mark, you can include the product name to the right of the mark.
The header bar can be a different theme than the rest of the page, but should be the same or darker than the UI on the page. You should not use a light UI header with a dark UI page.
If you are using a dark UI header with a light or lightest UI page, you do not need to include a divider between the header and page.
Components have their own defined keyboard interactions. For more information regarding component-level interactions, visit the component pages.
|Ctrl + F8||Bring the first item inside the header container into focus|
|Tab||Move from component to component from left to right in LTR languages, and from right to left in RTL languages|
|Apr 06, 2022||2.0.0|
|Jun 12, 2019||1.0.0|