What is Shell?
The Shell wraps around all of our applications and provides suite level consistencies, branding, and common functionality. It helps the user understand and navigate the core of the Zywave suite.
The shell includes 4 core sections that surround the content standard content area, Topbar, Side nav, and footer. For a consistent user experience, use all 3 shell components when building applications.
The Topbar is the section reserved at the top of the page that provides application branding, suite-level navigation, and high priority functionality such as search. For more detailed information, view the Topbar guidelines.
The Side nav provides a standard place for navigation within a product. Placed on the left-hand side of the site, it lists out the application-specific site features you can access, as well as features like settings, notifications, and help. For more detailed information, view the Sidenav guidelines.
The section at the bottom of most pages contain information that needs to be there, but doesn't necessarily demand the user's primary focus. The footer can include legal, trademark, terms & conditions, privacy statement, DMCA, cookie usage, and contact information. For more detailed information, view the Footer guidelines.
4. Content area
The Content area is the body of our applications where all the features and functionality gets placed. For more detailed information, view the Content area guidelines.
Suite vs individual products
Depending on if you are building a single point solution that will be sold individually or one that fits into our suite with other features of the same nature, the shell can change to accommodate an ideal user experience.
Example: Shell for the Zywave suite.
Example: Shell for a single point solution (ModMaster). The application bar becomes slightly larger to accomidate the application name.
The shell has been designed to transition itself for a better experience on mobile devices. At our mobile breakpoint (≥
720px), the side nav becomes hidden off-screen and slides in when the menu button his pushed. For a detailed list of what happens in each 4 core sections, please visit those sections.
What is the Topbar?
The Topbar gives the user easy access to suite and organization-level actions, as well as some important actions specific to the application or tool. The Topbar also provides a space for product branding. It is a base component of the suite and should be used for every product, unless there is a specific reason not to.
The suite Topbar contains many different components which aid in branding, navigation, and other user actions. The components include:
- Zywave logo
- Branding bar
- Search bar
- Application switcher
- Profile manager
Adding product-specific branding
When necessary, you can also include specific product branding in the Zywave Topbar:
- Product name - The name of the product.
- Product-specific branding bar - A taller branding bar.
Sizing & Spacing
Although there is not much difference in layout and componentry, depending on the application we have two different variations of the Topbar:
- Zywave Topbar - Use when the primary user is a user client. This Topbar has several different branding features depending on if the product is singular in focus or crosses multiple workflows.
- Client Topbar - Use when the primary user is a Broker's client; e.g., Employer Admin or Employee.
Actions in the Topbar
- Application switcher - When clicked, a dropdown list will appear and show the user other applications they own so they can easily switch between them.
- Profile manager - When clicked, a dropdown will show user information (e.g., principle and profile) and notifications.
Search is an optional feature dependent on the application and the users' needs. Depending on the importance or need of searching, this component may or may not be included in the Topbar. The search bar will default to the category that's searchable for the product. For example, "content" in Broker Briefcase.
The Topbar is the highest section of Shell, meaning everything in the Sidenav, Content area and Footer can slide underneath it when scrolling. When the user starts scrolling down the page the Topbar will shrink down to
10px tall, allowing for more vertical space in the Content area. Once the user scrolls up
1px or more, the entire Topbar reappears.
On smaller screens with a breakpoint <
720px, the Topbar responds to allow for a better mobile experience:
- The Zywave logo moves to the middle of the Topbar.
- A hamburger menu is located in the upper left. When pushed, the Sidenav slides in from the left.
- The right side of the Topbar should only be used for prime actions per product. For example, most partners search Broker Briefcase on mobile, so it would make sense for the search icon to be present in the mobile Topbar.
What is the Sidenav?
The Sidenav contains the majority of the application and suite-level navigation. This includes the feature-level navigation as well as access to Notifications, Settings, and Help and training. Having the Sidenav in a standard and reliable place helps ground the user experience of all our products. It should be used for every product, unless there is a speific reason not to.
What things go in the Sidenav
The following are nav items that are recommended for every application, when applicable.
- Home - Every application should have a home link at the top. This takes you to the home page of whatever application you are in.
- Product navigation links - These are the application links that take the user to the features they have access to.
- Notifications - A link to notification center, when applicable.
- Settings - Application-specific settings, when applicable.
- Help and training - Links to the support site or Get started with Zywave University.
- Collapse - Gives the user the ability to collapse the Sidenav for more working space in the Content area.
- Nav item
- Nav item icon
- Expand icon
- Nav item (with children)
- Subnav items
- Collapse action
- All top-level nav items should have a corresponding icon to help quickly identify the action. These icons are also used when the menu is collapsed.
- Child items do not have icons associated with them.
- For more information view our icon standards
- Expanded - At the breakpoint of ≥720, the full expanded side navigation is present.
- Collapsed - When the collapse button is pressed the menu will slim down to show only icons as main navigational items.
- Mobile - At the breakpoint of <720, the Sidenav is off-screen and slides in from the left when the hamburger menu is pushed.
Behavior (expanded state)
- Unselected nav item - Font color: ZUI Gray 700; font weight: 400 (Regular); icon color: ZUI Gray 800; background color: none
- Selected nav item - Font color: ZUI Blue 500; font weight: 700 (Bold); icon color: ZUI Blue 500; background color: none
- Expand & collapse action icon - When clicked, the icon rotates 180 degrees. The icon should always point the direction the action will happen.
- Selected subnav item - Font color: ZUI Blue 500; font weight: 700 (Bold); icon color: ZUI Blue 500; background color: none
- Hover - background color: ZUI Gray 50
Parent and children
- When anywhere on a parent item is clicked, the children will appear below that parent item.
- Parent items are used only for organizational purposes to reveal their child subnav items, they aren't linked to pages themselves.
- Parent items can all be open at the same time to show all subnav item for the entire application.
- After a user clicks on a link, expanded navigation remains expanded. Don't close the navigation until the user pushes to close it.
- When the list of expanded items extends the entire height of the viewport, a small scrollbar appears, allowing the user to scroll the Sidenav.
- The collapsed nav item remains stuck to the bottom and is not part of the scrolling section.
Collapsing the Sidenav
- The user can collapse & expand the navigation by clicking the collapse button at the bottom of the Sidenav.
- When collapsed, the content area will respond to make more room for itself by taking up the area that the Sidenav had been using.
- There is no need for the expand/collapse Sidenav function in the mobile state, so the button is hidden.
Behavior (collapsed state)
- Unselected nav item - Icon color: ZUI Gray 800; background color: none
- Selected nav item - Slide-out shows the full name of the navigation item. The user can then click the icon or the text to navigate to this page. Icon color: ZUI Blue 500; background color: none
- Hover nav item with children - Slide-out shows the nav item name and list of subnav items. The user can then select the page they wish to navigate to in the list. Background color: ZUI Gray 50
- Hover subnav item - Background color: ZUI Gray 100
- Selected item - Font color: ZUI Blue 500; font weight: 700 (Bold); background color: none
Behavior (mobile state)
The menu slides in over the content. To close the Sidenav, the user can click off to the right of the navigation.
Sizing & Spacing
Use the following links to find exact pixel specs for each state of the Sidenav.
What is the Footer?
The Footer is the small section at the bottom of each page that contains things like the privacy and cookie policies, and other legal and trademark information. It is easy to find the information you are looking for, should you need it, and does not interfere with using the app. The Footer is a core feature of Shell and should be used in every application.
The core features of the footer include:
- Zywave copyright
- Terms and Conditions link
- Privacy Statement link
- DMCA link
- Cookie Usage link
- Contact link
The footer stays at the bottom of the page. There are no special behaviors, other than responsive design changes listed below.
The links in the footer go to the following:
- Terms and Conditions link - https://www.zywave.com/terms-conditions/
- Privacy Statement link - https://www.zywave.com/privacy-statement/
- DMCA link - https://www.zywave.com/dmca-notice/
- Cookie Usage link - https://www.zywave.com/cookie-usage/
- Contact link - mailto:firstname.lastname@example.org
As the viewport grows, the footer moves from three lines stacked on top of each other to a single line.
Breakpoint - ≥ 480px
Breakpoint - ≥ 720px
Breakpoint - ≥ 1024px
What is the Content area?
The Content area is the body of our applications where all the features and funcionality get placed. When building features in our applications, it's important to understand the size of the canvas you'll be building on. A user should always understand the boundaries of our applications, so the Content area should not change from page to page.
Common page padding is important to keep the content in one place and give it some breathing room. Padding is automatically added to our standard Content area. Depending on the size of the viewport, there may be more or less padding. The amount of padding added is dependant on breakpoints. Here is a list of padding that is applied at each breakpoint.
|≤||Side navigation hides; mobile menu becomes available|
|≤||Collapsed side navigation appears|
|≤||Side navigation collapses|
em units are based off the browser's default font size of
Content area max-width
In most cases, the content on the page should fill the full width of the Content area—stretching end-to-end of the available screen real estate—leaving room for only standard padding. However, we recommend enforcing a max-width of
100em as the viewport gets larger. For a good user experience, it is typically not helpful to continue stretching past our recommended max-width. In cases where the content doesn't need to be stretched or would be more appealing at a smaller size, use the max-width of
Our standard Content area max-width is:
Component specific max-width
In special cases, a component should not fill the full width of the Content area. Instead it should stop at a specific width to ensure a good user experience. Enforcing these max-widths will allow the user to read and understand information easier than if the component was stretched.
Components with an enforced max-width should remain the same size when the Content area grows wider to suit a larger viewport. However, once a component's max-width reaches the limit of the Content area max-width, it should stop growing to not overflow.
Depending on content within Cards, and the rest of the components on the page, Cards can have two different max-widths; either
1600px (regarded as full-width).
900px width means that the Cards and all components on the page extend to a max-width of only
900px and then stop growing.
1600px width means that the page components are full-width, padding still in effect, on the page until they hit
1600px then stop growing.
Because Cards can hold a variety of different components and content, all specific max-widths still apply. For example, because a Text Input has a max-width of
730px, this will remain in effect in larger card sizes even though there may be empty space.
|full-width ||Side navigation hides; mobile menu becomes available|
|≤||full-width ||Collapsed side navigation appears|
|≤||full-width ||Side navigation collapses|
em units are based off the browser's default font size of
Studies have shown that between
75 characters per single line of text is the optimal length for reading. Anything shorter than this can cause the readers' eyes to bounce around too much. Anything longer and the reader can become fatigued and lose their place when moving to the beginning of the next line. Depending on font type and size, this character length equates to about
700px in width. Meaning that when there is a Text Area on the page or within a card, the max-width of that area should be
700px. Regardless of card size, ranging from
900px to full-width (up to
1600px), the Text Area should never be larger than
700px and be left-aligned with the card.
Using the same studies and conclusion as Text Areas, Text Inputs should also have a max-width of
700px for a single line of text. There is also
15px of interior left and right padding within Text Inputs, therefore the max-width of a text input should overall equal
730px. Meaning that when there is a Text Input on the page or within a card, the max-width of that input should be
730px. Regardless of card size, ranging from
900px to full-width (up to
1600px), the Text Input should never be larger than
Tables can have a large amount of information, options, and details within them; because of this, it is acceptable that they expand to the full width of
1600px of the page where applicable.
Content area best practices
Even though there may be empty space within components such as cards, all components on a page or in a workflow should always follow these rules. This will allow the user to move between pages easily because the components and pages are not jumping sizes to react to the content within.
When adding a form, make sure that it meets our max-width standards. When the content area is
900px and below, the form must always be full-width. When the content area is between
1600px, the form must be either
900px or full-width. When the content area is larger than
1600px, the form must be either
There should never be a situation where the form is smaller than
900px or full-width when the content area is larger than
When adding multiple components to a page or within the same workflow, all elements should have the same width.
There should never be a situation where a form has a max-width of
900px, and a table below it is full-width.
Gray and white background colors are available, depending on the situation.
When to use a gray background
For most applications, our standard is to use a gray background. We use gray because it creates a base layer we can build off of and highlight, allowing the user to focus on the task at hand. Most of our components and containers are specifically built to help draw the users attention and a gray background helps with that.
When to use a white background
Use a white background when the content is mainly text based to enhance readability.
What is the Context switcher?
The Context Switcher lives in the Sidenav when a user is viewing a feature on behalf of a different organization. It provides information about which organization is being accessed as well as an easy way to switch to a different organization.
The context switch indicates which organization is currently being viewed by the user. When clicked, it will return the user to their dashboard to switch to another organization.
Organization name - indicate the current organization the user is viewing
- Longer organization names will truncate and include ellipses
Switch action - allows the user to navigate back to their dashboard to switch to a different organization
- The icon and "Switch" label both remain when the sidenav is collapsed
On mobile devices, the Context Switcher is hidden off-screen within the Sidenav. This means the organization currently being viewed is hidden within the menu. See best practices for our recommendations on ways to help add more clarity about the selected account.
The background of the Context Switcher becomes ZUI Gray 100 on hover, indicating that the entire area is clickable.
When the Sidenav is collapsed, additional hover behavior is added to help identify the currently selected organization. The background behind the switch action becomes ZUI Gray 100 to indicate that it is clickable. In addition, there is a fly-out that shows the "Viewing as: organization" message on a white background, similar to the child items in the Sidenav.
Because the currently selected account is not immediately visible when the Sidenav is collapsed or on mobile devices, we recommend including the organization name in page titles or descriptions. Including the organization name will provide more clarity about which organization they are currently viewing.
The Context Switcher only appears in the Sidenav when the user has chosen to view a feature as an organization. Once they return to their dashboard, the Context Switcher should be removed.
The contents of the Sidenav should also change to reflect what is available for that account in the feature/tool.
Collapsing navigation behavior:
When collapsing the Sidenav, the flyout containing the "Viewing as: organization" message appears for a few seconds and then disappears. To view this message again, the user can hover over the switch action.
What is the Action bar?
The Action bar is used to provide the user with a consistent placement of actions on the screen when interacting with longer, more complex pages.
Action bar keeps the action buttons in a standard state on the screen, even when scrolling. It is the ideal component to use when walking the user through a complex step flow. While the content on the page follows our max-content-widths, the page title and buttons float to the far left and right inside the action bar, using the entire width of the screen.
- Use dialog box to keep the user focused on the form and input fields and if you have only a few input fields
In a long form
When you have a long form that is not broken up into multiple steps
For detailed documentation on using Action bar in a long form, view the design specs.
In a multi-step form
When you have a form that is broken up into multiple steps, the progress indicator is located on the left within the action bar and follows the format # of #: Step title
For detailed documentation on using Action bar in a multi-step form, view the design specs.
When editing a document
For detailed documentation on using Action bar when editing a document, view the design specs.
- Sticky bar: Shell-themed bar that is sticky to the bottom of the Top bar
- Page title: Title is located on the left side within the sticky bar
- Action buttons: action buttons are located on the right side of the sticky bar
For detailed documentation on Action bar anatomy, view the design specs.
The main purpose of the action bar is to provide the user with a consistent placement of actions. The Top bar and Side nav should remain available in an action bar to not limit the user in their ability to navigate out of the current workflow when necessary. To achieve that, the following behavior should be used:
- Zywave Top bar behavior should remain unchanged
- The action bar is sticky and should remain flush up against the bottom of the Top bar, even as the user scrolls down the page to keep the actions in a consistent place on the screen
- Depending on the task at hand and how the data is being saved, a dialog may need to be displayed before a user navigates away to prevent loss of information
Focused state with an expanded side nav
For detailed documentation on Action bar with an expanded side nav, view the design specs.
Action bar after scrolling down the page
For detailed documentation on Action bar after scrolling down the page, view the design specs.
The mobile action bar is a bit different from the desktop version.
- The Top bar should disappear completely when entering a focus state on a mobile device
- The action bar remains sticky to the top of the page
- The background of the action bar is white
- If the action bar uses a "cancel" action, it should be replaced with ZUI-remove and be moved to the left side of the action bar
- The title or progress indicator should be aligned 20px to the right of the cancel or back button
- When there are more than two actions, the title can be removed from the action bar
- If the title is important for the user to see, use an ellipsis in the title if it overlaps the actions in the bar
- The save or forward directional button should be located on the right
For detailed documentation on Action bar responsiveness, view the design specs.
The action bar will stay fixed to the top of the view point when the keyboard is present.
ZUI-remove will always be present. When you have a form that is broken up into multiple steps, include an action to go to the previous step such as "Back".
- Use the Action bar for forms that are longer than 5 input fields
- Use the Action bar for forms that are under 5 input fields
- Use the Action bar for step flows where there are more than X steps
- Use only one primary button
- Use more than one primary button