One-click quest completion (for "spammy" quests) #1735
Comments
=>
|
|
Weird, link works for me on both desktop and mobile. Maybe an extension I'm using is stripping referrers or something. Anyway, here's my own rougher-but-more-specific recreation of it:
|
|
Hui, this is an interesting idea. Regarding the simple idea, this is something I do not like because it changes the semantics on how these "quest forms" work in an unexpected way. For any quest, it is always input, then confirm. If the input doubles as a confirm button, this will confuse people and would be inconsistent. The radial menu is certainly very cool but comes with a few other gotchas:
So in total, I am not sure if this would be such an improvement. |
Alright, let's forget it :)
I'm glad to see that this is the exact same list of got'chas/downsides that I came up with (except one, which is a misunderstanding), so here's my solutions:
The idea is that selection happens on release. So the actions are:
There are libraries for this. It's also a bit faster because the options always appear in the same places, so once you've done a few, it becomes more like a gesture; you can start the motion as the UI is appearing. This is also why the selected option needs to disappear more slowly than the others, to give confirmation that you picked the right one. My original idea was actually to have the menu appear on touch down rather than long press; the center option would be "Open quest panel" (the regular UI), so a simple tap would function as normal; and there would be another option, down, to cancel. However, this would be too easy to complete by accident when panning the map. The current idea could include a down option to open the quest UI.
Gate the feature behind an acheivement/badge (#1715). Something like "Complete X quests" (X is 25? 50?). The achievement would both unlock the feature and explain it. By this point the user should have solved enough quests that they are past the point of reading the question text every time, and the answers that appear should be enough that they know what type of quest they're solving. This also addresses my concern that new mappers might abuse this feature to complete quests without being on site; when I first started mapping I was a lot more sure of my memory about these things (road surfaces in particular) than I am now. Or maybe I just hold myself to a higher standard of being sure. In any case, I think it's a reasonable thing to gate the feature behind having some experience mapping. Maybe also some experience with the specific quest (10 completions?).
This is the most complicated part. You can't really zoom on press, at all, because you need the center point, where the user's finger is, to remain the same, so that lifting their finger back up without moving it closes the menu without making a selection. There's two options for handling this. I prefer the second (but it's a bit more work):
(And now you see why I omitted this from the original post 🙂) |
Ah I see. Well there is another gotcha then. Tangram-es does only offer to set a "TouchInput.LongPressResponder" on its interface (which is tap down long, and release), not a generic touch down listener. Also, the kind of long press you imagine will most probably interfere with the normal map controls |
|
Alternative implementation, if press-and-drag proves hard to implement:
This is 2 taps and breaks context less, so it's still an improvement — and it's something to play around with and get a feel for whether press-and-drag would be worth the effort. |
|
Something like this could also be useful for simple yes/no questions that don't require much description, like "Is this [street|sidewalk] lit?" (Not for ones with picture descriptions, like the tactile pavings quests). |
|
You could try it out, but I am really not sure if this is such an improvement over the normal forms. The yes-no-forms are already one tap once opened, so two taps in total. |
Can you point me to where the map actually gets populated with quests? What's the best way to get a reference to the view containing the quest marker, for positioning the menu? I skimmed but didn't see a generic quest marker xml layout (to which I could add the menu) or something like that. |
|
see
|
|
Looked into the code bases a bit more. Getting something complete (press-swipe, handles edge cases) and maintainable seems like it will be quite a bit of work and maybe require tangram support. The main problem is that during the swipe portion we don't want the map to move. So we'd need tangram to offer a long-press responder that fired before release and a way to lock the map so it stops responding to touches until the menu is closed. That said, getting something hacked together that will work as proof of concept seems totally do-able, probably a weekend project. |
|
😠 build 😠 systems 😠 with 😡 incomprehensible 😡 error 😡 messages 🤬 |
|
Aaand we have render! Not quite all the way on screen, but, uh, minor details 😆
|
|
I am not going to have time to look into this until July, at least. Closing since it's unlikely anyone else will work on it, and I will re-open when I have time again, if I'm still interested. |
Use case
One of the new quest guidelines is "No spam" — avoiding quests that always have the same answer. However, there are still a few quests that brush up against this guideline — for example, the "Road Surface" and "Building Type" quests almost always have the same 1-3 answers in some areas.
The spamminess of these quests is offset because they are obviously useful. However, silly as it may be, I cannot deny that it does actually put me off from answering these quests sometimes… even considering that I like contributing to OSM — improving public goods gives me "the warm fuzzies".
The "recent answers" section of the two mentioned quests has gone a long way towards making these quests less of a pain. Before, I basically never answered them; now I do… sometimes, and I still view them as a chore to get out of the way so I can get to more interesting quests. So, I'm interested in exploring ways that could make these type of quests even easier.
Proposed Solutions
Both of these have the same two goals:
The second option does a better job at both goals, but is more radical and complicated to implement.
The simple option — One click dialog completion
In #1692 we discussed creating a visually distinct section for recently selected answers. That distinction means it could have different semantics — complete the quest instantly on tap, vs select+confirm.
This would reduce the number of taps to complete spammy quests from 3 to 2. I think this would make a significant impact, considering that adding recent answers also removed 1-2 taps (one to expand the section and sometimes one to scroll down).
It's also a tiny amount less context switching, since you only have to look back and forth between 2 elements (map and options) rather than 3 (map, options, confirm button).
The
radicalradial option — "Instant complete" radial menuTapping on a quest that has one of these functions as normal. However, on long-press:
This reduces the number of clicks to just one — can't get faster than that! It's also a much smaller context switch, since the map doesn't move and the menu covers less map than a dialog.
I think this is the best solution. I'd never leave a nearby road surface or house type quest unsolved. However, it's also more work to implement, especially to get the UX right, and has a few drawbacks, which I won't list now because this issue is already quite long and I think they're all solve-able.
The text was updated successfully, but these errors were encountered: