Multiple-option quests on SC

[rhhsm]

As suggested by @westnordost in #4697, I would like to start a discussion on whether it's a good idea to introduce multiple-option quests in SC.
There are some Points of Interests for which SC has a series of one-answer option quests, such as for pedestrian crossings, pedestrian traffic lights and public transport stops. I think it would be a powerful improvement if those quests could be combined in one multiple option quest for each PoI in which all features present at that PoI can be added in one go. When completed, SC will add all present tags to the PoI as well as a check date, but no *=no tags for features that are not present. The checkdate tag will serve as evidence that a PoI has been surveyed by a SC user, so SC will not ask the quest for PoIs that have a checkdate. Features already tagged as present on OSM can be highlighted on the answer form, and toggled off when no longer present.

I think this has the following pros and cons:

Advantages:

1. It is a more efficient way of entering data, with fewer taps
2. It avoids the addition of *=no tags for features that are not present (this was complained about in Please avoid "no" values #4191)
3. It makes it possible to ask about features for which the *=no value has not been documented (traffic_calming=no, for instance)
4. It allows for adding options that are rare, and that would result in "spammy" quests if they were asked for in a separate yes/no quest
5. If later on we decide we want to add more possible PoI features to the quest, they can simply be added as additional answer options. All PoIs with a check date before the addition would be quested again (and the previously added features can be resurvey at the same time).

Disadvantages:

1. This is a deviation from the fundamental design decision of SC to always only ask one thing about a PoI. However, housenumber and street can already be added in one go in the address overlay, and multiple answer options already exist (in the ramp quest, for instance)
2. SC's strength is its simplicity, and having multiple-option quests may be seen as complicated and overwhelming especially to new users. Multiple-option quests may also get very lengthy, with many answer option pictures and explanation text. Of course the length of any quest should be limited so it's not too confusing and time-consuming to answer it. If necessary, multiple-option quests could be switched off by default, and one-answer option quests can be kept for those who want to use them (default on). Multiple-option and one-answer quests about the same kind of PoI can co-exist, and their appearance can be influenced by their position on the priority list. We could also decide to use multiple-option quests only for features that are not suitable for one-answer quests (but then we loose much of the advantage).

[westnordost]

Have you heard of Ilya's Every Door?

[rhhsm]

No, but I will give it a try

[mnalis]

While I personally do generally like that concept (e.g. as implemented in EveryDoor or even Vespucci), I do not think it is a good match for SC, and likely even for SCEE fork.

Here are a few (of lots more) random questions/issues:

• it breaks one of the fundamental ideas about SC (Yes, so do Overlays, but they are completely separate mode of operation)
• if implemented, I think it definitely must be an user preference if they want it or normal simple quest
• that means that for every such quest, you would have to code and maintain not only simple quest, but also such multiquests, and keep them in sync. (Yes, we do have that problem with Overlays too, and it is showing problems when they behave differently for same thing. It is bad UX! Having 3 copies of code supposedly doing the same thing would be even more horrifying from programmers perspective)
• special coding if users do not care about some quests, you would now have to have separate UI tweaks in muliquests, so users are not bothered at all about things they don't care about).
• otherwise (and even with such tweaks) pressure to users would be non-welcoming ("well, I know you just care if this crossing has a lowered kerb or not, but here are 8 other questions too!")
• you would have to implement not only yes and no answers, but also unknown (i.e. if tag does not exist at all, or quest was hidden, or user is unsure of the answer etc)
• what about if user only answers some of the quests? as the timestamp has changed, no other quests would now be asked for that users, or other users? Or it will mark as the user has selected local hide option for all answers that were not given? What if users wants to answer it later (e.g. when they get to other side of that crossing and can actually answer vibrate quest for example? Would they have to go to settings / reset hidden quests? but that would reset all of them, not just the one they want?)
• how would it be marked? just single check_date (which would then be all_or_nothing, i.e. precluding other quests for years if you did not get them in the first go) ? or check_date:xxxx for every quest there is (which would then spam the OSM with tons of unneeded tags)?
• it changes what can be suggested as Quest, as it now becomes open for even more complex / problematic ideas
• etc.

There are many questions - some are easier, some are harder. There would also be much work to implement it correctly (likely least as much as for Overlays, but with much lower usefulness).

---

TL;DR - I'd also recommend to try EveryDoor (I did and love it for what it does - but it only handles points and sometimes polygons, not lines for which I still think SC is the best). It is a good tool for that job, especially because it avoids that whole quest-business (i.e. it is user-driven meaning that user chooses what to do if anything; and not quest-driven when mobile device generates the tasks for the user, and thus needs all that check_date tags and complications when to show what etc.)

If you were dead-set on SC having that functionality, such multi-question tasks would be much better be implemented as e.g. "Crossing overlay" (which is basically the SC mode that emulates EveryDoor/Vespucci user-driven UI, instead of being Quest driven: which is what SC was intended to do initially)

[rhhsm]

Thanks, some good points!

Here are a few (of lots more) random questions/issues:

• it breaks one of the fundamental ideas about SC (Yes, so do Overlays, but they are completely separate mode of operation)

True, but I think it should be allowed to question the fundamentals.

• that means that for every such quest, you would have to code and maintain not only simple quest, but also such multiquests, and keep them in sync. (Yes, we do have that problem with Overlays too, and it is showing problems when they behave differently for same thing. It is bad UX! Having 3 copies of code supposedly doing the same thing would be even more horrifying from programmers perspective)

I'm not very aware of such issues because I'm not an IT expert (did a lecture course in Pascal in my student days so I know a bit about what's it like, but that's all). I can only contribute here with my user experience. I'm not in favour of keeping single- and multi-option quests in parallel, but mentioned it as an option.

• special coding if users do not care about some quests, you would now have to have separate UI tweaks in multiquests, so users are not bothered at all about things they don't care about).

I wonder how many users are focussed on only solving certain quests and would be bothered by being asked to enter data on subjects they are less interested in. It's an alien concept to me: I'm trying to improve the map in any way I can and don't mind answering more quests when I'm at the PoI anyway.

• you would have to implement not only yes and no answers, but also unknown (i.e. if tag does not exist at all, or quest was hidden, or user is unsure of the answer etc)

I guess "unknown" would occur a bit more frequently but can still be solved by hiding the quest or leaving a note.

• what about if user only answers some of the quests? as the timestamp has changed, no other quests would now be asked for that users, or other users? Or it will mark as the user has selected local hide option for all answers that were not given? What if users wants to answer it later (e.g. when they get to other side of that crossing and can actually answer vibrate quest for example? Would they have to go to settings / reset hidden quests? but that would reset all of them, not just the one they want?)

Users should be encouraged to enter all the options that apply, and informed that SC will assume that their answer is complete. The PoIs I suggested can be surveyed from a single viewpoint, and maybe multiple-option quests should be limited to such PoIs.

• how would it be marked? just single check_date (which would then be all_or_nothing, i.e. precluding other quests for years if you did not get them in the first go) ? or check_date:xxxx for every quest there is (which would then spam the OSM with tons of unneeded tags)?

No, that would get too complicated. Users should be assumed and encouraged to give complete answers.

• it changes what can be suggested as Quest, as it now becomes open for even more complex / problematic ideas

That's an advantage, I think...

There would also be much work to implement it correctly (likely least as much as for Overlays, but with much lower usefulness).

Thanks to all coders here who put so much work into this, and my apologies for contributing only with more ideas for additional work ;)

TL;DR - I'd also recommend to try EveryDoor (I did and love it for what it does - but it only handles points and sometimes polygons, not lines for which I still think SC is the best). It is a good tool for that job, especially because it avoids that whole quest-business (i.e. it is user-driven meaning that user chooses what to do if anything; and not quest-driven when mobile device generates the tasks for the user, and thus needs all that check_date tags and complications when to show what etc.)

It's what I like about SC: a bunch of people here decide jointly which of the the many tags that can be added to the map are important enough to spend time on making a quest for it, so I can feel useful for adding data to the map that people find important.