present_ Eiji
<scribe> Agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2018Sep/0013.html
"Web Payments"
IJ: I think we should go with Web Payments. No other great option. And Browser Payments is too narrow.
Eiji: Some pushback that Web
Payments includes traditional forms
... I think we should still go with Web Payments for the
feature set with PR API etc.
Lawrence: Is the intent to have a name that we would communicate to the consumer?
IJ: Yes, but more like RSS Logo than Apple Pay type logo.
Lawrence: From a consumer perspective, my question would be - do they know that Google Pay is powered by PR API? Do they care?
Eiji: I have an explicit answer -
I would love to connect the user's mindset with the PR API UI
("the sheet")
... if the merchant directly launches google pay they should
use that logo
... only show visual identify if the sheet is to be shown
IJ: +1 to the view that the visual identity is associated with the button and sheet
Heath: +1
... I am getting a sense that "Web Payments" will be the
experience of going from the button to the sheet.
... do we want the experience (visually) to be different
... like a dynamic animation?
... you go from the button to the sheet
IJ: Any thoughts on that idea?
Lawrence: Is the idea to get the same experience across browsers/platforms?
Heath: ideally, yes.
... the question is how different do we want that experience to
be. I think Web Payments may be defined by that experience.
Eiji: I think it's an
implementation specific question
... it may be complex to convince each browser to implement it
the same way
... I think there if there are easier ways to associate sheet
and logo...may be better
[IJ on merchant identity/browser chrome]
Lawrence: When it comes to
consumer behavior, we need to tell them it's a consistent
experience; give confidence to user
... we can draw up a few proposals get get feedback from
consumers.
IJ: TPAC! :)
... but I realize those are Web people
Lawrence: We need to get avg consumer feedback
Eiji: The Chrome team is thinking
about revamping the UX
... one idea that came up was to make the payment sheet
paged.
... start with shipping address...then payment method..then
shipping options
... that way it can replicate the existing UX
IJ: What about one-click payments?
Eiji: Just wanted to mention this
as one idea
... still in brainstorming phase
... due to user expectations about the order of thing they
usual do on a site
Heath: The physical design of the
page could lend itself more to web payments
... it's a chance to reorganize and keep things simple
... you hit the button and one sheet opens...after the logos
there's a simple set of buttons: shipping, billing, payment
type
... rather than multiple screens, you do one at a time in the
sheet
... but the way it's laid out is an opportunity to do something
clean and different from how other things are set up
... I think UX will play a heavy role in experience
https://github.com/w3c/webpayments/wiki/Brand
https://github.com/w3c/webpayments/wiki/Web-Payments-API:-Brand-Analysis
===
Efficiency / Speed
Simplicity / Convenience
Payment / Money
Security / Trust
====
Heath: I have favored Simplicity
and Trust
... consumer will see something new, which raises another
question
... would we announce this and provide a cheat sheet on what's
to come?
IJ: Official announcement at Rec (with other materials); but we need feedback sooner
IJ: I would like to use TPAC to
get feedback on designs (by Heath)
... Would be interesting to see in the sheet an example of the
logo
Eiji: We also have the Samsung suggestion in slack
+1 to keeping Mozilla and Samsung int he loop in particular as we get closer to tpac
IJ: Timeline?
Heath: I can start to load sketches by end of this week
<scribe> ACTION: Heath to make available some sketches; we will review at the 27 September call
Next meeting on 27 September
RESOLUTION: We will call these Web Payments
(However we will continue to look at WebPay)