Re: Web Payments Demo

Thank you for the comments, Michael. This is indeed good food for thought
for all browser vendors. I will pass this on to the product and UX teams in
Chrome.

On Thu, May 26, 2016 at 8:13 PM Michael[tm] Smith <mike@w3.org> wrote:

> 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.
>
>   —Mike
>
> --
> Michael[tm] Smith https://people.w3.org/mike
>