MSC2790: Modal widgets (acquiring user input from a widget)

[turt2live]

Rendered

[turt2live]

Implementation: matrix-org/matrix-react-sdk#5252

[turt2live]

I'm relatively confident in this and the individuals who have had the pleasure of reading this haven't tried to suffocate me with negative feedback, so I think this is ready for FCP.

Under our new guidelines we'd normally request explicit review from a relevant spec core team member on MSCs first, but seeing as the current expert is me and no one else is volunteering, I'm essentially electing the entire core team as the secondary expert for this area.

@mscbot fcp merge

[mscbot]

This FCP proposal has been cancelled by #2790 (comment).

Team member @mscbot has proposed to merge this. The next step is review by the rest of the tagged people:

• @dbkr
• @uhoreg
• @turt2live
• @ara4n
• @anoadragon453
• @richvdh
• @erikjohnston
• @KitsuneRal

Once at least 75% of reviewers approve (and there are no outstanding concerns), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for information about what commands tagged team members can give me.

[t3chguy]

I sketched this up into a Sequence diagram for simplification.

title Modal Widgets

note over Widget,Client: standard widget init

Widget->+Client: open_modal ({...})
note right of Client: Client spawns the Modal Widget
Client-->-Widget: ACK

note over Client,Modal: standard session init

Client->+Modal: widget_config ({...})
Modal-->-Client: ACK

note right of Client: User presses a button
Client->+Modal: button_pressed ({id: ...})
Modal-->-Client: ACK

note left of Modal: Modal chooses to close with data
Modal->+Client: close_modal (D)
Client-->-Modal: ACK
note right of Client: Client destroys the Modal Widget

Client->+Widget: close_modal (D)
Widget-->-Client: ACK

[uhoreg]

I don't know a whole lot about widgets, but it looks plausible.

[dbkr]

I got some way through reviewing this but then got distracted by the infinite loop bug, so posting what I have

[dbkr]

This is true for any other type of widget though? Does it not have all the same problems anyway for displaying the URL part of the modal widget?

[turt2live]

This is true for any other type of widget though?

Yes, however modal widgets won't always be a modal dialog. On mobile clients for instance, it might be desirable to show a card or pop-in effect rather than a true dialog. In these cases, the widget would have to consider the brand, theme, and platform of the app which leads to infinite amounts of potential CSS. Instead, we pull the buttons and some other basic information out so the client can render it as natively as possible.

Does it not have all the same problems anyway for displaying the URL part of the modal widget?

which problems are you thinking of?

[dbkr]

Taking the example of the calendar add on mobile, would you not still have to have infinite amounts of CSS for the event details to match the brand / theme / etc? ie. you'll get a native, "New Event Details", native buttons and then the time / place / description in a white box in Times New Roman.

[turt2live]

Not necessarily, if taking the perspective of a cross-platform designer. A widget is typically displayed in a context where the user is aware that it's not native UI, so variances (or even completely different themes) are acceptable. A modal widget would want to provide as much native UI as possible though to give a better user experience within the app. It's much less of a concern for web apps as the CSS becomes super easy to do, but for iOS, Android, and other mobile devices there's not really a good CSS library that makes things appear as other elements.

It's a bit convoluted, but it also plays into a theory that clients can ignore the url and just natively render the widget (form) if they understand enough of the detail.

[nadonomy]

If helpful for extra context; the intent here is for modal widgets to default to native interactions for the call to actions on the platform they're being viewed on.

[dbkr]

Ah, I think the 'type' that allows clients to know what the content should be and render it natively is what I was missing here. The only mention I can see of this is in the real-world example part?

[turt2live]

@dbkr I've added a bit of clarifying text to the end of this paragraph. Let me know if it makes more (or less) sense.

[turt2live]

@uhoreg as the only other person who has ticked for FCP, it's only fair that I mention I've increased the scope of this slightly to support disabling buttons as well.

[turt2live]

Widgets are likely to change before this is worth putting in the spec. Pulling out of FCP.

@mscbot fcp cancel