# Progressive disclosure

## Progressive Disclosure in Forms

Forms vary from simple layouts with few inputs to complex structures with many components. **Progressive disclosure helps manage this complexity without overwhelming the user.** This approach involves a strategic use of design elements to enhance efficiency and understanding.

### **Structuring Information in panels**

Start by organizing related fields into [panels](https://design.mirakl.com/design/components/structure/panel) or using panel separators.&#x20;

This groups related information together, making it easier to understand and follow. Panels not only help in organizing the form but also make it visually appealing and guide users through the information logically.

Before adding a new panel, consider whether new fields can be accommodated within existing panels.

<figure><img src="https://1297765105-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FMoZPkWOmnKvoMWGW4aeM%2Fuploads%2Fqij5wYeL2Wm5mCeekFgH%2Fpanels.svg?alt=media&#x26;token=41aa74aa-72a4-4d61-87ea-a87013270a8f" alt=""><figcaption><p>Example of the use of panels in a form that guides users</p></figcaption></figure>

### **Dependency Dynamics**

#### **Enabling and Disabling Fields**&#x20;

Some forms have fields that depend on each other; the selection in one field can enable or disable another. Clearly show these dependencies using tooltips that appear when users hover over a disabled field. This helps users understand why some options are not available.

<figure><img src="https://1297765105-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FMoZPkWOmnKvoMWGW4aeM%2Fuploads%2FvHIf8Tp8OgpLsRWyBejd%2Fdisable.svg?alt=media&#x26;token=d93337a7-fbf5-4c25-a6d3-79f92aaa8e61" alt=""><figcaption><p>Example of the use of disable fields in a form that guides users</p></figcaption></figure>

#### **Enable vs. hide**

* **If a control is not applicable until a choice is made**, hide it at first and reveal it when the triggering choice is selected.
  * Rationale: avoids noise when the user cannot act yet.
* **If the user needs awareness** that a control exists but is currently unavailable, show it disabled.
  * Rationale: sets expectations and communicates capability, even if it’s not yet actionable.
* **If the dependent control is critical to task completion**, prefer revealing it (enabled) immediately after the trigger is satisfied, keeping focus in context.

{% hint style="info" %}
**Accessibility note**: hidden content must not be reachable by keyboard or screen readers; disabled controls are perceivable but not focusable in many UAs, so provide an accessible explanation (see next section).<br>
{% endhint %}

#### Using SubContentWrapper for Nested Dependencies

Progressive disclosure can reveal content in two fundamentally different ways: **peer-level conditional visibility** or **hierarchical nested content**. Understanding this distinction is critical to choosing the right pattern.

**Peer or Child?**

{% hint style="success" %}
Before revealing content, ask: **"Is the revealed content a peer requirement OR a sub-element of the trigger?"**
{% endhint %}

| Scenario                             | Relationship                    | Pattern                         | Visual treatment                            |
| ------------------------------------ | ------------------------------- | ------------------------------- | ------------------------------------------- |
| "Enable notifications" → Email field | **Peer** (separate requirement) | Standard progressive disclosure | No wrapper, field appears at same level     |
| "Custom shipping" → Carrier options  | **Child** (sub-configuration)   | SubContentWrapper               | Indented with vertical bar, nested visually |

#### **Standard Progressive Disclosure (NO SubContentWrapper)**

**Use when:** Revealed content is a **peer-level requirement** that depends on a choice but is not a sub-element of that choice.**Visual behavior:** Content appears at the same indentation level, no visual nesting.**Example scenarios:**

* ☑ Enable email notifications → \[Email address field appears]
* ☑ Apply discount code → \[Code input field appears]
* ☑ Subscribe to updates → \[Frequency selector appears]

{% hint style="info" %}
**Why no wrapper?** The email field, discount code, and frequency selector are **separate pieces of information** that happen to be required based on a choice. They are not configurations *of* the checkbox—they are peer-level form fields.
{% endhint %}

#### SubContentWrapper (WITH visual nesting)

**Use when:** Revealed content is a **child element or sub-configuration** that belongs structurally to the trigger.**Visual behavior:** Content appears indented with a vertical bar, creating clear parent → child hierarchy.**Example scenarios:**

* ◉ Custom shipping → **\[SubContentWrapper]** Carrier selection, rates, delivery options
* ◉ Enable advanced pricing → **\[SubContentWrapper]** Tier configuration, bulk discounts, rules
* ◉ Payment method: Credit card → **\[SubContentWrapper]** Card details form, billing address

{% hint style="info" %}
**Why use wrapper?** The revealed content is not just "required if you check this"—it's **part of** the thing you're configuring. Carrier options are *sub-options of* custom shipping. Card details are *the configuration of* the credit card payment method.
{% endhint %}

### Stepper forms

For long or complex forms, consider using steppers. Steppers break the form into smaller, manageable steps, helping to reduce cognitive load. They are particularly useful when user choices affect subsequent options. Steppers ensure that the user remains focused on one task at a time, adapting fields based on previous selections.

<figure><img src="https://1297765105-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FMoZPkWOmnKvoMWGW4aeM%2Fuploads%2FwIPXsFXNyGnTS1btvPQg%2Fstepper.svg?alt=media&#x26;token=9914fd04-145a-4304-86d7-49070b5e4d4c" alt=""><figcaption><p>Example of the use of stepper form that guides users</p></figcaption></figure>

#### **Considerations for Stepper Implementation**&#x20;

When considering a stepper, weigh its pros and cons :

#### Pros of Using Stepper Forms

* **Guides Users Through Complex Forms**: Steppers are excellent for navigating users step-by-step through complex object creation, reducing cognitive load and ensuring focus.
* **Adaptive Fields Based on User Choices**: They can dynamically adapt fields and options based on user selections in previous steps.

#### Cons of Using Stepper Forms

* **Not Ideal for Viewing and Editing**: Once an object is created using a stepper, viewing or editing it through the same stepper can be cumbersome. It's more effective to use a single-page form for these actions.
* **Requires Design of Multiple Interfaces**: Implementing steppers necessitates designing both the multi-step creation process and a complementary single-page interface for subsequent viewing and editing.

<figure><img src="https://1297765105-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FMoZPkWOmnKvoMWGW4aeM%2Fuploads%2Fim34aCYUvzDyhWdfnQUg%2Fretranscription.svg?alt=media&#x26;token=0184859a-1d65-419f-981d-f7200cdf9b55" alt=""><figcaption><p>A single page of an object created through a stepper, allowing users to have a full picture of the object without having to go through the whole stepper</p></figcaption></figure>

## Applying Progressive Disclosure Beyond Forms

{% hint style="info" %}
We can apply Progressive Disclosure principles when activating options using an Activable Panel. [Learn more about Activating Options](https://design.mirakl.com/design/patterns/configure-options).
{% endhint %}

### Expendable Panels

Use panels that expand when clicked, revealing more information. This method keeps pages clear and simple, revealing more content only when needed.

<figure><img src="https://1297765105-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FMoZPkWOmnKvoMWGW4aeM%2Fuploads%2F5harIkFItCdkw5UkbVGY%2Fexpand.svg?alt=media&#x26;token=99fb723e-b2f5-4f7b-9418-7d4e50baf05a" alt=""><figcaption><p>Exemple of how exepandable panels allow to reduce cognitive load</p></figcaption></figure>

### Side Drawer overlay

A side drawer can show additional details without overcrowding the main page. It's useful for examining supplementary information without leaving the current page.

<figure><img src="https://1297765105-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FMoZPkWOmnKvoMWGW4aeM%2Fuploads%2FiHhbS0o9JG9l15SUtFbt%2FCapture%20d%E2%80%99e%CC%81cran%202023-12-06%20a%CC%80%2015.42.17.png?alt=media&#x26;token=0286fc6f-1b96-4ed1-9d09-e8faefe417c6" alt=""><figcaption><p>Use of Side Drawer to diplay more information about an item</p></figcaption></figure>

### **Limited Display with "See More" Trigger**

Show only part of the content at first, with a 'See More' option for users to view the rest. This keeps the display clean while allowing access to more information as needed.

<figure><img src="https://1297765105-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FMoZPkWOmnKvoMWGW4aeM%2Fuploads%2FAPQAVLsssy0vCxJuVmia%2Fexpend.jpg?alt=media&#x26;token=79932b82-1fef-4a42-aed6-ba1d5698ab7b" alt="" width="563"><figcaption></figcaption></figure>

**Two Ways to Use 'See More':**

1. **Expandable Wrapper**: Clicking the button expands or collapses content within the same section. The hidden content appears directly in the panel where the button is placed.
2. **"See More" Button**: The button opens more content in a different component, like a modal or a new page.<br>
