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.

Anatomy

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.

1. Topbar

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.

2. Sidenav

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.

3. Footer

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.

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.

Anatomy

Zywave Topbar

The suite Topbar contains many different components which aid in branding, navigation, and other user actions. The components include:

1. Zywave logo
2. Branding bar
3. Search bar
4. Application switcher
5. Profile manager

Adding product-specific branding

When necessary, you can also include specific product branding in the Zywave Topbar:

1. Product name - The name of the product.
2. Product-specific branding bar - A taller branding bar.

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.

1. Home - Every application should have a home link at the top. This takes you to the home page of whatever application you are in.
2. Product navigation links - These are the application links that take the user to the features they have access to.
3. Notifications - A link to notification center, when applicable.
4. Settings - Application-specific settings, when applicable.
5. Help and training - Links to the support site or Get started with Zywave University.
6. Collapse - Gives the user the ability to collapse the Sidenav for more working space in the Content area.

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.

Anatomy

The core features of the footer include:

• Zywave copyright
• Terms and Conditions link
• Privacy Statement link
• DMCA link
• Cookie Usage link
• Contact link

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.

Standard padding

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.

View padding specs

*em units are based off the browser's default font size of 16px

Content area max-width

Standard 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 1600px or 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 900px or 56.25em.

Our standard Content area max-width is: 1600px or 100em

View standard max-width specs

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.

View component specific max-width specs

Cards

Depending on content within Cards, and the rest of the components on the page, Cards can have two different max-widths; either 900px or 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.

View card max-width specs

*em units are based off the browser's default font size of 16px

Text areas

Studies have shown that between 45 to 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.

Text inputs

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 730px.

View text standards

View form standards

Tables

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.

Background coloring

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.

Anatomy

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.

1. Organization name - indicate the current organization the user is viewing
   • Longer organization names will truncate and include ellipses
2. 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

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.

Usage

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.

Alternate considerations

• 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.

Anatomy

1. Sticky bar: Shell-themed bar that is sticky to the bottom of the Top bar
2. Page title: Title is located on the left side within the sticky bar
3. 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.

Behavior

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.

Responsiveness

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".

Best practices

Complex forms