-
-
Notifications
You must be signed in to change notification settings - Fork 365
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
Faster to answer bike lane quest (particularly "no bike lane") #2193
Comments
I actually had the same thought regarding the sidewalks quest today. There, the following would reduce the number of taps: In the main form, have three options:
Unfortunately, this doesn't work for the bike lane quest, because you also need to specify the type of the bike lane. But maybe the idea can be adapted? |
I do not at all see the necessity to add any shortcurts to specifying the left side and the right side for cycleways and sidewalks. It may even have a negative effect to do that. The questions specifically ask about the left side and about the right side separately and it is tagged also this way (that the StreetComplete user checked for the left side and the right side individually). So, data users trust on that things tagged with Keep in mind, that unlike for buildings (for housenumber quest etc ...) which you should be able to pass quite quickly while walking, the question for sidewalks and cycleways should be checked and answered for the whole street. So, the fact that it takes longer to answer this quest has much less a potential to impede the surveyor in his walking because the time to ascertain this data is usually much longer anyway than the time to input the data. The quest is just asked 1 time (up to a few times) per street, whilst for example the housenumber quest is asked for pretty much every building in the street, this is a big difference. For some roads, the user actually has to cross the road to ascertain the cycleway situation, for example if there is a parking lane that blocks the view onto a possible cycle track. If the app provided a shortcut to tag "it is the same left and right" or "there is nothing here", it would facilitate a sloppy survey. First of all, @smichel17 , the # 1 UX principle of StreetComplete is that the UI is simple and self-explanatory, not that it is efficient. What you propose is not self-explanatory and if it is prefilled with ❌, there is even the danger that people will just tap "OK" without checking as pointed out in the last paragraph (or accidentally). |
Also, as a bonus, after you once specified the cycleway situation, and be it "no" everywhere, when the app asks again (in 4-8 years), you'll be able to simply select "yes, it's still the same". That's one tap then. |
It is less true in cases where there is no cycling infrastructure anywhere and roads are quite heavily segmented (typical in my mapping, making this quest a bit irritating). I even implemented in my fork some hacky solution to make answering |
@westnordost I agree with the UI criticisms; they are why I did not propose that particular solution when I opened the issue. I was/am mostly interested in a "quick fix" to enter "no bike lanes on either side" in areas where few roads have bike lanes. But given the drawbacks, and since I have no brilliant UI ideas to avoid them, I will close this issue for now — it is probably not worth spending more time to fix it until StreetComplete is basically complete and we are just polishing minor details. edit: posted simultaneously with @matkoniecz so I didn't see your comment; if you (or someone else) wants me to re-open this, let me know |
Would it be helpful to have a shortcut for the last entered data, just like in the building stories/level quest? See #1237 |
Mentioned in the original post :) |
Use case
Particularly in the rural US, roads outside of town are unlikely to have a bike lane. Yet, this still requires 5 taps (left, none, right, none, confirm), each of which introduces a context change (popup opening/closing) — a mildly annoying (enough to post this, anyway) amount of work to tag that a feature does not exist, which would be the default assumption anyway. …though admittedly, this is not the highest impact improvement because the quest is asked relatively few times (compared to building heights, for example).
Proposed Solution
Options I can think of, and their problems:
The text was updated successfully, but these errors were encountered: