A list contains a group of related items listed vertically. Lists can be unordered (bulleted) or ordered (numbered).

Use an ordered list if the order of the items in the list matters, otherwise, always use an unordered list. All of our lists use hanging punctuation, where all text is left aligned and the bullets or numbers are pushed to the left. If you’re trying to represent complex numerical data, try using a table.

The strong/weak heading varies type weight from one line to the next. Make sure to choose which lines are presented in a heavier weight carefully to provide a visual hierarchy. Bold the lines that are most important to conveying meaning.

A drop or initial capital is a long-standing typographic tradition. We use it only at the beginning of a long piece of text, like a press release or a blog post. Normal static marketing pages should not use blog posts.

If you add the drop-cap class to a paragraph, that paragraph will have a drop-cap. If you apply it to a different element, if the first, direct child of that element is a <p> tag, that paragraph will be shown with a drop cap.

A pull quote can help place greater emphasis on a particularly powerful snippet of text in a longer article. Use sparingly. Pull quotes work best in long pieces of text intended for more liesurely reading, and most such pieces should not use more than one.

This component helps to provide social proof, testimonials, and other quotes in a clear manner.

The testimonial component expands upon the quote component by adding a photo of the person quoted, making it more effective when used for social proof. It should not be used in full-width columns, so for more extensive quotes the quote component will generally work better.

You can include multiple images (for example, a photo and a logo) by replacing the <img /> tag with <ul class="images">. Place each image in a separate list element (<li />), and mark any list element that contains a logo with the logo class.

The splash section component provides variety on static marketing pages. Use this component for short pieces of text with a compelling heading.

A button expresses to the user the corresponding action when they click or touch the button. They initialize background and foreground actions.

We use two different types of buttons: regular and secondary. Only use the secondary button when two buttons are side by side. Use the secondary button to de-emphasize an action such as cancel.

Buttons also have two different states, active (default) and disabled. A disabled button has a less saturated appearance.

When presenting multiple buttons together (for example, at the end of a form), wrap them in <p class="actions">. Choose one button as the primary, intended action (often the form submission). All other buttons should be presented in the secondary style (.p2).

Links are used primarily as a navigational element. They may also change what or how data is displayed (view more, show all).

Always use text for links, never graphics or images.

Keep links below four words.

Make sure the text associated with the link isn’t confusing. The user shouldn’t have to guess where the link will take them.

Be descriptive. Avoid using “Click Here” or “here,” for the link.

Drop zone is an area for a user to drop in a local file to be uploaded.

Make sure the text associated with the drop area indicate to the user the type of files accepted.

Validate that the file was uploaded or denied. If the file was denied, provide reasoning so the user can recover from their error.

The file-drag class identifies a <input type="file" /> tag as one that should be given a drop zone. The multiple attribute indicates that it can handle multiple files. If the user is expected to upload just one file, remove this attribute and the input will disallow multiple files.

The drop zone uses a <input type="file" /> tag, but if JavaScript is loaded, this is enhanced to create the full drop zone component. When files are selected or dropped in the drop zone, an upload button appears. When the user clicks this button, an array of the files selected is sent to the URL provided in the data-upload attribute, using the key provided in the data-name attribute, in a POST request.

A card is container for a few short, related pieces of information. It roughly resembles a playing card in size and shape, and is intended as a linked, short representation of a conceptual unit.

Cards should only be displayed on a grey background (#e1e5e6 or $gray1).

All content in the card should be related.

Keep content on the card short. Offer a linked entry point to further details, rather than the full details themselves.

Cards are essentially scannable lists, use them when you intend for the user to browse content. If hierarchical order is important, use a nested list instead.

As explained on the card pattern, a card should contain only “a few short, related pieces of information.” In most cases where you may want to pair this with an icon, the banner pattern would be a better choice. The banner is intended to “provide feedback of the system status when a user commits an action.” This pattern is very close to the banner pattern, but allows for more content on the card and does not necessarily require that it be tied directly to user input. Using this pattern likely indicates a deeper problem. If you’re considering using this pattern, it likely means that you’re not using the card pattern correctly. Are you sure that a table or some other pattern wouldn’t work better?

Banner messages provide feedback of the system status when a user commits an action. They span the width of a container and include an icon associated with the type of message, error or confirmation.

Banners appear at the top of a page, they shouldn’t be nested inside content.

These messages should not be able to be dismissed because of severity or importance to product usage.

Banners should always be white. The icon associated with the banner should coordinate appropriate color to the type of message and provide additional context.

This pattern should not be used. While confirmation dialogs can prevent user errors (if they are not overused), they are a perfect example of an enhancement. Enhancements are not features that are unimportant, but features that are not critical. Confirmation dialogs can prevent costly errors if properly used, but a system without confirmation dialogs will still function. The window.confirm() method might fail if a problem occurs with JavaScript, but that is acceptable. It uses an interface familiar to the user, and that familiarity can prompt her to recognize that she’s being asked to commit to an important decision. A custom-designed prompt like this one might look “better” but is not as well-designed because it fails to fulfill that need as well because it is less familiar and thus less recognizable.

Allowing users to undo a destructive action is, in general, a far better design pattern than requiring a confirmation. Any time you implement a confirmation dialog, try to find some way that you could provide an opportunity to undo the action instead. Use a confirmation dialog only if there truly is no way to provide an option to undo the action.

Use confirmations for actions that have serious consequences. Never use them for routine actions, or users will become too accustomed to dismissing them, which will defeat their purpose.

The heading for the confirmation should be specific. Never use, “Are you sure?” Instead, specify the action in question. Likewise, the text should also be specific, detailing what the consequences of the action will be. The text of the buttons should also be specific about the action that will take place if the user clicks them (e.g., use “Delete” rather than “Yes”).

When asking for a confirmation, do not select either option as the default. Confirmations should only be used for actions that have serious consequences, and if the consequences are that serious then we want to make sure that the user takes a moment to consider and act deliberately. Default choices reduce friction, making it easier for a user to proceed along the most likely route. In this case some friction is desired, because it gives the user occasion to pause and consider what she is about to do. That is the goal of this pattern. If the confirmation dialog is not to confirm anything but to gather extra information, then you can designate a default option (but if that’s the case, then this threatens to over-use the pattern, undermining its efficacy and violating previously-stated principles).

The confirmation dialog uses the same subclasses as the banner pattern, but rather than info, its default is warning, and it does not include the confirmation subclass. Setting info, approved, or error will set the corresponding icon. The info subclass should be used when the confirmation dialog is being used to gather additional information, as in the second example.

Pills are used for non-interactive tags, most often in tables or lists. They should be used only to indicate an item’s membership in a particular class, or a status from an enumerable list (e.g., showing that an item is verified or not).

This component is used to display the logo of another company or organization to show affiliations, certifications, or company partners.

Logos should either all be Blue 5 or their appropriate brand colors. Never present a mix of logos where some are in Blue 5 and others use their own brand colors.

Wherever possible, use SVG’s to preserve quality and scalability.

This component presents a media player for any videos used on the site. Video should be placed inside a container. Never play a video full screen. Use a video placeholder image for the placeholder.

For videos on YouTube, use the youtube class and link to the video using the form https://youtu.be/VIDEO_ID

For videos on Vimeo, use the vimeo class and link to the video using the form https://vimeo.com/VIDEO_ID

A determinate progress indicator is a visual representations of how far a process has progressed. A <progress> tag is determinate if it has max and value attributes, indicating how much progress has been made (value) and what the total will be when the process is complete (max). Use determinate progress trackers when the process completion can be detected. Determine progress trackers fill from 0% to 100% (left to right).

An indeterminate progress indicator is used when the progress of the process is unknown. Use indeterminate progress trackers when the progress isn’t detectable, or if it’s not necessary to indicate how long an activity will take.

The process step component is a visual representation of a user’s progress through a set of steps. They guide the user through several different steps in order to complete a specified process.

Always use some type of process tracker when a user is completing a complex task with multiple steps. Breaking down the entire process into smaller steps keeps the user focused, organized, and more inclined to complete the task. Break up the process into distinct steps that are each roughly equal in difficulty. Provide feedback when the user has completed each of the tasks. Allow for recovery if a user made an error on a previous step and wants to move back a step.

This component lays out navigation vertically on the left-side of a page. This is typically used with anchor tags or sub-pages of a micro-site.

Keep titles less than three words to fit nicely in the sidebar column. Use descriptive titles so the user never guesses where the menu item will take them. Use the current class to indicate the current page if the sidebar navigates to different sub-pages. Always use in a .col4 column.

Tabs are used to quickly navigate between views within the same context.

Tab labels should concisely describe the content in the tab view (generally just one word). If you do require more than one word, use sentence case.

Never use more than 6 tabs. More than 6 tabs will clutter the UI and make the labels unreadable. If you need 6 tabs, consider using a different component or pattern to display the content.

Breadcrumbs enable users to quickly see their location within a path of navigation and move up to a parent level if desired.

Place breadcrumbs in the upper-right corner, below the header and before the main headline of the page. Every tier of the breadcrumb except the current page should be a navigable link to that level. You can use one tier breadcrumbs to act as back buttons for the user.

Breadcrumbs should never replace the main navigation of a site.

Pagination is used for splitting up content or data into several pages, with a control for navigating to the next or previous page.

Use pagination when the user’s goal is not to browse a full collection, but rather to find a specific item and click through to that destination page. Include buttons to allow the user to click through to different pages, as well as the ability to click to a specific page. Indicate clearly where the user is in the list of pages, as well as how many pages are included in the entire list.

A checkbox is a small square that has a checkmark when selected. Use checkboxes when a user can select one or multiple options from a list. A stand-alone checkbox is used for a single option, such as turning something on or off. Avoid using negations for checkbox labels that could confuse the user about what will happen if they check a particular box.

Use the inline version only when the number of options is limited and the labels on each option is short.

Checkboxes should never be checked by default.

A radio button is a small circle that has a solid circle inside when it is selected. Use radio buttons when there is a list of two or more options that are mutually exclusive. Left align radio buttons vertically so a user can easily determine what label belongs to what radio button.

This component is used on the user dashboard to display information or provides a specific way for the user to interact with the CMMI Website. Dashboard widgets are built from a user need for a shortcut while interacting with our site. They are white cards and may include links to different parts or pages of the site.

This component provides layout for an image and accompanying text. Use it on marketing or static pages. Images should always occur to the left of the text. Use engaging visuals that enhance the text. Images should never distract from the text. All images must have descriptive alt text; if you have a hard time coming up with a good description for this purpose, that is usually a warning that the image is also failing to enhance the text.

Use the revealable component when incorporating progressive disclosure in a design. The component only shows a segment of information and forces a user to make the decision to show more. Critical information should never be hidden in a revealable component.

Use the togglable interaction component to remove clutter from a UI list.

A togglable-content element must follow each togglable-toggle element for it to work. Only the next togglable-content element will be affected, so you may need to use a wrapper element like a <div>, but as always tags with more semantic value should be preferred.

Add the default-open class to the togglable-content element to leave it open by default.

Use text input to collect a single line of text from a user. Use type="text" as a default, but more specific types should be used wherever possible, as on some browsers and devices these may provide the user with helpful context-specific options.

Text inputs should always be accompanied by a label. Use placeholder text to provide an example of the sort of data requested. Placeholder text must never replace the label.

When any text input is in an error state, you should provide a clear and concise error message. Error messages should focus on what the user needs to do to fix the problem, and not necessarily on the technical details of what caused it.

To display a text field in an error state, apply the error class to the label and the input. The error message should appear in a <p class="error"> tag following the input.

This input helps make it clear to a user that she is expected to enter a URL.

Use text areas to collect more than a single line of text from a user.

Text inputs should always be accompanied by a label. Use placeholder text to provide an example of the sort of data requested. Placeholder text must never replace the label.

If the number of characters that a user can use in a text area is limited, add a span class="char-limit"> tag specifying that limit. If you supply a data-limit attribute, JavaScript will enhance the component to supply instantaneous feedback.

The dates and times input allows users to interact with and input date and time data. Use labels to differentiate between start and end dates.

Number inputs contain controls used to increase or decrease an integer value. Use this type of input when a user is adding or removing items, for example when a user is reviewing the items in their cart. Number inputs work best for making small, incremental changes that only require a few clicks. Always use a clear label with this input.

Search enables users to specify a word or phrase to find particular relevant pieces of content without the use of navigation. Use placeholder content text within a search field to help users understand what page or section the search box will parse through.

Indicate what results are being displayed with labels or headers, such as “Results for [user input]” Be sure to also include a clear “no results” message

The file input allows a user to transfer a file or submit content of their own. To allow a user to upload more than one file, include the multiple attribute, as in the example provided here. To restrict a user to just one file, remove that attribute. If the types of files accepted are restricted, for example to just certain types or if they must be no larger than a particular size, add a helpful label to make sure the user is aware of these restrictions.

This is an input that allows a user to choose one option from a dropdown list. It can be used in forms or standalone as a navigational component (as it is at the top of this page). Use a descriptive label to inform the user what options are in the select. Provide a reasonable default setting for the select input wherever possible. If the user is only selecting from three or fewer options, use the checkbox or tab select components.

When JavaScript loads, <select> tags with the multiple attribute behave as you see here. Selecting an option adds a “tag,” which can be removed from the list.

Use this component when the user must choose among several options, the options are short and concise, and the user can choose more than one. If the options require more detailed explanation, use checkboxes.

The tag select component is an input that lets a user select an option from a list of tags. It works like radio buttons: all options are mutually exclusive. The system should respond when a user selects an option. Selected tags have an appearance similar to a button. Non-selected tags have an appearance similar to a secondary button.

Align the tags horizontally. If there are too many tags that they require a second line, use the radio button component instead.

A table presents information, numerical or textual, in a readable, scannable, and easily comparable manner. The header uses a Gray 5 background and white text. Our tables do not use zebra stripes.

The .actions class can be used on any table cell that provides a button set for a particular row. As with other button sets, this should include one button that is the intended action. Any other buttons should be marked as secondary by using the .p2 class.

If you can click on a table header to sort the values in that column, you can add the sortable class to that header (<th class="sortable" />) and wrap its content in either a <a> tag or a <span>. Sorting in descending order is the default. If you are sorting in ascending order, also use the asc class (<th class="sortable asc" />).

Since the exact criteria for sorting may differ from one implementation to the next, it is the responsibility of the behavior layer to handle the actual sorting and then update the classes applied in the markup appropriately. The behavior layer might be server-side code or JavaScript, for example. Depending on your implementation, you might use JavaScript or an <a> tag to make a column header clickable.

The responsive table presents each row like a card when there is insufficient horizontal space to lay out a table. Always use a responsive table if there is a chance a user will be viewing it on any other device than a desktop.

This component is styled as a table that allows a user to interact with and edit data. Use an editable table when a user needs to change inline data. Each row has a submit button to save changes, and may include a link to remove that row.

This component relies on one script which can process changes to data given a POST request. If you want to remove a line, you will need another script which can remove it with a GET request. Both use optimistic feedback, assuming that everything works appropriately and showing an error if anything unexpected happens.

data-warning-id defines the 0-based index of the field to use to identify a row in a warning message. In the example provided here, it is 0, indicating the first field in each row — the name. If not provided, this will default to 0, meaning the first field in each row.

Tags indicate association and related information. They can be clickable or static. They can be used to filter or find certain information based on the keyword that describes them. Multiple or single tags can be used to categorize items.

By default, the tags pattern assumes a white background. When placed against a gray background, use the class on-gray, which will set the tag background to white instead (as shown in the example above).

Labels inform users what the corresponding input fields mean. Labels are left aligned and placed directly above the input field.

A red asterisk placed after the label is used to inform what fields are required of the user to complete the form.

Notes can be added directly below the label and before the input field. They should be succinct but clear.

This component upports the action of adding or removing data items from a shown data set by turning on and off certain predefined criteria. We use multi-select filters that incorporate a checkbox functionality. Similar filters are grouped in categories with a category heading separating the different categories in a filter list. We use an interactive filter that applies the filter changes to the data set as soon as a user clicks a checkbox.

This component adds a scrolling interaction that jumps smoothly down a page or back up a page that doesn’t create a jarring experience for the user. Use this component when a user is navigating quickly to a different section of a page.

Adding the return-to-top class to the <body> tag (if it also has the cmmi-patterns class) adds a shortcut for users to quickly get back to the top of the page. Many of our pages use a single-column, long page design. These pages require the user to scroll a lot down and back to the top of the page. The button appears in the bottom right corner of the screen when the user has scrolled at least 1000px down and is using a device wide enough to use full layout.