diff --git a/packages/website/docs/patterns/beta_badges.png b/packages/website/docs/patterns/beta_badges.png new file mode 100644 index 00000000000..feff98cc65a Binary files /dev/null and b/packages/website/docs/patterns/beta_badges.png differ diff --git a/packages/website/docs/patterns/confirmation_prompts.mdx b/packages/website/docs/patterns/confirmation_prompts.mdx new file mode 100644 index 00000000000..0cd0888283a --- /dev/null +++ b/packages/website/docs/patterns/confirmation_prompts.mdx @@ -0,0 +1,44 @@ +--- +id: patterns_confirmation_prompts +slug: /patterns/confirmation-prompts +--- + +# Confirmation prompts + +Add safeguards that catch the user's attention before validating an action. + +## Confirming an action +Use a [Modal](../02_components/layout/modal/overview.mdx#confirm-modal) when you need to interrupt a user and ask them to confirm an action. + + + +**Structure** +1. **Title** _mandatory_ + - Whenever possible, frame it as a question that provides context for the action. Don't use "Are you sure?" + - Focus the question on what's important to the user and in a way that assumes intent from them. For example `Discard 7 changes?` instead of `Exit without saving?` + - Avoid including text variables in the title, especially for things users can input without character limits, or with long limits. This is often the case with object labels. + For example, `Apply configuration changes?` instead of `Apply configuration changes to Loremipsum-dolorsitamet-consectetur-adipiscing-elit deployment?` +2. **Body** _mandatory_ + 1. **Cause** _optional_ + - If the context is important to know, add it. + 2. **Consequences** _mandatory_ + - Let users know what happens if they continue. + - If possible, list the objects that may be impacted. + - Don't repeat the title. + 3. More information optional + - If necessary, anticipate user questions or need for help by including a link to a relevant source of information (like docs). +3. **Calls to action** _mandatory_ + - The main action confirms the question asked in the title. + - If there's enough space and it is relevant, include the number of impacted objects and their noun. For example `Invite 3 users` instead of `Send invite`. + - Always provide a secondary CTA that allows users to leave the prompt without taking an action. + - Not all choices are binary. Add a third CTA when it makes sense for common that actions users would want to do. + - Make sure each CTA is explicit and not ambiguous with the other CTAs next to it. + +## Confirming a destructive action +Asking to confirm a delete or remove action follows the same principles as the default pattern, with 2 additions: + +- The main CTA is extra clear on what is about to be deleted with a clear noun, in addition to visual clues (`color.danger` token). +- The body is unambiguous about what won’t be recoverable after the action is confirmed. +- Optionally, and depending on the importance of the destructive action, you may include an extra confirmation within the **body** of the modal. If you do so, use something generic, such as "delete" or that users can copy easily that will remind them of what they are actually deleting. + + diff --git a/packages/website/docs/patterns/help_content.mdx b/packages/website/docs/patterns/help_content.mdx index badd22c8b5f..1745a2faa0c 100644 --- a/packages/website/docs/patterns/help_content.mdx +++ b/packages/website/docs/patterns/help_content.mdx @@ -23,7 +23,7 @@ Defining terms is particularly useful in onboarding experiences or in the first **Interaction** - Question mark icon with the `primary` color directly following the term to explain. -- On hover, a [tooltip](https://eui.elastic.co/#/display/tooltip) appears. +- On hover, a [tooltip](../02_components/display/tooltip/overview.mdx) appears. - Use it anywhere needed: navigation, titles, or inline. **Tooltip content** @@ -48,7 +48,7 @@ Concepts are more than quick definitions. They help users understand how somethi **Interaction** - Information icon with the `primary` color directly following the setting to explain. -- On click, a [popover](https://eui.elastic.co/#/layout/popover) appears. It is dismissed by a second click outside of the popover area. +- On click, a [popover](../02_components/layout/popover/overview.mdx) appears. It is dismissed by a second click outside of the popover area. **Popover content** - Header _required_ @@ -73,7 +73,7 @@ _Note: the formatting of the flyout here is just an example._ **Interaction** -- Use a [Flyout](https://eui.elastic.co/#/layout/flyout), in `push` mode if possible, as overlays can be disruptive. +- Use a [Flyout](../02_components/layout/flyout/overview.mdx), in `push` mode if possible, as overlays can be disruptive. - Locate the interaction to open the flyout somewhere visible and that matches with the context of the content: - If that is for an entire app, use the help button from the header - If that is for a significant section or area of the UI, use an explicit link near the top of the area or section or a button. @@ -81,9 +81,9 @@ _Note: the formatting of the flyout here is just an example._ **Flyout content** - Header - - Action-oriented title - - Sentence case - - No punctuation + - Action-oriented title. + - Sentence case. + - No punctuation. - Body - Structure content to help users scan. - Keep it short, it doesn't have to be the fully-detailed documentation. Keep the most important to keep it readable. @@ -129,7 +129,7 @@ Providing reference docs directly in the product can help users stay focused on **Interaction** - Use the icon with the `primary` color to indicate a reference. When possible, add an explicit link text. - Locate the interaction for opening the reference right next to or under the field, depending on the UI layout. -- On click, a [Flyout](https://eui.elastic.co/#/layout/flyout) in `push` mode or a [popover](https://eui.elastic.co/#/layout/popover) opens. +- On click, a [Flyout](../02_components/layout/flyout/overview.mdx) in `push` mode or a [popover](../02_components/layout/popover/overview.mdx) opens. - For popovers, clicking outside closes the help. - For flyouts, add an explicit Close button to the footer. @@ -154,7 +154,7 @@ Elastic visualizations often show acronyms or depths of details that require leg **Interaction** - Use an explicit text link with the icon with the `primary` color to indicate a list of definitions. - This link must be within the context of what it applies to, generally near the upper right corner of the visualization or UI section. -- On click, a [popover](https://eui.elastic.co/#/layout/popover) appears. +- On click, a [popover](../02_components/layout/popover/overview.mdx) appears. **Legend content** - Header diff --git a/packages/website/docs/patterns/pre_ga_badges.mdx b/packages/website/docs/patterns/pre_ga_badges.mdx new file mode 100644 index 00000000000..8ba5a3b57db --- /dev/null +++ b/packages/website/docs/patterns/pre_ga_badges.mdx @@ -0,0 +1,31 @@ +--- +id: patterns_pre_ga_badges +slug: /patterns/pre-ga-badges +--- + +# Pre-GA badges + +Using badges in the interface allows to indicate upcoming features and product innovations available for testing and to set user expectations about the maturity, (non-)support, and stability of a feature. + + + +## Choosing between designations + +When a feature becomes available for users before being officially Generally Available (GA), it is marked using a badge. A badge can have a default and a short form (with a simple icon). With both forms, a tooltip text explains what this means for the feature to help users get the correct expectations. + +Features don't necessarily go through each stage defined in this document. For example, it can start with Beta, or it can start with Technical preview and be announced as GA next. + +Such badges rely on the [Beta badge EUI component](../02_components/display/badge/overview.mdx#beta-badge-type). + +| Stage | Technical preview | Beta | GA | +| ---- | ---- | ---- | ---- | +| Description | Experimental features that may not be kept or that may change fundamentally. | Features nearing GA that are not expected to fundamentally change for GA. | Features that are officially supported for production usage. | +| Default label | `TECHNICAL PREVIEW` | `BETA` | N/A | +| Short label
_For navigation and contextual menus_| | | N/A | +| Tooltip | `This functionality is experimental and not supported. It may change or be removed at any time.` | `This functionality is still under development and not ready for production usage.`| N/A | +| User expectations and perception | Unstable. For testing an innovation. Bugs and breaking changes are perceived as normal. | Fairly stable. For evaluating or testing an awaited feature. The feature is **almost** ready. There might be some bugs and UX/API refinements. | Production-ready. The feature is ready for production workloads. | + + + + +