Page MenuHomePhabricator

Dialog MVP: Design fixes
Closed, DeclinedPublic5 Estimated Story Points

Description

This task collects the suggested improvements after performing the design review of the Dialog component's MVP:

Interaction
  • Some of the properties of the enter and leave transition seem to not match the specifications. In the code, the enter and leave transitions share the same values. In the specs, timing function is different between the two. The designs also indicate a different duration for both transitions. To summarize:
TransitionValue in the code (source)Value in Figma (source)
Enter/Fade-in transitiontransition-duration: @transition-duration-base (=100ms); transition-timing-function: @transition-timing-function-user (=ease-out)transition-duration: @transition-duration-medium (=250ms); transition-timing-function: @transition-timing-function-system (=ease)
Leave/Fade-out transitiontransition-duration: @transition-duration-base (=100ms);transition-duration: @transition-duration-medium (=250ms);
  • Loading state: Judging from the MVP task, the loading state seemed to be in scope. But this doesn't appear to have been implemented. Loading state is out of scope for the MVP component.
Visual

Dividers

In the MVP specs, there's a version of the Dialog that present dividers. The ticket also mentions that these should be applicable via a prop: "we can add a prop to add the dividers as props". Nevertheless, this doesn't seem to have been implemented yet.

Overlay

The value of the overlay's background-color should be rgba( 255, 255, 255, 0.65 ). The token @background-color-backdrop-light is in the making (see patch) and should replace @background-color-dialog-mask. We should add a comment indicating that the value needs to be replaced by a token.

Sizes (generally)
From MVP task T313773:

  • Small/Normal size: @width-3200 (512px wide) for desktop (current size in normal dialogs in production) and full grid for mobile (leaving 16px on each side)
  • Big size: 896px wide (we should add a new width token) for desktop (current size in big dialogs) and fullscreen for mobile
  • Do we want to implement different props for size and fullscreenOnMobile?

Width

  • Mobile min-width: In the code, there's a min-width applied to the dialog that matches its assumed mobile width (@min-width-dialog--mobile: 288px;). Following the designs, though, dialogs are full-width on mobile, so the min-width value of .cdx-dialog should be the token @size-full.
  • Min-width: Starting at the tablet breakpoint, the min-width of Dialog (@min-width-dialog) should be 512px, as specified in the designs. This value will be replaced by the corresponding size token.
  • Max-width: As specified in the description of the MVP ticket, the expected max-width of Dialog should be 896px (to be tokenized) instead of the current 700px.

Height

  • Max-height: The value, calc( @height-dialog-mask - ( @padding-dialog * 2 ) ) currently equals to 100vh-21.33px (the – to be corrected– Dialog padding). There doesn't seem to be clear specs regarding the top and bottom margins that would dictate this height. The MVP ticket only mentions "a max-height of 100vh minus some top and bottom "padding". We should probably use a value from our spacing scale here instead. 24px might be a good approximation? Pinging @bmartinezcalvo to confirm.

Paddings

@padding-dialog: @size-base * ( 2 / 3 ); applies a homogenous 21.33px padding to the Dialog frame while, in the specs, sections have different paddings:

Screenshot 2022-09-30 at 15.12.29.png (520×1 px, 122 KB)

Margins

We might want to reconsider how/where the current margins are applied. In the version with dividers, the margin of the Dialog's body would be 12px instead of 8px (which would correspond to the bottom margin of the header).

Screenshot 2022-09-30 at 15.43.09.png (372×1 px, 90 KB)

(The body would also have an additional bottom margin of 16px, but that could be added separately without requiring any further changes.)

Fonts

Following the designs, the dialog title should be 16px (1em), with a 20px line-height (1.25). The body, 14px (0.875em) with a 20px line-height (1.4285714286*).

In the code, the same font size was applied to both title and body text (1em = 16px). This means that, under Vector, both elements will probably be sized 14px. This is not so much a question about avoiding the compounding effect, but about how to maintain the hierarchy applied in the design in production. A solution would be to increase the size of the title to 18px (1.125em with a 1.25 line-height, Heading S style in Figma). Pinging @bmartinezcalvo so she can consider this.

(*Just for visibility: This line-height will after all most likely not be introduced into the system, but will be replaced by 1.6.)

Token implementation

We should avoid defining local variables as much as possible and, instead, use the available base/decision tokens directly as values. Whenever the necessary tokens are missing, we should add comments indicating that the temporary discrete value will need to be replaced by a token as soon as it's available. We also should never use theme tokens as values (e.g. @padding-dialog-mask: @size-absolute-100;), or tokens with a different intent (e.g. @margin-dialog-body: @size-base * 0.25;). These suggestions would translate as follows in the current version of the code:

// TODO: Tokenize. [Applies to everything that remains under this line]
@background-color-dialog-mask: rgba( 255, 255, 255, 0.65 ); [Value updated, see section Visual>Width. Once the token is available, this variable should be deleted]
~~@min-height-dialog-mask: @size-full;~~  [not needed, use @size-full directly as min-height value of .cdx-dialog-mask]
@height-dialog-mask: 100vh; [Once the size token is available, this variable should be deleted]
@width-dialog-mask: 100vw; [Once the size token is available, this variable should be deleted]
~~@min-width-dialog--mobile: 288px;~~ [Should be removed and replaced by `@size-full`, see Visual>Width]
@min-width-dialog: 512px; [Value updated, see section Visual>Width. Once the token is available, this variable should be deleted]
@max-width-dialog: 848px; [Value updated, see section Visual>Width. Once the token is available, this variable should be deleted]
@max-height-dialog: calc( @height-dialog-mask - ( @padding-dialog * 2 ) ); [Value should be replaced based on design decision, see Visual > Height. Calc should involve tokens and be used directly as a value. Once the tokens are available, this variable should be deleted]
@padding-dialog: @size-base * ( 2 / 3 ); [Value should be updated/split, see Visual > Paddings. To be removed once values can be replaced by tokens]
@padding-dialog-mask: 16px; [Should be replaced by a base spacing token when available]
@margin-dialog-body: 8px; [The variable should be replaced by a base spacing token when available]
@margin-dialog-footer: 16px; [The variable should be replaced by a base spacing token when available]
@margin-dialog-actions: 8px; [The variable should be replaced by a base spacing token when available]
Demo
  • I'm curious to hear what @bmartinezcalvo will think, but I'd say that including the props/configuration table inside the body of the configurable (simple) Dialog is confusing. I think that the workflow would be good enough if the table were included in the demo page (under the 'Open dialog' button). Users could change the config and then open the Dialog to check the result. If this is not acceptable, then we could provide the config in a side panel to the right of the open Dialog? But that sounds more costly.

Acceptance Criteria for Done

Implement interaction amendments

  • correct transition values

Implement visual amendments

  • Dividers addable via props
  • Backdrop (Overlay mask)
    • Design needs to provide token
    • Unify on name (overlay vs mask vs overlay mask vs backdrop)
  • Sizes
    • Add normal size @width-3200 dialog
    • Add big size (=896px) dialog
    • Add full size dialog
    • Add props for
      • size
      • fullscreenOnMobile
  • Width
    • Mobile min-width should be @size-full on mobile instead of @min-width-dialog--mobile: 288px;
    • Tablet breakpoint min-width should be 512px, as specified in the designs. min-width-dialog carrying corresponding size token.
    • max-width should be 896px (to be tokenized) instead of the current 700px.
      • Design will provide new size token
  • Height
    • max-height: The padding value in calc( @height-dialog-mask - ( @padding-dialog * 2 ) ) should be updated to 40px.
  • Padding should be different, not homogenous @padding-dialog: @size-base * ( 2 / 3 ) equivs 21.33px
  • Margin needs increase at dialog content to 12px
  • Font:
    • dialog title needs to carry 16px (1em) font-size, with a 20px line-height (1.25).
    • dialog body needs to carry, 14px (0.875em) with a 20px line-height (1.4285714286*).
  • Token implementation
    • Replace theme tokens with base or component tokens
    • Replace calculated spacing tokens with design decision tokens (flag if needed)
  • Demo?
    • Demo props table in simple dialog
    • Replace “close” with “cancel”

Event Timeline

Thanks @Sarai-WMDE, this is extremely helpful! All the detail is much appreciated.

Change 837489 had a related patch set uploaded (by VolkerE; author: VolkerE):

[design/codex@main] Dialog: Use design spec transition tokens

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

Change 837489 merged by jenkins-bot:

[design/codex@main] Dialog: Use design spec transition tokens

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

Commenting here my thoughts about the component fixes captured in the task description:

Interaction

Loading state: Judging from the MVP task, the loading state seemed to be in scope. But this doesn't appear to have been implemented.

As explained in the open questions in T313773 the loading state should be part of the MVP component.


Dividers
In the MVP specs, there's a version of the Dialog that present dividers. The ticket also mentions that these should be applicable via a prop: "we can add a prop to add the dividers as props". Nevertheless, this doesn't seem to have been implemented yet.

As explained in the open questions top and bottom dividers should be implemented as component properties and we could use them according to each case. We should also explain (as recommendation) that we can use them when the dialog body content is too long (added this section in the Figma spec sheet recommendations to explain when dividers should be used).

Height
Max-height: The value, calc( @height-dialog-mask - ( @padding-dialog * 2 ) ) currently equals to 100vh-21.33px (the – to be corrected– Dialog padding). There doesn't seem to be clear specs regarding the top and bottom margins that would dictate this height. The MVP ticket only mentions "a max-height of 100vh minus some top and bottom "padding". We should probably use a value from our spacing scale here instead. 24px might be a good approximation? Pinging @bmartinezcalvo to confirm.

@Sarai-WMDE I think 24px could not be enough, I would use 40px instead (updated Figma spec sheet max example and MVP task description with this 40px padding).

Fonts

Following the designs, the dialog title should be 16px (1em), with a 20px line-height (1.25). The body, 14px (0.875em) with a 20px line-height (1.4285714286*).
In the code, the same font size was applied to both title and body text (1em = 16px). This means that, under Vector, both elements will probably be sized 14px. This is not so much a question about avoiding the compounding effect, but about how to maintain the hierarchy applied in the design in production. A solution would be to increase the size of the title to 18px (1.125em with a 1.25 line-height, Heading S style in Figma). Pinging @bmartinezcalvo so she can consider this.

As @Sarai-WMDE comments, the text styles should be 16px (title) - 14px (body) and it should be translated into 18px (title) - 16px (body) to reflect the same visual hierarchy as in the design spec (as I designed in the mobile version of the component where the title is 18px and the body content is 16px).


Demo

I'm curious to hear what @bmartinezcalvo will think, but I'd say that including the props/configuration table inside the body of the configurable (simple) Dialog is confusing. I think that the workflow would be good enough if the table were included in the demo page (under the 'Open dialog' button). Users could change the config and then open the Dialog to check the result. If this is not acceptable, then we could provide the config in a side panel to the right of the open Dialog? But that sounds more costly.

@Sarai-WMDE totally agree, I would include the configurable demo under the "Open dialog" button so that the body content in the dialog component is not too long.

I would not use any "Close" text button in the Codex demo since close action should be only be done with the close button (X) on top. Could we update the the "Close" text buttons in the demo with "Cancel" ones instead?

Captura de Pantalla 2022-10-03 a las 17.41.54.png (628×1 px, 461 KB)

Volker_E changed the point value for this task from 3 to 5.EditedOct 3 2022, 9:12 PM

Coming out of today's task refinement DST discussion: We've agreed, with further reconsidering the amount of open work, that this is a Large (5 point) task involving coordination and work by a few team members.

Fonts

Following the designs, the dialog title should be 16px (1em), with a 20px line-height (1.25). The body, 14px (0.875em) with a 20px line-height (1.4285714286*).

In the code, the same font size was applied to both title and body text (1em = 16px). This means that, under Vector, both elements will probably be sized 14px. This is not so much a question about avoiding the compounding effect, but about how to maintain the hierarchy applied in the design in production. A solution would be to increase the size of the title to 18px (1.125em with a 1.25 line-height, Heading S style in Figma). Pinging @bmartinezcalvo so she can consider this.

Would it be better for the Dialog component to simply not apply any font-size rules at all, and rely on the existing style rules for title and content?

Mobile min-width: In the code, there's a min-width applied to the dialog that matches its assumed mobile width (@min-width-dialog--mobile: 288px;). Following the designs, though, dialogs are full-width on mobile, so the min-width value of .cdx-dialog should be the token @size-full.

For the moment I'm focusing on default sizing at various breakpoints; I'm not handling dialogs with alternative sizes like large or fullscreen yet.

Based the Figma specs, I still see a need for a 288px min-width on the smallest screen sizes. That is the width of the dialog in this view:

Screen Shot 2022-10-03 at 2.52.04 PM.png (1×736 px, 94 KB)

We have another min-width that kicks in at the tablet breakpoint (512px). I guess the real question is: what should happen between between the smallest screen size in the mock-up (320px wide) and the tablet screen size (768px wide)? Should the dialog's min-width remain locked at the 288px size until we hit the next breakpoint, or should the min-width of the dialog only be limited by a margin of 16px on left and right edges?

Your comment seems to be implying a preference for the latter, but I'm concerned that this could look a little bit strange on big phones that fall just below the tablet breakpoint (say a screen width of 600-700px). You could conceivably have a situation where the dialog is wider on "big" small screens than it is on tablet sizes.

Change 837753 had a related patch set uploaded (by Eric Gardner; author: Eric Gardner):

[design/codex@main] [WIP] Dialog MVP Design Fixes

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

egardner changed the task status from Open to In Progress.Oct 3 2022, 10:33 PM
egardner claimed this task.

Mobile min-width: In the code, there's a min-width applied to the dialog that matches its assumed mobile width (@min-width-dialog--mobile: 288px;). Following the designs, though, dialogs are full-width on mobile, so the min-width value of .cdx-dialog should be the token @size-full.

For the moment I'm focusing on default sizing at various breakpoints; I'm not handling dialogs with alternative sizes like large or fullscreen yet.

Based the Figma specs, I still see a need for a 288px min-width on the smallest screen sizes. That is the width of the dialog in this view:

Screen Shot 2022-10-03 at 2.52.04 PM.png (1×736 px, 94 KB)

@egardner the mobile dialog width should be full-width 100% minus 16px padding on each side. Actually the dialog width was designed to be full-grid thinking in a future grid where the mobile margins are 16px. But the grids need to be implemented in T298198 I would implement the mobile dialog @width-full minus 16px padding on each side so these paddings match the 16px designed for the grid margins.

We have another min-width that kicks in at the tablet breakpoint (512px). I guess the real question is: what should happen between between the smallest screen size in the mock-up (320px wide) and the tablet screen size (768px wide)? Should the dialog's min-width remain locked at the 288px size until we hit the next breakpoint, or should the min-width of the dialog only be limited by a margin of 16px on left and right edges?

Desktop and tablet dialog will be @width-3200(512px) while mobile will be @width-full minus 16px padding on each side. I've updated the Figma spec to reflect this.

Your comment seems to be implying a preference for the latter, but I'm concerned that this could look a little bit strange on big phones that fall just below the tablet breakpoint (say a screen width of 600-700px). You could conceivably have a situation where the dialog is wider on "big" small screens than it is on tablet sizes.

I agree, in big screen mobiles (e.g. 639px where the breakpoint is still breakpoint-mobile) the dialog with 16px of margin on each side could be too wide.

Captura de Pantalla 2022-10-05 a las 15.50.04.png (1×2 px, 856 KB)

To solve this we could use 32px of margin in mobile instead, but then the dialog width could be too small (256px) in the smallest 320px screens. Also, if we don't use the 16px margin then the width of the dialog won't be full-grid when grids are implemented (keep in mind that all margins will be 16px in big mobiles of 600px or so when our new grids are implemented).

Captura de Pantalla 2022-10-05 a las 15.55.42.png (1×1 px, 651 KB)

We have another min-width that kicks in at the tablet breakpoint (512px). I guess the real question is: what should happen between between the smallest screen size in the mock-up (320px wide) and the tablet screen size (768px wide)? Should the dialog's min-width remain locked at the 288px size until we hit the next breakpoint, or should the min-width of the dialog only be limited by a margin of 16px on left and right edges?

As Bárbara described above, the specs define that the Dialog should be full-width on mobile. The 288px version just represents an instance of that full-size display.

I'm concerned that this could look a little bit strange on big phones that fall just below the tablet breakpoint (say a screen width of 600-700px). You could conceivably have a situation where the dialog is wider on "big" small screens than it is on tablet sizes.

The size difference would be acceptable. But, if we wanted to make Dialog consistent across devices, we could apply a default width of @full-width and a max-width of 512px. This way, we'd make sure that the Dialog is big enough on mobile, and yet that it never surpasses its fixed width, regardless of the viewport size. Judging from the epic task description and the specs, it seems that these 512px would correspond to the "small/normal" size of Dialog. (This means that even the Dialog "With overflowing content" in the demo should be 512px). I didn't realize this originally, but the max-width value applied to the MVP (700px) shouldn't be equal to the "big size": users will use the "large" size prop (848px*) to make the Dialog wider than its fixed, default 512px size (i.e. the prop will update the max-width value).

*Also important, the value of the "big size" Dialog was just updated following a design discussion. Instead of 848px, we decided to use the value 896px (which is more aligned with our size & spacing scale).

Let me know what you both think @bmartinezcalvo and @egardner, and I'll update this task's description accordingly.

We have another min-width that kicks in at the tablet breakpoint (512px). I guess the real question is: what should happen between between the smallest screen size in the mock-up (320px wide) and the tablet screen size (768px wide)? Should the dialog's min-width remain locked at the 288px size until we hit the next breakpoint, or should the min-width of the dialog only be limited by a margin of 16px on left and right edges?

As Bárbara described above, the specs define that the Dialog should be full-width on mobile. The 288px version just represents an instance of that full-size display.

@Sarai-WMDE @egardner right, the Dialog was designed to be full-width on mobile so 288px is just the full-width on a 320px screen.

I'm concerned that this could look a little bit strange on big phones that fall just below the tablet breakpoint (say a screen width of 600-700px). You could conceivably have a situation where the dialog is wider on "big" small screens than it is on tablet sizes.

The size difference would be acceptable. But, if we wanted to make Dialog consistent across devices, we could apply a default width of @full-width and a max-width of 512px. This way, we'd make sure that the Dialog is big enough on mobile, and yet that it never surpasses its fixed width, regardless of the viewport size.

@egardner if this implementation is possible it would be a good solution to avoid too wide dialogs on mobile.

Judging from the epic task description and the specs, it seems that these 512px would correspond to the "small/normal" size of Dialog. (This means that even the Dialog "With overflowing content" in the demo should be 512px). I didn't realize this originally, but the max-width value applied to the MVP (700px) shouldn't be equal to the "big size": users will use the "large" size prop (848px*) to make the Dialog wider than its fixed, default 512px size (i.e. the prop will update the max-width value).

@egardner as Sarai comments the dialog on desktop and tablet screens should be 512px fixed width, then it should not be wider when the dialog content is too long. We should implement the big size of the dialog component to use it in these cases with long content, so the user chooses the dialog size according to the length of the content they need to display.

*Also important, the value of the "big size" Dialog was just updated following a design discussion. Instead of 848px, we decided to use the value 896px (which is more aligned with our size & spacing scale).

As Sarai comments, we discussed about the dialog size and the new width token and we decided to create 896px instead since it's more aligned with our size&spacing scale.

Regarding Dialog sizes, I think it would be good to get everything in one place – both in terms of tokens to use as well as final pixel sizes. I want to make sure I understand the desired min-width and max-width for every combination of breakpoints (mobile, tablet+), and size options (default, large, fullscreen)  – there are a lot of variations. @bmartinezcalvo and @Sarai-WMDE, could you help me to fill in the table below? Adding a finalized version of this table to the top-level ticket would be helpful.

Dialog Sizes

VariantToken ValuesFinal Pixel ValuesNotes
Default size, base width@width-full - ( @size-absolute-200 * 2 )256px (on a 320px-wide viewport)Dialog should cover the width of the screen except for a 32px margin on left and right edges (previously this was specified as a 16px margin on each side – is 32px now the desired margin here?). This size is constrained by the max-width defined below.
Default size, max width@size-absolute-3200512pxMax width of default dialog is 512px
Large size, max width?896px?For "large" dialogs, a new max-width value should supersede the 512px value above. Needs a new token?
Fullscreen size, mobile??Should "fullscreen" variant on mobile fill the entire screen, with no visible overlay? I assume this would apply to height as well as width
Fullscreen size, tablet+??At tablet and larger breakpoints, should "fullscreen" dialogs leave a 32px margin to the edge of the screen? Should they run edge-to-edge? Or is there a max width that kicks in at some point?

Loading state: Judging from the MVP task, the loading state seemed to be in scope. But this doesn't appear to have been implemented

I don't see a loading state defined in the specs. Unless there is a clear definition of the intended behavior here, I'd recommend we remove this feature from the MVP.

@egardner as commented yesterday, I've updated the Figma spec sheet adding the new large size (896px wide) in which the dialog will be fullscreen on mobile.

Captura de Pantalla 2022-10-19 a las 10.21.30.png (758×1 px, 543 KB)
Captura de Pantalla 2022-10-19 a las 10.21.42.png (948×1 px, 729 KB)

@egardner updated table with the right values for the different dialog sizes and breakpoints (you can also check each size in the Figma spec).

Dialog Sizes

Default size
BreakpointToken ValuesFinal Pixel ValuesNotes
Desktop Wide + Desktop + Tablet?512px min and max widthDialog will be always 512px in desktop and tablet.
Mobile, min width?288px (on a 320px-wide viewport)Dialog mobile should be full-width content (16px on each side between dialog and screen) with a visible overlay behind the dialog.
Mobile, max width?512pxDialog mobile will be 512px max-width with a visible overlay behind the dialog.
Large size
BreakpointToken ValuesFinal Pixel ValuesNotes
Desktop Wide + Desktop?896px min and max widthLarge dialogs will be 896px in Desktop Wide and Desktop breakpoints
Tablet, min width?576px (on a 640px-wide viewport)Dialog tablet should be full-width content (32px on each side between dialog and screen) with a visible overlay behind the dialog.
Tablet, max width?896pxDialog tablet should be 896px max-width.
Mobile?Fullscreen (320px on a 320px-wide viewportLarge dialog will be always fullscreen on mobile (with no visible overlay since the dialog will cover the entire screen).
NOTE: not sure about the spacing&size token names since they are being updated.

Change 834410 had a related patch set uploaded (by VolkerE; author: VolkerE):

[design/codex@main] tokens: Add design-first Dialog backdrop background color tokens

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

Change 834410 merged by jenkins-bot:

[design/codex@main] tokens: Add design-first Dialog backdrop background color tokens

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

Volker_E updated the task description. (Show Details)

Change 837753 merged by jenkins-bot:

[design/codex@main] Dialog: MVP Design Fixes

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

egardner updated the task description. (Show Details)

Change 845041 had a related patch set uploaded (by Eric Gardner; author: Eric Gardner):

[design/codex@main] [WIP] Dialog: Mobile fullscreen scroll-locking

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

Drive by comment...
On the mobile website we currently show the close icon on the left hand side. I believe this is because the RHS is reserved for progressive actions and we want consistency between them:
https://en.m.wikipedia.org/wiki/Second_Battle_of_Cape_Finisterre#/languages
https://en.m.wikipedia.org/wiki/Second_Battle_of_Cape_Finisterre#/editor/0

Screen Shot 2022-10-24 at 5.33.21 PM.png (1×2 px, 170 KB)

Screen Shot 2022-10-24 at 5.33.45 PM.png (1×2 px, 368 KB)

Screen Shot 2022-10-24 at 5.35.09 PM.png (1×2 px, 306 KB)

Is the expectation that these components could be swapped in on mobile, or would mobile use a special kind of dialog e.g. MultistepDialog ?

@egardner here's what the fullscreen dialog looks like on mobile safari (latest version on iOS 16.1). There's a bit of jank on both open and close.

Change 849191 had a related patch set uploaded (by VolkerE; author: VolkerE):

[mediawiki/core@master] Update Codex from v0.2.1 to v0.2.2

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

Change 849191 merged by jenkins-bot:

[mediawiki/core@master] Update Codex from v0.2.1 to v0.2.2

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

I am going to close this task as "declined" for now. We can't really move forward with final design fixes until we first have consensus on how to handle mobile full-screen dialog behavior (see: T321893: Evaluate fullscreen mobile Dialog in Codex).

@Jdlrobson I'd recommend raising your comment there to help inform any design decisions that need to be made.

Once T321893 is resolved, we can return to the Dialog MVP and finalize it based on the agreed-upon design.