organicmaps / organicmaps

🍃 Organic Maps is a free Android & iOS offline maps app for travelers, tourists, hikers, and cyclists. It uses crowd-sourced OpenStreetMap data and is developed with love by MapsWithMe (MapsMe) founders and our community. No ads, no tracking, no data collection, no crapware. Please donate to support the development!
https://organicmaps.app
Apache License 2.0
8.7k stars 849 forks source link

[ios][android] Add fee indicator to Place Page and search results #5883

Closed dvdmrtnz closed 6 months ago

dvdmrtnz commented 8 months ago

This PR adds a fee indicator to the Place Page in iOS. This icon will show in any place that has a fee=yes property.

matheusgomesms commented 8 months ago

Great job!!! I always wanted that differentiation! Regarding the icon, I would personally use the dollar sign. I think it’s more recognizable than the bag one.

dvdmrtnz commented 8 months ago

Great job!!! I always wanted that differentiation! Regarding the icon, I would personally use the dollar sign. I think it’s more recognizable than the bag one.

🤔 I’m thinking that maybe it could be better to have it in text: Fee/No fee. That way we could have info about the feature being free, as opposed to no info available. Because I don’t thing there is a suitable "No fee" icon. WDYT?

dvdmrtnz commented 8 months ago

I've changed it to a localized Paid/Free text.

RedAuburn commented 8 months ago

I've changed it to a localized Paid/Free text.

this looks good :)

Jean-BaptisteC commented 8 months ago

What about Android?

dvdmrtnz commented 8 months ago

What about Android?

I’m not 100% sure but I think it should actually work in Android with these changes, since I’ve made this modification in the c++ core

Jean-BaptisteC commented 8 months ago

I see nothing on Android with latest build

dvdmrtnz commented 8 months ago

I see nothing on Android with latest build

Maps need to be regenerated because there is a new metadata property

dvdmrtnz commented 8 months ago

I see nothing on Android with latest build

I just tested it on Android. A minor change was needed, and now it works there too.

biodranik commented 8 months ago

Did you see https://github.com/organicmaps/organicmaps/issues/1312 and https://github.com/organicmaps/organicmaps/issues/2254 ?

How important is it to be able to quickly search by the value of the fee tag?

dvdmrtnz commented 8 months ago

Did you see #1312 and #2254 ?

How important is it to be able to quickly search by the value of the fee tag?

Yes, I saw those threads. I guess that you are asking me this because I took the "metadata" approach to adding this info, instead of adding it as a "type", right? I thought it was easier to add fee=* as metadata property and more scalable (given the limit of 7 types per feature), specially if we want to add some more properties like takeaway=*, delivery=*, capacity=*, drive_through=* and similar properties of other bigger places.

biodranik commented 8 months ago

fee is important for some other types too like parkings, toilets, etc. Using metadata in the search is possible, but it will be very slow.

dvdmrtnz commented 8 months ago

UI - no problem here.

I'm planning to refactor fee, access, etc #1312

Storing fee in metadata is not a good idea. At least because of fast reading for rendering. I'm sure, we will render some dynamic icons someday depending on these tags.

Okay. I guess we'll have to wait until the fee refactoring then.

pastk commented 8 months ago

Storing fee in metadata is not a good idea. At least because of fast reading for rendering. I'm sure, we will render some dynamic icons someday depending on these tags.

I think this solution is fine for the interim.

The fee/access refactoring mentioned is a very long shot. And dynamic icons is even longer one :) No need to wait for them when we can improve UX now.

Code changes in this PR are small, so no problem to re-do when we have a new system in place.

pastk commented 8 months ago

We've been discussing it and decided that adding separate fee-yes/fee-no types seems to be a better long-term approach.

dvdmrtnz commented 8 months ago

We've been discussing it and decided that adding separate fee-yes/fee-no types seems to be a better long-term approach.

I have tried adding to mapcss-mapping.csv:

fee|yes;[fee=yes];;name;int_name;1583;
fee|no;[fee=no];;name;int_name;1584;

But it doesn't seem to be working 🤔. I have regenerated maps and everything but it doesn't show up in the raw types. Any idea why?

https://www.openstreetmap.org/node/9341902098#map=19/42.81552/-1.64178

pastk commented 6 months ago

But it doesn't seem to be working 🤔. I have regenerated maps and everything but it doesn't show up in the raw types. Any idea why?

Types that don't have any styles defined are discarded by the generator. So you've got to add these new types into "exceptions" alongside cuisine and wheelchair in indexer/feature_visibility.cpp::IsUsefulNondrawableType().

Please add a note about this behavior into the comment in the mapcss-mapping.csv.

Also note that its better to use fee|yes;[fee?];... as it'll include non-yes values like fee=10 (basically everything except fee=no).

dvdmrtnz commented 6 months ago

@pastk @vng @biodranik PTAL. Now using fee-yes, fee-no types, instead of metadata

dvdmrtnz commented 6 months ago

Here are some iOS/Android screenshots:

Misalf-git commented 6 months ago

Is it necessary / beneficial to to show "free" in the place page?

IMO it's easier to understand information based on whether a value is present or not, instead of interpreting it.

In german, "paid" and "free" might translate to something rather similar on a quick glimpse: "Kostenpflichtig" and "Kostenfrei". Also, in case of cut off text (maybe for more languages that tend to inflate character count) this could lead to something like "Parkplatz · ​♿︀​ · Kost...".

dvdmrtnz commented 6 months ago

Is it necessary / beneficial to to show "free" in the place page?

IMO it's easier to understand information based on whether a value is present or not, instead of interpreting it.

@Misalf-git I think it's indeed beneficial to show "Free". You want to be able to distinguish no info vs no fee.

In german, "paid" and "free" might translate to something rather similar on a quick glimpse: "Kostenpflichtig" and "Kostenfrei". Also, in case of cut off text (maybe for more languages that tend to inflate character count) this could lead to something like "Parkplatz · ​♿︀​ · Kost...".

That's no problem. The line is set to wrap around into multiple lines if it doesn't fit in one line. It's the same with the cuisine for example.

Misalf-git commented 6 months ago

OK. Then it's up to the translation to prevent excessive brain activity.

biodranik commented 6 months ago
  1. With parking, is it better to display "Paid underground parking" than "Underground parking * paid"?
  2. "Paid" word alone looks weird in some contexts (the opposite of "not paid" instead of "free"). That's why it would be great to think about some short but clear symbol (or letter?) instead of text.
  3. @vng @pastk we have a limit of 7 types per feature, right? With this (and other added types), how many other types are lost? How important are these "lost types" cases?
  4. @vng you've mentioned types refactoring, how is it related to this change?
pastk commented 6 months ago
  1. With parking, is it better to display "Paid underground parking" than "Underground parking * paid"?

Maybe. But this approach is not very scalable and will complicate the code unnecessary (probably we'll have to hardcode parkings as exceptions). E.g. later we'd want to add "Private" also.

2. "Paid" word alone looks weird in some contexts (the opposite of "not paid" instead of "free"). That's why it would be great to think about some short but clear symbol (or letter?) instead of text.

https://github.com/organicmaps/organicmaps/pull/5883#issuecomment-1702449753

3. @vng @pastk we have a limit of 7 types per feature, right? With this (and other added types), how many other types are lost? How important are these "lost types" cases?

It happens mostly with cuisines and recycling types. (and the limit is 8 types actually)

4. @vng you've mentioned types refactoring, how is it related to this change?

Its first PR that converts a previously type-embedded attribute (fee) into a separate type

pastk commented 6 months ago

2. "Paid" word alone looks weird in some contexts (the opposite of "not paid" instead of "free"). That's why it would be great to think about some short but clear symbol (or letter?) instead of text.

But actually it might look OK if we use a symbol/icon for fee-yes and a Free text for fee-no..

pastk commented 6 months ago

But actually it might look OK if we use a symbol/icon for fee-yes and a Free text for fee-no..

@vng Will "paid" and "free" become searchable out-of-the-box after this change (there is a type and a corresponding translation)? If so then using an emoji as a translation will affect searchability?

biodranik commented 6 months ago

If so then using an emoji as a translation will affect searchability?

No. data/categories.txt supports emoji as search synonyms.

dvdmrtnz commented 6 months ago

Okay let's explore doing emojis. What about 💲for fee-yes and 💲✖ for fee-no:

dvdmrtnz commented 6 months ago

Emojis make it definitely easier to quickly see at a glance which results are paid/free when searching:

dvdmrtnz commented 6 months ago

Also this cross emoji approach could be used in the future for indicating for example wheelchair=no (♿️✖) which is currently not shown as far as I know

Misalf-git commented 6 months ago

The dollar sign may be recognizable by many, but IMO something international / neutral would be better.

I guess the generic "currency sign" is not known that much? ¤

And the "coin" emoji is probably too recent for older OSes. 🪙

There are several currecny related symbols in unicode though. ₣₦₧₩₪€₭₮₯₱₲₳₴₵₸₹₺₼₽₾₿

Two separate icons to depict one thing could be misinterpreted. Maybe grouping might help. [♿❌] Don't know if some can be combined in unicode.

pastk commented 6 months ago

The "paid" dollar sign emoji is great, for me its very recognisable. Not sure if its universal though... I don't know any better alternative. But the "free" version with added cross emoji is not so recognizable IMHO... Actually they look like separate entities. And no better alternatives come to my mind.. I think its better to keep it as a text.

biodranik commented 6 months ago

fee=no / fee=yes / no fee tag

(yes, it requires a bit more complex string processing, but it may be worth it)

  1. Free Toilet / Paid Toilet / Toilet
  2. Free Toilet / 💲 Toilet / Toilet
  3. Toilet / 💲 Toilet / Toilet (people care if it's paid).
  4. ~💲~ Toilet / 💲 Toilet / Toilet
dvdmrtnz commented 6 months ago

fee=no / fee=yes / no fee tag

(yes, it requires a bit more complex string processing, but it may be worth it)

  1. Free Toilet / Paid Toilet / Toilet
  2. Free Toilet / 💲 Toilet / Toilet
  3. Toilet / 💲 Toilet / Toilet (people care if it's paid).
  4. ~💲~ Toilet / 💲 Toilet / Toilet

Please no string handling. It can get quite messy with all the languages.

My options:

  1. Toilet • Free / Toilet • Paid / Toilet
  2. Toilet • 💲✖ / Toilet • 💲 / Toilet
  3. Toilet • Free / Toilet • 💲 / Toilet
pastk commented 6 months ago

Is there a crossed version of the 💲 emoji? Or a striked one like in biodranik's post?

Otherwise I like options 5 & 7 suggested by @dvdmrtnz

Note that we already have a well-established system/notion of displaying POI's additional info via a separator. I think we should use it for the fee info too for

  1. consistency
  2. to avoid complexity and high maintenance of custom strings like "Free Underground Parking", "Paid Private Toilet" etc.
Misalf-git commented 6 months ago

Seems to me like a double-negative but Iet's see if any of those will get displayed properly...

0024+043F+20E0: $͏⃠ 0024+FEFF+20E0: $⃠ 0024+2060+20E0: $⁠⃠ 1F4B2+2060+20E0: 💲⁠⃠ 1F10F: 🄏

I'd go for option 5. or 7. too, though.

dvdmrtnz commented 6 months ago

Seems to me like a double-negative but Iet's see if any of those will get displayed properly...

0024+043F+20E0: $͏⃠ 0024+FEFF+20E0: $⃠ 0024+2060+20E0: $⁠⃠ 1F4B2+2060+20E0: 💲⁠⃠ 1F10F: 🄏

I'd go for option 5. or 7. too, though.

pastk commented 6 months ago

IMHO none of those look good enough... Also their display might be dependent on available fonts, isn't it?

It might look OK if we make our own clean looking icon with a crossed dollar sign. But at the expense of hardcoding its display. And I don't think its worth it, a textual "Free" is a better option IMO.

dvdmrtnz commented 6 months ago

Some more options:

\u0024\u20dd $⃝

\u0024\u20e3 $⃣

\u0024\u20e5 $⃥

\u0024\u20ea $⃪

\u0024\u20eb $⃫

\u0024\u0336 $̶

\u0024\u20dd\u20e5 $⃝⃥

\u0024\u20dd\u0336 $⃝̶

\u0024\u20dd\u20eb $⃝⃫

It's quite funny what you can do with unicode and diacritics 🤣. Here's the list of unicode diacritics: https://en.wikipedia.org/wiki/Diacritic#List_of_diacritics_in_Unicode

By the way I am using this website to try out the characters: https://www.branah.com/unicode-converter

Some of these look okay in iOS but then look quite bad on Android 😂

dvdmrtnz commented 6 months ago

I'm setting it as Toilet • Free / Toilet • 💲 / Toilet

biodranik commented 6 months ago

@vng PTAL