FWIW, there is an onboarding dialog on the SuggestedTags page on Commons that is not a process dialog.

See T233233.

Would the UploadWizard onboarding screen be covered here?

In T332767#8718822, @Cparle wrote:

Would the UploadWizard onboarding screen be covered here?

@Cparle Do you have a screenshot or link to where one could see that?

I'm hoping to make this easier as part of T324708: Dialog: support header and footer customization, if you all can afford to wait a week or two on this. My current patch introduces header and footer slots which would allow you to provide your own markup to this component without having to either 1) re-implement everything or 2) write a bunch of hacky CSS to hide or override things that are not intended to be overridden.

Here's an example: https://900456--wikimedia-codex.netlify.app/components/demos/dialog.html#with-custom-header-and-footer

The visual editor has a couple of onboarding/informational bits:

There are also some messages like https://www.mediawiki.org/wiki/MediaWiki:Anoneditwarning that I think are more "warning" than "onboarding", but new editors might be particularly likely to see them.

Until this week (when it was deleted), WikiEditor had an onboarding popup for Realtime Preview that looked like this:

The Wikisource extension has one for the OCR button (part of Wikimedia OCR):

DST has decided to move forward with treating the onboarding dialog use case as the first Codex pattern. Part of creating the pattern will be defining it's intended use case. Thank you to everyone who has provided examples. Some of the examples provided in this ticket are related to feature onboarding, but outside the scope of this specific pattern. This pattern focuses on a single or multi-step dialog, as opposed to something more akin to a tooltip that directs the users attention to a specific part of the interface.

As part of this work, we plan to update the Figma library and the Codex docsite with the pattern's definition and example usage.

hi @Sgs - one thing that came up during design review today was that the current Growth onboarding dialogs have gesture support to move forward/back in the steps via swipe, so my expectation would be that this should be in the new version and should be documented in this pattern too. Is that correct?

In T332767#8779413, @RHo wrote:

hi @Sgs - one thing that came up during design review today was that the current Growth onboarding dialogs have gesture support to move forward/back in the steps via swipe, so my expectation would be that this should be in the new version and should be documented in this pattern too. Is that correct?

I don't know where should mobile gestures specifications be documented, do we have an example of a Codex component which provides support for them?

afaik Vue provides touch low level events, eg touchstart, touchend and there are libraries (vue3-touch-events) that implement higher level events, eg: tap, swipe, hold, drag, etc. which is the kind of interaction you are requesting. It would be interesting to know the Design-System-Team view on this. Will Codex support mobile gestures as first class interactions? Or do we have a recommended way of tying together Codex with mobile gestures, a plugin maybe?

In T332767#8789902, @bmartinezcalvo wrote:

I've defined the OnboardingDialog pattern spec sheet with the following:

Illustration (or image)

We will implement an image component’s property and the designer will create an illustration with this format/size and they will export the illustration as an asset so developers can use it as image.

Next/Previous buttons and "Don't show again" position

They will be grouped on the right (as we have in the Dialog component) and “Don’t show again will be always placed on the left. We will do the opposite when RTL.

"Don't show again" maximum example

As we defined in Dialog's component, "Don't show again" will move above buttons when its text is so long. The footer height will increase.

Steps number in the onboarding

The minimum will be 1 step and the maximum will be free (close button will be different and steppers will be displayed just when more than 1 step).

Dividers (header and footer)

As we defined in Dialog's component, dividers will be visible just when scrolling. This will be implemented in T332124.

---

@KieranMcCann assigning this task to you so you can provide feedback about some pending visual decisions:

• Next/Previous buttons:
  • Icons: iconNext or iconArrowNext?
    
  • Padding between buttons. Although the padding defined between buttons on Dialog's component was 8px, do you think we should increase it to 12px so buttons are visually more separated when using icon-only buttons?
    
• Apart form this, feel free to provide feedback about any other elements in the Figma spec.

Regarding stepper placement, I will have a meeting with @RHo (since she was the Growth's onboarding dialog designer) to decide the best solution and also to prepare the spec sheet for Growth's team handoff.

After design details are resolved, we will present the "Pattern" spec with Growth eng working on this, @Sgs and @VYanez-WMF.

In T332767#8792917, @Sgs wrote:

In T332767#8779413, @RHo wrote:

hi @Sgs - one thing that came up during design review today was that the current Growth onboarding dialogs have gesture support to move forward/back in the steps via swipe, so my expectation would be that this should be in the new version and should be documented in this pattern too. Is that correct?

I don't know where should mobile gestures specifications be documented, do we have an example of a Codex component which provides support for them?

afaik Vue provides touch low level events, eg touchstart, touchend and there are libraries (vue3-touch-events) that implement higher level events, eg: tap, swipe, hold, drag, etc. which is the kind of interaction you are requesting. It would be interesting to know the Design-System-Team view on this. Will Codex support mobile gestures as first class interactions? Or do we have a recommended way of tying together Codex with mobile gestures, a plugin maybe?

Maybe @AnneT has some more info on this? I think even if Codex doesn't yet have this, it would make sense for Growth to not lose this existing functionality in moving to Vue though, so I wonder if this is something that is contributed by Growth in v1?
If so, would it make sense for @bmartinezcalvo to add to the Pattern documentation for Onboarding dialogs (and/or the stepper?)?

In T332767#8793046, @RHo wrote:

Maybe @AnneT has some more info on this? I think even if Codex doesn't yet have this, it would make sense for Growth to not lose this existing functionality in moving to Vue though, so I wonder if this is something that is contributed by Growth in v1?
If so, would it make sense for @bmartinezcalvo to add to the Pattern documentation for Onboarding dialogs (and/or the stepper?)?

@Sgs @RHo I've documented the gestures for both mobile and tablet in the Figma spec, and I included a text next to the image, but not sure if this is enough for devs. Should I include something more?

In T332767#8793046, @RHo wrote:

Maybe @AnneT has some more info on this? I think even if Codex doesn't yet have this, it would make sense for Growth to not lose this existing functionality in moving to Vue though, so I wonder if this is something that is contributed by Growth in v1?

Yes, that makes total sense, we would't want to loose support for mobile gestures in the Growth dialogs. The existing swipe implementation is indeed implemented in the GrowthExperiments code, I've filed T335044: Add support for swiping between steps on mobile for this. I think it would be nice to think about Codex defaults for mobile experiences in general not just the scope of the Dialog component. This is somehow related to T321893: Evaluate fullscreen mobile Dialog in Codex which is another blocker for the new on-boarding dialog to mimic the behavior of the old one.

If so, would it make sense for @bmartinezcalvo to add to the Pattern documentation for Onboarding dialogs (and/or the stepper?)?

Sure, better to document all relevant specifications in Figma. Two questions that are still unclear to me are:

• How many components are we planning to build?
• Are any of these "planned" components still candidates to an eventual Codex upstream? If not, how could this pattern be replicated in a different extension than GrowthExperiments?

In T332767#8792917, @Sgs wrote:

afaik Vue provides touch low level events, eg touchstart, touchend and there are libraries (vue3-touch-events) that implement higher level events, eg: tap, swipe, hold, drag, etc. which is the kind of interaction you are requesting. It would be interesting to know the Design-System-Team view on this. Will Codex support mobile gestures as first class interactions? Or do we have a recommended way of tying together Codex with mobile gestures, a plugin maybe?

This is a good question. So far this hasn't come up yet, but if you are already supporting these gestures in the OOUI implementation and don't want to lose them then perhaps we need to consider how we want to approach this.

This is potentially a bigger issue that goes beyond the scope of just the OnboardingDialog, so I went ahead and filed a task for it: T335047: Better support for mobile touch events in Codex. Feel free to weigh in there if you have ideas.

@Sgs do you consider work on OnboardingDialog to be blocked until the question of mobile touch event support is resolved?

In T332767#8793696, @egardner wrote:

@Sgs do you consider work on OnboardingDialog to be blocked until the question of mobile touch event support is resolved?

No, I think we can come up with a custom implementation using touchstart, touchend events as we did with OOUI. I've filed T335044 for the Growth team to work on it.

This is potentially a bigger issue that goes beyond the scope of just the OnboardingDialog, so I went ahead and filed a task for it: T335047: Better support for mobile touch events in Codex. Feel free to weigh in there if you have ideas.

Right, thank you! We'll share our learning from T335044 there as it might be useful feedback.

Thanks @bmartinezcalvo. Comments below:

• Next/Previous buttons:
  • Icons: iconNext or iconArrowNext?
    

Personally I have a preference for Op.1 (current arrows). This might be partially due to familiarity but I also feel that the new arrows indicate movement i.e. that they would be used when indicating you were moving a component to a new space on the page or collapsing it.

• Padding between buttons. Although the padding defined between buttons on Dialog's component was 8px, do you think we should increase it to 12px so buttons are visually more separated when using icon-only buttons?
  

Preference for Op.2 (12px padding). 8px feels a bit tight to my eyes.

In T332767#8795660, @KieranMcCann wrote:

Thanks @bmartinezcalvo. Comments below:

• Next/Previous buttons:
  • Icons: iconNext or iconArrowNext?
    

Personally I have a preference for Op.1 (current arrows). This might be partially due to familiarity but I also feel that the new arrows indicate movement i.e. that they would be used when indicating you were moving a component to a new space on the page or collapsing it.

@KieranMcCann in makes sense. The current arrow (Op.1) is being used in other Back/Next patterns so let's use it in this Onboarding Dialog.

• Padding between buttons. Although the padding defined between buttons on Dialog's component was 8px, do you think we should increase it to 12px so buttons are visually more separated when using icon-only buttons?
  

Preference for Op.2 (12px padding). 8px feels a bit tight to my eyes.

@KieranMcCann at the moment, we are using 8px padding between buttons in both desktop and mobile dialog. Since the Onboarding Dialog pattern is created with the Dialog component, we should use the same padding in both. This means we should increase the padding between buttons in the Dialog component first. Would you increase the padding between buttons on both desktop and mobile or just on mobile?

The Figma spec has been completed and the Onboarding Dialog pattern is Ready for development. I've included in both the Figma spec and the task description the most relevant information about this pattern.

{F36966601}

The stepper will be finally placed below the dialog's title (in the same place where the dialog's subtitle was). Regarding the Image, we've defined a max height for both desktop and mobile images, so the image doesn't take up too much space in the dialog.

Regarding the button's padding, we will go with 8px for now (as we have in the Dialog component) and we will increase the padding to 12px in the Dialog component if needed in the future. Since the Onboarding Dialog pattern uses the same styles as the Dialog component, the padding should be increased in the Dialog first (so it's not a priority for this task).

In T332767#8793607, @Sgs wrote:

Sure, better to document all relevant specifications in Figma. Two questions that are still unclear to me are:

• How many components (composables, mixins, etc) are we planning to build?
• Are any of these "planned" components still candidates to an eventual Codex upstream? If not, how could this pattern be replicated in a different extension than GrowthExperiments?

I believe this questions remain unanswered, I think this is relevant to make the investment on developing the spec worth.

Per meeting on Tuesday 9th of May there might be room for several reusable artifacts (components, composables, mixins, tokens) for building and making the work reusable for others. Anticipating all of them is challenging. Growth team will document the outcome of a first iteration of the Figma specification for this pattern in T336270.

Moving this to "Following" for now since DST isn't actively working on this ticket, even though we were working on some of the related tasks. We may put this on another board in the future (potentially a "DST Roadmap" or "Collaborations" board).