pastk commented

Member

Our map files already contain ~3.5M OSM description tag values. They should be:

Visible to users
Editable

We can start with (1), and then proceed with (2).

The most complex part of the Place Page is that our bookmarks can also have a description. And there is a Wikipedia description section too.

Previously there was no UI for it. Let's design and enable it. The most important thing is a comment/label to this field, describing to people what should be there and what should not be there.

Originally posted by @biodranik in #1929 (comment)

Our map files already contain ~3.5M OSM [description tag](https://wiki.openstreetmap.org/wiki/Key:description) values. They should be: 1. Visible to users 2. Editable We can start with (1), and then proceed with (2). The most complex part of the Place Page is that our bookmarks can also have a description. And there is a Wikipedia description section too. > Previously there was no UI for it. Let's design and enable it. The most important thing is a comment/label to this field, describing to people what should be there and what should not be there. _Originally posted by `@biodranik` in https://git.omaps.dev/organicmaps/organicmaps/issues/1929#issuecomment-1022502023_

pastk commented

2022-01-27 08:19:57 +00:00

Author

Member

I guess it should support multiple languages?
So the UI could look similar to the one used for a multilingual name field.

I guess it should support multiple languages? So the UI could look similar to the one used for a multilingual `name` field.

biodranik commented

2022-01-27 08:27:28 +00:00

(Migrated from github.com)

Yes, but let's discuss it before implementing. There are unobvious issues with the name field where we try to guess which languages the user speaks and show them to him.

Questions for descriptions:

Should we display descriptions in all existing languages or only those matching user languages?
Which default language to use when a user opens the editor and starts typing?
Should we use language detectors like this for Android and this for iOS?
Can we also improve the current name languages logic and fix some related bugs?
- #442
- #762
- #1478

Yes, but let's discuss it before implementing. There are unobvious issues with the name field where we try to guess which languages the user speaks and show them to him. Questions for descriptions: 1. Should we display descriptions in all existing languages or only those matching user languages? 2. Which default language to use when a user opens the editor and starts typing? 3. Should we use language detectors like [this for Android](https://developers.google.com/ml-kit/language/identification/android) and [this for iOS](https://developer.apple.com/documentation/naturallanguage/nllanguagerecognizer)? 4. Can we also improve the current name languages logic and fix some related bugs? - #442 - #762 - #1478

pastk commented

2022-01-31 15:19:52 +00:00

Author

Member

mentioned in issue #1233

pastk commented

2022-01-31 15:21:20 +00:00

Author

Member

A useful discussion about proper naming/targeting of the description field to the users: #1233

pastk commented

2022-01-31 16:10:38 +00:00

Author

Member

changed title from Add descripton field into OSM editor to Add descripton field into {+Place Page and +}OSM editor

changed title from **Add descripton field into OSM editor** to **Add descripton field into {+Place Page and +}OSM editor**

pastk commented

2022-06-25 14:26:10 +00:00

Author

Member

mentioned in issue #1888

biodranik commented

2022-12-06 22:29:51 +00:00

(Migrated from github.com)

@arnaudvergnet @SiarheiFedartsou

Would it be possible to implement displaying of descriptions on Place Page? They are already in the data.

The trickiest part is that we already have:

Optional Bookmarks descriptions
Wiki articles

And users should clearly distinguish between these.

`@arnaudvergnet` `@SiarheiFedartsou` Would it be possible to implement displaying of descriptions on Place Page? They are already in the data. The trickiest part is that we already have: - Optional Bookmarks descriptions - Wiki articles And users should clearly distinguish between these.

arnaudvergnet commented

2022-12-16 20:14:12 +00:00

(Migrated from github.com)

The place page on Android is quite a mess, so we could start by refactoring it to make it easier to add new fields. There is also #2825 which could make adding the description difficult.

We have to support 6 possible cases:

Only the description
Only Wikipedia
Only the bookmark description
Wikipedia + description
Bookmark description + description
Wikipedia + bookmark description + description

This is the order in which I would show the information, as well as some explanation on why:

Description
- See https://wiki.openstreetmap.org/wiki/Key:description
- Directly describes the feature, usually only a few sentences. Should be shown directly below the place page preview, or even inside the preview. The wiki asks mappers to keep short description, but we should also prepare for cases where the description is way too long. In such cases we could add a ...more button like in Wikipedia articles. To optimize the space, there should not be a header indicating this is the description. It should be obvious to the user.
Bookmark description
- Important information manually entered by this user. This should be directly visible when the user clicks on a feature. As the description should be only a few sentences long, this bookmark description could be shown at the top right below the description (if any), or if too long only the top. Right now there is a header shown indicating this is a description. We could change this header to tell this feature is bookmarked, and place the edit bookmark button in this header. The description could then follow this header. If the feature is bookmarked but has no description, the header with the edit button should still be shown.
Wikipedia
- Still important information, but less relevant and more general than the others. It should still be shown, and directly visible when clicking on a feature like the bookmark description. In the case a bookmark description is present, the Wikipedia data should be visible but only when expanding the place page. If a feature is bookmarked without description, the Wikipedia article should show without expanding the place page, right below the bookmark edit button. The header should not simply say "description", but instead tell the user it is an extract from Wikipedia. Clicking this header should bring the user to the full online Wikipedia page.

I hope this covers all the possible cases. We'll have to experiment a bit with the design once we agree with the behavior.

The place page on Android is quite a mess, so we could start by refactoring it to make it easier to add new fields. There is also https://git.omaps.dev/organicmaps/organicmaps/issues/2825 which could make adding the description difficult. We have to support 6 possible cases: - Only the description - Only Wikipedia - Only the bookmark description - Wikipedia + description - Bookmark description + description - Wikipedia + bookmark description + description This is the order in which I would show the information, as well as some explanation on why: - Description - See https://wiki.openstreetmap.org/wiki/Key:description - Directly describes the feature, usually only a few sentences. Should be shown directly below the place page preview, or even inside the preview. The wiki asks mappers to keep short description, but we should also prepare for cases where the description is way too long. In such cases we could add a `...more` button like in Wikipedia articles. To optimize the space, there should not be a header indicating this is the description. It should be obvious to the user. - Bookmark description - Important information manually entered by this user. This should be directly visible when the user clicks on a feature. As the description should be only a few sentences long, this bookmark description could be shown at the top right below the description (if any), or if too long only the top. Right now there is a header shown indicating this is a description. We could change this header to tell this feature is bookmarked, and place the edit bookmark button in this header. The description could then follow this header. If the feature is bookmarked but has no description, the header with the edit button should still be shown. - Wikipedia - Still important information, but less relevant and more general than the others. It should still be shown, and directly visible when clicking on a feature like the bookmark description. In the case a bookmark description is present, the Wikipedia data should be visible but only when expanding the place page. If a feature is bookmarked without description, the Wikipedia article should show without expanding the place page, right below the bookmark edit button. The header should not simply say "description", but instead tell the user it is an extract from Wikipedia. Clicking this header should bring the user to the full online Wikipedia page. I hope this covers all the possible cases. We'll have to experiment a bit with the design once we agree with the behavior.

arnaudvergnet commented

2023-01-04 21:26:55 +00:00

(Migrated from github.com)

mentioned in merge request !4174

pastk commented

2023-01-06 15:04:02 +00:00

Author

Member

* Bookmark description
  
  * Important information manually entered by this user. This should be directly visible when the user clicks on a feature. As the description should be only a few sentences long, this bookmark description could be shown at the top right below the description (if any), or if too long only the top. Right now there is a header shown indicating this is a description. We could change this header to tell this feature is bookmarked, and place the edit bookmark button in this header. The description could then follow this header. If the feature is bookmarked but has no description, the header with the edit button should still be shown.

Let's call it a "Note" instead of description to avoid confusing with OSM description?

* Wikipedia
  
  * Still important information, but less relevant and more general than the others. It should still be shown, and directly visible when clicking on a feature like the bookmark description. In the case a bookmark description is present, the Wikipedia data should be visible but only when expanding the place page. If a feature is bookmarked without description, the Wikipedia article should show without expanding the place page, right below the bookmark edit button. The header should not simply say "description", but instead tell the user it is an extract from Wikipedia.

This one could be called a "Wikipedia summary"?

Clicking this header should bring the user to the full online Wikipedia page.

Summaries are often too long to display them in full, so there is a "more" button. So clicking a header should show a full summary and accessing an online article should be done differently.

> > * Bookmark description > > * Important information manually entered by this user. This should be directly visible when the user clicks on a feature. As the description should be only a few sentences long, this bookmark description could be shown at the top right below the description (if any), or if too long only the top. Right now there is a header shown indicating this is a description. We could change this header to tell this feature is bookmarked, and place the edit bookmark button in this header. The description could then follow this header. If the feature is bookmarked but has no description, the header with the edit button should still be shown. > Let's call it a "Note" instead of description to avoid confusing with OSM description? > * Wikipedia > > * Still important information, but less relevant and more general than the others. It should still be shown, and directly visible when clicking on a feature like the bookmark description. In the case a bookmark description is present, the Wikipedia data should be visible but only when expanding the place page. If a feature is bookmarked without description, the Wikipedia article should show without expanding the place page, right below the bookmark edit button. The header should not simply say "description", but instead tell the user it is an extract from Wikipedia. This one could be called a "Wikipedia summary"? > Clicking this header should bring the user to the full online Wikipedia page. Summaries are often too long to display them in full, so there is a "more" button. So clicking a header should show a full summary and accessing an online article should be done differently.

biodranik commented

2023-01-06 16:09:11 +00:00

(Migrated from github.com)

Let me correct several assumptions:

Bookmark descriptions are the most important for users, and should be displayed as early as possible if there are other descriptions or Wiki available.
A bigger preview can be considered to display the first piece of information. The question is what if it will inconsistently display different types of info? On the one hand, some important info should be easily accessible, at the top. On another hand, it should be easily distinguishable, what is it: an editable bookmark description, and editable OSM description, or a read-only Wiki article?
Many users love detailed descriptions imported from other sources. So it is not correct to assume that most descriptions are short. Actually, imported KML may contain larger images and tables (that's why a WebView is needed).
Headers take up a lot of important vertical space. Can we avoid using them? For example, can we display a small square logo (OSM, Wiki, or a bookmark star) at the beginning of the detailed text view (at the upper-right corner)? Then more words from the description will be seen on the screen.
OSM descriptions and bookmarks can be edited. Wiki articles can be expanded. Is there a friendlier way to edit them than displaying a wide Edit Bookmark/Edit OSM description?
As OSM description is a part of the OSM feature, should editing be done in the full Editor interface? Or should be there a simpler UI to quickly update or add a missing OSM description?
Should we consider moving Edit OSM feature button to the toolbar?

Let me correct several assumptions: 1. Bookmark descriptions are the most important for users, and should be displayed as early as possible if there are other descriptions or Wiki available. 2. A bigger preview can be considered to display the first piece of information. The question is what if it will inconsistently display different types of info? On the one hand, some important info should be easily accessible, at the top. On another hand, it should be easily distinguishable, what is it: an editable bookmark description, and _editable_ OSM description, or a read-only Wiki article? 3. Many users love detailed descriptions imported from other sources. So it is not correct to assume that most descriptions are short. Actually, imported KML may contain larger images and tables (that's why a WebView is needed). 4. Headers take up a lot of important vertical space. Can we avoid using them? For example, can we display a small square logo (OSM, Wiki, or a bookmark star) at the beginning of the detailed text view (at the upper-right corner)? Then more words from the description will be seen on the screen. 5. OSM descriptions and bookmarks can be edited. Wiki articles can be expanded. Is there a friendlier way to edit them than displaying a wide Edit Bookmark/Edit OSM description? 6. As OSM description is a part of the OSM feature, should editing be done in the full Editor interface? Or should be there a simpler UI to quickly update or add a missing OSM description? 7. Should we consider moving Edit OSM feature button to the toolbar?

VladimirMorozov commented

2023-04-11 19:57:29 +00:00

(Migrated from github.com)

It looks like only feature details panel is discussed here as a place to put description in.

Here are some descriptions on highway=* ways

Foot path to Kuradisaar usable on low tides and out of birds nesting season (see dedicated sign at beginning of trail).
derelict bridge, can be crossed on foot
awful for cycling
Dangerous bridge, cant pass by wheels, ramp-on made of concrete, middle part that crosses river has wooden planks that have rotten away. Barely passable by feet.
Тропка, которая была дорогой. По части, проходящей по болоту, уложена гать. Летом воды максимум по колено
Beware of the dog

wiki https://wiki.openstreetmap.org/wiki/Key:description also mentions
description=Muddy in wet weather
description:bicycle=Ridable along most of the way but has sections with tree roots

I think it should be considered that user's attention should be somehow drawn to this information without him explicitly opening details panel. For example, when creating a route there should be some icon telling that there is a description on ways or nodes through which the route is made and a way to view these descriptions. Maybe even displaying it on ways without routing if in future hiking view is to be made.

It looks like only feature details panel is discussed here as a place to put description in. Here are some descriptions on highway=* ways - Foot path to Kuradisaar usable on low tides and out of birds nesting season (see dedicated sign at beginning of trail). - derelict bridge, can be crossed on foot - awful for cycling - Dangerous bridge, cant pass by wheels, ramp-on made of concrete, middle part that crosses river has wooden planks that have rotten away. Barely passable by feet. - Тропка, которая была дорогой. По части, проходящей по болоту, уложена гать. Летом воды максимум по колено - Beware of the dog wiki https://wiki.openstreetmap.org/wiki/Key:description also mentions description=Muddy in wet weather description:bicycle=Ridable along most of the way but has sections with tree roots I think it should be considered that user's attention should be somehow drawn to this information without him explicitly opening details panel. For example, when creating a route there should be some icon telling that there is a description on ways or nodes through which the route is made and a way to view these descriptions. Maybe even displaying it on ways without routing if in future hiking view is to be made.

oleg-rswll commented

2023-11-15 06:20:41 +00:00

Member

Requirements

Problem Statement
The OSM Place Description field has useful information about a POI, and it is already included in the OSM data which is downloaded with the map, but it is not being displayed anywhere.

Criteria

Displaying OSM Description

Add OSM Description field to Place Page for viewing. If the description is more than 2 lines, on the second line display an ellipses followed by a blue button named "more", which expands to the full text.
Display in the language which is the device's system default language, if available. If that language is not available, display in English. If text is not available for this field, do not display it.
The OSM Description displays as the first field in the OMS section, just above the OSM contact info such as phone number, website, hours, etc.
To the left of the description is an OSM icon (the simplified icon and in monochrome so it matches the style of the other icons).
The OSM description will not be display by default in the "folded" view of the Place Page, to see it, the Place Page will need to be expanded (in the same way that seeing a website address requires expanding the Place Page).

Phase 2 - Bookmark (Favorite) Info

To avoid confusion about the source of the data, above the Bookmark Note and to the left, display a star icon, to indicate that this information is related to the bookmark.
- Make the start a link which leads to open a bookmark in edit mode
- Icon is a solid star, blue color to indicate it's a link
Above the Bookmark Note, add a label "Bookmark Note"

Phase 2 - Wikipedia data

To avoid confusion about the source of the data, to the left of the Wikipedia article, display the wikipedia logo, in greyscale, matching the other icons.
Limit the Wikipedia text to 2 lines. Instead of the 'more' link being on its own new line and taking up valuable vertical space, display the blue 'more' link at the end of the 2rd line.

Phase 2 - Editing OSM Description

Add OSM Description field to Place Page Edit, below the Place Name fields
Include language selector for the description field, to allow adding languages in addition to the local language.

Design
(the scope of this issue includes only the part of the design in the green rectangle)
https://www.figma.com/design/4IJ7QbJ207Z66OQTXRuBlF?node-id=421-688#832752552

# Requirements **Problem Statement** The OSM Place Description field has useful information about a POI, and it is already included in the OSM data which is downloaded with the map, but it is not being displayed anywhere. **Criteria** _Displaying OSM Description_ - Add OSM Description field to Place Page for viewing. If the description is more than 2 lines, on the second line display an ellipses followed by a blue button named "more", which expands to the full text. - Display in the language which is the device's system default language, if available. If that language is not available, display in English. If text is not available for this field, do not display it. - The OSM Description displays as the first field in the OMS section, just above the OSM contact info such as phone number, website, hours, etc. - To the left of the description is an OSM icon (the simplified icon and in monochrome so it matches the style of the other icons). - The OSM description will not be display by default in the "folded" view of the Place Page, to see it, the Place Page will need to be expanded (in the same way that seeing a website address requires expanding the Place Page). Phase 2 - _Bookmark (Favorite) Info_ - To avoid confusion about the source of the data, above the Bookmark Note and to the left, display a star icon, to indicate that this information is related to the bookmark. - Make the start a link which leads to open a bookmark in edit mode - Icon is a solid star, blue color to indicate it's a link - Above the Bookmark Note, add a label "Bookmark Note" Phase 2 - _Wikipedia data_ - To avoid confusion about the source of the data, to the left of the Wikipedia article, display the wikipedia logo, in greyscale, matching the other icons. - Limit the Wikipedia text to 2 lines. Instead of the 'more' link being on its own new line and taking up valuable vertical space, display the blue 'more' link at the end of the 2rd line. Phase 2 - _Editing OSM Description_ - Add OSM Description field to Place Page Edit, below the Place Name fields - Include language selector for the description field, to allow adding languages in addition to the local language. **Design** (the scope of this issue includes only the part of the design in the green rectangle) https://www.figma.com/design/4IJ7QbJ207Z66OQTXRuBlF?node-id=421-688#832752552

pastk commented

2024-03-19 07:48:47 +00:00

Author

Member

mentioned in issue #7602

pastk commented

2024-03-19 09:35:25 +00:00

Author

Member

mentioned in merge request !7625

pastk commented

2024-03-19 09:44:44 +00:00

Author

Member

I think it should be considered that user's attention should be somehow drawn to this information without him explicitly opening details panel. For example, when creating a route there should be some icon telling that there is a description on ways or nodes through which the route is made and a way to view these descriptions. Maybe even displaying it on ways without routing if in future hiking view is to be made.

This is an interesting idea. I think is deserves its own separate issue, would you mind creating it, please?

And in this particular issue let's focus on PP design (its complicated already).

> I think it should be considered that user's attention should be somehow drawn to this information without him explicitly opening details panel. For example, when creating a route there should be some icon telling that there is a description on ways or nodes through which the route is made and a way to view these descriptions. Maybe even displaying it on ways without routing if in future hiking view is to be made. This is an interesting idea. I think is deserves its own separate issue, would you mind creating it, please? And in this particular issue let's focus on PP design (its complicated already).

pastk commented

2024-03-19 09:47:33 +00:00

Author

Member

UI

* Place Page: Add the OpenStreetMap Description field, just below the top white section, above the list of all the other fields.  If the description takes more than 2 lines, display and ellipses followed by a button named "more", which expands to the full text.

I agree with @biodranik that if there is an user-entered bookmark description then it should be the top-most (more important than OSM description).

* Edit Place page: Add the OpenStreetMap Description field to the Edit Place page, below the Place Name field(s)

Might make sense to create a separate issue for editing OSM description and focus here on PP?

> **UI** > > * Place Page: Add the OpenStreetMap Description field, just below the top white section, above the list of all the other fields. If the description takes more than 2 lines, display and ellipses followed by a button named "more", which expands to the full text. I agree with `@biodranik` that if there is an user-entered bookmark description then it should be the top-most (more important than OSM description). > * Edit Place page: Add the OpenStreetMap Description field to the Edit Place page, below the Place Name field(s) Might make sense to create a separate issue for editing OSM description and focus here on PP?

pastk commented

2024-03-19 10:14:30 +00:00

Author

Member

mentioned in issue #7612

oleg-rswll commented

2024-03-19 23:30:16 +00:00

Member

@pastk Today, when a Bookmark/Favorite name is saved, this name replaces the OSM name in the top summary section, without labeling it as a user-defined name rather than OSM data. And if the Favorite name is similar to OSM name, it appears almost as a duplication. Also, the List Name is placed next to the Place Type (for example Restaurant), making the user defined List Name appear like OSM data rather than OM data. The Favorite name is definitely important, that's why it's worth improving this experience. One approach is to group data so it's visually clear about the source of the data.

Attached is an example where OSM date, OM data and Wikipedia data is each in their own sections:

`@pastk` Today, when a Bookmark/Favorite name is saved, this name replaces the OSM name in the top summary section, without labeling it as a user-defined name rather than OSM data. And if the Favorite name is similar to OSM name, it appears almost as a duplication. Also, the List Name is placed next to the Place Type (for example Restaurant), making the user defined List Name appear like OSM data rather than OM data. The Favorite name is definitely important, that's why it's worth improving this experience. One approach is to group data so it's visually clear about the source of the data. Attached is an example where OSM date, OM data and Wikipedia data is each in their own sections: ![image](/uploads/3f82b2281146c0ebca8c02066e596761/f06fd3e1-4098-4a43-bd65-c91efa4c60e0) ![image](/uploads/cb9881949e3dcb9d12a6cb3d01f3b03b/bd110021-a645-40fd-af65-ce5969d8bc36)

pastk commented

2024-03-20 16:40:46 +00:00

Author

Member

I like grouping of list name, bookmark name and a star symbol (makes it very obvious its a bookmark data).

Though in my mind the bookmark data should go before any osm data, place name included.
Also currently the share button shares bookmark's name, which is logical IMO (but the original osm name should be included into the shared text too, its a different issue).

And bookmark name is much more important than list name (better to have it in a smaller font somewhere IMHO).
Its current position as the first item in the subtitle is controversial:

on one hand we use the subtitle to mix many entities anyway (e.g. "Cafe * Pizza * Sandwich * 57 North St * WiFi")
on the other - the list name feels like the biggest misfit indeed
- but its not worth a separate dedicated line

Perhaps we can think also about making editing bookmark's data more easy / faster? I mean future-proofing the UI design to support this idea.
E.g. edit the title in-place when its tapped, change the list by tapping on it, change the color (or pick a custom icon) by tapping on the colored star symbol?
I did some mock-ups long time ago:

#1636

P.S. I like the image gallery idea, though perhaps it should be expandable (and collapsed by default) or configurable or somehow adhering to the internet usage setting - worth a separate issue to discuss IMO.

I like grouping of list name, bookmark name and a star symbol (makes it very obvious its a bookmark data). Though in my mind the bookmark data should go before any osm data, place name included. Also currently the share button shares bookmark's name, which is logical IMO (but the original osm name should be included into the shared text too, its a different issue). And bookmark name is much more important than list name (better to have it in a smaller font somewhere IMHO). Its current position as the first item in the subtitle is controversial: - on one hand we use the subtitle to mix many entities anyway (e.g. "Cafe * Pizza * Sandwich * 57 North St * WiFi") - on the other - the list name feels like the biggest misfit indeed - but its not worth a separate dedicated line Perhaps we can think also about making editing bookmark's data more easy / faster? I mean future-proofing the UI design to support this idea. E.g. edit the title in-place when its tapped, change the list by tapping on it, change the color (or pick a custom icon) by tapping on the colored star symbol? I did some mock-ups long time ago: - https://git.omaps.dev/organicmaps/organicmaps/issues/1636 P.S. I like the image gallery idea, though perhaps it should be expandable (and collapsed by default) or configurable or somehow adhering to the internet usage setting - worth a separate issue to discuss IMO.

oleg-rswll commented

2024-03-20 17:49:20 +00:00

Member

The two screenshots are just two scenarios for the Place Page, the design for additional scenarios are in the Figma design:
https://www.figma.com/file/4IJ7QbJ207Z66OQTXRuBlF
these should be discussed when the Place Page will be updated #8401, the reference to this design is to start looking at the broader perspective to have a common goal for the ongoing separate issues, but which are related.

(the photos from Wikimedia are a different feature which can be discussed in #3252, the idea is that photos would be partially visible in the default compacted view, just enough to show that photos exist for the place, and a person can expand the view to see the photos).

The use case for creating a custom Favorite name is not clear, this needs to be well defined. It would be very useful to have people share how they use this field.

Possible use cases that can help guide how to proceed:

A significant number of people likely use Bookmarks/Favorites like Bookmarks/Favorites in a browser, hit the button, it gets saved with the default name, and the person never does anything custom with it, they just open it later when needed.
Saving a place and typing a custom name that is slightly different than the OSM name. [ it would be helpful to understand why people change it just slightly, why is the OSM name not sufficient ]
Saving a place, and entering a completely custom name: when the OSM name is just an address, but a meaningful name such as "Home", "Work", "Parents", or "Buddy John's Place" is much more helpful than an address.
When hiking, saving a point on the map which does not have a Place entry in OSM, and giving it a custom name for that location.

The two screenshots are just two scenarios for the Place Page, the design for additional scenarios are in the Figma design: https://www.figma.com/file/4IJ7QbJ207Z66OQTXRuBlF these should be discussed when the Place Page will be updated #8401, the reference to this design is to start looking at the broader perspective to have a common goal for the ongoing separate issues, but which are related. (the photos from Wikimedia are a different feature which can be discussed in #3252, the idea is that photos would be partially visible in the default compacted view, just enough to show that photos exist for the place, and a person can expand the view to see the photos). The use case for creating a custom Favorite name is not clear, this needs to be well defined. It would be very useful to have people share how they use this field. Possible use cases that can help guide how to proceed: 1) A significant number of people likely use Bookmarks/Favorites like Bookmarks/Favorites in a browser, hit the button, it gets saved with the default name, and the person never does anything custom with it, they just open it later when needed. 2) Saving a place and typing a custom name that is slightly different than the OSM name. [ it would be helpful to understand why people change it just slightly, why is the OSM name not sufficient ] 3) Saving a place, and entering a completely custom name: when the OSM name is just an address, but a meaningful name such as "Home", "Work", "Parents", or "Buddy John's Place" is much more helpful than an address. 4) When hiking, saving a point on the map which does not have a Place entry in OSM, and giving it a custom name for that location.

pastk commented

2024-03-20 18:40:14 +00:00

Author

Member

Its not uncommon to bookmark arbitrary points on the map (esp. in the outdoors), I guess this is the most reasonable case for custom naming.

5. Its not uncommon to bookmark arbitrary points on the map (esp. in the outdoors), I guess this is the most reasonable case for custom naming.

pastk commented

2024-03-21 16:43:32 +00:00

Author

Member

mentioned in issue #7430

biodranik commented

2024-03-26 23:08:36 +00:00

(Migrated from github.com)

Common case: bookmark a building (address), and type some meaningful/searchable name (friend's or business name).

VladimirMorozov commented

2024-04-09 12:20:32 +00:00

(Migrated from github.com)

mentioned in issue #7872

patepelo commented

2024-05-21 15:52:58 +00:00

Member

Maybe we can also change wording of bookmark from description to notes. It's more precise on what it is and removes confusion with OSM and Wiki description.

Can we also look for a different word for the wiki description? Maybe Wiki Summary?

Maybe we can also change wording of bookmark from _description_ to _notes_. It's more precise on what it is and removes confusion with OSM and Wiki description. Can we also look for a different word for the wiki description? Maybe Wiki Summary?

biodranik commented

2024-05-21 16:36:04 +00:00

(Migrated from github.com)

@patepelo that is an interesting idea. It may conflict a bit with OSM "note" which we also support when adding or editing a place.

There is a word "comment" which may be used instead bookmark's description or OSM description.

OSM description can also be replaced with "review" word.

@euf @oleg-PK

`@patepelo` that is an interesting idea. It may conflict a bit with OSM "note" which we also support when adding or editing a place. There is a word "comment" which may be used instead bookmark's description or OSM description. OSM description can also be replaced with "review" word. ` @euf` `@oleg-PK`

patepelo commented

2024-05-21 16:49:18 +00:00

Member

@patepelo that is an interesting idea. It may conflict a bit with OSM "note" which we also support when adding or editing a place.

and with Key: note=* which maybe we'll never use since is for inner communication between OSMers

There is a word "comment" which may be used instead bookmark's description or OSM description.

Not a fan of that but it's ok

OSM description can also be replaced with "review" word.

I'd avoid this one as review should be exclusively used for POIs reviews of users (rating and reviews written)

> `@patepelo` that is an interesting idea. It may conflict a bit with OSM "note" which we also support when adding or editing a place. > and with Key: note=* which maybe we'll never use since is for inner communication between OSMers > There is a word "comment" which may be used instead bookmark's description or OSM description. Not a fan of that but it's ok > OSM description can also be replaced with "review" word. > I'd avoid this one as review should be exclusively used for POIs reviews of users (rating and reviews written)

oleg-rswll commented

2024-05-22 01:35:01 +00:00

Member

These appear to be the primary use cases:

POI with OSM Name: When favoriting a POI that already has a POI name in OSM, often a custom name is not needed, potentially less common to customize this name. This can be businesses, parks or other areas which is not likely to need a custom name.

POI without name: 1) Most common POIs: When favoriting a home address, work, parents’ place, the OSM name is much less relevant and custom names are the most useful. 2) Hiking: Many locations along hiking or biking trails will not have POIs in OSM, so the Favorite will just have GPS coordinates and it’s necessary to have a custom name to identify a spot.

The question: how to more clearly identify a POI which has been favorited which may have a custom name that is not an OSM name.

One option is placing a Favorite icon next to a favorited POI, and the name of the list directly below the name instead of on the same line as the POI type.

Not favorited POI
https://www.figma.com/file/4IJ7QbJ207Z66OQTXRuBlF?node-id=3:886&locale=en&type=design#811788522

Favorited POI
https://www.figma.com/file/4IJ7QbJ207Z66OQTXRuBlF?node-id=334:425&locale=en&type=design#811787642

These appear to be the primary use cases: POI with OSM Name: When favoriting a POI that already has a POI name in OSM, often a custom name is not needed, potentially less common to customize this name. This can be businesses, parks or other areas which is not likely to need a custom name. POI without name: 1) Most common POIs: When favoriting a home address, work, parents’ place, the OSM name is much less relevant and custom names are the most useful. 2) Hiking: Many locations along hiking or biking trails will not have POIs in OSM, so the Favorite will just have GPS coordinates and it’s necessary to have a custom name to identify a spot. The question: how to more clearly identify a POI which has been favorited which may have a custom name that is not an OSM name. One option is placing a Favorite icon next to a favorited POI, and the name of the list directly below the name instead of on the same line as the POI type. Not favorited POI https://www.figma.com/file/4IJ7QbJ207Z66OQTXRuBlF?node-id=3:886&locale=en&type=design#811788522 Favorited POI https://www.figma.com/file/4IJ7QbJ207Z66OQTXRuBlF?node-id=334:425&locale=en&type=design#811787642

oleg-rswll commented

2024-05-22 01:36:01 +00:00

Member

Placing the OSM description field by all other OSM data seems like a good idea.

https://www.figma.com/file/4IJ7QbJ207Z66OQTXRuBlF?node-id=45:1017&locale=en&type=design#811800199

Placing the OSM description field by all other OSM data seems like a good idea. https://www.figma.com/file/4IJ7QbJ207Z66OQTXRuBlF?node-id=45:1017&locale=en&type=design#811800199

oleg-rswll commented

2024-06-04 04:08:56 +00:00

Member

assigned to @oleg-rswll

assigned to `@oleg-rswll`

biodranik commented

2024-06-13 20:52:11 +00:00

(Migrated from github.com)

Redesigning how bookmarks will look may greatly delay the implementation of this feature. I suggest focusing on "how to add OSM descriptions into the existing UI with minimal efforts as the first step", then "how to make them editable/addable by users", and only then "how to refactor Place Page and improve bookmarks/wiki/descriptions".

oleg-rswll commented

2024-06-14 05:58:43 +00:00

Member

Redesigning how bookmarks will look may greatly delay the implementation of this feature. I suggest focusing on "how to add OSM descriptions into the existing UI with minimal efforts as the first step", then "how to make them editable/addable by users", and only then "how to refactor Place Page and improve bookmarks/wiki/descriptions".

@biodranik To keep the scope of this request very narrow, all the items which are there for adding clarity by labeling existing fields, are now marked as "Phase 2", and can be moved to a separate issue. Also, the design is updated to show only the narrow part of the section which will have the field.

#1953 (comment)

https://www.figma.com/design/4IJ7QbJ207Z66OQTXRuBlF?node-id=421-688#839849395

> Redesigning how bookmarks will look may greatly delay the implementation of this feature. I suggest focusing on "how to add OSM descriptions into the existing UI with minimal efforts as the first step", then "how to make them editable/addable by users", and only then "how to refactor Place Page and improve bookmarks/wiki/descriptions". ` @biodranik` To keep the scope of this request very narrow, all the items which are there for adding clarity by labeling existing fields, are now marked as "Phase 2", and can be moved to a separate issue. Also, the design is updated to show only the narrow part of the section which will have the field. https://git.omaps.dev/organicmaps/organicmaps/issues/1953#issuecomment-1811872943 https://www.figma.com/design/4IJ7QbJ207Z66OQTXRuBlF?node-id=421-688#839849395

simonschaufi commented

2024-06-14 22:11:51 +00:00

(Migrated from github.com)

Why is the figma file protected? I requested access but still nobody approved me.

pastk commented

2024-12-23 13:28:34 +00:00

Author

Member

unassigned @oleg-rswll

unassigned `@oleg-rswll`

pastk commented

2024-12-23 13:29:13 +00:00

Author

Member

@kirylkaveryn could you please take a look at this one (displaying description in the PP) when you have time?

`@kirylkaveryn` could you please take a look at this one (displaying description in the PP) when you have time?

oleg-rswll commented

2024-12-23 19:44:00 +00:00

Member

@kirylkaveryn the design for this issue is only in the green rectangle here:

https://www.figma.com/design/4IJ7QbJ207Z66OQTXRuBlF?node-id=421-688#839849395

`@kirylkaveryn` the design for this issue is only in the green rectangle here: https://www.figma.com/design/4IJ7QbJ207Z66OQTXRuBlF?node-id=421-688#839849395

bjohas commented

2025-01-28 21:44:42 +00:00

(Migrated from github.com)

There's also the wheelchair:description tag, which would be good to show as well (where available).

bjohas commented

2025-01-28 21:45:23 +00:00

(Migrated from github.com)

mentioned in issue #10125

Rows
Columns

Add descripton field into Place Page and OSM editor #1953

Requirements