Helium314
Automatically open next quest when moving
I recently got a request for adding a mode that automatically opens the "next quest" when you're moving along a path / road. This could be usefule when you're in a car, bus, or even on a bicycle (though I don't wan't to encourage this). Might also work for pedestrians, but probably not that well.
So here is a rough idea how it could work, in case it gets implemented:
- The first step would be determining what this "next quest" is. Getting direction of movement is simple, and movement could be predicted by using a close highway the user is moving parallel to (though there could be performance issues). Now that we know where the user is moving, the next quest could be determined by distance to user and the highway, e.g. closest quest to the highway, within a distance of 20-100 m from user. Here it will not be possible to be perfect, e.g. because view can be obstructed, and good choice also depends on quest type (like roof shape vs housenumber). Also the highway the user is moving on should be considered, and possibly preferred if it has any quests.
- Then this "next quest" is opened and kept open until the user answers, closes, or is too far away (what this actually means can be determined later).
- When the quest form is open, the map should show both the user's position and the quest geometry.
I recently got a request for adding a mode that automatically opens the "next quest" when you're moving along a path / road
Sounds interesting, but I'm not sure how well it would work in practice. Even when I click my own quests (so I know exactly which object that is in real life before quest pops up) while moving on e.g. bus/train, I'm surprisingly often not successful in solving it in time so have to cancel.
Having some AI predict that location better then me, and then me managing to mentally connect the location it has chosen on the map with the object I am seeing in real life, and answer it in time, seems like a not an easy task, especially if solution is to be "one size fits all".
Probably would have to have some auto-learning capacity (per-quest-type maybe, as different quests might take different amount of time to solve), i.e. be able to determine if it is asking quest too close or too far away for current user to solve them in time, and auto-adjust accordingly (like how TCP adjusts its speed depending on available bandwidth by looking how often packets gets dropped -- with additional problem that humans are more easily annoyed than computers if quests get offered too fast / dropped too often, so better stick with conservative methods like slow start ) .
kept open until the user answers, closes, or is too far away
That "too far away" option might be problematic too. Having old quest disappear and/or be replaced by new one "automagically" while the user is looking / trying to interact with the app sounds like bad UX to me. "Until the user answers or closes" part seems fine though, provided "which quest to choose and when" issue above could be solved in satisfactory way...
I have an informed opinion on this as I did try both mapping from a bus and doing everything on my path while walking.
For mapping on a bus or passenger seat, it's feasible, but very limited. I would only do easy quests, like "is there a thrash can at this bus stop" with good visibility, you can have a definite answer in a second and go on to the next thing. I don't think we should need or add any fancy AI or program into it. At best write a guide that says it's possible to do very moderately. Nobody is fast enough or has enough visibility to do much more.
As for going on foot, I don't know how simple that would be to implement, but what would actually be great is to trace your way in advance :
Let's say I'm going down a straight street and I have one quest per building on the side to add building use. I would trace a line going through all the buildings on that street. Then as I answer a question, it will automatically open the next one along the line I drew, going from quest to quest in the order that the line touches them.
Allow to hide or skip one if it turns up too difficult for that workflow. Allow to exit and cancel the last change at any time, of course.
This allows for instance to do only one side of the street at a time, if you wish, or to ignore some things you know are out of view, but are, on the map, closer than things you can actually see. And moreover, it's MUCH easier to keep track of what you are mapping than if the computer decided what is next.
On a final note, I wouldn't advocate having this on the basic SC editor, at least not without being thoroughly tested and approved by people more knowledgeable than I am.
I'd like to note that in my experience there is additional problem when being moved in motor vehicle -- unless one pre-downloads the areas manually (IOW the quests can not be autoselected if SCEE does not even know they exist because that upcoming area has not been downloaded yet).
In my experience, when in moving vehicle like a bus or a car or a train, even with 5G and recent fast flagship smartphone, data is not being auto-loaded in time for that. By the time it loads, I've already moved past the quest... See https://github.com/streetcomplete/StreetComplete/issues/3052 and https://github.com/streetcomplete/StreetComplete/discussions/4999
So for fast moving vehicles; only solution usually is manually pre-loading areas in advance. 🤷♂️
Of course, for walking that auto-loading is likely to be much less of a problem, but then again, for walking, existing Settings / UI / Show next quest immediately and Show nearby quests might be good enough? Have you @ghazarian-w perhaps tried those?
True, in my case, using the bus was something that I did in areas where I'm also regularly on foot, so preloading didn't come to mind. But it did happen to me too.
As for @mnalis asking about the features already in place, yes, I do use them and they do save some time. "Show nearby quests" is great if you missclick, but no use to chain quests. "Show next quest immediately" does chain quests, but only if they are on the same element. Still gotta click on each element along your trip.
What I talked about earlier is specifically thought out to close that hole in functionality while preserving 100% of user choice. You only automate the path that the user paints, it closes the gap between elements of the map faster.
Is it worth it to code, IDK, it would really be a power user oriented feature. Someone that is actually bored of clicking so much to do what they were going to anyways.