Let users know of required storage location change and let them opt-in before August 2020

1. What is the general goal of the feature?
New Android privacy requirements mean that Collect files will need to be moved by August 2020 (read more details at Collect will need to stop using /sdcard/odk for files). The goal of this feature is to alert users of this upcoming change and allow them to opt-in when it is convenient for them. To minimize risk of data loss, the migration will only be allowed if all filled forms have been submitted.

One big challenge in the feature design is that end users of Collect may not have all the knowledge needed to make an informed decision. For most users, it should be safe to migrate as soon as all data has been sent. We need to balance clear messaging with not providing too much information that will confuse or alarm users.

The goal is for as many users as possible to opt-in before the summer. Come the summer, we will need to force the migration and this may be disruptive.

2. What are some example use cases for this feature?

  1. A user installs the latest version of ODK Collect. They don't use external application integrations. They can immediately opt-in to the scoped storage change.
  2. A user installs the latest version of ODK Collect. They will be required to use an external application integration like OpenMapKit or OpenHDS. They can delay opting in until those applications have been updated.
  3. A user already has ODK Collect installed and doesn't use an external application integration. They have collected a lot of data offline and will not be online until the end of the week to submit data. They can wait to opt-in to the scoped storage change until after they have submitted all their data.

3. What can you contribute to making this feature a reality?
Feature design, project management, software development.

I have an initial design document here that I would appreciate feedback on. Comments directly in the document are preferred.

The basic flow proposed is:

  1. A banner that can't be dismissed

  2. Tapping on Learn more and migrate will display a full screen dialog that provides some information.

  3. While the migration is in progress, the user interface will be entirely blocked.

  4. Success or failure results for the migration will be displayed in the banner.

I have made some refinements to the specification according to feedback. I have also updated the mockups above.

Some notable changes:

  • the banner is not dismissible because we think this change is safe for most users to do right away and we want to avoid users dismissing the banner, not getting updates before August, and then losing access to submissions.
  • having unsent submissions won't block migration because it's meant to be safe anyway. Submitting all data is a suggestion but not a requirement.

The addition of a banner potentially makes the main menu title, tagline and "Main Menu" label seem even stranger. @seadowg has put together a proposal for collapsing some of this redundant information in this document.