Should show() be renamed?

[adrianhopebailie]

In TAG review @triblondon said:

I'm wondering if show() is poorly named, since in some cases a payment app may be able to fully automate its response without user interaction, in which case nothing would actually be shown. is that ever a possibility?

[adrianhopebailie]

@msporny said:

The Web Payments Community Group Browser API specification proposed .start():
http://wicg.github.io/web-payments-browser-api/checkout-api.html#simple-checkout-example

[zkoch]

Well, show() in this case is a request to the payment mediator (e.g. browser) to show details of the transaction and the intersection of supported payment methods. So as of right now, you would never run into a situation where show() didn't show something explicit.

[msporny]

@zkoch wrote:

So as of right now, you would never run into a situation where show() didn't show something explicit.

What if you're blind but can hear (audio interface)?

What if you're blind and can't hear (braille text interface)?

What if there is nothing to show (all selections can be made automatically based on user preferences)?

[sideshowbarker]

in some cases a payment app may be able to fully automate its response without user interaction, in which case nothing would actually be shown

Even if that is a possibility, from that it does not follow that the method ought to be renamed. In those cases, I would think the show() call would simply just be a no-op, and nothing would be presented to the user. Which is fine.

As far what the resulting user experience is for an end user in a screen reader or other AT, of course their SR/AT is going to present the dialog to them in a non-visual way, and so “show” is simply shorthand for “present something to the user”—in a similar way to the convention that say, telling a user to “press the Foo button” in a software UI doesn’t mean a physical button has somehow been created for them to work with, and that they have to actually “press” it in the same way they do a physical button (that is, by actually physically pushing the button down their finger so that it physically moves down)…

[dlongley]

@sideshowbarker,

Even if that is a possibility, from that it does not follow that the method ought to be renamed.

We don't have any users of this API yet, rather we're still in the design phase. That suggests to me that picking something that is even just marginally better is a good idea. We don't have to settle for "fine" just yet.

...and so “show” is simply shorthand for “present something to the user”

I think another word can convey the necessary shorthand without the drawbacks stated in this thread. For example, start, which can mean "start the payment request flow", which may or may not include presenting something to the user. All that matters is the caller of the API knows that they have fully prepared the payment request and they are now ready to ask the user agent to start doing something with it.

[ianbjacobs]

I think show() is ok (and isn't necessarily visual for all definitions) but there may be room for improvement.

The spec says "The show method is called when the page wants to begin user interaction for the payment request." Some other ideas that come to mind:

• prompt()
• getConsent()

Ian

[msporny]

Again, closed without the final decision being clearly documented.

[adrianhopebailie]

The decision is to not change anything at this time.
If there is a desire to change the name of the show() method the most useful way to exercise this would be through a PR on the spec.