organicmaps/organicmaps-tmp

Archived

Fork 1

Add descripton field into Place Page and OSM editor #1953

New issue

Open

opened 2022-01-27 08:18:42 +00:00 by pastk · 7 comments

pastk commented

2022-01-27 08:18:42 +00:00

Owner

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 organicmaps/organicmaps#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_

👍 4 ❤️ 3

pastk commented

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

Author

Owner

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

👍 1

pastk commented

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

Author

Owner

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

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 organicmaps/organicmaps#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.

👍 4

pastk commented

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

Author

Owner

* 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.

👍 3

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?

This repo is archived. You cannot comment on issues.