Quest Selection Screen: Filter options

[mcliquid]

Problem

The “Quest selection and order” screen currently displays all available quests in a single, flat, scrollable list. With almost 200 quests, the list has become very long and increasingly difficult to navigate. It requires extensive scrolling, makes it hard to locate specific quests, and slightly affects perceived performance due to the sheer number of items rendered.

As StreetComplete continues to grow, this flat structure does not scale well from a UX perspective.

Use Case

Users who want to:

• Enable or disable specific quest types
• Reorder quests
• Explore which quests are available
• Quickly find a specific quest

are confronted with a long, visually dense list. Grouping related quests (e.g. roads, buildings, accessibility, public transport, EV, POI, etc.) would significantly improve discoverability and usability.

Proposed Solution

Introduce collapsible thematic groups in the quest selection screen:

• Quests are visually grouped into logical categories (e.g. Roads, Buildings, Accessibility, Transport, etc.).
• Each group has a header (optionally with an icon) and can be expanded/collapsed.
• By default, groups are expanded.
• Reordering continues to work within the existing flat structure
• This would be a UI-level enhancement in the Compose-based QuestSelectionList, without changing the core quest ordering or serialization logic.

[mnalis]

related: #2308 (which I think was wrongly closed, while as somewhat related, it was not the same as "quest presets" which eventually got implemented) and #3209

As StreetComplete continues to grow, this flat structure does not scale well from a UX perspective.

I agree. I'm however not sure how the proposed solution proposes to fix that.

Could you make some mockups or explain in more detail how it is supposed to be used in practice? (e.g. use case: "I want to find bicycle quests and order most (but not all) of them all to the top of the list" - how would I do that / what would be the steps and UI shown)

Reordering continues to work within the existing flat structure

This in particular I do not get how it it supposed to work. (for just selecting/deselecting it is easy, but not for reordering)

So, we'd have a list that is grouped, but as soon as you start dragging a quest, it would automatically show itself as a flat list? And then when you raise the finger (finish the move) it would automatically re-display as grouped list? And/or you'd have some toggle which switches between flat/grouped lists so you can check the ordering? How it would keep your current location and/or selected quest?

[mcliquid]

Thanks for your input!

I agree. I'm however not sure how the proposed solution proposes to fix that.

Could you make some mockups or explain in more detail how it is supposed to be used in practice? (e.g. use case: "I want to find bicycle quests and order most (but not all) of them all to the top of the list" - how would I do that / what would be the steps and UI shown)

I thought something like this:

This in particular I do not get how it it supposed to work. (for just selecting/deselecting it is easy, but not for reordering)

So, we'd have a list that is grouped, but as soon as you start dragging a quest, it would automatically show itself as a flat list? And then when you raise the finger (finish the move) it would automatically re-display as grouped list?

Yes, that was my initial idea. When dragging starts, all groups automatically expand. While dragging, the full flat list is visible. After drag ends, the UI re-applies grouping and collapse state. If a quest is dragged across group boundaries, it simply moves in the global flat list. The visual grouping would then update automatically according to its new position.

But I think I can already see where the problem lies. If you move the quest “outside” the group, what happens to the group?
Another option would be to use “Quick Filter” directly below the top bar. I select a filter at the top (icon) and the list is reduced to only the filtered entries. These filters could also be tabs: All, Bicycle, Road, Transportation, ...

In Android Material there are Filter Chips. This would result in tag-based filter chips without rigid groupings.

But the contrasts in the UI remain. Maybe someone else has an idea, but then you'll probably have to do without the ability to sort globally within the filter chips.

[mnalis]

But I think I can already see where the problem lies. If you move the quest “outside” the group, what happens to the group?

Well, obviously moving the quest in flat space should not affect the group it is in -- after all, bicycle quest remains bicycle-related, even if it is moved between two car-quests. I think that can be fixed by always expanding to flat space immediately when you start dragging (and not only when "exiting" the current group).

But I don't know how would I then verify is my ordering is to my liking when I've done several dozen moves -- there would need to be some separate button to switch between flat (fully ordered) and group (not really ordered / only partially ordered) view.

In Android Material there are Filter Chips. This would result in tag-based filter chips without rigid groupings.
[...]
but then you'll probably have to do without the ability to sort globally within the filter chips.

IMHO the whole point of the moving quest around is for making global ordering of quests (so to define when they show up on the map, e.g. when multiple quests are queued for the same location/OSM element). If I could only sort Quests within the same "group" / "filter chip" then it becomes mostly useless, as I cannot make certain bicycle quests more important then certain car quests (or whatever).

[mcliquid]

You are absolutely right: the main purpose of this screen is to set a global quest priority. Groupings or filter chips could only affect the display of the list, but not the stored order.
When starting a drag-and-drop operation, the UI would immediately switch to flat mode so that all quests are visible and the actual global order remains recognizable. No quest logically leaves its group, as groups are merely visual clusters and not structural containers. After dropping, the view can either remain in flat mode or return to grouping – but the underlying order always remains global and flat.
Filter chips also should not create independent sorting contexts. They would only temporarily filter the visible list. Changes made via drag-and-drop continue to affect the global order and remain completely intact after the filter is removed. But of course, if this cannot be guaranteed cleanly, grouping should remain purely visual.

[westnordost]

It's always an option to drop the reordering of quest types if it is in the way. Remember, that feature was introduced in ancient times, when StreetComplete used to download quests via overpass per quest and due to it taking so long each, would only download a few at a time. For quests to show up at all in a timely manner, they had to be somewhat at the top of the priority list.

[westnordost]

Apart from the specific suggestion of this feature request, I am absolutely open to make the search for quests in that screen more powerful (i.e. accept PRs for that), e.g.

• make the search not only search for words in the quest title, but also for e.g. the class name, the wiki link

• filter by (some?) achievement types, as they roughly align with "topics" the quests are about

• filter by currently selected/not selected

Any such additional filter options would probably display below the search bar, when opened.

[mcliquid]

• filter by (some?) achievement types, as they roughly align with "topics" the quests are about

When I got up this morning, it suddenly occurred to me again that this was exactly my idea. I do realize that my original idea doesn’t work. But with filter chips, I could well see that working as a compromise. First, I’d deactivate everything, then filter by the ‘BICYCLIST’ achievement and activate only that group. And if I wanted to, I could also activate the ‘RARE’ group. In my view, that would be a great help.
It would be great if, on the one hand, you could enable and disable entire groups, and on the other hand, filter by a group, then view all the quests in that group and enable or disable them individually.

[westnordost]

Right, so the way this should be implemented is similar to the way logs filters are implemented. There should be a filter icon at the top, which opens a dialog (or, if there are too many options to easily fit in a dialog, an own screen) that lets you select the filters.

Alternatively, if the UI can be made really small, the filter options could be displayed in-line, just like the search is.

Another useful filter option would be to only display those that are currently disabled or those that are enabled.