Parking overlay blocked by note created by StreetComplete #5703
Comments
|
in general note created for given object blocks further quests |
|
Okay, but it's not really clear to me why I shouldn't be able to tag the parking spots just because there's no option in StreetComplete for polymer surface of the roads and thus I couldn't select a surface from the list. |
|
That is by design unfortunately... See #4529 and SC FAQ: Editing in Overlay mode opens Notes instead The reasoning seems to be that when the note is opened there, it is unknown how it affects every other feature there. E.g. your note was "Road surface is not in the list" which should not affect the parking overlay, but it could equally well have been "The whole area has been become construction site and there is no road or anything else here now". SC lacks AI to determine which one is the case, so plays it safe by not allowing further edits on the element until that note is resolved. I too agree it would be nice if there was a way to override that behaviour (i.e. "I understand the note, but still want to proceed solving this quest/overlay" button). My workaround is to use SCEE in offline mode, force-resolve the note (SCEE-specific feature), then do overlay/quest updates that I want, and then undo that note-resolving action. Not ideal, but works. In StreetComplete, only workaround is much more cumbersome - by long-pressing on the screen to create NEW note providing extra text/pictures to the note to describe what else you wanted to map (i.e. parkings) and then manually convert that to OSM data at home in iD or JOSM (or whatever full-fledged editor of choice). If you go that way, please do create new note as described, instead of adding text/pictures to original note, in order not to poison original note with unrelated data. |
|
I think if I create a note it should just hide the quest which is stored in the note as the culprit. It's a bit overprotective to disable all actions on this road section and doesn't help in the case you've described anyway, cause there will be other objects in the vicinity anyway. In it's current form it is blocking further action unnecessary without any real benefit (from what I can tell). Apart from that it breaks the user expectation (Principle of Least Astonishment) if my own note pops up, if I click in an overlay on a road, as my own notes are otherwise always hidden. I seriously thought that's not how it was intended to work. Offtopic: Well I've used SCEE and I think you mean the "hide" button at the note. This doesn't work either. |
|
Apart from that it breaks the user expectation (Principle of Least Astonishment) if my own note pops up, if I click in an overlay on a road, as my own notes are otherwise always hidden.
I seriously thought that's not how it was intended to work.
so did I, as you can see from linked issue...
Offtopic: Well I've used SCEE and I think you mean the "hide" button at the note. This doesn't work either.
No, I've really meant resolving the note, i.e. putting a checkbox on
"Close note (only do this if you actually solve the note!" in a note
window.
(you also need to type some text in text field for so you can
actually resolve/close the note, e.g. "oops, please reopen this note"
the text itself doesn't matter, unless you forget to undo the
close-note later)
Then it works.
|
|
A note in StreetComplete blocks ALL quests, regardless for which quest it was created. This is (also) by design, as a note may hint at that not only a single quest cannot be answered (e.g. "Does this count as a bust stop bench?? ") but that anything for that element may be wrong (e.g. "bus stop does not seem to exist? "). We don't know. Remember that not all open notes are displayed to the users because only notes where it is reasonably likely that he can actually contribute something are shown by default. So, the existence of another note on the same element may not be known to the user. Following the same logic, then of course the same must be applied to overlays. The difference here is that for overlays, we can't just hide the element that is blocked by a note. A piece of road that seems to be missing from the overlay will very much feel like a bug or missing data, prompting either the creation of another note or a bug report. Worse, for POI overlays, such as the shop overlay, it would be a very bad idea to hide elements blocked by a note, as this may actually lead to the user adding the POI as a duplicate. So, hiding the element as it is done for quest is not an option for overlays. I agree that it is certainly unexpected that way, but the alternatives seem to be worse. |
|
When tapping on an element blocked by a note, the note will be shown, even if it was not visible before.
I think that displaying the note which _might_ be affecting the
overlay edit of that element is always a good idea, as that provides
maximum feedback to the user.
So that part of current implementation sounds just fine to me
(even if it might be somewhat unexpected -- just like some highway
hazard sign would be unexpected to driver, but welcome nonetheless).
I agree that it is certainly unexpected that way, but the alternatives seem to be worse.
But after the note is shown to the user, it would be nice if there
was other button/option in addition to current
"no (I cannot contribute anything to this note)".
One with the meaning:
"Thanks for the warning, but I'd still like to edit this element please"
(of course, probably in somewhat shorter form, suitible for a button).
Or do you feel that it would be too confusing or too much choice to be
giving the average SC user? Or would it be too problematic to implement?
As noted, I personally can live with SCEE workaround, but I still
think that streamlined solution in SC might be appreciated by others,
as I seem to recall seeing this issue mentioned several times before
(and there are probably more confused users than those that manage to
reach GitHub issue tracker)
|
Well, also notes hidden by the user do block quests. So from a technical perspective, it still means a special treatment for overlays. I do remember that initially notes did not block overlays and that this resulted in some crash. I do not remember the details, though, but it is a reminder that your proposed solution might be more complex than it seems. |
|
Anyway, Ruben, what happens when you click on "No" (I can't contribute anything to this note)? The note is shown again currently when tapping on the same element, right? |
|
Yeah, if I click on "no" it will just reappear. I mean I understand that it might be logically or technically difficult to solve. Just the way it is presented currently is weird. Maybe a simple "this section of road currently has a note open and thus cannot be edited, until this note has been resolved" popup or something like this would go much further to explain IMHO why I can't edit it as a user. As notes (especially for a completely different detail) and parking spot mapping aren't really connected and just confused me. |
I've created a note on a road regarding the surface, which was uploaded.
Then I tried to select the road in the parking overlay.
Instead of letting me enter the parking spots on both sides, the note got opened - even though it isn't visible on the map view itself.
I can only close it with "no" but not discard it in any way which would let me access the parking details.
How to Reproduce
InShot_20240624_120103932.mp4
Expected Behavior
The parking details should appear
Versions affected
58.0
The text was updated successfully, but these errors were encountered: