Labels should be used to indicate status of an object or to deliver contextual information that is secondary in relation to a primary piece of content (for example, showing that an exception is tracked or that a project is on hold).
When using a label to convey a message to the user, ensure that the label is consistently applied: If 'On hold' uses a warning label in one part of the platform, it should do so elsewhere.
Use the default label style unless a specifically positive or negative connotation is desired. Labels should always be displayed using a consistent size.

Badges are used to indicate counts of to-do items, available results, and so on. Generally these shouldn't take precedence over the navigation elements they usually sit next to - only use the emphasis classes to draw the user's eye in special cases (like a new or overdue item).

When a user triggers an action, they should see a confirmation of their action. Alerts are the most frequent type of confirmation feedback, and should be used whenever a form is submitted or whenever an object is added, removed, moved, etc. Alerts will appear in a fixed position at the top right of the screen. The proper ‘level’ of the notification should be based on its content.

Callouts should be used to draw a user's attention to a specific section of the page. These should be used sparingly, generally no more than one per page. Don't use these as decorative elements.
Callouts are used to indicate announcements and messages from Lumere to the user. They are preferred to wells for this purpose. Don't use them for error or success messages.
Also used for the product facts box and people results within search.
Titles are optional.
An icon may be added to the left side of the callout for additional emphasis.

Cards are a standard interaction pattern for the display and inline editing of data within the solution. The following standards should be applied when creating them:

• If using a card, apply standard card styling. If making an editable section, ensure that the editable content within is clearly delineated visually on the page.
• Place the 'Edit' button in the top right. When clicked, this should toggle edit mode (clicking while edit mode is active is equivalent to clicking the cancel link). The Edit button should not disappear when edit mode is active.
• Standard 'Save or cancel' controls should be placed in a well at the bottom of the editable card/section.
• To the extent possible, maintain the placement of labels, data, and controls between the edit and view modes.
• If an object can be deleted, deletion should occur via a 'Delete this (object)' checkbox that appears when edit mode is active.
  • When the delete checkbox is toggled to on, the 'Save' buton's text should change to read 'Delete (object)' and it should receive a button-danger class.
• Save and delete actions within an editable section should only affect the data present in that card/section, not other data on the page.

Ribbons are used to summarize metrics and key performance indicators at the top of a page and are intended to provide a high-level overview of the detailed information below.

• Individual metrics within a ribbon can be links to more detail, but this shouldn't be a primary navigation mechanism.

When displaying currency in a ribbon, always use our standard decimal and abbreviation conventions:

• $0–$9.99 : Display using 2 decimal places
• $10–$99,999 : Display whole number using zero decimals
• $100,000–$999,999 : Display as K value with zero decimals, ie. 112K
• $1,000,000 and up : Display as M value with two decimals, ie. $1.52M

Tables are used extensively throughout our application. In many cases, they may serve as a syntactically appropriate structure for elements that contain table-like data: for example, the product facts box used in product profiles. This section does not cover those special cases—it only addresses the typical ‘Table with a capital T’ elements found in the solution.

• Tables should have the .table class applied.
• Also apply the .table-striped class unless the design specifies otherwise.
• It is best to create a table initially using fully automatic layout (no preset column widths).
• Non-paginated tables should be given a fixed height
• When column width adjustments are necessary, adjust one column at a time. Always apply widths using percentages, not pixels.
• Don’t add additional columns just to constrain adjacent elements (for example, product photo and product name). Use markup inside the cell to accomplish that instead.
• When filters apply to a table, the filters should act as a header for the table and contain the table within a common element. See Filters.
• When buttons are used within a table, add the .btn-sm class to the button so that its size is proportionate with the rest of the type in the table.

Tooltips are the most basic 'popup' component and should be used for displaying additional contextual information when only a small amount of information is needed.

• Tooltips cannot contain styled/formatted content or interaction. If either are needed, use a popover instead.
• Tooltip content should be limited in length, preferably no more than a sentence.
• Top positioning is preferred and should be considered the default.
• The data-toggle="tooltip" attribute is what applies the tooltip, from ph.js

Non standard placements

• Should be used sparingly, the top placement is the default

Popovers are more robust than tooltips, but smaller and less obtrusive than modals, and should be preferred to modals when the user is editing a small number of data elements or when formatted contextual information needs to be displayed.

• Popovers can contain editing controls, whereas tooltips can't.
• Popovers, unlike modals, do not use a transparent overlay that covers the screen background.
• A popover's location should be relative to the data being modified, but should not cover that data if possible. Top positioning is preferred and should be considered the default.
• Popovers do not require a title.
• Clicking anywhere outside of a popover should close it, as if the 'Cancel' link had been clicked.
• Don't use a popover for an 'Are you sure?' message - use a modal in that situation instead.
• Popovers should float over the side nav but under the top nav.

Modal windows, if used inappropriately, can be a usability hindrance, but in the appropriate circumstances they can aid the user’s efficiency by allowing focused interaction without disrupting their primary workflow.

• Don’t use modals for multi-step workflows.
• If there’s information displayed on the page (or present elsewhere) that the user needs to help them complete the task, make sure it’s also included in the modal. Don’t rely on the user’s recall regarding information they were presented before.
• Modals should always include a close icon and should be closable by clicking into the shaded area outside of the modal itself.
• If a user has entered data into a text input or text area, show an unsaved changes warning before closing the modal in this fashion.
• Avoid making modals scroll by constraining their height to ~700px. If more space is needed, consider whether a modal is right for the job.
• Modals should be centered horizontally and positioned 30px from the top edge of the viewport.
• If the modal has to load content from elsewhere, make sure the ‘wait’ interaction is triggered.

• Use the most appropriately sized image as required by the design: the original image resolution should match the CSS-enforced resolution as closely as possible.
• Use the thumbnail_url template tag to return an appropriately-sized image:
  • thumbnail_url: "small" (150x150px)
  • thumbnail_url: "medium" (270x270px)
  • thumbnail_url: "large" (up to 800x800px depending on original file)
• If scaling is required, always prefer to scale down rather than up.
• In some cases a 2x resolution image may be desired for additional quality on HiDPI devices.
• When an image is displayed in a square frame (as in a product image), it should be scaled proportionally to fit the longest dimension, never stretched.

Showing an image in tandem with a product and brand name is far and away the most common use of images in our solution. The product image/name/brand combination forms a discrete module that should always be displayed the same way.

• The product image and name should always be links to the product profile.
• Product images should always be square and be displayed with a border.
• Brand name / Manufacturer name (if present) should always display as small muted text.
• If the product and/or brand name
• Hovering over the product image or name should always trigger the universal product popover.
• Exception: if a product is displayed within a modal, the link can optionally be removed. The product popover should never be displayed over a modal.
• When products appear in this format, they may appear next to products that don't have an image. In this case, the products without images should be left-aligned with the images- there shuldn't be empty space where the image would otherwise appear.
• If notification exists for the product, it should be using a bell icon that displays the notification in a tooltip when hovered.

Non-photographic images such as logos and custom icons should be served as SVG files whenever possible. Because certain legacy browsers do not render SVG files properly, a PNG fallback is necessary. Therefore, vector images should be deployed using the following method:

<img src="logo.png" srcset="logo.svg">

This will ensure that browsers supporting srcset will display the SVG file, whereas those that will not will display the PNG.