- 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. —Mike -- Michael[tm] Smith https://people.w3.org/mike
Received on Friday, 27 May 2016 03:14:26 UTC