What is the difference between the Update modal, About | Reload, and reloading from browser?

Do all of these do the same thing? And more specifically, if I “Cancel” the update modal and then manually refresh the browser page, will it have the same effect (ie my app will be updated)?

1. Update Modal

Screen Shot 2022-08-04 at 10.19.19 AM

2. About | Reload

Screen Shot 2022-08-04 at 10.20.53 AM

3. Refresh page from browser

Screen Shot 2022-08-04 at 10.23.40 AM

2 Likes

All three buttons will do the same thing - reload the page, which will apply any updates that have already been downloaded.

If the update modal is cancelled then the next time the page is refreshed the update will be applied. The prompt will also be shown again two hours later to remind the user to update.

One idea I’ve been kicking around is that the webapp could automatically reload when a user completes an action, for example, submitting a report. If we were to look into this then we’d need to make sure reloading the app was fast enough that it’s not disruptive to a user who may be in the middle of series of tasks, eg: a house visit.

1 Like

Couple questions:

  1. Is the reload itself a potential slow operation? For example, if I go hit the reload button but there are no updates to the app, is there a risk that the action of reloading could be really slow?
  2. Are there certain things we know will be slower and certain things that are unlikely to be slow? For example, we could require a prompt if operation 123 needs to be done but just do the reload automatically if operation 123 doesn’t need to be done.

Reloading the app is a slow operation in general. Because the webapp is a Single Page Application (SPA) everything is set up when the app loads. However it is relatively predictable for given hardware - the same phone will reload the app in about the same amount of time, so there’s no risk of a substantially slower startup. There are a couple of exceptions to this rule, for example, initial replication, and the cht-android webview data migration. There is also a bug which was fixed in 3.15.0 which would cause a slow load if you had a weak internet connection.

Are there certain things we know will be slower and certain things that are unlikely to be slow? For example, we could require a prompt if operation 123 needs to be done but just do the reload automatically if operation 123 doesn’t need to be done.

Yes that makes sense. In future we may do client side migrations on cht-core upgrade which may take some time. Right now I can’t think of anything we do in a release which would cause a significantly longer reload time.

My main concern is while the reload time may be predictable it is generally too slow, and it wouldn’t be good to force this refresh in the middle of a house visit. A compromise would be to give the user some time (say a week?) to refresh on their own, and if they still haven’t done it then force it at the next sensible time. That way it may be annoying but I expect most users will avoid it.

I don’t know if we collect this data right now but it would be very useful to find out how many users keep the old version running and ignore the prompt for multiple days. It may be that this is not an issue in the real world…

It’s actually an issue in the real world @gareth. Users actually cancel (not sure if this means ignore) the prompt for various reasons including not knowing what the implication of the update means to their work on the app.

We gathered some feedback from MoH Uganda team and few questions came through:

  1. Sometimes the prompt pops-up while the VHT is in the middle of a task. If the VHT cancels the prompt, can the update happen later?
  2. Is the update prompt serving the purpose in reference to this comment?
  1. Can we have the app update happen in the background without distrupting the user or requiring them to accept/cancel?
  2. Can we communicate the config/workflow changes through training cards instead of the prompt to upgrade?