W3C home > Mailing lists > Public > public-payments-wg@w3.org > July 2016

[w3c/webpayments] [Payment apps] How can we optimize user experience when there is only one match? (#169)

From: ianbjacobs <notifications@github.com>
Date: Tue, 19 Jul 2016 13:40:51 -0700
To: w3c/webpayments <webpayments@noreply.github.com>
Message-ID: <w3c/webpayments/issues/169@github.com>
Up to now we have described the following user experience for third party apps

1. User pushes a "buy button" on the merchant site. This causes the browser to display matching apps (or their instruments)
2. The user selects an app and the browser hands control to the app.
3. The user then selects a way to pay from within the app.

It has been pointed out that when there is only one match, it would be a bad user experience to have to select the same information twice. Therefore, it has been suggested that, in essence, we combine 2 and 3 above into a single selection when there is just one match.

I don't yet know whether this should be a requirement; my guess is that it should not be, but that everyone will seek the improved user experience anyway. The question is: what information is required (if any) to enable this better user experience? What does the specification need to say?

For example, if we support the ability of mediators to display specific payment instruments (e.g., by showing a card nicknamed "My favorite credit card") then ideally I should be able to click on that
in the mediator to complete payment. One way this could work would be that when I click, the mediator hands off control to the third party payment app, which immediately returns data given the payment method in question (a credit card). So step 3 turns out to "still exist" but it happens without additional user interaction.

Is this how others view third party payment app interactions working? 

Ian

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments/issues/169
Received on Tuesday, 19 July 2016 20:41:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 19 July 2016 20:41:46 UTC