Proposal talk:Mobile apps

Brand wide tagging

I'm not very fond of the idea of a brand:app:*=* tag. How many stores have their own proprietary phone app? I see no particular use in distinguishing among the app of a brand and the app of a shop if the latter happens very unfrequently. --Davidoskky (talk) 11:40, 29 September 2022 (UTC)

Many museums have their own app. The brand:*=* namespace is established to be used for anything that relates to the brand instead of the specific element, e.g:

• website=* relates to the specific element, while brand:website=* relates to the brand
• wikidata=* relates to the specific element, while brand:wikidata=* relates to the brand

So for the sake of consistency app:*=* should also relate to the specific element (while brand:app=* may be used to relate to the brand).

--Push-f (talk) 12:27, 29 September 2022 (UTC)

Android vs Google

I don't understand the rationale used to deprecate android in favor of google. To me android appears more specific than google and better explains that the app/payment system runs on android. Independently of the kind of app store you're using, the application runs on android. --Davidoskky (talk) 11:49, 29 September 2022 (UTC)

The tags are meant to link a particular app in a particular app store. Since there are multiple app stores for Android it would be negligent to have app:android=* only refer to the Google Play store. E.g. there's also the Amazon Appstore or F-Droid. --Push-f (talk) 12:27, 29 September 2022 (UTC)

There is also the Google Chrome Webapp store to confuse things, and recent Google Chromebooks can install Play store apps and Chrome store apps. I don't think there is a significant issue with payment:app:android=* due to the Play store monopoly, and even if something did come and challenge it the majority of app ids are the same as they are defined by developer, not by the Play store. But even if that was the case, I don't think there would be an issue with introducing payment:app:epic=* or payment:app:android:epic=* in the future. --CjMalone (talk) 09:31, 1 October 2022 (UTC)

Since the proposal defines app:*=* to be about mobile apps, it should be clear that app:google=* is about the Play store (as opposed to the Chrome Webapp store). The Play store does not have a monopoly ... it has the largest market share but there is nothing stopping an Android user from using one of the alternative app stores. And yes while app ids are defined by the developer, an app id that cannot be resolved to a specific app store is quite pointless. Referring to the Google Playstore as just "Android app store" is like referring to Google Maps as just "maps", it's neglecting that there are other (good) alternatives. --Push-f (talk) 07:16, 2 October 2022 (UTC)

Payment app

I don't understand why the methodology used to install the application should be relevant in this case. The app store used should not be listed in my opinion. Thus, in my opinion payment:app:android=* and payment:app:apple=* work perfectly well. I'm not sure how many different applications to pay exist, but I also don't see a great relevance in dividing among android and apple phones. In my opinion if the applications used to pay are not excessive this could simply be tagged as payment:app=* and allowing multiple values, such as google pay; apple pay; wechat. --Davidoskky (talk) 11:57, 29 September 2022 (UTC)

For general mobile payment services payment:app=* should not be used at all. payment=* already recommends payment:google_pay=*, payment:apple_pay=* and payment:wechat=*: this proposal does not aim to change anything about that. payment:app=* should really only be used for payment apps that are not general payment services but can only be used with the given amenity like e.g. Beryl Bikes (which is currently tagged as payment:app:android=cc.beryl.basis). I will clarify that in the proposal. --Push-f (talk) 12:27, 29 September 2022 (UTC)

Yes this is very strange! For example, Alipay and WeChat are 2 major mobile pay app in China, we only say "怎么付？支付宝还是微信？"(Which payment method do you want? Alipay or Wechat?) when pay the bill, don't care using a iPhone or Android phone. It's people's habit and policy let this APP survive, not device its self. Payment service will adapt to new device. If they force to specify divice, I only can use app:ios=alipay;wechat+app:android=alipay;wechat, value are same and long-winded. --快乐的老鼠宝宝 (talk) 19:20, 8 October 2022 (UTC)

As explained in the proposal app:*=* should NOT be used for such common payment providers. For Alipay and Wechat you should just use payment:alipay=yes/no/only and payment:wechat=yes/no/only respectively. --push-f (talk) 20:00, 8 October 2022 (UTC)

Application names

I don't like the idea of using store specific identifiers to describe the app. app:apple=id621307961 and app:google=nl.rijksmuseum.mmt tell nothing about which is the app. Moreover, if the identifier changes on these databases the data on OSM will become erroneous. I'd rather use the actual name of the application, so that it can be easily understood by humans. Moreover, this does not address applications which are not provided from a store and it does not specify which system it is for. app:zhushou=95487 provides basically no useful information to the user; all information has to be retrieved from external sources rather than being incorporated within OSM data. --Davidoskky (talk) 12:05, 29 September 2022 (UTC)

These tag values can very easily be turned into links to the app store pages (you just have to prefix https://apps.apple.com/app/ for app:apple or https://play.google.com/store/apps/details?id= for app:google).

On the app store pages you can then read the up to date information about these apps as well as install them if you so choose to.

App identifiers cannot be changed. They will only break when an app is removed from the app store (which does however of course happen sometimes).

App names can easily be changed (without having to remove the app from the app store) and are thus more likely to become out of date. Furthermore there can be multiple apps with the same name in the same app store (whereas the app ids are unique within the app store).

It is extremely uncommon for mobile apps intended for regular people to be distributed outside of any app store. Apple does not even let you install apps from outside their app store. For Android such apps could be linked with e.g. app:apk=https://example.com/myapp.apk.

I strongly disagree with e.g. app:google=nl.rijksmuseum.mmt not providing any useful information to the user. Most users do not look at raw tags but instead use some app. Once these tags are improved they can be supported by apps which can turn these identifiers into links, which users can click, making them quite useful.

--Push-f (talk) 12:40, 29 September 2022 (UTC)

I do understand the points you are making and they do make sense. I don't think that providing information regarding the specific methodology used to install the application should be important. You can have the same application of different application stores, and both in android and apple systems. I believe the main information to be provided should be the name of the application or the official website, and then some more specific tags might be introduced to specify how that app can be retrieved. Thus I think your proposal might be left unchanged in regard to this, but I'd like to have something like app=* to have the name of the app and app:website=* for the actual website of the application.--Davidoskky (talk) 12:55, 29 September 2022 (UTC)

Since I propose to have different tags for different app stores, it's absolutely no problem that an app can be in multiple app stores. I fail to see how the application name or the application website are of particular interest. The app store page of a particular app generally acts as its web page (and prominently features the app name). --Push-f (talk) 13:10, 29 September 2022 (UTC)

Mobile applications for different types of actions

In a place there you be different mobile applications recommended or required for different actions. The action of payment is mentioned in the proposal. But such applications can have another usages. Think in the infamous German application Luca, which was required to trace Covid19 infections in some places in Germany for some time. An example for this application: To visit a restaurant in the administrative district of Nordfriesland it was required to check in with that application. The locations in which such check-in was required could offer payment via mobile applications and it could (although such requirement seams to be not relevant in spread in that country) require a reservation of a table via a application in advance.

I advice to expand the proposal in the following manner: Application tagging should be namespaced always. Useful prefixes beside payment:app could be: reservation:app and payback:app. Another namespace to differentiate between required and recommended application usage could be useful too.

--Sdicke (talk) 16:59, 29 September 2022 (UTC)

I don't think that apps should always be namespaced. E.g. if a museum has an app, I think it's fine to tag that as app:*=*. I have never used any reservation or payback apps so I don't consider myself in a position to suggest tagging for those. I'll however add some text to encourage tagging $purpose:app:* where $purpose may be payment, contact or some other purpose. --Push-f (talk) 19:59, 29 September 2022 (UTC)

Include web applications?

To achieve a uniform tagging, the inclusion of web application usage possibilities could be included in this proposal. Think in cinemas or theatres that allow to buy ticket in advance with a simple seat choice in addition to the possibility to buy it at the location without a guarantee that any seat is free and a limited seat choice. From a technical point of view mobile applications and web application are in many cases (almost) the same.

--Sdicke (talk) 17:05, 29 September 2022 (UTC)

I think web applications can already be tagged perfectly fine with website=* (or $something:website or website:$something ... depending on the tagging convention). --Push-f (talk) 20:01, 29 September 2022 (UTC)

ios ids

Resolved

The current usage of payment:app:ios=* is to just use the (numeric) id, this proposal says to prefix it with "id". While I don't have a massively strong opinion, I don't think the prefix is useful. --CjMalone (talk) 09:47, 1 October 2022 (UTC)

Thanks for pointing that out! You're of course right, I have updated the proposal accordingly. A certain advantage of omitting "id" is that the values correspond to the values of Wikidata:Property:P3861. --Push-f (talk) 23:36, 1 October 2022 (UTC)

Maybe those kind of application name too complex? And must google?

In some countries, like China, we don't use google play, the major app install method on Android is APK. Developer usually won't upload to Gplay, so how can I provide application name? the com.xxxxx.yyyy long name? That's something "official_name", not "name". In my opinion, "name" should be more common "WeChat", and "package_name/official_name" is you wanted "com.tencent.mm".

And China user have many different app market, Huawei/Xiaomi/Vivo/Oppo, every manufactor trying to build a eco-system of their own, user can't install other market if they don't get root. But app's package name are same, developer will publish them in every market. So should I duplicate them for 4 times? Things will be like app:huawei_market=com.tencent.mm+app:xiaomi_market=com.tencent.mm+app:oppo_market=com.tencent.mm+app:vivo_market=com.tencent.mm……But they are the same thing, same app.

--快乐的老鼠宝宝 (talk) 19:10, 8 October 2022 (UTC)

For payment apps, please see my reply in #Payment app. And as I explained in #Application names I think for other apps app-store specific tags are the way to go, because just because app identifiers are commonly the same across app stores, they do not have to be. And no :google is just an example, you could just as well use :huawei or :xiaomi. --push-f (talk) 20:04, 8 October 2022 (UTC)

Sorry for use this app as example, WeChat is not only a payment app(this part had been suggested in #Payment app, thank you!), but also a daily SNS app, also entry of many miniapp(talk about miniapp should after this short story: #What_about_local_forced_app_and_miniapp?, this is a very knotty problem I think).--快乐的老鼠宝宝 (talk) 20:36, 8 October 2022 (UTC)

So……I truly have to mention the app's name/package name for 4 times? 😭--快乐的老鼠宝宝 (talk) 20:36, 8 October 2022 (UTC)

And what about package name or common used name's suggestion? like Key:official_name--快乐的老鼠宝宝 (talk) 20:36, 8 October 2022 (UTC)

What about local forced app and miniapp?

I don't know whether other countries will have same problem with us, but this is real in China, let's see this scenario: (A short story of daily life, hope you can enjoy it):

One day, @快乐的老鼠宝宝 want to buy some fried chicken in KFC near home, so she use "Beijing Bus" app take a bus, this app automatically call "Beijing Health Code" wechat miniapp for getting PCR result, and call "Alipay" to pay bus fee without password, but those 2 action is unaware to her. Then when she want to enter that KFC, she was asked to scan QR code using "Beijing Health Code"(In Beijing if you don't scan QR with this miniapp, you can't enter any public places, this is local policy), and only can order food in a wechat miniapp called "KFC order", then use "WeChat" to pay for it.

Don't digress to epidemic prevention, let's only focus on tagging itself. So can you tell me how should I tag "app" for the bus route and for this KFC?

1. Should those force used app/miniapp used to get entrance places be tagged?
2. How to clarify this is miniapp(What's worse, you can't get appid if don't use debugger), because now almost every brand have its' own miniapp, and based on wechat, so every shop are using wechat?
3. And which app refer to this restaurant? The "KFC order" or "WeChat"? If you choose former, that's because the behavior of order related to restaurant, and if choose later, that's bacause you pay with this app.

After this series of question, some mapper tag this restaurant with app:pay:<platform, ios or android>=WeChat+app:order:wechat_miniapp=kfc_order, and another mapper think should be app:platform:<behavior, such as pay or order>=*, so they meet with a edit war. Thank's to previous talk, so we don't need to tag payment application, just payment=*, but other behaviors?

Just after writing this little story, I'm already afraid of using app-related tags.

--快乐的老鼠宝宝 (talk) 20:18, 8 October 2022 (UTC)

Haha, thanks for the short story :) And thank you very much for bringing these questions up!

1. If using an app is required for all public places in an administrative area, I think that should be tagged once on the area relation instead of on every single public place within the area. Which tag to use for this ... I don't know.
2. This is a very good question. I am unfamiliar with WeChat mini apps but it seems like you don't have to install them? I should clarify my proposal that a primary purpose of the app:*=* tags is that they can be turned into install links. If WeChat mini apps don't need to be installed, tagging their name instead of their app id might make more sense (especially if miniapp ids are difficult to find out and not really helpful).
3. I don't quite know how the behavior should be tagged exactly. But the tagging scheme I propose is $purpose:app:$platform=$identifier (I'll try to clarify this in the proposal). So yeah e.g. order:app:wechat=kfc_order would be in line with the proposal. But please note that my proposal currently does not specify any purposes other than "payment" because there can be many purposes, so I don't think that the first proposal about mobile app tagging should attempt to specify all of them.

--push-f (talk) 21:29, 8 October 2022 (UTC)

1. It's not an attribute of the POI. Thus it shouldn't be on the POI.
2. This miniapp have own URL in the wechat. Is there any QR or how could I find out which miniapp I need for payment for the bus ride? Or can you share (not inside WeChat but SMS or email) the miniapp to others? There you'll find the URL to the WeChat and the miniapp. I'm not familiar with mobileapp development but I'm sure that URL looks like wechat://mini_app/BeijinBus or http(s)://wechat.cn/mini_app/BeijinBus something like that. I saw webpages that lead to exact page in the correspond mobileapp (aliexpress, bank apps, but not WeChat). And this URL may work for the proposed scheme.
3. We have simple payment:wechat=yes/no/only scheme (it tells that you can pay with WeChat but gives you no details). It might be extended with miniapp name like payment:wechat=BeijinBus as in contact:telegram=*: first part of the tag (key) points to WeChat app or website and second part (value) is a link to the miniapp in WeChat. And this will work on any mobile platform, but it will be a headache of mobileapp developers (they must program behavior of their apps for this tag).

--VlIvYur (talk) 08:32, 20 October 2022 (UTC)