Prevent users from losing work when they lose internet connection.

[Anthony-Alridge]

A user may be in the process of creating an exploration when they lose internet connection. This can cause frustration as attempting to refresh the browser at this point will cause the user to lose any work which they have so far done on the page (e.g if they were inputting a large amount of text, it will be gone). See here for more detail.

The aim of this is to solve this frustration for the user by protecting their work when they suddenly go offline. A possible approach would be to detect when the user goes offline and at that point save the work they have completed so far into localStorage. This way after they refresh we still have the work saved locally. As a result it will be possible to repopulate the page with the work which they would have otherwise lost.

To replicate fire up the dev server and create an exploration. Click on a state to and add content to the state editor.

Now disable the internet connection (check the offline radio button in the network tab in dev tools), then click save content. Oppia will prompt you to refresh.

So you fix your internet connection and refresh, but then the work is gone!

This would clearly be frustrating for a user so we need a way to deal with it. Note that the problem isn't so much the loss of internet connection, but the fact that the user will lose any text they have written when they refresh if it is not yet saved. It would be nice to protect the user against this such that when they refresh without saving their work is still protected, preferably without needing any direct action on the user's part so that when they refresh they get...

[Anthony-Alridge]

Hi @seanlip I've got a few questions about how to approach this.
I'm taking the problem to be that a creator who has entered a lot of work onto an exploration card will lose this work if they refresh their browser. (I think it's sufficient to focus on the situation where creator's are creating explorations, I can't think of anywhere else a user will enter enough text for this to be a frustration but correct me if I am wrong).

Now onto the solution, rather than saving the user's work when they go offline per se, I'm thinking it may be better to save the user's work (into localStorage) at regular intervals, then when the user refreshes the webpage we can restore they're work. This may be better because it solves the more general problem of the user losing work when they refresh the webpage, as opposed to just solving the issue of the user losing work when they go offline.

[seanlip]

So, one thing I should mention is that we do already have functionality for autosaving drafts to the backend. I think localStorage could be part of a solution, but was wondering how the two things (drafts and localStorage) would interact with each other?

[Anthony-Alridge]

Okay I've had a look at the code and from what I can tell it works as follows: whenever the user makes a change to the exploration (e.g. adding a new state or editing a state) they have to save it (e.g save content in the case of editing the content property of a state). This is registered as a change and is autosaved to the backend. The user manually saves by clicking save draft, which essentially commits the user to the changes he has made so far and clears the list of changes. Please correct me if I'm wrong about any of that.

Okay so onto the issue of integrating these functionalities. It seems to me that the only change which needs to saved to the frontend is the text content of a state editor (i.e the key could be the state name, the value would be the text content of the state editor), so we will not need to save the full changeList to the frontend. Furthermore, the way the changeList auto save behaves is quite different to the behavior we need here, hence the implementation of the local autosave functionality may be somewhat separate from the back end autosaves (e.g. we do not want to populate the list of changes every time the user types something into the state editor). The integration I think will play more of a role in terms of updating the autosaved data. That is, when the page is refreshed the autosaved data is fetched from the backend. It may be the case that we have a local change saved more recently that this backup local save and so we may need to update the state property of the autosaved change list with the more recent text content. A problem here would be in knowing exactly which is more recent (the local autosave or the backend autosave). Given how the backend autosave works however I think it will be reasonable to assume that the local autosave will be the more recent copy, so if there exists text content in the local autosave then we augment the autosave gathered from the backend to reflect the new content before returning the changelist. This could be done by looping through the keys (i..e state names) we've saved to localStorage and modifying the text content property of the appropriate state in the draft.

I think it makes sense to include these modifications in changeListService (where the autosave functionality is handled). To summarize, we need to expose one new function and modify one existing one. The new one should be capable of taking a state name and text content from a state editor and saving it to localStorage if a matching key:value pair (matching in the sense that the text contents are the same) doesn't exist. This could be called in intervals from StateEditor.js. Next we need to modify the loadAutoSaveData function which currently takes a draft and populates the list of changes in changeListService with this draft list. Instead it needs to first update the text contents of each state as necessary, and also return this newly updated draft to be used instead of the original draft fetched from the backend.

I may need to investigate a little more but does this seem like a viable approach to you?

[seanlip]

Thanks, @Anthony-Alridge! Let's step back one second, first; I want to fully understand the exact "success criteria" for what solving this issue entails.

In the issue description at the top, would you mind providing some steps that one could take on a local server to simulate this, a description of what happens, and a description of what should instead happen? Note that there's a checkbox in the chrome devtools (Network tab) that you can use to simulate an offline connection.

In particular I want to understand the intended behaviour from the user perspective, and then we can drill down (based on your discussion above) to see what measures we need to take in order to bring about that behaviour.

Thanks!

[Anthony-Alridge]

Thanks @seanlip I've amended it, how's that?

[seanlip]

The new description is excellent. Thanks @Anthony-Alridge!

So, looking at your notes: I agree with your first paragraph. I think the components you are looking at are the right ones and I think the approach looks promising, but I would suggest thinking about two things:

• how are you going to keep localStorage and the autosaved drafts in sync (eventually)? It seems to me that if you end up restoring from localStorage we should perhaps update the autosaved drafts as well?
• would it make sense to store timestamps so that you can resolve which changes happened earlier/later?

Perhaps it might make sense to start a design doc in Google Docs so that you have more room to lay out your approach and so that it can be commented on.

Thanks!

[Anthony-Alridge]

Hi @seanlip I've opened up a doc here. I need to add more detail into the exact changes (hopefully will do tomorrow) but it provides an overview similar to above, please tell me what you think. Thanks.

I've tried to address your points in the doc but indirectly so I'll comment here:

• When loadAutoSaveData is called the changes will be amended by using the addChange helper method within ChangeListService, which will add these changes to the backend. This should keep them in sync.

• I'm not sure if the timestamps will be necessary for this. I've explained it in the design doc but I think that the implementation will be such that the locally saved text content will always be more recent than any text content saved in the backend (provided that when the user clicks save content to save their draft of the text content the code is amended such that any local saves related to that state are deleted). I'm not against storing the timestamps of course but i'm not sure if it's necessary (and may it be worth avoiding having to change the models etc to reflect the change if not needed)?

Thanks!

[seanlip]

Hi @Anthony-Alridge, I'm going to pass this to @wxyxinyu since I'm a bit strapped for bandwidth at the moment. She has a lot of experience with the saving system so she will be able to give you good feedback, probably this weekend. Sorry for the delay!

[wxyxinyu]

Hi @Anthony-Alridge -- thanks for the doc! I left a few comments. I'm slightly confused by what exactly you plan to save in local storage, so some clarification would be nice.

[anmolshkl]

@Anthony-Alridge ping?

[Anthony-Alridge]

Hi sorry about the late response something came up last week, hey @wxyxinyu thanks for that. I've added some comments to the doc, does that clarify things?

[anthkris]

@Anthony-Alridge @wxyxinyu A friendly ping. Any updates on this?

[tjiang11]

@Anthony-Alridge @wxyxinyu ping