Modal flexibility

[yesenia-perezcruz]

The Modal component is used heavily in admin and we frequently get questions about it.

Usage
The Modal component is used 1,208 times in admin. Additionally there's 34 modals in /web/components, 23 not "on mainline," and 1 paged modal in /polaris-next.

Issues:
The modal component doesn't work for the range of use cases needed

Polaris users have asked for:

• Easily dismissible modals with background close
• Blocking modals that stop users and force them to wait before continuing
• Modals without primary and secondary buttons
• Modal typography flexibility, sometimes not having a heading or body text

Opportunities:

• We could consider using different modals for different scenarios. An example of this would be the way Material Design and Carbon use modal variants for a range of situations.
• We could also consider how the design of modals (depth, shadow) could adapt for different modes. I.e. a modal design that brings more focus to the task vs one that doesn't interrupt from your flow.

I'd like to use this discussion to collect other issues, opportunities, and ideas to improve the Modal component.

[heyjoethomas]

@dGoligorsky had a great breakdown of this. I am not sure we currently have the same experiential needs that Carbon does to warrant a suite of modal variants. I think the biggest issue we have is lack of composability. There seems to be too much baked into it or not easy ways to compose experiences in it.

[alex-page]

One confusing thing I have noticed is that Modals props title primaryAction secondaryAction render ui all over the modal. Users have little control of the spacing, ui rendered, etc. when using these props. When pairing with @yuraima it wasn't initially clear that the button at the bottom of the modal was being created by a prop that is defined in the first line of code in a modal. This should be fast and frictionless to understand.

This markup doesn't help developers quickly know where and what UI is rendering.

<Modal primaryAction={{ content: "Add Instagram", onAction: handleChange}}>
  <p>Hello world</p>
  {/* A button will appear here */}
</Modal>

Adding composability removes this confusion and simplifies the modal

<Modal>
  <Stack>
    <p>Hello world</p>
    <Button primary onClick={() => handleChange}>Add Instagram</Button>
  </Stack>
</Modal>

This happens across multiple components, but I noticed it on Modal recently and think it's worth bringing up.

[yesenia-perezcruz]

@alex-page That explains why this modal has duplicated CTAs inside the modal and in the modal footer.

s

[al-mcquiston]

This wasn't exactly your prompt but it is something that has come up for me related to modals. I would love to see guidance around modal usage. For example, are there instances where there is too much information to reasonably scan (a long list or a complex table) or too many interactions needed for a given task and a modal is not suitable? Instead, that information should live in a sub page or something other than a modal. Some standards or rough guidance around best practices might be helpful in increasing consistency throughout the admin.

[osamaghazal01]

On my end, working on media and file mgmt, I found the following:
1- There's one or two design approaches for modals that makes it very challenging accounting for contextual needs or use cases that come up contextually. for instance, designing the file picker, it is a modal window that entails multiple functionalities.
2- Seems like modals have been designed in a one way fits all so if there's a use case that has more than one step, the result will be modal on top of modal...etc.
3- A bit overly relied on vs. inline design approach which I found a bit challenging scaling for smaller breakpoints and mobile web as well as maintaining closer parity when designing for native apps. (edited)
4- Horizontal default style makes it challenging to maintain clear hierarchy especially when we factor in adding tools like search, sort..etc

[Jacquesattaque]

Personally I find hierarchy challenging with the title separated by a dividing line from the content. Makes the rest of the modal tough to design elegantly.

[dGoligorsky]

Following up from the recent Slack prompt to share thoughts on modals:

Here's a video (9m17s) talking through frameworks and how they play out in specific examples within Shopify admin.

[jennipurr]

Often, the title for modals with less content gets repeated in the context of the modal and offers little value. See example:

[aminpaks]

Hi folks, we're working on building something similar, and I would like to share a prototype that I've built very quickly regarding a multistep/paged modal.

Here an example of how it works.
Here is the source code, and here is how it's API could potentially be used.

[dGoligorsky]

Capturing another thread on modals—

Came upon the Cancel order modal and felt that the spacing was off— hierarchy was lost because the spacing between headings and content is the same as spacing between sections.

In a quick push to suggest an improvement, noticed discrepancies in the type styles used for section labels.

• e.g. Export Orders uses body text, which has good legibility, but no hierarchy since it’s the same style as the radio select text.
• e.g. Manage Rates uses subheading, which has ok hierarchy, though I believe all-caps are less legible than sentence case.

Dropping three variations here, curious what people think… My lean is towards the “header” style b/c it’s sentence case and creates hierarchy.