Modal Experience Fragment Component

[shsteimer]

[Request To Comment] To anybody who intends to use the Core Components, please provide your feedback about the following requirements. We want to make sure that we build a component that fits your needs, so don't hesitate to tell us how that component should work, so that you will be able to use it.

User Story:

As a content author, I want to be able to curate modal content as an experience and easily create a link to open that experience in a modal window

Acceptance Criteria:

• Modal content can be authored inside an experience fragment using arbitrary components, When the authored modal link is clicked, the XF is requested via ajax and it's content is displayed in a modal
• The modal can be closed by clicking outside the modal window or by clicking an "x" icon to close
• Modal will be implemented as a new template for experience fragments, which authors will use to create the Modal content
• A Sling rewriter extension will check for any links to XF pages created using this template, adding a class "cq-xf-modal" to the anchor tag to indicate it will be opened as a modal
• client library javascript code will check for links with the "cq-xf-modal" class applied and bind a click event which will request the xf page content via ajax and show it in the modal.

[pauldrago]

Overall I think this is good-- but is an on click event the only time an author is going to want a modal?

What about an on page load event?

[gabrielwalt]

Hi @shsteimer, it's a brilliant idea to edit the content of the modal as an XF, I like that!

I'm less convinced about is the automatic opening of a modal when linking to the XF directly:

• Requiring a flag on the XF templates that is specific to the Modal component creates a dependency between two features that will make maintenance brittle.
• Requiring a Sling rewriter to verify the presence of such a flag for every link might be slow and also adds further undesired cross-product dependencies.

What is the need or the use-case behind having multiple pages to display the same modal? I'd rather drop this, at least in a first step, and for now have every page that wants to display the modal to include the Modal component.

I'd suggest the following simplified behavior:

• The Modal dialog that includes the XF has an ID attribute (this ID could typically be a hash of the component's path on the page).
• Adding that ID to the URL of the page (eg: page.html#1234) opens the modal automatically.
• That way:
  • having any link on the page that points to that ID will open the modal on click;
  • having any other page linking to this page with the ID appended will open the modal on load.

@shsteimer, would that be acceptable? @pauldrago, is that enough for opening the modal on load?

Also, I'd imagine that the modal component also renders a CTA link with similar markup than the Teaser component.

(AGSIL-79)

[shsteimer]

Hi @gabrielwalt ,

I struggled a lot with thinking through how to implement this in a way that balances making it easy for an author and also isn't brittle maintain or technically complex. I think what you are proposing is a good balance, and should work, at least for a first pass.

[abhishekagg19]

@gabrielwalt Adding modal ID to the URL of the page (eg: page.html#1234) will open the dialog on the load of the page. But in some scenarios, users might not want to append an extra link attribute to the URL but still would like to display the modal on the load of the page. To handle such cases, should we provide an option in the modal dialog to display on the page load? If multiple modals are present on the same page with the display on load option selected, then we can load and display the first modal window. Is this acceptable?

[gabrielwalt]

@shsteimer, I'm glad that such a simplified version would be ok for you for a first iteration. From there, we can then see how to bring it to the next level if needed.

@abhishekagg19, it would indeed make sense to have the automatic opening of the modal configurable as well, like you suggest. An author might configure multiple modals to auto-open on a page, but as verifying that no other one has been configured to auto-open, I'd ignore that for now for the sake of simplicity, and leave it to the author to create meaningful content.

Not sure if we also want to make the ID of the modal editable... But as there are thoughts to add an editable element ID to all Core Components, I'd keep the implementation of the Modal ID minimalistic and just a hash of the resource path.

Then, I'd name this component just "Modal", and it would typically wrap, extend or delegate to an XF component. Also, it should implement the Style System. Maybe we should also create a Core Experience Fragment component that extends the Foundation one to just add the Style System, and this Modal component then extends the Core Experience Fragment component.

In addition to the Style System, I then see just one addition to the Edit dialog, where there would be an additional "Modal" tab:

• [Checkbox] "Display the modal on page load"

[richardhand]

These requirements seem good to me, just had a few additional thoughts:

Dialog versus Modal I wonder if we should use the more general name of Dialog for this component, Modal being a subset of dialog in UI/UX speak. From the initial requirements, it seems that these dialogs will be typically Modal (fully blocking user interaction / mode switch), but the Dialog naming would future proof the component if we later support a non-modal scenario whereby background content can still be interacted with. https://www.nngroup.com/articles/modal-nonmodal-dialog/

Dismiss / Close

The modal can be closed by clicking outside the modal window or by clicking an "x" icon to close

I would generalise this to "The dialog can be closed by any dismissing element in the dialog on click - typically a close X, or by clicking a modal backdrop". This would allow for other actions in the dialog to cause the dialog to close. Could be implemented with a data attribute API for example <button data-close>X</button>

Dialog Structure A typical dialog has the following content areas:

• Header -> Title text and close button
• Body -> The Content / Experience
• Footer -> Footer Content, typically confirmation / cancel buttons

Is it expected that this structure is handled in the content itself? I think a case could be made for allowing for a dialog title at least to be provided in the Edit Dialog, and if not present not displaying it.

cc @gabrielwalt

[lewandowskidawid]

Hi,

I see the modal feature has been already implemented in the following PR: https://github.com/adobe/aem-core-wcm-components/pull/570. Do you have any plans in terms of releasing it in the close future?

Thanks

[tjameswhite]

Following @lewandowskidawid's comment, the merge was 10 months ago. Is there a release date? I have customers asking for this functionality and would like to provide a timeline.