Closed pepakriz closed 7 months ago
Name | Link |
---|---|
Latest commit | e256e7c0c5d4ebea7a6d94847330507348c74393 |
Thanks for the PR!
I think this needs a little bit more design thought as we may need to support multiple 3rd party apps going forward.
I think we should have a single generic icon next to the existing set, with a hover showing the 3rd party app required. e.g. Qerko, cryptoconvert (used at Pick n Pay in SA).
@cogentgene @3j2009
I'd like to take this opportunity to redesign the card entirely as there's a number of design issues with the existing cards that I think can be improved. I'll incorporate the 3rd party payments into the new design.
>>>>>>>> Please see the comments in the Figma file for import change details to the card
@3j2009 I attempted to modify the code based on your graphical suggestions. Take a look. To check the interactivity, it would be best to deploy the current version to a test environment.
@pepakriz can you please add the merchant's website
there in with navigate
and share
. The website's link is the value from the website
tag in OSM if one is found. If no website tag is found for the merchant than the website button's display should be hidden.
Also please can you populate the 'type' descriptor under the merchant's name, which is "hairdresser" in the prototype example I posted. We should be able to grab that info from OSM using the text value from any/all of it's respective OSM tags that match:
("shop=
" || "amenity=
" || "business=
")
@3j2009 Take a look:
@pepakriz everything looks good, thanks!
👀 @dadofsambonzuki
Looks good to me.
Needs @secondl1ght to review and deploy to a test environment.
Hi @secondl1ght , just in case you missed the notification. Could you please check this out? Thank you.
Hey @pepakriz thanks for the PR, sorry I have been very busy and haven't had time to look at this yet. But I will make some time next weekend to review this!
Thanks for the PR!
I think this needs a little bit more design thought as we may need to support multiple 3rd party apps going forward.
I think we should have a single generic icon next to the existing set, with a hover showing the 3rd party app required. e.g. Qerko, cryptoconvert (used at Pick n Pay in SA).
@cogentgene @3j2009
As mentioned above and in some of the other Querko threads we want to keep this generic, that way any third party provider that doesn't natively support bitcoin can add the required tags to OSM and a warning to notify the users will appear on BTC Map. So this won't include any specific company logos. I like the idea of having it at the end of the Payment Methods row. I have an icon set I can have a look at to see some that might make sense for this generic purpose. And a tooltip that displays the name of the third party app required would work nicely and work the same as the current icons. Please let me know if you don't want to spend any more time refactoring this and I could add this feature for you. Sorry again for the delay in responding.
@secondl1ght what are the proposed benefits to support your suggested UI against the current design?
@3j2009 I assume that motivation for that is lower maintenance in the future. But still there might be some fall-back (default) icon for third parties and if you add specific one it looks better than. Isn't it?
But it's not my call, so I'm sorry for the interruption.
Hi all - just wanted to bump this to a conclusion.
I think we have a good solution with a generic icon and a specific tooltip based on an OSM tag.
@secondl1ght - are you comfortable?
Yes I can bring this across the finish line with the changes we talked about - I have been focusing on other higher priority items but it's on the TODO list to complete this and close it.
@secondl1ght So what is the next step? Is my code still relevant? I can rebase it to the main branch, but I'm unsure about your final vision. (yes, I realize it needs to use TypeScript, no problem)
I will close this PR since it is outdated and we refined the scope of this task and I will finish making the changes on the master branch that we talked about. I may have time to get this finished this weekend but if not then I can do it next weekend for sure. Thanks again for helping with this!
Is this the outcome?
There are businesses that support for example lightning and 3rd party app at the same time...
Yep, that is the outcome for 3rd party apps.
Merchants that also accept payments directly should logically have the other icons shown in addition for sure. Perhaps they were tagged because their legacy provider was on-boarded without their knowledge for example.
Ooops, didn't mean to re-open the PR!
For example this business accepts Qerko (3rd party) and lightning at the same time.. But there is visible only mobile icon (3rd party) https://btcmap.org/merchant/node:2035703150
Is this the outcome?
There are businesses that support for example lightning and 3rd party app at the same time...
Hi @hynek-jina, that is not what the tag name suggests payment:lightning:requires_companion_app
. It says that a companion app is required, not optional. Also if the merchant accepts regular lightning payments then there is no need to advertise a third party app because the interoperable option is preferred. This tag was meant to flag businesses that ONLY accept via third party as it could cause friction when a customer visits the store and they discover they need to download an additional app. If a merchant accepts native lightning then there is no need to notify the user of any extra requirements and they can proceed as usual. We actually want to promote native options over walled gardens. So basically if payment:lightning
exists then payment:lightning:requires_companion_app
should be removed as they are conflicting tags.
This seems a bit messy to me. payment:lightning
should mean that you can pay there directly with lightning. You shouldn't be able to overwrite it by some additional third party. These 3rd parties might not know about businesses ability to accept native lightning..
In case the merchant accepts btc over Qerko, we add these tags:
'currency:XBT': 'yes',
'check_date:currency:XBT': ...,
'payment:lightning:requires_companion_app': 'yes',
'payment:lightning:companion_app_url': 'https://www.qerko.com',
and then we can recognize the difference between native LN, LN over Qerko, or both simultaneously.
edit: BTW my original PR works in this way.
Agree with @hynek-jina and @pepakriz.
We shouldn't be making decisions on behalf of merchants nor users. We should be presenting merchants faithfully 'as tagged'.
If you want it to work this way then you'll have to update the tags because it currently clearly states that a companion app is required. payment:lightning:requires_companion_app
- so it works as expected.
If you look back on the discussion on this you'll see we were always talking about how to tag locations that require a third party app https://github.com/teambtcmap/btcmap-data/issues/4283#issue-1754389589. See the very first post states in bold: 'Customers need to use Querko app (download it or use instant app) to get the LN invoice'. That's why the tag was named this way.
We even added a filter so that users can remove locations based on this tag because many users do not want to download a proprietary app to use bitcoin https://github.com/teambtcmap/btcmap.org/issues/124.
It will have to be changed to payment:lightning:companion_app
or payment:lightning:optional_companion_app
. If the idea has changed that this will be used alongside interoperable options.
I still think that this logic is not correct. These tags should be independent..
payment:lightning
then you are able to pay there natively with lightning - no matter what are other added tags.Payment tags were a mistake and they don't stand a single chance of being officially accepted by OSM. I agree that payment:lightning
should always mean native LN. We're basically discussing the parsing priority when we have conflicting data due to a poor tag system design. In my view, payment:lightning
should have a higher prio, so we can stop the parsing routine and ignore the rest of the tags if we can find this tag and if it's set to yes
.
We can also simply delete the rest of the tags once the place is converted to native LN.
I would prefer to keep both information.
I agree with @bubelov. But @hynek-jina what you are talking about can be achieved however there is currently an issue with the tag naming convention that needs to be resolved as I mentioned. I think Querko is the only one using this tag so it should be safe to proceed with a bulk update if you want to.
Where is this discussion about naming convention?
Pick'n Pay is South Africa falls under this category too, but currently doesn't use the 3rd party app convention.
I am in contact with them about bulk re-verification and so it would be a good time to add the 3rd party tags once agreed.
Hi all,
I'm a developer from Qerko, an app that enables you to pay at restaurants without interacting with a waiter. Three months ago, we introduced Bitcoin Lightning support, and over this period, we've stabilized it. It is now highly usable and issue-free.
During this time, I've been collaborating with @hynek-jina, who is working on finding a good solution to tag Qerko restaurants in OSM. You can follow the discussion here: https://github.com/teambtcmap/btcmap-data/issues/4283
Now, it's time for the next step: improving the visualization on btcmap. Currently, it's challenging to identify restaurants that natively support Bitcoin and those that require a third-party app. In this merge request, I've introduced a new section called "3th Payment Methods." You can see it as part of the popup marker on the map and on the merchant page details.
The solution is designed for future expansion. If someone wishes to add another third-party app, they simply need to update the configuration in the thirdPartyPaymentMethods config. That's all.
This was my first experience with the Svelte library, so I'm not sure if the code adheres to best practices. Please let me know if there's something I can improve.
Maybe this can be an answer to this issue https://github.com/teambtcmap/btcmap.org/issues/104