Skip to content
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

Remove manual upload of changes #753

Closed
westnordost opened this issue Jan 7, 2018 · 10 comments
Closed

Remove manual upload of changes #753

westnordost opened this issue Jan 7, 2018 · 10 comments

Comments

@westnordost
Copy link
Member

I have been thinking for a while whether I should remove the manual upload of changes altogether and do the upload all automatically behind the curtains.
Because, for the normal user, it is irrelevant if his change has been uploaded already or not yet because he is offline right now.

Pros:

  • simpler UI. Less buttons and displays (i.e. no confusing ★ 123 (+45))
  • changes could automatically be uploaded with a short delay (without confusing the user as to why the changes are not uploaded), so that quick undos do not always result in a revert but can be done locally

Cons:

  • possibly confusing for power users because of the loss of control
@althio
Copy link
Contributor

althio commented Jan 8, 2018

I would not like it, or I think it would require some mechanisms regarding the delay.

A few notes:

  • UI will be better and much less confusing with something like Upload answered quests #696 so no real need to remove that info altogether.
  • Removing info will be confusing (not for loss of control, for loss of info). People that go with StreetComplete without connection need a visual hint that items are queued and waiting for upload.
  • Privacy concerns. StreetComplete could become a forced tracker, publishing time-space accurate location for private people. I don't know where this could lead StreetComplete and OSM regarding privacy regulations like General Data Protection Regulation [GPDR on wikipedia] but I don't think it is a step in the right direction.
    • OR [privacy by design] StreetComplete should manage delays (not-so-short, long enough, maybe some randomness) and should maybe let user decide/configure a typical delay (10 min, 2h, 1d, 1w...).

@smichel17
Copy link
Member

smichel17 commented Jan 8, 2018

I set it to manual upload so that I have a chance to undo if I messed something up. I wouldn't particularly care if it did auto-upload, as long as I could still undo.

Once you understand that the (+x) is the number not yet uploaded, the current UI is perfectly clear. Thus, the problem is conveying that understanding. I think you could do that by displaying the non-uploaded count closer to the upload button (Is it possible to put the count on the button? I know menu item icons are typically static resources...).

@westnordost
Copy link
Member Author

@smichel17 You can undo changes even after it uploaded though.

@althio Regarding privacy concerns, this is actually one of the reasons why I am thinking to implement #753 actually. If I remove the manual upload, I can remove the UI for the queue, and if that UI is removed, users will not get confused if StreetComplete does not seem to upload the changes immediately but waits a predefined amount of time until it does so.

@rugk
Copy link
Contributor

rugk commented Jan 8, 2018

If autoupload is enabled (as it is by default if I understood the FAQ correctly) I'd have nothing against removing the button for uploading them manually.
However, I'd argue for keeping the indicator for things still upload. Not only because there is a PR open making it a little nicer to look at, but also because it can be very useful information.

It is useful to know pending uploads for debugging various issues. E.g. when toy have network connectivity problems. Or when you have not created an osm account yet.
Also it is another nice visual feedback for the user, when they see that their changes are getting included.
Especially when they might want to compare it with the osm website, they might see it still needs to be uploaded. (Although I know there is an additional delay.)

@althio
Copy link
Contributor

althio commented Jan 8, 2018

@althio Regarding privacy concerns, this is actually one of the reasons why I am thinking to implement #753 actually. If I remove the manual upload, I can remove the UI for the queue, and if that UI is removed, users will not get confused if StreetComplete does not seem to upload the changes immediately but waits a predefined amount of time until it does so.

@westnordost It depends the predefined amount of time we are talking about.
If it is a short amount of time: no confusion about upload; but more privacy concerns.
If it is a long amount of time: less privacy concerns; but more likely confusing (especially without feedback indicator)

@westnordost
Copy link
Member Author

Ok so for now, this is off the table.

@althio
Copy link
Contributor

althio commented Jan 22, 2018 via email

@rugk
Copy link
Contributor

rugk commented Jan 22, 2018

@althio This issue was about removing that feature. Actually, the feature is already implemented. (it's called auto-upload)

@althio
Copy link
Contributor

althio commented Jan 22, 2018

@rugk I disagree.
What the title of this issue says: remove manual upload.
What the issue is really about: remove manual upload and modify auto-upload (add a delay).
What is implemented now: manual upload and auto-upload (no delay).

@blipp
Copy link

blipp commented Jan 24, 2018

The following could be interesting when this topic is discussed again at some point: when doing manual or delay automatic upload, it could be interesting to randomize the order of the answers. Otherwise the direction of movement would probably be preserved and this might be considered a privacy issue. This should be discussed in the OpenStreetMap setting, though, to see if the order of the answers might be an actually import part of the data for some reason.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants