Disable display of (certain) POIs

pastk commented

2022-04-07 09:19:35 +00:00

Member

There could be a lot of different POIs cluttering the map when users don't actually need them.

Let's discuss options how to give users an ability to switch POIs on/off. All at once or make possible to choose certain categories?
How should it be from UX/UI point of view?

We probably don't want to add a complex UI for it with a long list of all possible POI types.. OM way is to make things simple and efficient.

This feature was asked / discussed several times already, please check the following for use cases and ideas

There could be a lot of different POIs cluttering the map when users don't actually need them. Let's discuss options how to give users an ability to switch POIs on/off. All at once or make possible to choose certain categories? How should it be from UX/UI point of view? We probably don't want to add a complex UI for it with a long list of all possible POI types.. OM way is to make things simple and efficient. This feature was asked / discussed several times already, please check the following for use cases and ideas - #744 - https://git.omaps.dev/organicmaps/organicmaps/issues/1577#issuecomment-1047884119 - https://git.omaps.dev/organicmaps/organicmaps/issues/1577#issuecomment-1090826323 - #1676 - #6780

👍 3

alensiljak commented

2022-04-07 09:48:31 +00:00

(Migrated from github.com)

Why against giving all options to those who want to customize a view?

I'd create two layers of customization. One is the detailed, providing access to all POI types available. This is for enthusiasts, though. But provides access to the second layer, where the individual POI types are grouped into more practical units.

For example, the pedestrian view of the map (i.e. #2356) would include a set of POIs that are relevant to pedestrians/hikers. This, however, should be customizable to allow excluding some of the categories or adding other ones from the complete list.

Creating custom groups should also be possible.

These are probably not the features one would use every day, but the tools that provide a way to create an experience for everyone. If the ready-made groups are not enough, the users should be able to customize them or turn on/off.

This explanation is fairly generic and broad but that's the idea. We should take concrete examples when focusing on detail.

Why against giving all options to those who want to customize a view? I'd create two layers of customization. One is the detailed, providing access to *all* POI types available. This is for enthusiasts, though. But provides access to the second layer, where the individual POI types are grouped into more practical units. For example, the pedestrian view of the map (i.e. #2356) would include a set of POIs that are relevant to pedestrians/hikers. This, however, should be customizable to allow excluding some of the categories or adding other ones from the complete list. Creating custom groups should also be possible. These are probably not the features one would use every day, but the tools that provide a way to create an experience for everyone. If the ready-made groups are not enough, the users should be able to customize them or turn on/off. This explanation is fairly generic and broad but that's the idea. We should take concrete examples when focusing on detail.

👍 1

RedAuburn commented

2022-04-07 12:32:06 +00:00

Member

Something similar to how streetcomplete manages visible quests ('Settings' -> 'Quest selection and priority') would be good

pastk commented

2022-04-07 13:02:17 +00:00

Author

Member

There are 130 entries in the list in StreetComplete. A complete POI list will even longer (200+ I guess). We kind of have similar list in the "add a point to the map" menu already. Its OK for a use case of finding a single entry via search. But going through the whole list switching entries on/off will be too much for the most users.

I suggest let's focus on a solution most users will be happy with. Hopefully we can tend to enthusiasts later after a general solution is clear.

I think a categories list should be short enough to fit into the screen so that a user will have an immediate overview of what's enabled and what is not.

Also the hiking, cycling, sightseeing etc. views feature will overlap POIs display functionality somewhat.
So e.g. someone not interested to see all the POIs could just use hiking or driving mode maybe?
Or maybe just an enable/disable switch will be enough in addition to the views feature?

There are 130 entries in the list in StreetComplete. A complete POI list will even longer (200+ I guess). We kind of have similar list in the "add a point to the map" menu already. Its OK for a use case of finding a single entry via search. But going through the whole list switching entries on/off will be too much for the most users. I suggest let's focus on a solution most users will be happy with. Hopefully we can tend to enthusiasts later after a general solution is clear. I think a categories list should be short enough to fit into the screen so that a user will have an immediate overview of what's enabled and what is not. Also the hiking, cycling, sightseeing etc. views feature will overlap POIs display functionality somewhat. So e.g. someone not interested to see all the POIs could just use hiking or driving mode maybe? Or maybe just an enable/disable switch will be enough in addition to the views feature?

biodranik commented

2022-04-07 13:34:26 +00:00

(Migrated from github.com)

@pastk As you already referenced, it should be a part of one of the generic map styles: hiking, cycling, etc. In this way the UX would be very easy and clear for most users.

Customizing hundreds of POIs doesn't make much sense if proper POI filtering is implemented with a focus on the user's task.

@pastk As you already referenced, it should be a part of one of the generic map styles: hiking, cycling, etc. In this way the UX would be very easy and clear for most users. Customizing hundreds of POIs doesn't make much sense if proper POI filtering is implemented with a focus on the user's task.

pastk commented

2022-04-07 17:20:09 +00:00

Author

Member

@pastk As you already referenced, it should be a part of one of the generic map styles: hiking, cycling, etc. In this way the UX would be very easy and clear for most users.

Customizing hundreds of POIs doesn't make much sense if proper POI filtering is implemented with a focus on the user's task.

I don't think map styles will help much with POI filtering unfortunately.
E.g. a cycling trip could be very different: sight seeing, commuting, mtb, long distance touring etc. Sets of POIs to display will be very different for these cases.

Maybe we should consider separating mode of transport from "interests"?

We have modes of transport in the router already: pedestrian, cycling, driving, public transport.
We can extend them to map styles: e.g. for "cycling" highlight cycleways, prioritize cycling-related POIs and conceal car- and PT-related ones, etc.

Then we can have a separate set of "interests" layers:
outdoors, sight seeing, shopping, snow activities etc.
These layers won't be limited to POIs selection and priorities, but can include style changes too, e.g. for outdoors it'll be more visible tracks and paths, relief contours/shading, etc.

So e.g. hiking will be best suited by a combination of "pedestrian" mode of transport + "outdoors", while mtb will be "cycling" + "outdoors", etc.

> @pastk As you already referenced, it should be a part of one of the generic map styles: hiking, cycling, etc. In this way the UX would be very easy and clear for most users. > > Customizing hundreds of POIs doesn't make much sense if proper POI filtering is implemented with a focus on the user's task. I don't think map styles will help much with POI filtering unfortunately. E.g. a cycling trip could be very different: sight seeing, commuting, mtb, long distance touring etc. Sets of POIs to display will be very different for these cases. Maybe we should consider separating mode of transport from "interests"? We have modes of transport in the router already: pedestrian, cycling, driving, public transport. We can extend them to map styles: e.g. for "cycling" highlight cycleways, prioritize cycling-related POIs and conceal car- and PT-related ones, etc. Then we can have a separate set of "interests" layers: outdoors, sight seeing, shopping, snow activities etc. These layers won't be limited to POIs selection and priorities, but can include style changes too, e.g. for outdoors it'll be more visible tracks and paths, relief contours/shading, etc. So e.g. hiking will be best suited by a combination of "pedestrian" mode of transport + "outdoors", while mtb will be "cycling" + "outdoors", etc.

biodranik commented

2022-04-07 18:02:51 +00:00

(Migrated from github.com)

That complicates things :) It should be easy for cyclists to select a tourist layer and find what is necessary. And then switch back to the cyclist style. Otherwise, it's hard to imagine an easy UX.

For example, you select a tourist style, select a monument, press route to, select a bicycle, and the style switches to the cycling one.

Let's brainstorm if it's possible to make an easier UX. Do you know any other apps that tried to solve this issue?

How many valid "combinations" do you see? In your example, hiking + outdoors and cycling + outdoors are actually two different styles.

That complicates things :) It should be easy for cyclists to select a tourist layer and find what is necessary. And then switch back to the cyclist style. Otherwise, it's hard to imagine an easy UX. For example, you select a tourist style, select a monument, press route to, select a bicycle, and the style switches to the cycling one. Let's brainstorm if it's possible to make an easier UX. Do you know any other apps that tried to solve this issue? How many valid "combinations" do you see? In your example, hiking + outdoors and cycling + outdoors are actually two different styles.

pastk commented

2022-04-07 18:59:22 +00:00

Author

Member

That complicates things :) It should be easy for cyclists to select a tourist layer and find what is necessary. And then switch back to the cyclist style. Otherwise, it's hard to imagine an easy UX.

There should be no switching necessary. The point is to have both mode of transport and an activity (e.g. "cycling" + "sight seeing") active at the same time. So the map view will have both cycling lanes / POIs and sightseeing POIs visible at the same time.

For example, you select a tourist style, select a monument, press route to, select a bicycle, and the style switches to the cycling one.

This option is not very good, because I'd like to explore tourist attractions appearing along my way too.

Let's brainstorm if it's possible to make an easier UX. Do you know any other apps that tried to solve this issue?

A "transport mode" is always active just like an "activity" (sight seeing, outdoors, etc.)

I.e. instead of the current "layers" button there could be two buttons / icons:

with a chosen transport mode
with a chosen activity

Or maybe a single compound icon / button. E.g. a bigger square icon of the active activity with a smaller round icon of the active transport mode in the corner. This button will open a pane with two distinct parts:

a row of smaller transport mode icons at the top - similar to the one we have in the routing screen
a set of bigger square activities icons

How many valid "combinations" do you see?

To my mind all of them are valid, except that "snow activities" is not fitting into "activities"/"interests" exactly, because it often demands e.g. skis as a mode of transport :) Maybe it should be a "snow" mode of transport instead, which will highlight winter roads, ski trails etc.

Also I'm not sure yet how to include the current "contour lines" and "subway" layers into this system.

In your example, hiking + outdoors and cycling + outdoors are actually two different styles.

Could you elaborate what do you mean here? Of course they're different, that's the point.

> That complicates things :) It should be easy for cyclists to select a tourist layer and find what is necessary. And then switch back to the cyclist style. Otherwise, it's hard to imagine an easy UX. There should be no switching necessary. The point is to have both mode of transport and an activity (e.g. "cycling" + "sight seeing") active at the same time. So the map view will have both cycling lanes / POIs and sightseeing POIs visible at the same time. > > For example, you select a tourist style, select a monument, press route to, select a bicycle, and the style switches to the cycling one. This option is not very good, because I'd like to explore tourist attractions appearing along my way too. > > Let's brainstorm if it's possible to make an easier UX. Do you know any other apps that tried to solve this issue? > A "transport mode" is always active just like an "activity" (sight seeing, outdoors, etc.) I.e. instead of the current "layers" button there could be two buttons / icons: - with a chosen transport mode - with a chosen activity Or maybe a single compound icon / button. E.g. a bigger square icon of the active activity with a smaller round icon of the active transport mode in the corner. This button will open a pane with two distinct parts: - a row of smaller transport mode icons at the top - similar to the one we have in the routing screen - a set of bigger square activities icons > How many valid "combinations" do you see? To my mind all of them are valid, except that "snow activities" is not fitting into "activities"/"interests" exactly, because it often demands e.g. skis as a mode of transport :) Maybe it should be a "snow" mode of transport instead, which will highlight winter roads, ski trails etc. Also I'm not sure yet how to include the current "contour lines" and "subway" layers into this system. > In your example, hiking + outdoors and cycling + outdoors are actually two different styles. Could you elaborate what do you mean here? Of course they're different, that's the point.

biodranik commented

2022-04-07 20:07:07 +00:00

(Migrated from github.com)

Could you elaborate on what do you mean here? Of course, they're different, that's the point.

Hiking style. It is obviously focused on the outdoors. With interesting sightseeing points included.
Cycling style. It is obviously focused on the outdoors too. With interesting sightseeing points included. But in cities bike paths and bike-related amenities are highlighted, and car/public transport-related stuff is not in the focus.
City tourist style. It is focused on foot and pedestrian paths/public transport stations and city sightseeing. Tourism-related businesses are also visible (e.g. local government offices are not necessary).
Public transport style highlights metro/tram/bus/train lines for easier planning. Allows to quickly determine if it is feasible to get into the area by public transport.
Driver style. Focus on the road amenities and interesting sightseeing on the way. Footpaths are almost invisible. Traffic is highlighted. Our current navigation style is a good start.
(NEW) Local city dweller style. Focus on public transport and amenities useful in daily life.

> Could you elaborate on what do you mean here? Of course, they're different, that's the point. 1. Hiking style. It is obviously focused on the outdoors. With interesting sightseeing points included. 2. Cycling style. It is obviously focused on the outdoors too. With interesting sightseeing points included. But in cities bike paths and bike-related amenities are highlighted, and car/public transport-related stuff is not in the focus. 3. City tourist style. It is focused on foot and pedestrian paths/public transport stations and city sightseeing. Tourism-related businesses are also visible (e.g. local government offices are not necessary). 4. Public transport style highlights metro/tram/bus/train lines for easier planning. Allows to quickly determine if it is feasible to get into the area by public transport. 5. Driver style. Focus on the road amenities and interesting sightseeing on the way. Footpaths are almost invisible. Traffic is highlighted. Our current navigation style is a good start. 6. (NEW) Local city dweller style. Focus on public transport and amenities useful in daily life.

ackern commented

2022-04-07 20:16:40 +00:00

(Migrated from github.com)

@biodranik @pastk

I reallllly realllly recommend checking out "Offline Maps for Android" by Topobyte.de They've addressed many of the exact issues you're talking about, IMHO successfully. You can show/hide 10 broad categories of POI quickly and effortlessly (Food, Arts, Education, Shops etc). Trust me the interface is super uncluttered, quick and convenient. If you want you can expand each of these and show/hide individual subtypes (Fast Food, Bakery, Cafe, Bar, Pub [what's the difference between bar and pub?!])

Not that you need to mimic their layout exactly but even if you did you could still add another category for User Type where the choices would be something like Hiking, Driving, Cycling, Sightseeing, and Minimal.

https://www.topobyte.de/products/offline-maps/available-maps.html.

PS in previous post I misspelled the URL. It's topobyte.de, not topobytes.de The catch is, it's not global but only for about 50 specific cities.

@biodranik @pastk I reallllly realllly recommend checking out "Offline Maps for Android" by Topobyte.de They've addressed many of the exact issues you're talking about, IMHO successfully. You can show/hide 10 broad categories of POI quickly and effortlessly (Food, Arts, Education, Shops etc). Trust me the interface is super uncluttered, quick and convenient. If you want you can expand each of these and show/hide individual subtypes (Fast Food, Bakery, Cafe, Bar, Pub [what's the difference between bar and pub?!]) Not that you need to mimic their layout exactly but even if you did you could still add another category for User Type where the choices would be something like Hiking, Driving, Cycling, Sightseeing, and Minimal. [https://www.topobyte.de/products/offline-maps/available-maps.html](https://www.topobyte.de/products/offline-maps/available-maps.html). PS in previous post I misspelled the URL. It's topobyte.de, not topobytes.de The catch is, it's not global but only for about 50 specific cities.

biodranik commented

2022-04-08 06:39:08 +00:00

(Migrated from github.com)

I have checked the topobyte app. The reason why they made a "POI filter" menu is because their map rendering is unusable without it. They do not overlap POI properly and it looks cluttered without a filter in dense cities. Also, they use 10-years old outdated OSM map style and colors that are "too bright and colorful" also unusable in a long term.

I understand that menu-like filtering looks ok, but it is just a workaround. Topobyte apps are focused on city tourism. For a worldwide map with an outdoors focus there will be way more feature types, and the whole UI/UX becomes very complicated for users.

That's why we try to understand what is the real problem that our users are trying to solve with these "workarounds". For example, @ackern in your case, what exactly problem are you trying to solve now in Organic Maps? Are there any other ways to solve it more conveniently instead of making complex manual filters?

I have checked the topobyte app. The reason why they made a "POI filter" menu is because their map rendering is unusable without it. They do not overlap POI properly and it looks cluttered without a filter in dense cities. Also, they use 10-years old outdated OSM map style and colors that are "too bright and colorful" also unusable in a long term. I understand that menu-like filtering looks ok, but it is just a workaround. Topobyte apps are focused on city tourism. For a worldwide map with an outdoors focus there will be way more feature types, and the whole UI/UX becomes very complicated for users. That's why we try to understand what is the real problem that our users are trying to solve with these "workarounds". For example, @ackern in your case, what exactly problem are you trying to solve now in Organic Maps? Are there any other ways to solve it more conveniently instead of making complex manual filters?

pastk commented

2022-04-08 14:15:23 +00:00

Author

Member

1. Hiking style. It is obviously focused on the outdoors. With interesting sightseeing points included.

2. Cycling style. It is obviously focused on the outdoors too. With interesting sightseeing points included. But in cities bike paths and bike-related amenities are highlighted, and car/public transport-related stuff is not in the focus.

3. City tourist style. It is focused on foot and pedestrian paths/public transport stations and city sightseeing. Tourism-related businesses are also visible (e.g. local government offices are not necessary).

What's the difference with 1. Hiking? Hmm, looks like these cases could be merged into "Pedestrian"?

4. Public transport style highlights metro/tram/bus/train lines for easier planning. Allows to quickly determine if it is feasible to get into the area by public transport.

5. Driver style. Focus on the road amenities and interesting sightseeing on the way. Footpaths are almost invisible. Traffic is highlighted. Our current navigation style is a good start.

These two will be good for planning A to B trips. For something more complex e.g. with stops or seeing something along the way its not good, because a user will have to switch to another layer with his destinations (e.g. shops) and then back.

My whole point is that its very convenient and important to have both destinations ("interests", "activities") and means to get there / around (transport) in one map view, it should answer both "what?" and "how?" questions ideally.

6. (NEW) Local city dweller style. Focus on public transport and amenities useful in daily life.

And what about locals who get around by car or by bicycle?

Actually, looking at your proposal, all of the styles but one are basically centered around sightseeing/tourism case. And there is one for locals (though limited to public transport only).

How about adding one button that switch between "touristic" and "local" POIs? (and "no POIs/minimal" maybe?)

> 1. Hiking style. It is obviously focused on the outdoors. With interesting sightseeing points included. > > 2. Cycling style. It is obviously focused on the outdoors too. With interesting sightseeing points included. But in cities bike paths and bike-related amenities are highlighted, and car/public transport-related stuff is not in the focus. > > 3. City tourist style. It is focused on foot and pedestrian paths/public transport stations and city sightseeing. Tourism-related businesses are also visible (e.g. local government offices are not necessary). What's the difference with 1. Hiking? Hmm, looks like these cases could be merged into "Pedestrian"? > > 4. Public transport style highlights metro/tram/bus/train lines for easier planning. Allows to quickly determine if it is feasible to get into the area by public transport. > > 5. Driver style. Focus on the road amenities and interesting sightseeing on the way. Footpaths are almost invisible. Traffic is highlighted. Our current navigation style is a good start. These two will be good for planning A to B trips. For something more complex e.g. with stops or seeing something along the way its not good, because a user will have to switch to another layer with his destinations (e.g. shops) and then back. My whole point is that its very convenient and important to have both destinations ("interests", "activities") and means to get there / around (transport) in one map view, it should answer both "what?" and "how?" questions ideally. > > 6. (NEW) Local city dweller style. Focus on public transport and amenities useful in daily life. And what about locals who get around by car or by bicycle? Actually, looking at your proposal, all of the styles but one are basically centered around sightseeing/tourism case. And there is one for locals (though limited to public transport only). How about adding one button that switch between "touristic" and "local" POIs? (and "no POIs/minimal" maybe?)

alensiljak commented

2022-04-08 14:27:15 +00:00

(Migrated from github.com)

It is looking as if the mode-of-transport is the primary division (pedestrian, cycle, motor vehicle, public transport, ski?). This affects the graphical display of the paths/roads, buildings, parks, land-use areas, etc. I think some kind of default view is also useful exactly because it is generic.

The secondary division are the POIs. These should be pre-set for the mode-of-transport views but also configurable because there are many more use cases. So, at least a quick access to a list of 5-10 items with POI categories (dining, culture, sport, tourism, shopping, public offices, entertainment...) that are remembered.

What else is there, apart from the POIs? Favourites, contours, wikipedia articles, travel wiki, weather forecast, traffic data, relief shading?

It is looking as if the mode-of-transport is the primary division (pedestrian, cycle, motor vehicle, public transport, ski?). This affects the graphical display of the paths/roads, buildings, parks, land-use areas, etc. I think some kind of default view is also useful exactly because it is generic. The secondary division are the POIs. These should be pre-set for the mode-of-transport views but also configurable because there are many more use cases. So, at least a quick access to a list of 5-10 items with POI categories (dining, culture, sport, tourism, shopping, public offices, entertainment...) that are remembered. What else is there, apart from the POIs? Favourites, contours, wikipedia articles, travel wiki, weather forecast, traffic data, relief shading?

pastk commented

2022-04-08 14:59:32 +00:00

Author

Member

The secondary division are the POIs. These should be pre-set for the mode-of-transport views but also configurable because there are many more use cases. So, at least a quick access to a list of 5-10 items with POI categories (dining, culture, sport, tourism, shopping, public offices, entertainment...) that are remembered.

To my mind in your sample list some categories are heavily intersected, e.g. culture and tourism and entertainment.

Let us try to speak in terms of use cases, not POI categories maybe?

E.g. @biodranik has formulated well the sightseeing/tourism use case and "a local dweller" use case. They're quite different indeed, though some POIs may appear in both (e.g. supermarkets, toilets...) which makes sense and is not an issue if its not too much.

Also use cases should be "big" enough, e.g. I don't think that "dining" deserves its own, because its narrow enough to be tended to by search well (we have a "Where to eat" search category). And use cases should describe activities which are likely to keep the user in this "map mode" for quite some time, imho. E.g. for dining and public offices its usually a matter of finding a place via search and then going there. While one could be in a "tourist" mode for a long time and get the benefit of exploring sights, entertainment, cafes, etc. while moving around without distraction from furniture shops, public offices, specialist doctors, etc.

Upd: re "dining" there is actually a use case of "gastronomic touring", but I think its not big enough and is better included into a generic "tourism"

> The secondary division are the POIs. These should be pre-set for the mode-of-transport views but also configurable because there are many more use cases. So, at least a quick access to a list of 5-10 items with POI categories (dining, culture, sport, tourism, shopping, public offices, entertainment...) that are remembered. > To my mind in your sample list some categories are heavily intersected, e.g. culture and tourism and entertainment. Let us try to speak in terms of use cases, not POI categories maybe? E.g. @biodranik has formulated well the sightseeing/tourism use case and "a local dweller" use case. They're quite different indeed, though some POIs may appear in both (e.g. supermarkets, toilets...) which makes sense and is not an issue if its not too much. Also use cases should be "big" enough, e.g. I don't think that "dining" deserves its own, because its narrow enough to be tended to by search well (we have a "Where to eat" search category). And use cases should describe activities which are likely to keep the user in this "map mode" for quite some time, imho. E.g. for dining and public offices its usually a matter of finding a place via search and then going there. While one could be in a "tourist" mode for a long time and get the benefit of exploring sights, entertainment, cafes, etc. while moving around without distraction from furniture shops, public offices, specialist doctors, etc. Upd: re "dining" there is actually a use case of "gastronomic touring", but I think its not big enough and is better included into a generic "tourism"

alensiljak commented

2022-04-08 16:02:11 +00:00

(Migrated from github.com)

To my mind in your sample list some categories are heavily intersected, e.g. culture and tourism and entertainment.
Let us try to speak in terms of use cases, not POI categories maybe?

Yes, I fully agree. That will make things easier to communicate. I'm drawing most of these from the use cases, actually. It is true that culture/entertainment/tourism overlap a lot. In reality, it is quite simple - wanna go out. Where to go tonight? Would like to see a museum. Let's see a list of museums in the vicinity. Need an option to display just museums. Eventually art galleries. Or perhaps cinemas and other sorts of entertainment. A place for dinner or a snack nearby. Turning on the whole "tourism" thing is getting there but only partly.

Also use cases should be "big" enough, e.g. I don't think that "dining" deserves its own, because its narrow enough to be tended to by search well (we have a "Where to eat" search category). And use cases should describe activities which are likely to keep the user in this "map mode" for quite some time, imho. E.g. for dining and public offices its usually a matter of finding a place via search and then going there.

Well, I was looking for a notar the other day. Search is kinda helpful, yes. Depends also on how the POIs are categorized. But would still be nice to just turn on all the legal services and try to plan the day / route. It turned out that 3 of them were not able to help me out so was on the lookout for a solution, for example.
Edit: there's actually a Notary Service POI type.

Anyways, I'm not saying this has to be there. There are other apps that list and rank various services (POIs) but I'm thinking, since they are already there in OSM, why not? It's just a matter of applying filters.

> To my mind in your sample list some categories are heavily intersected, e.g. culture and tourism and entertainment. > Let us try to speak in terms of use cases, not POI categories maybe? Yes, I fully agree. That will make things easier to communicate. I'm drawing most of these from the use cases, actually. It is true that culture/entertainment/tourism overlap a lot. In reality, it is quite simple - wanna go out. Where to go tonight? Would like to see a museum. Let's see a list of museums in the vicinity. Need an option to display just museums. Eventually art galleries. Or perhaps cinemas and other sorts of entertainment. A place for dinner or a snack nearby. Turning on the whole "tourism" thing is getting there but only partly. > Also use cases should be "big" enough, e.g. I don't think that "dining" deserves its own, because its narrow enough to be tended to by search well (we have a "Where to eat" search category). And use cases should describe activities which are likely to keep the user in this "map mode" for quite some time, imho. E.g. for dining and public offices its usually a matter of finding a place via search and then going there. Well, I was looking for a notar the other day. Search is kinda helpful, yes. Depends also on how the POIs are categorized. But would still be nice to just turn on all the legal services and try to plan the day / route. It turned out that 3 of them were not able to help me out so was on the lookout for a solution, for example. Edit: there's actually a Notary Service POI type. Anyways, I'm not saying this has to be there. There are other apps that list and rank various services (POIs) but I'm thinking, since they are already there in OSM, why not? It's just a matter of applying filters.

pastk commented

2022-04-08 17:10:34 +00:00

Author

Member

@MisterY still I think that your sample cases are better served by search. There are some predefined categories already and users can enter a more specific search term, e.g. "museum", "notary", "cinema", etc. and get a map view with these POIs highlighted. It works while in navigation mode too. I suggest checking a recent related discussion in #2362 as well.

I think a separate map style is needed to create a specific "experience", not just display a specific POI category as it'll just duplicate search results map display OM has already.

@MisterY still I think that your sample cases are better served by search. There are some predefined categories already and users can enter a more specific search term, e.g. "museum", "notary", "cinema", etc. and get a map view with these POIs highlighted. It works while in navigation mode too. I suggest checking a recent related discussion in #2362 as well. I think a separate map style is needed to create a specific "experience", not just display a specific POI category as it'll just duplicate search results map display OM has already.

ackern commented

2022-04-09 16:06:50 +00:00

(Migrated from github.com)

I have checked the topobyte app. The reason why they made a "POI filter" menu is because their map rendering is unusable without it. They do not overlap POI properly and it looks cluttered without a filter in dense cities. Also, they use 10-years old outdated OSM map style and colors that are "too bright and colorful" also unusable in a long term.

I understand that menu-like filtering looks ok, but it is just a workaround. Topobyte apps are focused on city tourism. For a worldwide map with an outdoors focus there will be way more feature types, and the whole UI/UX becomes very complicated for users.

That's why we try to understand what is the real problem that our users are trying to solve with these "workarounds". For example, @ackern in your case, what exactly problem are you trying to solve now in Organic Maps? Are there any other ways to solve it more conveniently instead of making complex manual filters?

Sounds like we have very different definitions of some fundamental terms. What you call "too bright and colorful" I call mild and discreet. I've studied information design at the PhD level at Yale under Edward Tufte, if that name means anything to you (some of my work appears in one of his books), and at RISD so I have training in the subject. There was much emphasis on appropriate color intensities. FWIW Topobytes' colors are objectively much less bright and colorful than Google's markers, which are so intense you can barely make out the streets.

I'm having trouble understanding how the age of a style is relevant. Age isn't a measure of usability.

What you call a complex workaround, I find effortless, convenient and practical. I'm having trouble imagining what could be simpler than switching "Food & Drink" on and off with one click, or "Parks & Nature", etc.

I did mention a couple times in my first posts that I don't know what OM's specific intention is (couldn't find it stated anywhere) and I'm only posting what I personally look for in maps, which is what I understood the question to be. My needs, which don't vary much between home and traveling, are:

plain old street map without clutter, sometimes no POIs at all and sometimes a few certain categories (hence the wish to switch on/off).
route planning by bike: This is a highly complex specialized function and I don't expect OM to tackle it. I only mention it to say that a separate app for bike routing seems unavoidable -? For example BBBike.de and BBBike.org (different sites with different features) let you tailor routes by things like: "no cobblestones", "prefer side streets ", "avoid side streets", "prefer bike lanes in the street", "prefer bike lanes on the sidewalk", "avoid traffic lights" , "prefer traffic lights" etc. These I would consider complex (but absolutely essential); "Food & Drink on/off" I don't consider complex.
route planning or real-time navigation by foot or car: I only do that maybe once a month so for that I don't mind sticking with Google because for such rare occasions I can live with their various annoyances and privacy invasions.

> I have checked the topobyte app. The reason why they made a "POI filter" menu is because their map rendering is unusable without it. They do not overlap POI properly and it looks cluttered without a filter in dense cities. Also, they use 10-years old outdated OSM map style and colors that are "too bright and colorful" also unusable in a long term. > > I understand that menu-like filtering looks ok, but it is just a workaround. Topobyte apps are focused on city tourism. For a worldwide map with an outdoors focus there will be way more feature types, and the whole UI/UX becomes very complicated for users. > > That's why we try to understand what is the real problem that our users are trying to solve with these "workarounds". For example, @ackern in your case, what exactly problem are you trying to solve now in Organic Maps? Are there any other ways to solve it more conveniently instead of making complex manual filters? Sounds like we have very different definitions of some fundamental terms. What you call "too bright and colorful" I call mild and discreet. I've studied information design at the PhD level at Yale under Edward Tufte, if that name means anything to you (some of my work appears in one of his books), and at RISD so I have training in the subject. There was much emphasis on appropriate color intensities. FWIW Topobytes' colors are objectively much less bright and colorful than Google's markers, which are so intense you can barely make out the streets. I'm having trouble understanding how the age of a style is relevant. Age isn't a measure of usability. What you call a complex workaround, I find effortless, convenient and practical. I'm having trouble imagining what could be simpler than switching "Food & Drink" on and off with one click, or "Parks & Nature", etc. I did mention a couple times in my first posts that I don't know what OM's specific intention is (couldn't find it stated anywhere) and I'm only posting what I personally look for in maps, which is what I understood the question to be. My needs, which don't vary much between home and traveling, are: - plain old street map without clutter, sometimes no POIs at all and sometimes a few certain categories (hence the wish to switch on/off). - route planning by bike: This is a highly complex specialized function and I don't expect OM to tackle it. I only mention it to say that a separate app for bike routing seems unavoidable -? For example BBBike.de and BBBike.org (different sites with different features) let you tailor routes by things like: "no cobblestones", "prefer side streets ", "avoid side streets", "prefer bike lanes in the street", "prefer bike lanes on the sidewalk", "avoid traffic lights" , "prefer traffic lights" etc. These I would consider complex (but absolutely essential); "Food & Drink on/off" I don't consider complex. - route planning or real-time navigation by foot or car: I only do that maybe once a month so for that I don't mind sticking with Google because for such rare occasions I can live with their various annoyances and privacy invasions.

👍 1

biodranik commented

2022-05-29 12:40:40 +00:00

(Migrated from github.com)

@ackern Thank you for the detailed feedback. I would say that the main mission of OM is Simplicity for most users. That means that we sometimes sacrifice functionality for simplicity. And looks like it is worth it because there are already complex OSM-based apps like OSMand. Another important reason for simplicity is that we're a small team of enthusiasts, working in our free time on the free project. And we obviously prefer solutions that are simple to code and simple to test.

One of the simplest solutions could be creating several different map styles for the widest audience groups.

@ackern Thank you for the detailed feedback. I would say that the main mission of OM is Simplicity for most users. That means that we sometimes sacrifice functionality for simplicity. And looks like it is worth it because there are already complex OSM-based apps like OSMand. Another important reason for simplicity is that we're a small team of enthusiasts, working in our free time on the free project. And we obviously prefer solutions that are simple to code and simple to test. One of the simplest solutions could be creating several different map styles for the widest audience groups.

Rows
Columns

Disable display of (certain) POIs #2355