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

Re: Web Payments Demo

From: Michael[tm] Smith <mike@w3.org>
Date: Fri, 27 May 2016 12:13:55 +0900
To: Rouslan Solomakhin <rouslan@google.com>
Cc: Adrian Hope-Bailie <adrian@hopebailie.com>, Tommy Thorsen <tommyt@opera.com>, Ian Jacobs <ij@w3.org>, Web Payments Working Group <public-payments-wg@w3.org>
Message-ID: <20160527031355.GC27731@sideshowbarker.net>
Hi Rouslan,

Rouslan Solomakhin <rouslan@google.com>, 2016-05-26 03:20 +0000:
> ...
> I'm not sure whether the the broader community has seen this, Chrome has
> some demo websites as well:
> 💵 https://rsolomakhin.github.io/samples/paymentrequest/credit-cards/ - a
> sample that accepts credit card payments and does not request shipping
> information.
> 📬 https://rsolomakhin.github.io/samples/paymentrequest/free-shipping/ - a
> sample that accepts credit card payments and provides free shipping
> worldwide.
> 📬 📬 https://rsolomakhin.github.io/samples/paymentrequest/shipping-options/
> - a sample that accepts credit card payments and provides a couple of
> shipping options regardless of shipping address.
> <https://rsolomakhin.github.io/samples/paymentrequest/dynamic-shipping/>
> 🏰 🗽 https://rsolomakhin.github.io/samples/paymentrequest/dynamic-shipping/
> - a sample that accepts credit card payments and varies the availability
> and price of shipping options depending on the shipping address.
> ...
> 👷 You can try these samples in Chrome Dev for Android:
> https://play.google.com/store/apps/details?id=com.chrome.dev
> 🇧🇷 Remember to enable the Chrome flag:
> chrome://flags/#enable-experimental-web-platform-features

It is great to see this becoming real.

Some comments I have that are outside the scope of the spec itself because
it’s about implementation-specific UI (but that I think are relevant for
other implementors putting together UI around this):

## Show all available payment methods in the UI at the same, on equal footing

I think the UI should not only show the one payment method that the browser
(based on internal heuristics I guess) decides on its own should be the
default displayed, and bury the rest of payment-method choices in a select
menu or other UI that requires the user manually activate a disclosure
triangle or other UI widget to see what payment methods they can use.

## Users use different payment methods depending on which merchant they use

I think one problem with trying to choose only one default payment method
to show in the UI at one time is that a lot of users use different payment
methods depending on which merchant site they happen to be buying from. So
showing those users only one default is likely to be really annoying to them.

## Suggestion: Always show all available usable payment methods in the UI

So I think the right/optimal UI here from a user POV is to always show the
user all the available usable payment methods (the intersection of the
payment methods the merchant supports, and those the user has).

I think that means practically the UI needs to show just the icons/logos
for each payment method, maybe with some minimal text (e.g., for credit-
cards the last 4 digits), in some kind of arrangement that fits as well as
it can into the limited screen real estate (e.g., the icons in rows and
columns)—but if they don’t all fit, it is more acceptable from a UX POV for
the user to need to scroll a bit to see them all than it is to by default
suppress all of them except one and force the user to always manually
activate some UI widget just be able to see more than one.

I’m not a UI designer and I realize you’re not either and you did not
design the UI here, but my comments are not intended to be just about this
particular implementation but instead that across all implementations I
think it is important that when users go to a particular merchant site, it
is very important for users to be able to very quickly and easily see all
the payments they can use with that merchant.

I think otherwise the UI is actually getting in the way of the user
instead of helping them, and not giving the best user experience.

And although this is a spec for a programmatic API and not for a UI, I
think the considerations around the UI here are highly relevant in the
particular case of this API, because the highest-priority goal for this
spec is to streamline the checkout user-experience for users, and getting
the UI right across implementations is essential to that.


Michael[tm] Smith https://people.w3.org/mike

Received on Friday, 27 May 2016 03:14:26 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 May 2016 03:14:28 UTC