Re: [w3c/webpayments] [Payment Request] Should we allow a "polling" mechanism for websites to not invoke the API if there are no enabled methods (#159)

@sideshowbarker said:

> Solutions that help to address problems for other non-user constituencies involved are net bad on balance if the cost of them is that they degrade the user experience or disrupt or intrude into the normal user interaction/expectations for sites/services they want to get something done with.

Yes!  Yes and yes!  Of course the end user should have the least pain. If it ever seemed like I was not advocating for that, thank you for giving me the opportunity to correct the record.

The greatest number of users should have the least amount of pain.  Conversely, the smallest number of affected people (e.g. implementors) should be prepared to deal with some inconvenience so that the greater number of people *can* experience the least amount of pain.  

I don't think anyone involved with this activity would disagree with these precepts.

With regard to the current discussion topic... Maybe I am just being obtuse here.  I agree that onboarding needs to be as seamless as possible.  But that's a UI and flow design issue.  I am not clean what that has to do with the app that is being installed calling a "register" interface to inform the environment it is available.  

If the argument is that users shouldn't have to register anything... well, that's confusing to me.  Surely a user needs to do all sorts of things to configure a payment app the first time it is used?  Agree to install it, teach it about a payment instrument, teach it their address(es).  Yes, that's a hurdle.  Should it be low?  Of course.  But it's going to be there.  I feel like I am missing something.

---
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments/issues/159#issuecomment-236268488

Received on Friday, 29 July 2016 19:12:36 UTC