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)?
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.
Couple questions:
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:
@sue Thanks for the info!
Yes absolutely. If the user cancels or ignores or closes the dialog then the update will happen next time the app is reloaded. The dialog will also be shown again later on to remind the user to reload, but it can be cancelled again.
If I understand your question correctly, you’re asking if there’s any point showing the dialog given the upgrade will be applied later anyway? If so, then we have found some users do not reload the app very often, depending on how they use their device. For these users it’s important to have them apply the update eventually so they can be on the latest version of the app.
Unfortunately not. For the software to be updated the whole app needs to be unloaded from memory and reloaded from scratch. There are areas that can be improved to make this less disruptive, for example, having the reload complete faster, or only reloading the part of the application that has changed.
As above, for now, config changes require a complete reload of the application. Training cards should be used when there is a visible change to the application that requires additional training, but this occurs separately to actually changing the software running on the device.
I’d love to get some feedback about how the upgrade dialog could be improved. For example…
@gareth Thank you for your elaborate response plus I really like your questions, let me gather some insights on this from the MoH and revert back.
Thanks!
@gareth this will be a huge improvement considering an upgrade dialog can be very tricky and unpleasant for field staff.
(Not sure if that make sense there with reload slowness) But It is possible in that case to default the upgrade only for report submitted with specific time frame. eg : report submitted by end of the day / moment of the day within lowest activities ?
Can you help me understand why the upgrade dialog is tricky and/or unpleasant? Is it just that they don’t know what it does? Would more text help to explain what to expect?
That is possible, but it’s difficult to predict if the user is planning to keep working after they submit this form or not. For example, if they are visiting the last household of the day, and completing two tasks while there, then ideally the app would reload after the second task not the first, but it’s difficult to detect.
Most of the users do not understand conversation from the dialog, and often skip the action required. Being myself a former field staff in another context, I used to skip updates from my field app dialog while most of pin that I dropped in the map was not showing up later and I do not realize the update was the fix to that problem.
Yes more text / audio of what the update do, will allow user to acknowledge the importance of the action required.
I will sync with @sue and gathers feedback and see if my assumptions really apply to the CHW’s real context.
@sue @aziz_kane Have you experimented with changing the wording of the message? This is something I think you can do now without any development.
For example…
Update available
An updated version of the website is available. Reload to get the latest version.
Reload required
Your app needs to be reloaded. Press “Update” to do it now or “Cancel” to be reminded again in 2 hours.
I think these are the translation keys you could use