Building type quest - allow to access full list by scrolling, not by clicking "show more"

[matkoniecz]

Use case On mobile it is more natural to scroll list than to click on button.

Proposed Solution

Current: list with top answers and blue "show more" button. Pressing button replaces top values with a full list.

Proposed: list with top values and full list below - accessible by scrolling, not by pressing button.

Seems clearly better to me (multiple people in testing tried to scroll and completely failed to notice big blue button). But I want to check before implementing anything.

[westnordost]

Hm, but you already have to scroll to even access the top 6 or so items

[matkoniecz]

You also need to scroll to get to the button.

So current way is to:

• scroll
• stop, notice button, tap it
• look around for matching entry

I propose it to replace by

• scroll until matching entry

[smichel17]

I am conflicted.

On one hand, I agree that having to scroll and tap a button is annoying, and that scrolling is the natural motion.

On the other, the categories interface is equally cumbersome, and having 6 recent entries allows me to avoid using it most of the time (and #3373 will reduce that further). I'm not sure I want to reduce the number of recent entries or make the category view even more clogged and awkward; I think you'd need to do one of those, unless you're proposing to have two "sticky" scroll positions (expanded recents & category view with no recents) which… that might work. I'm open to at least trying it.

[matkoniecz]

I'm not sure I want to reduce the number of recent entries

I am not proposing this

make the category view even more clogged and awkward

not his

I think you'd need to do one of those

Why? I want to have one menu, with top answers on top and categories below them in one continuous list

[smichel17]

• Open a category
• Scroll down
• Scroll back up with a "fling" motion so there is momentum

Current behavior: stops at the top of the category list, where you can see the open category (to collapse it again). New behavior: scrolls all the way to the top of the top items. Now you have to scroll back down to get to the categories.

I am open to the possibility that it won't be that bad, or that we can put two "scroll momentum stopping" points (like what we currently have, that stops the scrolling at the top of the category list, instead of moving the form down lower).

[pkoby]

Why? I want to have one menu, with top answers on top and categories below them in one continuous list

A thought I had for this case: instead of the top 6 (or x number) recent selections being full rows with title and description, could they be smaller buttons (say, 3 to 4 in a row) of the icon with the title underneath? I know that might be tough because some of the titles are pretty long, and I would guess that just the icons is not enough information for casual users.

[mnalis]

@smichel17 Perhaps convert Recents to just another category, which is placed at the top of the list, and expanded by default?

Then clicking on the building type quest could open the list of categories directly, and get rid of annoying show more button, while converting whole scroll / find show more button / tap show more button / scroll to just scroll and thus fixing this issue, while still having recents as easily accessible as they where before.

[smichel17]

I like that option, except for one issue: all of the other categories be selected as an answer. Recents, of course, cannot. It may be possible to work around, or may not.

[westnordost]

"For cars" cannot be selected as an answer, some others not as well.

[alex-m-ffm]

Maybe the top values could also reflect the most common types already in the database in the current surroundings, rather than just the recent selections of the user? Of course this might require additional database queries... In the first days I was too lazy to explore the "Show more" button and might have misclassified some non-residential buildings as multi-family homes, since the default top 6 are all residential types. Perhaps other newcomers fall into the same trap.

[smichel17]

I re-used the "other" image + string for a proof of concept of @mnalis' idea. It turned out to be much easier than I expected.

Now that I implemented it, I think my fear in https://github.com/streetcomplete/StreetComplete/issues/3387#issuecomment-944894497 is probably overblown. After all, in the first screenshot above, you can still see the categories. And it's still way less work than clicking the "show more" button was before. On the other hand, with the solution of making "recent items" a category, then we always have a useless item taking up the top slot when the form is first opened, like in the second screenshot.

So I think I will probably go with the original idea, and just stick the recent items on top of the list. Needs a few tweaks so it looks right and to clearly mark it as "Recent/Suggested", but otherwise seems good to me.

[matkoniecz]

It appears to be on https://github.com/smichel17/StreetComplete/commit/1a25091c6c8339eb2d67ce5c0d98eb487762a04f

[smichel17]

Yes, that's it

[smichel17]

Right now, this is pretty low priority for me personally, so I don't know [if/when] I will finish it. I'll unassign myself to reflect that; if someone else would like to implement this, feel free.

[if/when]: I seem chronically incapable of not getting involved in whichever tools I use, organizations I'm part of, etc— and then my current involvements fill up my time so I can't continue with my previous ones. So if you see activity on my OSM profile, you can also expect to see me around here shortly :)