Button

The when, how, and why to use buttons.

Buttons should be used in situations where users might need to:

• Submit a form
• Begin a new task
• Trigger a new UI element to appear on the page
• Specify a new or next step in a process

Using the design system Button Component will ensure your button looks like a button and is in line with HPE designs. Ensure to apply an appropriate label so the user has a clear understanding of what action to expect.

• Use clear and concise wording.
• Avoid contractions or colloquialisms. Keep the language approachable but not personal, for examples, see point of view.
• Ensure your button label matches the route destination.

Buttons are unique components since their alignment depends on where they appear (drawers, modals, etc.). Buttons should always be where the user most expects it. In general, follow this guide on how to align buttons in most use cases.

Button types may be applied in various combinations, however they should always be ordered by order of importance and in relation to their alignment: Primary first, followed by Secondary, then by Default.

The HTML elements for buttons and links (a.k.a. anchors) describe a very specific type of action that is going to be taken when they are used. It is important you know when to use which, as the distinction matters:

• Use a link when you’re navigating to another place, such as: a "view all" page, "Jane Chen" profile, a page "skip link" etc.
• Use buttons when you are performing an action, such as: "submit," "merge," "create new," "upload," etc.
• An action almost always occurs on the same page

Cancel buttons enable users to exit out of or dismiss the current screen in order to go back to the previous one. Having an explicit way to cancel provides a fallback to safety as it helps discard any unwanted changes.

Cancel buttons should be presented in the default button styling. The neutral appearance signifies the non-committal action. Visually emphasizing the cancel button should be avoided to minimize user confusion.

Toggle buttons are used either to switch between two states, such as checked and unchecked, or to trigger two actions like on or off.

Icon buttons have an a11yTitle, aria-label or button label that describes the action that the user will be performing when using screen readers.

Best Practices:

• Limit to 2-3 descriptive words.
• Use verbs first to describe the action such as "Hide/View," "Switch/Unswitch," "Favorite/Unfavorite," "Light/Dark," or "Like/Dislike."
• Use sentence case capitalization.
• Words such as "the" and "a" should be avoided.

For buttons with icons ONLY, it is important that you show the two following elements:

1. Show the current state of the button through the use of an icon.

2. Inform the user of what will happen when the button is clicked by including a11yTitle or aria-label.

If pressing a Button results in a new URL, or the resultant UI makes sense as "a new browser tab," that is a link <a>. Everything else is a <button>.

The distinction is important to screen reader users to know what's going to happen next. Will I navigate somewhere or will something happen on the page? So it's important to choose the right HTML element for the job.

Primary buttons highlight actions on a page delivering the most benefit to users. They are helpful in enabling users’ goals, unlocking new value by enabling a new experience, capability, or creation of something which hadn’t previously existed.

Primary buttons have increased visual weight through placement and contrast, drawing users’ attention by distinguishing the button from surrounding content. At HPE there are two kinds of primary buttons, a CTA button and a primary action button. Learn more about the purpose behind each and when to apply them.

Call to action (CTA) buttons entice a user down a curated path leading to incremental value. A primary call to action is meant to encourage the most desired action you want visitors to take, leading prospects and customers towards conversion, whether that be to learn more, register, test drive and even buy a product.

Specifically, CTA buttons should be used when a prospective or current HPE customer will gain value from HPE's edge-to-cloud promise. This occurs in marketing contexts such as:

• Within .com experiences such as highlighting an event or allowing a user to launch an HPE application.
• Within enterprise application where a service, feature, trial opportunity, or event is being promoted.

Because a CTA button is very visually prominent:

• Only use one CTA button per context to highlight the main action.
• Generally, there should only be a single CTA button for a page region. However, this is not a firm rule and should be handled on a case-by-case basis.
  • For example, it may be appropriate for multiple cards within a single region to each have their own CTA button.

If there is not a need to highlight an action, it is appropriate to use other controls.

• For example, enabling a new feature could be presented on a dashboard with a CTA button but it also could be presented in a menu or as a toggle in a settings page. This decision is to be determined by the designer based on the use case.

If you have questions about your use case, feel free to reach out in the #hpe-design-system channel on Grommet Slack.

Primary action buttons are used within enterprise applications. They are meant to assist - as opposed to CTA buttons, which intend to entice - and are designed to maximize a user’s experience by highlighting the most common or important action on a page and allowing the user to accomplish a goal or task.

Actions supported by primary action buttons are numerous and may be constructive or destructive in nature. Example actions include: create, schedule, deploy, add, save, and depending on context could even be cancel or delete.

There are a couple "flavors" of button depending on use case.

Used for key actions on the page. Primary buttons can also be referred to as “Brand” or “CTA (Call to Action)” and should only be used once per page. All other supporting actions should use Default button. Consider that the 80% use case for some pages is visualization and not action. In cases like these, a call to action is inappropriate and a secondary button can be used.

Secondary buttons are used to represent calls to action that are either in support of the primary call to action or stand-alone. There can be multiple secondary buttons per page. However, a default button should be used for any navigation-type actions.

CTA buttons should be used whenever a prospect or customer is unlocking new value from HPE’s edge-to-cloud promise. Read when to use a CTA button for detailed guidance on usage.

Toolbar buttons are used when buttons are placed in a row with other toolbar controls.

A common use case would be when creating a filtering experience. In this situation, a search input, filter button, and action menu are presented as a unified set of controls. The intent is to present each control with equal prominence.

To implement, apply kind="toolbar" to Button or Button-based components like Menu.

This is the default appreance and behavior of button. The majority of buttons on your page should use this form of button. If you are designating a primary call to action, use a primary button. If you are designating a secondary call to action, use a secondary button.

When looking to accent an interaction or for special use cases that require more importance than a default button, the color button can be used to support an HPE sub-brand when appropriate or a serious action (i.e. using red for a destructive task).

Icons may be incorporated into buttons, either inline with text or as an icon only. When using icon only buttons, the dimension of the clickable area should be kept in mind for its use on mobile devices. Areas too small lead to errant clicks, and as result, poor experience.

A button's visual state may be specified as appropriate in the application's context. For example, using "active" for the current item or "disabled" until a set of criteria are met. However, use of disabled controls is discouraged because it tends to elicit a "why?" response from users. It is better to leave buttons active and use messaging upon click to indicate that criteria have not been met. Buttons that do not apply (for reasons of context or permissions) should not be shown at all, rather than being shown as disabled.

Button label text size may be specified. Padding and rounding scale proportionately to the label size. The default size is medium.

Ensure you are always being mindful of our responsive page layouts when designing user experiences. Even if you don’t anticipate your users leveraging mobile or tablet devices, they may be reducing/expanding browser widths, zooming in on content, or manipulating the browser in unanticipated ways. As a best practice, always design for a usable UI on all browser widths and resolutions.

• Ensure the button label does not wrap, truncate, or alter the text content in any way when presented on smaller browser widths.
• Button label text should not scale down to fit on smaller browser widths.
• The minimum button width for any button should be 42px.

On screen widths of less than or equal to 576px (Grommet "small"), it is best to have buttons fill the full width of the container. Because press target size and an unclear visual hierarchy are key concerns at smaller resolutions, this utilizes available space to ensure users can easily identify and interact with the buttons.

For button groups on screen widths less than or equal to 576px (Grommet "small"), ensure each button within the group follows the established guidance for single buttons. If a button group is presented inline horizontally, rearrange the buttons vertically on smaller browser widths to ensure the proper full button widths can be achieved.