Buildings overlay

[westnordost]

building_ov.mp4

Building type overlay features:

• buildings are roughly categorized according to function and get their highlight color from there. Additionally, when zooming in, the icon of each building type is displayed.

• some not supported building types are treated as "synonyms" to supported building types. E.g. building=livestock is treated as synonym to building=farm_auxiliary. These buildings will be displayed as that building type in the app and if the in-app building type is not changed to another building, the "synonym" is retained on saving changes.

• other not supported building types are highlighted in grey, together with "other" buildings, clicking on them and changing them is still possible

• deprecated building types are highlighted in red, i.e. as if the building type hasn't been specified yet. However, if the building has a tag that potentially already describes the building type (e.g. amenity, shop, emergency, etc...), it is not highlighted in red

• the last selected buildings are displayed as buttons below the building selector

• added more selectable buildings: tower, container, tent, outbuilding, tomb also for the quest

• changed the categorization of the buildings: There is now a new category named "outbuilding" (which is also selectable) that contains all those smaller secondary buildings, like garages, sheds, garden allotment buildings, service buildings etc.

Additionally

last_picked.mp4

• added last-picked buttons to surface overlay (only for main surface), lit overlay, cycleway overlay (for separate cycleways) (fixes Add 'previous choice' option to Street lit overlay #4741 and more)

[westnordost]

Oh, and of course, I disabled the building type quest now by default.

To be honest, this was the main reason why I even started the implementation for this overlay. The quest is just so spammy.

[Helium314]

Some minor issues I found in a short test:

• The icon can be outside the building outline. This is the same as for quests, but for the overlay it "feels different". But I remember reading that correct placement inside the building can be tricky in some cases, so probably too much work.
• The icons for recently selected values are somewhat too wide for my display, so the rightmost icon has ~10-20% cut off. The whole line is scrollable, but it still seems a little weird.
• Some icons have weird lines at the bottom (they change color when zooming):
  

[westnordost]

Thanks for trying it out!

1. Yes, that's Marker outside oddly shaped target area #4965 . It would be nice, but I do not see it as required for this PR to be merged, although the implementation would roughly be just 150 lines of code (+tests)

2. Hmm... it is difficult to find a right max width that will not look much too small on some devices. Can you add a screenshot, both in portrait mode and in landscape mode? For the building levels quest, you do not have this problem? After all, there are buttons like these, too?

3. Yeah, I'm pretty sure that's tangram-specific. I don't really want to concern myself with tangram issues.

[Helium314]

For the building levels quest, you do not have this problem? After all, there are buttons like these, too?

The building levels quest only has 5 buttons, so there it's not an issue.
Maybe the number of recent values could be reduced if not all fit on screen?

[westnordost]

In general it would of course be best if one could actually scroll the buttons, and that is possible, but the default UI for that is not good. I experimented a bit with overlaying a gradient at the beginning and end (like done in the tutorial) but gave up because it turned out to be too much work. And in light of me wanting to migrate to Jetpack Compose as UI framework soon-ish, I don't want to put too much complexity in (new) layouts.

Anyway, maybe it would suffice to just make the buttons just a little bit narrower, I will have a look.

[westnordost]

2dp smaller should do the trick, right?

[mnalis]

Oh, and of course, I disabled the building type quest now by default.

To be honest, this was the main reason why I even started the implementation for this overlay. The quest is just so spammy.

Uhh, while I agree that building quest was spammy and of relatively low value (see #2464), doesn't that (disabling building quest by default) mean that solving (among most important of the quests, IMHO) Address quest is now significantly less likely to be triggered?

I'm afraid that it would make address quest much less discoverable and usable.

E.g. when there are lots of buildings tagged just with building=yes (as is most common, and happens in ~80% of all cases), am I correct in assuming that now Address quests won't ever be asked by default, unless user enables Building overlay and starts tagging buildings with more specific values? (or of course enables Address overlay and tags housenumbers there directly)?

---

Perhaps now would be a good time to revisit #2464 (comment) (which was postponed at the time) and extended housenumber quest to asks also for generic building=yes?

While I have used Address Overlay in the past, it was sporadic (and mostly to correct off-by-one numbering). In all other cases, I've found Address Quest to be significantly more useful and easier to use. It would be real shame to basically lose it in 80% of the cases...

[westnordost]

Yes, it is less likely to be triggered. I expect less contributions to the building type, and subsequently less contributions overall, at least in the short run, because building type is the quest that is by far solved the most. But we have the address overlay. That is what I meant in the ticket you linked. I do not consider to ask the address quest on building=yes.

Yes, it will lead to less addresses being contributed with StreetComplete.

You know that the primary goal of this app is not to make users contribute as much valuable information as possible efficiently. What the app sought out to do is to appeal to those that just want to contribute a bit on the side, casually. It is certainly a non-goal to [prey on certain tendencies and goodwill of some people and] burn them out by overloading them with what feels like work. (In other words, the sort of gamification you see in many free to play games.)

Those people who drop the app because there is just too much boring and repetitive stuff to do in general don't come here to complain. As it stands, it is only a few honest nerds amongst those that try out the app that actually give me feedback about how, well, not-fun and/or feels-like-work the app really is. Maybe not in relation to the other OSM editors out there, but definitely to normal people. Normal people just drop it.

I am aware the opinion making is somewhat skewed on github towards power users, who want more, not less. Normal people don't even come here.
The building type quest was at the top of the list of quests that are not only massively spammy and time consuming but also at times somewhat difficult answer. It was high time that this quest was eliminated from the default configuration.

The app feeling like work is the top # 1 complaint I get when people get the chance to give me feedback about the app face to face. In fact, recently, one of the NLNet people (i.e. open source enthusiasts!) I talked to told me that he was actually surprised to see that the app is actually used by that many people, after he tried it out himself - that it feels like work.

But the editor usage stats are misleading. It might be 20k+ per year, but most contributed just a few quests and then were never seen again. Sure, there a new users every year, and a few stick around, but retention of new users is a huge problem.

Does that sound dire? Because I mean it, I do think the situation is dire. But there is hope, of course:

• I hope that migrating to maplibre will make the map look prettier, smoother and solve things like the chopped off animations when zooming in. Sounds like a small thing, but UX isn't a small deal. Not to mention possibly opening up the possibility towards making the "quest forest" a little less intimidating and solving many long-standing usability issues that have to do in one way or another with the map.

• when moving to Jetpack Compose, since the UI needs to be rewritten anyway, this gives the opportunity to refresh some UI. In particular, some things OpenStop is doing are really neat and worth copying

• with the building quest by default gone and much less quests being displayed in consequence, performance should be better again. (Note that the performance gets worse with every quest type added! - download takes more time, quest creation takes more time, more quests are persisted and returned from the database, more quests need to be displayed, ...)

[matkoniecz]

And power users can reenable this quest type and/or use overlay - so they are not impacted negatively. (I would oppose removing quest completely, here and for others that got overlays - but switching off seems fine to me)

[mnalis]

Thanks for the detailed answer @westnordost , I really appreciate it!

I definitely agree that nice and smooth UX is a must for targeting newbies, and that default config should not be targeted towards advanced users (so I am OK with your decision here - I was just unsure if the collateral damage was overlooked or intended).

I've opened #5472 as discussion to identify issues and suggest possible fixes to make SC more fun and less work for users (in order not to pollute this PR)