Advertisement
Guest User

Untitled

a guest
Jun 10th, 2019
612
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 11.52 KB | None | 0 0
  1. [15:27] <micah_> I hope someone can help shed light on how I can make a feature request to fix this issue or allow devs like me to make local changes
  2. [15:29] <@koopajah> micah_ : One of the reasons is that Apple has strict guidelines/rules for their button and it has to match those. For non-Apple we use our own generic button that works for all (Google Pay, Microsoft Pay, Samsung Pay, etc.)
  3. [15:30] <micah_> @koopajah: i hear you and that's similar to what the Github comment said (although the dev in that comment included Apple Pay in his list)
  4. [15:32] <micah_> @koopajah: the purple button, as nicely designed as it is, doesn't make sense when added above another generic "Buy now" button provided by the WordPress theme. It becomes a UX issue of why should I use one button over the other? Why is one purple and the other is black or whatever the theme used
  5. [15:33] <@koopajah> I would discuss this with WooCommerce though that's their implementation. But if you have the Apple Pay button you shouldn't be getting the other one. It's supposed to be one button
  6. [15:34] <micah_> @koopajah: Someone on the WooCommerce forums directed users to Stripe's documentation saying it's a Stripe issue that must be addressed: http://ideas.woocommerce.com/forums/133476-woocommerce/suggestions/33869989-replace-purple-buy-now-button-with-g-pay-branded
  7. [15:35] <@koopajah> sure, that's just misunderstanding though. Their code decides which button to show and one. Unfortunately we don't control that code, they do (or you if you change the code). As long as they mount PaymentRequest once there would be just one button
  8. [15:35] <micah_> @koopajah: correct, Apple devices only see Apple Pay button, Android users only see Purple Button. But both devices additionally see the default "Add to Cart" button provided by the chosen WordPress theme's WooCommerce plugin
  9. [15:36] <micah_> I wrote incorrectly that it was two "Buy Now" buttons. It's a Stripe Payment Request button above a theme's WooCommerce provided "Add to Cart" button
  10. [15:36] <@koopajah> gotcha. Fwiw many websites do the 2 buttons. But ultimately this is still 100% controlled by WooCommerce
  11. [15:38] <micah_> @koopajah: I think we're talking around each other. The UX for an Apple Pay button to show makes more sense. You see Apple Pay on top of "Add to Cart" button. This makes more sense to a user despite the fact that it's still a little confusing.
  12. [15:39] <@koopajah> yeah sorry, I don't understand what you're asking anymore.
  13. [15:39] <micah_> @koopajah: The more confusing UX is a generic "Buy Now" button on top of a "Add to Cart" button. The unbranded, usually not consistent with the theme's brand, button is confusing to see. There's a lot of similar comments on various sites saying similar things
  14. [15:39] <micah_> @koopajah, should I provide images? I can do that
  15. [15:40] <@koopajah> micah_ : Hmmm okay I think I see. Ultimately though this is absolutely something that only WooCommerce decides, not us
  16. [15:40] <micah_> https://woocommerce.com/wp-content/uploads/2018/01/mobile_payment_screens.png
  17. [15:40] <@koopajah> I do hear your point. I disagree though, but I see what you're saying. The idea with this button is to become canonical and well know, the way the old "Pay now" for Checkout was.
  18. [15:40] <micah_> In the third screenshot from the image I linked to, this purple button sticks out and does not make sense. It cannot be updated stylistically to match the brand colors of the theme
  19. [15:41] <@koopajah> You can technically brand it your way by just showing your own button instead too
  20. [15:42] <micah_> Since that button is served in an iframe from Stripe, what you're saying about "showing your own button" isn't really true unless I modify the WooCommerce plugin itself. It's confusing why I would get a correctly branded Apple Pay icon and not a Google Pay or Samsung Pay or Microsoft Pay icon
  21. [15:42] <micah_> But specifically, I think a large majority of people would need styling for Google Pay using Chrome
  22. [15:43] <micah_> The purple button creates a UX issue as it's provided
  23. [15:43] <micah_> and if I was to remove or hide the "Add to Cart" button, I'm taking away the correct functionality from WooCommerce that should be there
  24. [15:43] <@koopajah> I know, but we just disagree here. What you're saying is a personal judgement (which is totally fair)
  25. [15:44] <@koopajah> But again, this is just the payment request button. You can use your own button and style it your own way without issue, it's just JS.
  26. [15:44] <@koopajah> We believe this button is recognizable and will become more and more common as websites adopt it (which you disagree with, which is fair too)
  27. [15:45] <micah_> @koopajah: I'm confused on how we disagree. A purple button that doesn't match the brand, which is served by Stripe but doesn't say it's from Stripe... I'm not following how that's recognizable. I'm totally willing to understand but without any branding, it is out of place with the theme.
  28. [15:46] <@koopajah> I don't know how else to explain it. Your point is "this button is not recognizable". And I would say that if you talked to customers who have used it and are familiar with it they would disagree.
  29. [15:46] <micah_> For the many reasons I laid out, I wish there was a way for me to make my case as an official feature request to Stripe to change this. If Apple Pay is technically possible, despite it being legal, it doesn't make sense why you couldn't do the same for the other brands
  30. [15:47] <@koopajah> We don't have plans to make a branded button, but this can be done easily
  31. [15:47] <@koopajah> (on your side)
  32. [15:47] <micah_> @koopjah: so there is not way for us on the developer side to make our voice heard to Stripe developers who implement this to consider changing the way this is served?
  33. [15:47] <micah_> *not a way
  34. [15:48] <micah_> I believe there's a growing number of people who would agree with me that it doesn't make sense to only provide Apple Pay branded button and not others
  35. [15:48] <@koopajah> micah_ : well there is, you just did, and I'll share that feedback for sure. But I don't believe we'd change this button just after that one feedback, and it's not something we've commonly heard before either. Also since you are using WooCommerce, you can also ask *them* to change that theme or make a custom theme.
  36. [15:50] <micah_> @koopajah: I use a custom theme provided by WooCommerce. They have been kind enough within their Stripe plugin to pull the Stripe buttons since that's the best way to integrate Stripe with WooCommerce. It's confusing to me that Apple Pay has a branded button from Stripe and others do not (nor the ability to customize the purple button returned from Stripe)
  37. [15:51] <@koopajah> Sure I understand that, but it's mostly because you want customization and we want that button to be canonical (except for Apple Pay where it has to meet their guidelines).
  38. [15:51] <micah_> But I appreciate you having this conversation and sharing this feedback with your colleagues. I do hope my voice is heard. If you need, I can provide you with several links from others who have requested similar changes to the purple button if that helps make my case
  39. [15:52] <@koopajah> if you have more links I'm happy to share those, but this is a widely used button, it's not something we'd make a unilateral change to after a discussion. And also this is extremely easy to tweak in code and make your own styling, we made this possible from day 1
  40. [15:53] <micah_> @koopajah: I hear you about the guidelines from Apple and that's fine. But you will get a lot more cheers if you were to also adhere to the Material Design guidelines from Google or the Fluent design guidelines from Microsoft
  41. [15:54] <@koopajah> Which is totally fair
  42. [15:55] <micah_> @koopajah: "extermely easy to tweak" = we'd have to request to the WooCommerce Stripe plugin devs to disregard both Apple Pay button (which looks great) and canonical purple button and allow devs to use custom buttons. Maybe it doesn't have to be all or none but it sure seems a little hacky to me
  43. [15:56] <@koopajah> that is not true, they could keep our button for Apple Pay and have their own for the rest. It really is easy and not that much code
  44. [15:57] <micah_> @koopajah: Stripe's Apple Pay button comes from your API. So (I think) they'd have to do a device detection on their end to know when to get a Payment Request API button and when not to?
  45. [15:57] <@koopajah> yes
  46. [15:57] <micah_> that doesn't seem trivial?
  47. [15:58] <micah_> It makes more sense that this API be more consistent on Stripe's end, right?
  48. [15:58] <micah_> Or maybe serve those buttons on the DOM intead of an iframe so that we have a little more control?
  49. [15:58] <micah_> i'm just spitballing ideas :)
  50. [15:59] <@koopajah> yeah, but we already discussed this. We consider it consistent across browsers, you don't because you want a different approach/feature and we disagree. I've shared the feedback though and we'll look into it
  51. [16:00] <VioletPixel> micah_: For what it's worth I actually went through customizing the Payment Request button myself in order to get the "Subscribe with Apple Pay" variant that Apple provides but Stripe doesn't support. Instead of using the button in the iframe Stripe provides you can call the Stripe functions using a click handler attached to any element you wish.
  52. [16:00] <micah_> @koopajah: i really appreciate you sharing this feedback. I really do hope a change or update will be considered.
  53. [16:01] <VioletPixel> micah_: I also used my own button instead of Stripe's "Buy Now" version for non-Apple Pay scenarios.
  54. [16:01] <micah_> VioletPixel: I need to double check, but I think WooCommerce's Stripe plugin uses PHP to talk to the JS in order to make the API request. I might be wrong about that. So it would be me hacking the plugin itself, whether PHP or JS, and WooCommerce has already directed us to talk to Stripe about this feature request update
  55. [16:01] <VioletPixel> micah_: Might be worth filing a feedback request to WooCommerce so they can do the same.
  56. [16:02] <VioletPixel> micah_: Yeah, WooCommerce needs to modify their code to make it work.
  57. [16:02] <micah_> VioletPixel and @koopajah: you can see multiple requests like mine here: http://ideas.woocommerce.com/forums/133476-woocommerce?query=google%20pay
  58. [16:02] <VioletPixel> micah_: However, there's nothing stopping them from changing the behavior today. They can replace Stripe's button with their own version, or a customizable/themeable version right now if they wanted to.
  59. [16:03] <micah_> @koopajah: this thread also goes into the same problem, and you can see 14 people have liked the comment made that outlines my same confusion: https://github.com/stripe/stripe-payments-demo/issues/9
  60. [16:04] <micah_> VioletPixel: that is valid, I understand. I think their intention of trusting Stripe to provide the correct buttons is the right one, but it is also disappointing that I don't have more control either with Stripe's API via their plugin or even their plugin itself.
  61. [16:05] <micah_> I'm kind of stuck in the middle trying to find a way to do this without directly modifying the plugin code (which could be overwritten on a plugin update in the future)
  62. [16:07] <VioletPixel> micah_: Yeah, I wouldn't recommend updating the plugin code... I think you are kind of stuck, unfortunately. Since you're not writing the code for the Stripe integration yourself you're depending on WooCommerce to do what you want at the code level.
  63. [16:07] <micah_> VioletPixel: That's correct
  64. [16:08] <micah_> The canonical button is well designed, I hope that's clear, but I think Stripe's missing an opportunity by not going with Material Design or Fluent Design buttons similar to Apple Pay's guidelines
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement