Allow notification modals to have buttons stacked atop eachother

[lloydhumphreys]

Enhancement request

Description of feature

Currently, the buttons can only be side-by-side and their width is fixed. That means we end up with something like this:

and then we have to compromise and do something like this...

Example use cases and/or Prototype links

I updated the design of the notifications a while ago, so here's that link. I don't really mind where we end up with these, being able to stack buttons is the easiest fix here. https://tradeshift.invisionapp.com/share/KE7VTBXC7#/172190460_Modal-Notification-Decision

Designs and/or Prototype screenshots

[lloydhumphreys]

@jerf @bomouridsen

[wiredearp]

One could suggest that we then always stack the buttons vertically, since it would perhaps be confusing and potentially catastrophic if the Accept button changed position from last to first depending on the whim of the developer (or the locale that has the longest strings in the button label, if we do it automatically). There's by the way a bonus enhancement suggestion in the screenshot, since it allows the Dialog to have more buttons than the standard OK and Cancel buttons. If the buttons list becomes freely customizable, there's even more opportunity for inconsistent button placement between dialogs, so we should consider if this is a priority for Dialogs (with the current pattern, where Accept and Cancel are locked to positions, we by the way still have an opportunity to reverse them on Windows so that they conform to convention, I guess this will be hard once we let the developer put random buttons in there).

[wiredearp]

The buttons in the example dialog are by the way reversed, while on the subject, so that the Accept button is labeled Back while the Cancel button is labeled Send with next available ID. This is the button that will be clicked (or rather, the associated callback oncancel will be called) when the user presses ESCAPE on the keyboard, so it does make a difference. This convention will by the way also be difficult to enforce if we support random buttons in the Dialog.

[lloydhumphreys]

• I don't think it's catastrophic if we're smart about color, and perhaps enforce a pattern for generic "accept/reject" / "yes/no" / "ok/cancel" scenarios.

• I don't think that enforcing the platform native button placement matters so much. It seems like complexity we don't really have to take on, since that's not a thing users expect to be consistent on the web.

• If we just associate an oncancel with an action in the available selections, why would it matter how many we have?

We can never know what we'll need for every use case. Enforcing such a rigid selection & layout is just going to create more of these requests.

[wiredearp]

You should in that case file "[Dialog] Multiple buttons" as a separate enhancement request so that we can preserve this issue as a low hanging fruit, I think. The change in question would (or should at least) be a breaking change since the current API is hardwired for binary "accept/reject" / "yes/no" / "ok/cancel" scenarios:

ts.ui.Dialog.confirm('Will you try?', '(optional Cancel text)', {
    onaccept: function() {
        ts.ui.Notification.success('Good luck');
    },
    oncancel: function() { // also triggered on ESCAPE
        ts.ui.Notification.success('Come back later');
    }
});

This proposed new API would involve a dialog.buttons([...]) array that can be configured much like in the TopBar and I guess it would be strange to have the same buttons configured in two different ways with potential for conflicts.

But then again: The OK-Cancel dialog is a time-tested UI component that even works in native JavaScript (you can try pasting alert(confirm('Will you try?')) into the browser console) and we've never seen a request for more buttons coming from the actual product (apart from this design), so it is perhaps still open for discussion whether or not we should invent a more complicated API to let the Dialog do what the Aside and SideBar and Modal already does for us, perhaps especially if leads to non-uniform button placement.

It's probably true that we can never know what we need for each use case, but the use case can also be adapted to what we offer: If you need to accept or cancel an operation, use the Dialog; if you need so many options as the design claims, use a Modal. Perhaps that's even better than having a Dialog and a Modal (and a SideBar and an Aside) that does much the same thing, except of course the Dialog doesn't support Forms, so we would probably also need to add that :cry: To cover this apocalyptic scenario, I would personally much rather implement a non-fullscreen Modal to cover this area of enhancement :nerd_face: