Improve UX of crosswalk to webview migration

[garethbowen]

In 0.6.0 we hastily added a crosswalk to webview data migration and published a webview flavour for Android 10+. While this does the trick it's not the best UX and if we can it'd be good to make it smoother particularly when we decide to roll the webview version to all Android versions.

Firstly, the service worker cache is not migrated, so if the user upgrades and the loses internet an ugly error message is shown.

Secondly, sometimes when the app is first loaded post upgrade the migration hasn't yet finished so the user is taken to the login page. Restarting the app eventually fixes the problem, but we should have some indication that this is the case, and ideally automatically reload when the migration is complete. This is challenging because this migration step is mostly transparent to us, but we could run some JS in the webview checking for the existence of the session cookie which indicates when it's complete.

[MaxDiz]

Relevant conversation for user need and prioritization (internal):
https://medic.slack.com/archives/C024KSXQX/p1606761771060100
https://medic.slack.com/archives/C024KSXQX/p1606761794060400

[MaxDiz]

android support for inline updates documented here

[garethbowen]

Added to 4.0.0 because this will be required when we roll the webview version out to Android 5+. We may decide to solve it earlier than that.

[MaxDiz]

Further discussion with @garethbowen and @mrjones-plip - scheduling in 3.11 as a low priority. If eng time frees up after Angular work is complete, please pick up this ticket.

Regardless of whether time is allocated for eng implementation in 3.11, we should aim to have the design and eng solution detailed. In the case that a deployed project running android 10+ receives a de-listing notification from Google, it will become a high-priority.
cc: @n-orlowski

[MaxDiz]

Chatting with @n-orlowski , we think there are 3 design components, but not totally sure. We need some additional eng exploration to define design requirements

1. Error message- @garethbowen mentioned that the first attempt at migrating the service worker cache was unsuccessful. If it cannot be migrated, we’ll need some design work to replace the “ugly error message” being shown. If it can be migrated, then this design req should go away.

2. Update in progress- Something to tell the user that the update (ie migration) is in progress. Perhaps an improvement from the “Improve system status visibility while upgrading” epic (may already be scheduled in 3.13- need to check)

3. Restart/reload the app post upgrade - This is not a commonly known step to users and puts some operational burden on the Deployment team. Can we use this googleOS feature? If not, need to design alternative messaging that we can provide to the user at upgrade completion?

[garethbowen]

My thoughts...

1. Note that this error message also shows for first time users who install the app and then open it for the first time without an internet connection, so whatever we do here should be generic enough to catch both scenarios.
2. I don't think we can easily use that feature. My initial thoughts on design were to: show an Android screen with a spinner and message, add some JS to keep checking for when the cookies and DB are available, then when they are, reload the page and close the Android screen. We will need some sort of timeout or manual override just in case the migration fails to allow the user to log in manually, otherwise they will be permanently stuck on the spinner screen.

[n-orlowski]

Aligned with @garethbowen on the below:

• Top screen: update in progress with some copy explaining what is happening and a spinner
• If update times out, show new message with option to cancel. If user cancels, they are taken to the log in screen.
• If the update is successful, the app opens and user is taken to the Tasks page
• If the update is successful but the user is not logged in, they see the log in screen
• If there is no connection, show error message with CTA to retry. The retry button won't restart the migration, it will go to either "success", "not logged in", or "no connection" screen almost immediately. This error message can also be used for first time users who install the app and open it for the first time without an internet connection.

LMK if I missed anything!

[MaxDiz]

Nice changes! Does this design supersede this issue scheduled in 3.13?

[garethbowen]

@MaxDiz Unfortunately not. That issue is about cht-core upgrades, whereas this one is about migrating data in the android app.

[MaxDiz]

Based on the roadmap planning discussion, this issue should be added to the next android release to:

1. meet compliance requirements with google
2. solve the underlying usability issue
   I have increased the priority level since this is blocking for project upgrades to new containers where users are on android10+

[kennsippell]

This should likely be considered blocking for BRAC's android upgrade - they have several thoursand Android 10 users. Play Console has given a deadline of March 29th due to compliance issues.

[mrsarm]

@kennsippell @garethbowen @craig-landry ,

Here are some promising results I got today:

• As Gareth's hypothesis, the problem is that when the app migrates the cookies from XWalk to Webview, they are not accessible when the app is launched the first time. If the app is restarted by the user manually, the cookies are there so the user can access to the app without log-in again.
• The problem is: for some reason, the cookies are not accessible the first time the app is launched after the migration, I tried some approaches discusses with Gareth, like reload the page within the Webview, reload the activity, even using pauses in between. Moreover I tried to reload the page injecting javascript code in the view, or using some API methods from the Webview Java object that allows to reload or load a new URL. Nothing works, the cookies are not there.
• But there is a way to reload the whole app from scratch programmatically only after the migration process. I made the code (tomorrow I'll provide a PR, it needs some rework first). Taking this approach after the installation the app starts twice.
• It may not be the best startup UI experience but does work and as you can see in the recording below, it only adds a few seconds to the startup process.

I still need to solve this other issue reported in the ticket:

Firstly, the service worker cache is not migrated, so if the user upgrades and the loses internet an ugly error message is shown.

But I have taken a look to the events triggered when it happens and it shouldn't be hard to fix, though it will involve to implement a new view or two to display the mockups provided by Nicole, so maybe it is best to create a PR to solve first the migration issue, and then another for this last error that also can happens during migrations but is not directly related and less likely to happen.

[garethbowen]

Thanks for the update! It looks good to me, but if we can add Nicole's UX to warn about the restart that'll be perfect.

I'm happy for this issue to be split into two. The bit you've solved is by far the most important. The service worker cache is unfortunate and may introduce downtime but doesn't risk losing data.

[mrsarm]

The pull/162 is ready for review.

Changes from my last comments above:

• The implementation is the same, but I made some changes to hide completely the login page that some times was visible for a fraction of seconds
• Added the splash screen to explain the user that the app is migrating the data and need to wait a bit until the app is usable again:

Note that in the recording above the phone uses the dark mode that is why the background is black instead of white as in the mockups.

As discussed earlier, we should move forward with the review and testing of this, instead of block the ticket while I start to work next week on:

Firstly, the service worker cache is not migrated, so if the user upgrades and the loses internet an ugly error message is shown.

If the above is easy to solve I would try to push the changes in the same PR next week, otherwise I think because the major issue is solved in the PR it would be better to move forward with a release with what we have.

[mrsarm]

Ready for AT, branch 134-imp-ux-migration, from this PR: #162

The changes don't cover the improvements for the error messages displayed when there are connection errors (moved to #163). What was implemented are the changes mentioned above.

Also, here are the steps for a quick test: #162 (comment)

[ngaruko]

Tested as follow using a phone with android 9:

1. checked out master in Android studio
2. Installed unbrandedXwalkDebug build variant on the phone
3. selected server (gamma-cht)
4. logged in as a chw user
5. ---> waited for all the bells and whistles that go with first log in
6. Back to Android Studio, checked out branch (134-imp-ux-migration)
7. Modified minSdkVersion to 28 (for Android 9).
8. Selected unbrandedWebviewDebug build variant and run
9. ==> app shows message while upgrading
   

Not sure how important this is from a UX perspective @n-orlowski , the spinner is not in same colour as the one in the mock you suggested (looks greenish). Other than that, it looks good to me.

Also tested:

1. upgrade did succeed
2. user still logged in
3. no data loss
4. basic functionalities : send message, add new person, submit report

[n-orlowski]

@ngaruko, I pulled the spinner in the mock from what we are currently using for when the app loads for the first time. We should try to be consistent if possible 🙂 (although it's not a huge UX issue)

[mrsarm]

@n-orlowski sorry I didn't clarify about this, the UI that you see is built with an native Android layout, no HTML / CSS. I tried to pull the spinner from the CHT codebase but it is not a animated gif, it is a pure CSS image with CSS animations that I cannot use in the Android layout, so I used a native spinner component that is present in any Android SDK that looks pretty similar.

I'm not sure if I can customize the colors of it (that is the big difference), and for sure I cannot customize the border size, but I can give it a try at least to the first. I'll try later, but please @ngaruko lets continue with the "functional" tests in the meantime.

[mrsarm]

@n-orlowski I couldn't change the icon, the circle in the spinner is an image that then is rotated (not a gif). Make the icon equals to the CHT one would require create a transparent PNG version for the different configuration sizes, and then replicate the animation with the styles language used in Android. We are short of time so we will continue with the native spinner for now, please @ngaruko continue with the tests with the version there is now.

[ngaruko]

@mrsarm I do assume this PR/issue was just about this warning plus checking that the app still functions properly, especially: user not logged out, the upgrade actually happened, no data loss. So, we are good to go, ready to merge.

[mrsarm]

Merged into master. As mentioned above, the changes don't cover the improvements for the error messages displayed when there are connection errors, that was moved to #163, and in progress to include both tickets in the next release.

[craig-landry]

@mrsarm To be clear, we are not going to release this by itself yet. The plan is to get #163 done and do a single release with this and #163 together. If we run out of time, then we will do a release with only this. Is that correct?

[mrsarm]

Right @craig-landry , both improve the migrations process, but are not related, and releasing a new version just with the changes on this ticket is possible because it tackles the major problem when migrating.

[derickl]

@mrsarm @craig-landry are we waiting for #163 or can we can a release with #134 ?

[mrsarm]

Yes @derickl , we are waiting for #163 that is developed but waiting review, if everything goes right, I expected it to be approved today, and maybe tested by QA if there are no important changes to make before releasing an alpha version.

Please @garethbowen , could you prioritize the reviewing of pull/165 so we can move forward with a new release this week?