Add limited connection mode

[neslihanturan]

I think most of our users might be travelling abroad and they possibly have limited internet connection. They should be able to select "limited connection mode" to prevent contribution and nearby lists from load (we can display an information string instead). So user can only upload image by using minimal amount of resources. Do you also think such feature would be nice?

[misaochan]

I think Nearby takes a very small amount of bandwidth currently. But you have a point re: contributions (although AFAIK uploading in and of itself takes a whole lot more bandwidth due to the image being full-size, compared to thumbnails for contributions). But, I'm good with this if there is a need for it, at any rate it couldn't hurt. :)

[tobias47n9e]

I think that our current traffic map also needs to get traffic information in addition to the map tiles. Not sure what impact that has.

I think Commons uploads and downloads fall under Wikipedia Zero in participating countries.

Is there a low bandwidth map we can load from mapbox?

[nicolas-raoul]

Image upload is clearly the biggest data plan eater.
Far second is probably the gallery, and third maps.
The nearby query and categories search take almost nothing.

So I think a "low-bandwidth mode" should:

• Upload picture later, only when WiFi is detected.
• Not show gallery pictures (unless they are cached?)
• Use the nearby list rather than the nearby map

[neslihanturan]

Upload picture later option is a great idea. We can even create a queue of pictures.

Mapbox supports offline maps if user has selected the area. Plus, I think we need to change our traffic map to pedestrian map in any case.

[maskaravivek]

Yes, it would be great to implement the offline support(upload later). I would be able to help with the flow and sync logic having done it for offline payments. :)

[misaochan]

Sounds good to me. :) Do you guys think it is sufficiently important/easy that we should add it to the renewal proposal? Or if it's not easy, do you think it's sufficiently important that we should remove something else to make way for this?

[neslihanturan]

Hard question. I don't think it is easy, however in my point of view it is quite important.

[maskaravivek]

I agree with @neslihanturan. Its important as in my opinion the feature to queue up pictures for upload and not waiting for the upload to complete could highly motivate users to upload more pictures

[misaochan]

@maskaravivek I think our app already queues up pictures for upload, you can upload as many as you want without waiting for the previous uploads to complete. But waiting for WiFi could definitely help in a situation where the user has limited mobile data, then he can queue the uploads for later instead of having to remember to do it later.

[neslihanturan]

Do you think it is easy to implement this feature?

[psh]

An upload queue would be a really nice addition to the app - it would be a great debug tool for us as it gives insight (and manual control of) the sync adapter & its database.

Mockup 1 - normal operation

Mockup 2 - waiting for a wifi connection

Shown in the mockups -

• Toolbar button to manually pause, or force re-start of the upload queue
• App detecting wifi state (we will need to ask users for a new permission for that)
• Ability to monitor progress of uploads
• Ability to see upload status, and kick-off a retry

If we switch the retry button for an overflow menu, that would be a place to have options to Retry and Cancel a given upload. If we add a settings menu, we could also include an Advanced option to show additional low-level details about the upload and the sync adapter (if needed).

Moving the upload status to the new screen would help simplify the contributions activity / fragment. I imagine that there will be a few new settings covering whether we want to upload using mobile data, or only wifi, and if we are interested in advanced details about the uploads.

[psh]

I believe I made a bad assumption about how multiple share works in those mockups - looking through the code I see that although I might share 5 images in a single "batch" and they land in the database with a flag saying multiple=true there isn't a concept of a upload group ID to tie them all together. Would that be something we want to add? If so, I can create an issue for it.

[nicolas-raoul]

Jun 12, 2017 Google Play review:

It would have been better if there was a resume option when the data connection fails or stops as a result of poor network. Once the internet connection is lost, It has to be uploaded again. It is time consuming and also data. Please fix it. Thank you.

[misaochan]

@psh 's mockups for the upload queue look great to me. :)

Jun 12, 2017 Google Play review:

It would have been better if there was a resume option when the data connection fails or stops as a result of poor network. Once the internet connection is lost, It has to be uploaded again. It is time consuming and also data. Please fix it. Thank you.

I've been thinking about this, and it would be very useful indeed if we could allow the upload to be done in chunks, so that it can be paused and resumed (and also users don't lose upload progress if their internet is spotty). I am sure it CAN be done as other apps have done it, but I'm not sure how time-consuming or involved the implementation would be. @maskaravivek @psh or anyone else, any thoughts on this?

I would like to add this to our plans for next year, if it is feasible. :)

[sivaraam]

I would love to have the feature of pausing and resuming the download upload. I like to have it as I live in a place where the internet connection is not so good. There isn't continuously stable internet connection here. As a consequence of which there's a lot of possibility for uploads getting interrupted in between. So it would be nice to have the ability to pause downloads and resume downloads uploads.

[sivaraam]

Also, it would be nice if the app automatically detects a slow internet connection and switches to the limited connection mode without the user having to turn it on. And yes, the user should be allowed to turn it off if he wants to.

[misaochan]

Thanks for the feedback @sivaraam , happy to hear that the feature will be useful for you. :)

I am not so sure about automatically detecting a slow internet connection - what would we define as "slow"? What if the user doesn't actually want to turn on limited connectivity, but stubbornly wants to browse pictures even if his home connection is slow? He may be annoyed at having to keep turning it off.

[sivaraam]

I'm not sure about the feature too but just some random thoughts.

what would we define as "slow"?

Some time period within which you expect the response to have come but it hasn't?

What if the user doesn't actually want to turn on limited connectivity, but stubbornly wants to browse pictures even if his home connection is slow? He may be annoyed at having to keep turning it off.

Yeah, some features sometimes turn out to have bad consequences for a few people. I guess we could play safe by not trying to detect slow networks for the session (until app is killed) if the user turns off when we detect slow network. Also, making it customizable might also help.

I'm not going to advocate this feature a lot. Just writing out some of my thoughts about it.

[neslihanturan]

For slow network discussion:
Maybe we can remind limited connection mode button with a silent snackbar and/or an animation on limited connection more toggle when we detect slow network, instead of forcing user.

We plan to have a limited connection mode toggle on the action bar as mentioned in #2843 . A user may want to use the app in normal mode in general (ie. using the map) but just want to wait for Wifi for uploads. Or they may want to use their connection for upload, but not for the map. For this possibility I think we can have an additional toggle as upload when wifi detected on upload steps. Ie:

If the global "limited connection toggle" is activated, then the default value for this button should be on.
If the global button is deactivated, default value for this button should be off. What do you say?

[misaochan]

If the global "limited connection toggle" is activated, then the default value for this button should be on. If the global button is deactivated, default value for this button should be off. What do you say?

Great idea IMO! I am all for it. :)

[neslihanturan]

Hi team, for upload queue UI, I loved the designs proposed by @psh :

But they are not very similar with our existing constibutions list style:

So here is my question, should I keep the current list design and create something similar for upload queue, or should I redesign our contributions list in a similar way with @psh 's design?

It can be good to note that we are planning to have a new overall design at the end of this year #2843 . In scope of this new design our MediaDetailsActivity will be redesigned in a similar style of our current 3 upload screens which are added by @maskaravivek . So we won't have a semi-transparent layer on MediaDetails anymore and it may be a good decision redesigning all semitransparent black components (see the layer for file names on the list). This means changing our current contributions (and explore) list style together with MediaDetailsActivity.

[misaochan]

I like the proposed designs, too. :) A few considerations:

• After the advent of New main screen UI in v3.0 #2843 , I don't think the currently-uploaded file(s) should be tied with "contributions" anymore. Rather, IMO it should be in 'Home' - you would be able to pause/resume uploads from there, and perhaps see thumbnails of the last few images uploaded. For instance, like these horizontal scrollview cards in Google Play:

• So what I was thinking was having @psh 's design as part of Home, except made a bit more compact. In the top card we could downsize the image hugely and put it on the right of the title. The second card might need a bit of a redesign, unless we want separate cards for failed uploads and for successful uploads.

• Contributions should still exist as a separate fragment to allow users to easily browse ALL their uploaded images, of course. But I don't think pausing/resuming should work from there.

• Yes, redesigning the contributions list style with the existing theme. (in 'Contributions') would be great, too.

[misaochan]

Edit: see #2843 (comment) for more details.

[misaochan]

Note: When we do this we should also increase the timeout limit for network-based procedures (e.g. logging in). We currently seem to time out after about 10 seconds, based on my experience with the app when Commons was experiencing latency spikes.

[sivaraam]

My suggestion for the toggle, and progressbar, and for contribution list.

That looks nice. Just a suggestion. "(Uploading… 53% of image is uploaded)" seems too verbose and the brackets seem unnecessary. I believe "Uploading… 53%" would be concise and clear. Ditto for "Paused…". Additionally, I think it would be useful to show the size corresponding to the part of the image that's left to be uploaded.

[sivaraam]

Allowing users to download manually via "Download image" in the media details view is fine, I was referring to the automatic download of thumbnails that populates the Contributions etc list.

Yeah. As I said before, wouldn't it be a little too aggressive, to prevent the automatic download of thumbnails that populates the Contributions etc list? Wouldn't it significantly affect the usability the app when browsing images?

[misaochan]

Yeah. As I said before, wouldn't it be a little too aggressive, to prevent the automatic download of thumbnails that populates the Contributions etc list?

I don't think so, as it is an option that the user can toggle on and off as they wish. Currently all users must load at least the first page of Contributions before they can even use the app. This way users who want to just, say, use Nearby to photograph a few pins while on limited data, won't have to waste their data on image downloads.

Wouldn't it significantly affect the usability the app when browsing images?

It will, but if we want maximum usability of all features all the time, there is no point to even implementing a limited connection mode, as limiting bandwidth usage is the very definition of the mode. If a user wants to browse images, they can turn limited connection mode off.

[sivaraam]

It will, but if we want maximum usability of all features all the time, there is no point to even implementing a limited connection mode, as limiting bandwidth usage is the very definition of the mode. If a user wants to browse images, they can turn limited connection mode off.

Yeah, that certainly would be a solution. Anyways, I was thinking if it would be nice to have multiple levels in the limited connection modes:

1. Normal mode - App behaves the same as how it does now.
2. Medium mode - Thumbnails images would be automatically downloaded but any upload/download would be queued until the device is connected to a Wi-Fi
3. Aggressive mode - No thumbnails would be automatically downloaded, upload/download would be queued until the device is connected to a Wi-Fi and maybe show only the Nearby list instead of the map.

I'm not sure if its worth it, though.

[misaochan]

Could be a future enhancement. ;) Let's implement the basic feature first and get user feedback?

[sivaraam]

Let's implement the basic feature first and get user feedback?

Sure. :)

[maskaravivek]

Here are the changes that I am making for the remaining pieces of this feature:

1. Limited Connection mode toggler in the toolbar
2. Enabling Limited Connection mode would not upload image even when online
3. As soon as the user disables the Limited Connection mode sync will start to sync all images which the user tried to upload while in offline mode
   4 Upload failures in Limited Connection mode will be handled via the usual flow as in they will be shown in the contribution list with failed-retry option

cc @misaochan

[sivaraam]

Offline mode toggler in the toolbar

So, "limited-connection" mode had turned to "offline" mode now. It's a little weird because I see our app's primary purpose as uploading images and then to browse them. So, a "Offline" mode sounds contradictory right in it's name. I didn't get this feeling for "limited-connection" mode. We should like think about the name 🤔

When in offline mode, Category Selection Fragment won't be shown, and any image processing which requires internet will be skipped

This sounds a little off to me. So if a user enables offline mode, they would have no way to add categories to the image they upload via the app? I wonder if that's going too much to conserve data as it's clearly curbing such users from a useful feature of the app. I would say it's better to allow users to add categories to the uploaded image regardless of the mode.

Ditto for the image processing checks. I feel that there shouldn't be a problem with doing any check that does not upload the whole picture. I just don't get why we should skip significant /useful checks just because a user has limited data. For instance, wouldn't it be better if we do the "Image already present in Commons" check and warn the user before hand about that instead of skipping that check; allowing user to upload it; have that image possibly deleted as a duplicate later?

Correct me if I got something wrong.

[maskaravivek]

@sivaraam Sorry, for the confusion. I have updated the scope based on your comment.

[sivaraam]

Nice. I just have one doubt for now:

Enabling Limited Connection mode would not upload image even when online

Does this apply only for mobile data or also for Wi-Fi? I'm mostly just trying to get a refined meaning for "online" here. My understanding is that this should happen only for mobile-data per #746 (comment):

A "limited connection mode" (that the user can toggle on and off as they wish) would automatically pause uploads until Wi-Fi is detected, and not download any images (i.e. thumbnails of previous contributions).

[maskaravivek]

For now, limited connection mode if enabled would be effective on any network the user might be using. In the future, we can have another set in the Settings page where he can define his preference.

[misaochan]

Here are the changes that I am making for the remaining pieces of this feature:

1. Limited Connection mode toggler in the toolbar
2. Enabling Limited Connection mode would not upload image even when online
3. As soon as the user disables the Limited Connection mode sync will start to sync all images which the user tried to upload while in offline mode
   4 Upload failures in Limited Connection mode will be handled via the usual flow as in they will be shown in the contribution list with failed-retry option

Makes sense to me @maskaravivek .

• Additionally, as per Add limited connection mode #746 (comment) : Not automatically download any images to populate Contributions list, Explore, etc. Make sure they don't crash when you can't download, but perhaps display a placeholder image (@neslihanturan what is your thought on the placeholder that we can use?)

• As per New main screen UI in v3.0 #2843 (comment) , we also need a clear way to indicate to the user that limited connection mode is on. However that should probably be addressed in New main screen UI in v3.0 #2843 itself.

Does this apply only for mobile data or also for Wi-Fi? I'm mostly just trying to get a refined meaning for "online" here.

Hmm, good point @sivaraam . I should have defined that more clearly in the scope. At the moment it feels like adding Wi-Fi detection would be adding a lot of complexity to the implementation. After the basic feature is out, perhaps we can get feedback from users on their preference for whether or not they'd like network detection.

[neslihanturan]

Well, I could not find nice a CC0 placeholder file, so made one myself :). We can use this: https://commons.wikimedia.org/wiki/File:Placeholder_view_vector.svg

[jidanni]

Did anybody try uploading images with limited connections, like in #3972?

[fnordson]

Has there been any progress on this feature?
I'm kinda lost with the Tags here and it being moved from "in progress" to "done".

[nicolas-raoul]

@fnordson I have never tested it yet, but I believe it is now implemented on the master branch, which you can get by opting for the alpha version, instructions at https://github.com/commons-app/commons-app-documentation/blob/master/android/Volunteers-welcome!.md#how-to-install-the-alpha Thanks!

[fnordson]

@fnordson I have never tested it yet, but I believe it is now implemented on the master branch, which you can get by opting for the alpha version, instructions at https://github.com/commons-app/commons-app-documentation/blob/master/android/Volunteers-welcome!.md#how-to-install-the-alpha Thanks!

I've successfully signed up yesterday but I didn't get the Alpha. Still on 2.13.2.
I was in the Beta programme already.

[misaochan]

Hi @fnordson , what email address did you sign up to the alpha google group with?

[nicolas-raoul]

@fnordson Can you please post a screenshot of your About screen? The commit number might reveal something.

[fnordson]

@misaochan you should have got it if you have notifications on.

@nicolas-raoul

[nicolas-raoul]

@fnordson Does Play Store show the app as up-to-date? And if yes, would you mind trying to uninstall and reinstall? Sorry for the inconvenience!

[fnordson]

@nicolas-raoul No problem. I did uninstall it twice now. Once a few hours after I joined the alpha programme and a second time minutes ago. (Other apps did update in that time so it's not my store or something like that)
It does say that I'm a beta tester before I install. Do I have to opt-out of beta to get to alpha maybe?
I was on Beta on another phone months ago because I had issues logging in in a past version.

[misaochan]

@fnordson , I did not receive a notification, hence why I am asking for the email address that you signed up with, so that I can check if you are actually a member of the group (which is required for alpha testing). If you don't wish to reveal it here, please email commons-app-android-private@googlegroups.com so that we can look into it.

Alpha testing is a subset of beta testing. To be an alpha tester you have to be signed up for beta testing on Google Play, and also a member of https://groups.google.com/d/forum/commons-alpha

[fnordson]

@misaochan I seems my join to the group had been blocked by my adblocker. I'm in now...sorry for the confusion :(

[misaochan]

Happy to hear that @fnordson :)