-
-
Notifications
You must be signed in to change notification settings - Fork 358
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Building type quest - allow to access full list by scrolling, not by clicking "show more" #3387
Comments
Hm, but you already have to scroll to even access the top 6 or so items |
You also need to scroll to get to the button. So current way is to:
I propose it to replace by
|
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. |
I am not proposing this
not his
Why? I want to have one menu, with top answers on top and categories below them in one continuous list |
Current behavior: stops at the top of the category list, where you can see the open category (to collapse it again). 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). |
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. |
@smichel17 Perhaps convert Then clicking on the |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
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... |
Proof of concept for streetcomplete#3387
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 #3387 (comment) 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. |
It appears to be on smichel17@1a25091 |
Yes, that's it |
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 :) |
Proof of concept for streetcomplete#3387
Proof of concept for streetcomplete#3387
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.
The text was updated successfully, but these errors were encountered: