Change 707650 abandoned by Jdlrobson:

[wvui@master] POC: Dialog (simple and complex)

Reason:

Not looking for review right now,

https://gerrit.wikimedia.org/r/707650

In GlobalWatchlist we currently use the dialog created by OO.ui.confirm to interact with the viewer - that method returns a promise for which button was clicked (resolved to false if cancel, true if OK) - I would hope that any WVUI dialog component has a similar way to interact with it where it doesn't need to be manually included in the template and told when to display or not, but rather have a public api like OO.ui.confirm does.

Hi all,

I've created the Figma spec sheet for the SimpleDialog component, adding the following variants:

• With and without close action
• With text in the dialog content
• With text input in the dialog content
• With different buttons combination and also with horizontal/stacked buttons (full width buttons for stack variant)

I've updated the task title from Basic Dialog to SimpleDialog since we will have simple and complex dialog variants and I guess we will cover only the simple one in this task.

Here you can view the Figma spec sheet.

I move the task to Ready for development and I leave the task free to be assigned by whoever starts with its development. If there is a use case missing or something needs to be updated, let me know so I can reassign to me the task.

Change 789708 had a related patch set uploaded (by Catrope; author: Catrope):

[design/codex@main] [WIP] Dialog component

https://gerrit.wikimedia.org/r/789708

Chiming in from the abstract team! We currently use a dialog that looks like this:

So it has three points of interaction: two buttons, one that roughly is CONFIRM and one that roughly is CANCEL and an additional icon that, on click, also triggers a CANCEL action

Thanks @JKieserman, this is a helpful example! This is mostly in line with what we've started building: an icon-only "close" button, a primary action that can either be progressive or destructive, and a default action.

The only difference I see between this example and the design spec is the order of the buttons when vertically stacked: in the design spec, the primary action is first (on top). @bmartinezcalvo Do you think the order of the buttons should be configurable, or should the primary action always appear on top?

In T284838#7931844, @JKieserman wrote:

Chiming in from the abstract team! We currently use a dialog that looks like this:

So it has three points of interaction: two buttons, one that roughly is CONFIRM and one that roughly is CANCEL and an additional icon that, on click, also triggers a CANCEL action

@JKieserman with the new SimpleDialog component we could cover this use case since we can use both primary-progressive and primary-destructive buttons as primary actions (view these use cases in the spec sheet).

In T284838#7931939, @AnneT wrote:

The only difference I see between this example and the design spec is the order of the buttons when vertically stacked: in the design spec, the primary action is first (on top). @bmartinezcalvo Do you think the order of the buttons should be configurable, or should the primary action always appear on top?

As @AnneT comments, the only difference with our new SimpleDialog component is that primary action will always be on top when the buttons are in vertical.

But this dialog version with vertical buttons should only be used in cases where the button text is too long. So we should always use the version with horizontal buttons, unless the button text is too long, which we should avoid in all buttons to improve the UX Writing experience (review this component recommendation).

@bmartinezcalvo Another question: The OOUI dialogs scale in and out slightly (see demos) for a more intuitive transition. Is this something we should consider implementing in the Codex version? We could start with the same transitions that are used in OOUI and refine from there.

In T284838#7939894, @AnneT wrote:

@bmartinezcalvo Another question: The OOUI dialogs scale in and out slightly (see demos) for a more intuitive transition. Is this something we should consider implementing in the Codex version? We could start with the same transitions that are used in OOUI and refine from there.

@AnneT what if we implement the same behavior as in message component?

• Fade in: ease (system)
• Fade out when user closes the dialog with one of the buttons or close: ease-out (user)

@AnneT about the width of the SimpleDialog, do we want to implement different sizes as we have in OOUI demo or do we want to have one single SimpleDialog size in Codex? I assume we need a single size for now and we would add new sizes in the future if we need them.

@bmartinezcalvo I agree; let's stick with one size for now and add the option for configurable sizes in the future if we need to.

I guess we're technically offering two sizes in the initial implementation: fullscreen or not.

@AnneT @Catrope @bmartinezcalvo and @DAbad for visibility: do you think that this component could be a good candidate to be implemented by WMDE contributors? It looks like the specs are ready

hey @Sarai-WMDE, @Catrope and I spent some time pairing on the Dialog component a while back (see patch, with a list of remaining to-dos in the commit message), although that work has been paused since it was de-prioritized in favor of TypeaheadSearch and other new components. Because this is pretty far along and the remaining work is largely specific to this implementation, it probably makes more sense for us to wrap it up vs. passing it over to WMDE contributors. That said, if we identify subsequent features we want to add to Dialog, we could create separate tasks for them and anyone could work on them.

Dialog open questions

This comment documents the current open questions around all potential Dialog components.

Simple and complex designs

The Design Style Guide's Dialog page defines simple and complex dialogs with the following differences:

1. Body: simple dialogs have a short message, complex dialogs can have any amount or kind of content
2. Actions: simple dialogs can have both a confirmation action (progressive) and a dismissive/secondary action, complex dialogs can only have a progressive action
3. Layout and spacing: padding differs between the two designs, and complex dialogs have a fixed top and bottom bar since the body content may be scrollable

Open question: do we need separate components for "simple" and "complex" dialogs?

Is this distinction needed, or can we consolidate these two designs into a single component? Can we build a single Dialog component that covers all use cases, allowing for maximum flexibility and no unnecessary confusion?

ProcessDialog

In OOUI, a ProcessDialog encapsulates a process, which may include multiple steps, loading states, an multiple actions. For Codex, we need to figure out which of these features we want to support, and how we'll fit that into our component architecture.

Some of the features of a process dialog are:

• The ability to add multiple steps to a dialog, with a progressive button for moving forward in the process and a default back or cancel button
• A loading state that shows the user that something is happening and they should wait (e.g. save)
• Different behavior based on the outcome of that process (e.g. whether the save succeeded or failed)
• Any kind of content within the dialog body, including form elements or actions
• Multiple potential actions (more than just one progressive and one default/safe)

Open question: which parts of the OOUI ProcessDialog do we want to support in Codex?

First, we need to decide which features we will support in Codex.

Open question: which features require a separate component, and which could be added to the basic Dialog component?

Next, we should determine component architecture. The multistep feature will likely require a separate component that uses Dialog internally, but some of the features (e.g. loading state) would be useful inside the Dialog component itself, allowing us to offer that feature to any user of the Dialog component.

We should base our decision on clarity of use cases and offering flexibility. Right now, ProcessDialog is difficult to understand without seeing examples, and some of the features would be useful in regular Dialogs, too.

Template dialog

The following ProcessDialog is used to select templates:

Open question: how could we support such a dialog in Codex?

Should we build out this pattern so it can be reused? Or should we empower developers to build the UI themselves based on a flexibly and fully-featured single Dialog component?

Note that the first open question (simple and complex designs) is by far the most important to answer now; the others are lower priority but are worth considering now as we determine basic architecture.

In T284838#8176297, @AnneT wrote:

Note that the first open question (simple and complex designs) is by far the most important to answer now; the others are lower priority but are worth considering now as we determine basic architecture.

@AnneT as you commented in T313773 we could define the Dialog component architecture based on the number of steps in the dialog to avoid the architecture to be based on the type of body content.

In T313773#8176259, @AnneT wrote:

Given all that, I would recommend the following architecture:

• Dialog
  • Has a fixed top and bottom bar, so that the body content can be scrollable
  • Optional icon-only close button
  • Slot for any body content. You could even add the sidebar in the template dialog example.
  • Up to 3 actions, with appropriate styles for desktop and mobile
  • Configurable fullscreen prop (perhaps just for mobile). Note that this has been requested by the web team. This way, users can decide if their content is complex enough to require a fullscreen dialog on mobile.
  • Loading state that can be turned on/off
• MultistepDialog
  • Allows you to add multiple Dialog components (or different body slot contents) in a sequence
  • Allows you to define that sequence, including contingencies (i.e. different behavior if a save process succeeds or fails)
  • Adds a back button to each step (other than the first)

We could define one single Dialog component with no Simple/Complex differentiation (adding all the necessary props to be able to build the MultistepDialog with it) and then decide whether or not we want to implement the Multistep (or Process) Dialog in our system.

@bmartinezcalvo perfect, thank you for confirming!