Quest filters

[smichel17]

In https://github.com/streetcomplete/StreetComplete/discussions/2457, I have noticed that many of the use cases are not mutually exclusive. For example,

• There are some quests that I may want to hide at night.
• There are some quests I may want to hide when there is snow out.
• When it is nighttime and snowy, I want to hide both sets of quests.
  • This is true whether I am walking, biking, on the bus, etc.

Quest presets would not address these use cases, because the idea of the preset is that you can only select one at once. Therefore, I propose an alternative: Quest filters.

• Quest filters are similar to presets, except you can select as many as you want.
• Enabling a filter hides all associated quests.

I am not (yet) proposing that quest filters should replace presets entirely; I would like to try them before deciding whether I think they complement or replace presets. Filters should be implemented first because they might remove the need for presets, whereas presets definitely will not remove the need for filters.

For the initial implementation, I propose a single, hard-coded filter: quests that require you to enter a place to answer. That's the vegetarian, vegan, internet connection, wheelchair accessibility (x2), accepts cash, baby changing table, and kosher quests. This way, we're replacing existing functionality instead of adding something new; we're not making it any harder to change course later on, since we'd have to modify the "disabled by default" functionality anyway. Steps to implement:

• [ ] Remove the "disabled by default" functionality from these quests, except for the kosher quest, which has a second reason for being disabled by default.
• [ ] Add a simple checkbox or switch preference at the top of the quest selection screen, "Hide quests that require going inside"
  • [ ] Add some way to view the list of quests that this applies to. Maybe one of those two-section switch preferences, where tapping the switch itself enables/disables and tapping the text opens a popup which lists the included quests? Very open to better ideas.
• [ ] Update the quest display logic to check for this filter, in addition to just checking each quest's status individually.
  • This is the real goal of the change… to lay the technical foundations for quest filters (while also being a positive change — easier to enable/disable all these quests at once).

[mnalis]

Hmm, it might have some advantages, but overall it seems to me, especially if there is more than one filter (and even before I think of several of my own preferences, I can see at least commonly requested filters lately: "going inside", "winter", "night"):

• it does not really provide new functionality which cannot be done with custom presets (it might save some clicks on initial setup, though. Or not, depending on steeper learning curve)
• it to more complex (as it have both add/remove and they stack) than custom presets even if current quest selection is removed completely (and much more so if it is not - I can see how interaction of filters with "disabled by user", "disabled by country", "disabled by default" might make its decision nearly incomprehensible even to advanced users - which most of SC users are not)
• for user it would be even more problematic, as it would be nightmare to use and maintain if filters allow both hiding and enabling quests, as they then should then have specific ordering, as one filter might change another. In the end, list of enabled filters and of their ordering would likely be much more complex than current list of quests, unless we also implement "custom presets of filter presets" which sounds like serious overengineering...

Thus, Occam's razor would suggest going for simpler solution (eg. plain custom presets).

[smichel17]

as it have both add/remove and they stack

The idea was only to have remove, not add. When the filter is enabled (by default), those quests are not shown. When the filter is disabled, these quests are shown, as long as they are not excluded for some other reason. This is why I named the feature "filters" :P

I can see how interaction of filters with "disabled by user", "disabled by country", "disabled by default" might make its decision nearly incomprehensible even to advanced users - which most of SC users are not)

If a quest is disabled by any of these methods, it is disabled. The only form that needs a special interaction is when a quest is enabled individually (ie, checked) and disabled by the filter, and the functionality for that already exists. It is the little blurb below a quest which is disabled by country. Right now it might read, "Never shown in US-MA"; if it is disabled by filter, it would read, "Hidden by indoor filter". If it is both, it would show "Never shown in US-MA", because that one cannot be changed.

custom presets of filter presets

This would be called "custom filters".

simpler solution (eg. plain custom presets).

I disagree that plain custom presets are necessarily simpler. Even if we only consider the 3 independent variables that have been mentioned so far (night, snow, inside), you've already got 8 different possible presets. And then you can overlay that on top of your movement profile presets, and maybe movement speed, boring/spammy quests and all the sudden you've got dozens of them, even if you don't create every combination (as I'm sure most people wouldn't).

One reason I suggested this particular initial implementation is that even if no other filters are ever implemented, having one switch to hide indoor quests is an improvement over having to toggle 8 different quests if you want to change it. This is also why I proposed keeping it in the settings instead of moving it to the main UI.

[caugner]

@smichel17 Another approach would be an action "Hide this kind of quest [until tomorrow/forever]" when selecting a quest on the map. This would be a versatile solution to easily/quickly hiding quest types in different circumstances.

[smichel17]

That's a fine feature, but I think it is off-topic, since it does not replace this suggestion, unless you also propose enabling all "indoor" quests by default. The reason I am suggesting this particular implementation is that it has value even if it is never expanded into a general solution — not having to scroll the whole list to individually enable quests which are disabled by default.

[mnalis]

as it have both add/remove and they stack

The idea was only to have remove, not add. When the filter is enabled (by default), those quests are not shown. When the filter is disabled, these quests are shown, as long as they are not excluded for some other reason. This is why I named the feature "filters" :P

Ah, okay, I misunderstood (I thought that you intended "indoor filter" to enable indoor quests, instead of disabling them).

So if understand correctly the use case is basically "enable all quests that you ever want to solve" and then "use filters to disable groups of quests you don't want to solve at that particular moment".

I see you propose to start just with hardcoded "indoor" filter, however I'd mostly be interested if filters could be created and modified by the user (ie. to use it as an possible alternative to custom presets - the "indoor" group of quest is fine example for filters, but one of much less relevance to me personally).

I disagree that plain custom presets are necessarily simpler. Even if we only consider the 3 independent variables that have been mentioned so far (night, snow, inside), you've already got 8 different possible presets. And then you can overlay that on top of your movement profile presets, and maybe movement speed, boring/spammy quests and all the sudden you've got dozens of them, even if you don't create every combination (as I'm sure most people wouldn't).

Yes, that ability to activate several filters cumulatively is seducing! However it comes at a cost - while selecting preset is just one click for choosing preset, selecting combination of several presets is several clicks, which makes for a slow change (eg. I might be in "only important stuff, visible in night, and in winter, excluding indoor" for part of the trip, and then switch to "mostly everything" mode when I see this part of the map is cleared and I'd be idling, and then when I get in more unmapped terrain again switch back to "only important stuff, visible in night, and in winter, excluding indoor" set of filters etc.

And if we have enough filters, it starts to look almost as annoying as current situation with long quest list. And yet, to be truly useful, there needs to a dozen of filters at least:

For example, users (myself, for example) might want filters to:

• disable indoor quests
• disable quests not solvable at night
• disable quests not solvable in winter
• disable annoying useless building quests (except useful houseaddress ones)
• disable all quests not easily solvable from train
• disable all quests not easily solvable from bus
• disable all quests not easily solvable from car
• disable all quests when user is in a hurry on foot
• disable car parking, car lanes, speed limits and other quests not interesting to non-car persons
• disable all quests for which user has to stop the bicycle, except important ones (where important is defined by user)
• disable all quests user deem of less importance etc.

One reason I suggested this particular initial implementation is that even if no other filters are ever implemented, having one switch to hide indoor quests is an improvement over having to toggle 8 different quests if you want to change it. This is also why I proposed keeping it in the settings instead of moving it to the main UI.

And yet, it is likely because that one filter is the one you personally care the most about. If I personally had to choose only one filter, it would by far be "disable all quests for which user has to stop the bicycle and s/he wouldn't stop otherwise (so ones at crossings are OK), except rare few important ones for longer-range cycling navigation (in effect, disable everything except: crossing quests, oneway, cycleway, surface, smoothness, tracktype, lit, opening_hours)"

And somebody else would have some third set of preferences, I'm sure. That's why I think the possibility of the user being able to create/modify the filters (or presets, in that other ticket) is of paramount importance.

[smichel17]

And yet, it is likely because that one filter is the one you personally care the most about.

Nope. If I had to choose one filter, it would be to disable "spammy" quests, like building:levels and roof type, as these are the ones I toggle most frequently.

I chose it for the reason I already stated: it is effectively a refactoring of existing functionality (indoor quests disabled by default) rather than adding new functionality. It is kind of a silly, but you could imagine the current functionality as 9 different hard-coded quest filters (one for each type of quest that is disabled by default, all for the same reason). From that perspective, I'm proposing that we unify those filters into a single one.

For example, users (myself, for example) might want filters to:

Yes, these are all documented quite nicely over in #2457.

I'd mostly be interested if filters could be created and modified by the user

I'm aware. I actually agree with you that in the long run, whatever implementation of presets or filters should be user-customizable. However, implementing user-customizable behavior is a lot more work than a single hard-coded feature (users generate lots of edge cases!), and it locks in the design more (removing the feature will annoy users who have spent time customizing it). I basically want to be more informed about what it's like to use the feature before committing to that.

It is surprising to me — and, if I'm being honest, a little frustrating — that you push back so hard against anything that does not include customization, even when it is explicitly just an initial implementation for testing and understanding, rather than the final thing. It's like if we were constructing a building, and I proposed building a little hut with no foundation, to get some idea of what it will be like. Your pushback seems to me like saying we shouldn't build the hut, because the house must have a foundation. I agree, the house probably needs a foundation (and it would be a good idea even if it is not strictly required). But laying a foundation is a lot of work and hard to change; I want to see what we can learn from living in the hut for a while, so that when we move on to building the house, we can build it right the first time.

However it comes at a cost - while selecting preset is just one click for choosing preset, selecting combination of several presets is several clicks, which makes for a slow change

It might. Or it might not. It's hard to know. I'd like to get a chance to play around with it and see how often I actually do this.

If it turns out to be a problem, that toggling a variety of filters takes too much time, then I'm more than happy to add quest presets in addition to filters. If this is the only problem with filters, then maybe presets end up just being a combination of filters (rather than a full custom list). Or, if it turns out that filters do not provide enough power and it's still required to toggle individual quests, then maybe presets end up being separate from filters — a different base on top of which filters can be applied. Or maybe it turns out that most filters can be toggled automatically (based on time of day, season, movement speed, etc), and there's really no need for adding them to the UI, and everything else can be turned into a preset.

The point is that I don't know, and I want to take small steps to get some experience and find out. I would appreciate if you would stop arguing against it on the basis that it does not fix every problem. It's not intended to. If it creates problems or is incompatible with a different solution that you'd like to see, then by all means bring those concerns up. Or if I were pitching this as "I no longer think presets are worth implementing at all." But I don't think any of those are the case.

[mnalis]

It is surprising to me — and, if I'm being honest, a little frustrating — that you push back so hard against anything that does not include customization, even when it is explicitly just an initial implementation for testing and understanding, rather than the final thing. It's like if we were constructing a building, and I proposed building a little hut with no foundation, to get some idea of what it will be like. Your pushback seems to me like saying we shouldn't build the hut, because the house must have a foundation.

Fair enough. That is actually not a bad analogy. Yes, I probably would advise against building a hut, where I estimate an apartment building with strong foundation is actually needed. It is not that I hate huts. But, because when it becomes obvious that the apartments with foundation is what is actually needed, the huts would have to be razed to the ground. Which usually makes hut inhabitants nervous. Which usually makes it hard to raze the huts to build better solution. (I actually live in city like that, where it is for all practical purposes impossible to improve transportation, as decisions from times past prevent it. It sucks. So by default, I always try to look longer term in order not to paint myself into a corner.)

I agree, the house probably needs a foundation (and it would be a good idea even if it is not strictly required). But laying a foundation is a lot of work and hard to change; I want to see what we can learn from living in the hut for a while, so that when we move on to building the house, we can build it right the first time.

Only, when you build hut, you suddenly have much less incentive to raze it in order to build apartment building at its location. And so, when you accept it is hard to remove that hut, but you still need more places for people to live, you start looking at solutions like "let's build an apartment building, but make it so it's first few floors are holes, so the hut can remain where it is and apartment building will be built over it". Which makes it more complex to users, and needlessly much harder to engineer, and thus even less likely to happen.

So, in short, yes, I would prefer one harder to implement final solution which will solve multiple problems, instead of half-solutions which will likely make proper solution impossible to achieve. (please do not think of this as bashing of idea; I just want to say here that feature that fixes just one hardcoded thing is less capable then the one which can solve multiple ones).

However it comes at a cost - while selecting preset is just one click for choosing preset, selecting combination of several presets is several clicks, which makes for a slow change

It might. Or it might not. It's hard to know. I'd like to get a chance to play around with it and see how often I actually do this.

Sure, I was just pointing out possible issues in that case (eg. trying to plan in longer term, as you did hint that, while not initially, in the longer term it might evolve into something with more features).

If it turns out to be a problem, that toggling a variety of filters takes too much time, then I'm more than happy to add quest presets in addition to filters.

I would actually think it is a bad idea to have both. Increased complexity in software is rarely a good idea. Not for a developers, and much less so for users (especially when your mission is "be simple and easy to use"), and especially if features would overlap in such way - it is bad design IMHO.

If this is the only problem with filters, then maybe presets end up just being a combination of filters (rather than a full custom list).

I'd be totally compatible with filters being replacement for custom presets. But I think they would need to be customizable in that case (which is what my second comment boils down to).

The point is that I don't know, and I want to take small steps to get some experience and find out. I would appreciate if you would stop arguing against it on the basis that it does not fix every problem. It's not intended to. If it creates problems or is incompatible with a different solution that you'd like to see, then by all means bring those concerns up.

I do apologize if my comments made you think I was bashing the idea. To clarify, I am not arguing against filters. My first comment was misunderstanding that filters would have ability to both "add" and "remove" quests, which would IMHO be very hard to use correctly. After your explanation that they would only "remove" quests, in my second comment I was actually fairly enthusiastic about the filters (that is, their futuristic customizable variant), so I tried to look into the future, and see how advanced version of filters might solve many other problems (including my pet ones) than just this first hardcoded one.

However, if you are against filters being customizable (at first you didn't look like idea bothers you, but now it seems to me like it does; so please forgive me if I miss the point here), then I would think such hardcoded-only implementation is problematic, due to issues mentioned above (hut analogy etc). If you want, I can elaborate more, but I've already been far too long (just wanted to apologize and explain myself), and I'm not even sure if you consider idea of custom filters good or bad currently (I'm getting mixed signals: on one hand you seem to say you want to see custom filters, but on another hand you seem irritated when I say custom filters are a way to go)?

Or if I were pitching this as "I no longer think presets are worth implementing at all." But I don't think any of those are the case.

Well, I did say in my second comment that filters would be very interesting to me if they could REPLACE custom presets (and then proceeded to say that they might be even better solution in some aspects, as they could stack).

[smichel17]

Alright. It looks like this is (yet another) instance of text-based communication being hard (specifically an XY Argument). So, I think I owe you an apology for not responding to the most charitable interpretation of your posts. In particular, I failed to pick up on the enthusiasm. I broadly agree with those concerns… and I think this particular proposal does not run afoul of them.

Let's see if I can stretch the analogy to its breaking point :smile: The main thing I want to add to the analogy is distinguishing between different parts of the property. There's the front, near the road, where we've been discussing building an apartment — as part of the main UI; probably in the main menu — and the back, near the woods — the settings screen.

I agree that we shouldn't build a hut in the front, to avoid having to raze it or build a frankenstein apartment around it. However, there's already a group of lean-tos in the back . I'm proposing replacing most of those lean-tos with a single hut — specifically because the lean-tos are already there, so we won't (or will barely) increase the footprint of developed land. Any decision to raze the hut later would also need to raze the lean-tos it is replacing. Yes, there's some risk that people will become attached to the hut, but I think it is relatively low, and even if we have to leave this one hut standing after something has been built in the front, it is not such a big deal. So I think the hut is purely a positive development, no matter what we decide to do out front.

I already know that I don't really like the lean-tos, and I don't spend much time in them (seldom toggle or re-arrange quests). I'd like to try living in the hut out back for a while to see if I like it, or if I have similar annoyances. Hopefully that will help me decide whether I think it would be enough to build a bunch of huts out front or whether we need to build an apartment building.

However, if you are against filters being customizable (at first you didn't look like idea bothers you, but now it seems to me like it does)

I'll state my opinions on customization here and try to be as straightforward as I can:

• I am not against filters being customizable.
• I am against bringing up "$feature must be customizable" in every branch of the discussion, because it makes discussing any other part of the design difficult.
• I am for some part of the system being customizable, but against all parts being customizable.
  • Which part depends on what the final design is. For example, I would be okay with "only filters (customizable)" or "filters (hard-coded) and presets (customizable)" but not "filters (customizable) and presets (customizable)".

---

This is only part of my response — the "meta" part. This has been a fairly long exchange (I did not spend the time to write short posts) and much of it has been misunderstanding, so I want to clean up the discussion before getting back to the design of the actual feature (especially since I know @westnordost has less time recently and I want this issue to be easier to follow).

So, my plan is, with your and @caugner's permission:

1. Edit the original post to clarify that filters are only for hiding quests.
2. Write a comment where I quote and reply to all the parts of the conversation which are not misunderstandings.
3. Hide all the other comments in the thread.

This probably won't be today, though.

[mnalis]

@smichel17 thanks for the clear up, I do agree with you there that having both customizable filters and customizable presets is not a good combination. I personally think that as a final solution it would probably be best to choose only one of them (in its customizable form, of course). Good idea about lessening the load on our favorite developer, by all means feel free to hide my comments and re-clarify this ticket.

[westnordost]

I've read through this all again and - skipping that part about huts and foundations - the idea is alluring.

Comments:

• I don't see the need for custom filters. Any filter would work like that it only disables quests. So, if a person never wants to solve building levels, he just disables that in the normal quest selection list. This then works independendly of the quest filters.
• I wonder how theoretical the use case of solving things in a train or in a bus really are. I remember trying to solve some quests on the train and I mostly failed. It just moves too fast for the download of the appropriate area to complete. I imagine it is very similar for a car. For a bus, at least it stops very regularly. I wanted to get on a bus today and try out some mapping but unfortunately I am ill right now so I have to postpone that. Anyone has some actual experience here?
• As indicated above, I doubt that a profile for car, for train and even for bicycle would make sense. As you are not a passenger in a bike, there are enough other things to do on a bike, this mode of mapping that distracts from traffic should not really be supported. I once also tried that, but ended up only really mapping whenever I was waiting somewhere. But when I am waiting, I am practically back on foot for most intents and purposes.
• How many viable filters would then still be there? "Need to go inside", "Not quick & easy to solve" (aka spammy quests), maybe (though this is kind of very specific) "Only solvable if the ground is not covered in snow"

[eginhard]

• I wonder how theoretical the use case of solving things in a train or in a bus really are. I remember trying to solve some quests on the train and I mostly failed. It just moves too fast for the download of the appropriate area to complete. I imagine it is very similar for a car. For a bus, at least it stops very regularly. I wanted to get on a bus today and try out some mapping but unfortunately I am ill right now so I have to postpone that. Anyone has some actual experience here?

I sometimes do quests on buses and mountain trains that go slow enough for me to identify the information I'm looking for. It works very well for building types, crossing and bus stop details, road surface, lane counts, cycling lanes.

[matkoniecz]

Anyone has some actual experience here?

My friend was solving some quests from tram that in my city are pretty slow and stop often, making quest solving more feasible than from a train (which I also tried and failed).

[Helium314]

• I wonder how theoretical the use case of solving things in a train or in a bus really are. I remember trying to solve some quests on the train and I mostly failed. It just moves too fast for the download of the appropriate area to complete. I imagine it is very similar for a car. For a bus, at least it stops very regularly. I wanted to get on a bus today and try out some mapping but unfortunately I am ill right now so I have to postpone that. Anyone has some actual experience here?

Loading is not really an issue. On bus you often know the route, so you can load it in advance. On train or tram you even see the route on the map. (in my personal build I disabled auto-download, this helps with pre-loading while moving) Regainding the fast movement, I find it very helpful to have the quests already loaded and decide which quests to answer before I actually see the road/house/object they're about.

Some quests are usually rather quick and easy to answer, like road surfaces and lanes, building type/height, crossing type/island. Depending on movement speed and distance to quest, it's also often possible to answer quests like bench backrest, railway crossing, transport stop shelter/bench/bin, bicycle parking type/covered, steps railing/direction/ramp or even wheelchair access (only in cases where there is a clear 'no').

[smichel17]

I don't see the need for custom filters.

I think it's a combination of what @mnalis wrote in these comments:

1. https://github.com/streetcomplete/StreetComplete/discussions/2457#discussioncomment-268311 — Going on a bike ride, and wanting to see only the quests worth stopping for (aka that @mnalis cares about). This is the mode most of the time.
2. https://github.com/streetcomplete/StreetComplete/discussions/2457#discussioncomment-268350 — Sometimes, just using SC to kill time and wanting all quests enabled.

I think a single custom filter might be the best compromise. Regardless, this can come later; I stand by my proposal for the initial implementation — a single hard-coded filter for indoor quests.

[westnordost]

It's really difficult to decide what to do...

For a "on a bus" profile, I am currently trying to decide what should be in and what should be out here https://miro.com/welcomeonboard/UnBNenVoV1dYT3FpeThOdnJaaU10ZjE2UWxYVThlQ0YwZTN2akVYZThVYXRUakVockl0S0l1Rm1Ra0Vyb3RLWXwzMDc0NDU3MzQ5NTk3NDI5MzAy but it is really quite fuzzy.

Same with an "only display easily to solve" button / filter...

[westnordost]

So now I am thinking if not ... many issues can be solved by changing the quest order from "importance" to how quick and easy it can be solved regarding both the time to input the answer but also to spot and explore the answer:

1. first quests that are quick and easy to answer from a distance and/or while passing by
2. second, quests that are still quick and easy to answer but require to be on foot / in front of it
3. next, quests that require a little more time to input, f.e. with a number input
4. same but with more complex, i.e. time consung input
5. almost last come quests that may need some exploration, i.e. walking around to check
6. then last come the things that require one to go inside
7. finally, quests that usually come in heaps come last, i.e. if there is anything else than building types etc, it is asked first

So if the quests that are easy to answer also when moving faster and can be answered on the spot rather than needing to look around and explore (bike, bus, passenger), it mostly solves the need to have such mode-of-transportation-based filters. As mentioned earlier, it is really hard to define what is still solvable in a bus and what is not, this solution works around that. Of course, filters such as "ground is covered in snow" are not solved by this, but IMO this is really somewhat of a fringe use case - also, iwth the new order, surface quests, sidewalk and cyclway quests etc. tend to come later because they are not answerable on the spot but require some walking around (to check if it is the case for the whole highlighted stretch)

What this also does not solve but is very important to me, is the "I am overwhelmed, don't show so many quests!" issue. Need to think about it. There should in any case be a dialog that reads something like

Overwhelmed by the number of quests? Would you like to hide some of the more dull quest types for the time being?

You can change and fine-tune this anytime in the settings.

[Hide dull quest types] [Go to settings] [No thanks]

Those "dull quests" would then be quite at the end of the list: building type, building levels, roof levels (and maybe also lit, surface, lanes, cycle track, sidewalk etc - needs test how "empty" the map then looks)

[westnordost]

Again, please check out https://miro.com/welcomeonboard/UnBNenVoV1dYT3FpeThOdnJaaU10ZjE2UWxYVThlQ0YwZTN2akVYZThVYXRUakVockl0S0l1Rm1Ra0Vyb3RLWXwzMDc0NDU3MzQ5NTk3NDI5MzAy I added a proposed new order there

[mnalis]

@westnordost What do you mean exactly by "dull", though?

1. quests that are many in number?
2. quests that do not seem important (to that particular user)?
3. quests that are spammy (ie. has predominantly only one answer)?
4. quests that take more effort/time to solve? (or less?)
5. some combination of the above?

For example to me, for some activity to be dull it probably must be be both frequent (1) and not seem important (2), although spamminess (3) might (or might not) be playing a factor too.

To wit: one might enjoy (and even be addicted to) some computer game because they feel they are doing something important (buffing up stats in a game, collecting trophies or whatever - let's ignore the objective reality that anything done in any game is quite likely totally wasted part of your life, but it is that feeling that you're doing something important in that gameworld that counts). Now, the game might be requiring the player to go through quite many same elements (1 - eg. shooting down enemies) and they might be even quite spammy (3 - for example collecting your farm output in farmville or building troops or whatever), but they players would not call it "dull", quite the contrary.

On the other hand, if one is playing some RPG/adventure game and they're stuck (even though they can move through a ton of different new terrain so not 3) so they just wander aimlessly without accomplishing anything (ie, they do not have a feeling they are doing something useful/important 2) it becomes "dull" and they're likely to give up after some time.

So I would argue for two filters:

• "dullness" filter - filter out quests that are both many in number (1) and do not feel important to majority of people (2 - obviously, this can not fit everyone unless filters are customizable, so would have be developer educated guess of how important some quest is)
• "time expensive" filter - filter out quests that are both many in number (1) and take more effort/time (4). It might take into account that grouped quests (quest which usually come in bunch together, like for example highway=steps related) should be counted as one time expensive quest (as opposed to several separate relatively quick quests). Although steps is probably not great example as it usually is not that many of them all around (1)

Both depend on "many in number (1)" because even if something feels useless, if it happens rarely enough people would probably solve it without problem (ie. I don't feel there is much use for "bridge type" quest so it's not really important to me (2), but since it happens very rarely (1) I happily solve it - even when it requires some little extra effort like walking few dozens meters away from my path to get better view).

[westnordost]

Mostly many in number that are not very important: building type, building levels, roof shape. Maybe also surface etc. need to look at the map to see how empty it really becomes if those are also hidden

[mnalis]

@westnordost that sounds reasonable. Do note that surface is (IMHO, as a cyclist) is definitely one of the more important quests that actually gets used in practice (there is an extreme difference weather some way is asphalt, compacted or grass - for both motorized and non-motorized traffic) so (unless it makes situation much worse, of course) I would tend to keep it.

[westnordost]

Maybe not even that, actually. Maybe just tell the user that he can change it in the settings. I reordered all the quests in the quest-order branch an dI am quite happy with the result. Looking at the map now looks a lot more "diverse", many different icons can be seen. When zooming in further, everything is still full with little dots, but at least the visible ones are not all the same quest type.

[peternewman]

• I don't see the need for custom filters. Any filter would work like that it only disables quests.

I don't know quite where it fits in the proposed ideas, but consider the following challenge. Postbox collection times are more important and useful than post box royal cyphers I think the majority of people would agree, so while on foot I want to do collection then cypher. However in a car unless we stop in traffic right next to the postbox, I'm unlikely to be able to read the collection time reliably, but going vaguely slow I can probably see the cypher with a good degree of confidence. So on foot I'd like to prioritise collection time as normal, in a vehicle I'd like to see cypher first. I guess we could just hide collection time, but it would be nice to just deprioritise it in case I get lucky with the traffic.

• I wonder how theoretical the use case of solving things in a train or in a bus really are. I remember trying to solve some quests on the train and I mostly failed. It just moves too fast for the download of the appropriate area to complete.

I've done trains in two ways, firstly as others mentioned scrolling to the next station and downloading stuff around there (e.g. footbridges/benches etc. Secondly there have been a few bits where trains have really crawled along for various reasons and I managed to get some crossings etc.

There's also the case of e.g. waiting for/interchanging on bus or train, where you're relatively speaking stuck in one place, but for a while.

I imagine it is very similar for a car. For a bus, at least it stops very regularly. I wanted to get on a bus today and try out some mapping but unfortunately I am ill right now so I have to postpone that. Anyone has some actual experience here?

Firstly sorry to hear about the illness.

I've done buses quite a lot, and cars a little bit. As someone who's normally downloading on WiFi, for bus commutes, I'd either pick up free WiFi or have downloaded the route in advance, then each time I was on the bus I'd be able to do a bit more, e.g. spotting benches at bus stops as you go back and forth, or being able to pick up more house detail when the bus stops in traffic.

For the car stuff, I downloaded the area around my destination prior to arrival and when we got close just watched on the map when we got near and started solving quests. I did notice in the car, perhaps as it was going faster, GPS did seem to lag occasionally, but I managed to answer lots of quests successfully (as you're travelling over a large area very quickly).

• How many viable filters would then still be there? "Need to go inside", "Not quick & easy to solve" (aka spammy quests), maybe (though this is kind of very specific) "Only solvable if the ground is not covered in snow"

• The lit one that's been discussed elsewhere, aka needs to be dark.
• Non-accessible prioritised ones (e.g. wheelchair/tactile), from https://github.com/streetcomplete/StreetComplete/discussions/2457#discussioncomment-272325
• Non-high up from https://github.com/streetcomplete/StreetComplete/discussions/2457#discussioncomment-323706

Although the last two feel like they're back to changing priority, rather than explicitly hiding some quests.

So if the quests that are easy to answer also when moving faster and can be answered on the spot rather than needing to look around and explore (bike, bus, passenger), it mostly solves the need to have such mode-of-transportation-based filters. As mentioned earlier, it is really hard to define what is still solvable in a bus and what is not, this solution works around that.

I'd always imagined the order changing, so you don't have to define that, it just shows you the easy glance ones first (e.g. steps incline), then the more involved ones next (e.g. handrail) and finishes on the most complex (e.g. ramp), so if you're stuck you'd naturally work your way through the list, but if you're moving past, you could just glimpse the easiest one.

I reordered all the quests in the quest-order branch an dI am quite happy with the result.

LGTM. I've taken the liberty of commenting on https://github.com/streetcomplete/StreetComplete/commit/c1336a4ca5dbd6368d75c2c3332caeac172416ad with a few suggestions I think could make some minor improvements to the ordering from my experience.

[westnordost]

Solved (differently) in #3210 / #3034