Wordpress-android: Perceived content loss when users mistakenly overwrite published posts with drafts

[designsimply]

Steps to reproduce:

1. Create and save a draft in the app.
2. Leave the app open to the Blog Posts list.
3. Open the draft on the web, make edits to the title and body, and publish it.
4. In the app, open the post again from the drafts post list.
5. View, edit if desired, and publish the post.
6. Note that the changes made from the web are lost.

Result: if a draft made with the app is edited and published on the web, users have been accidentally overwriting the newer edits from the web with the draft seen in the app if they haven't refreshed the post list in the app. (1m36s)

^{Tested with WPAndroid alpha-182 (12.9 alpha) on Pixel 3 Android 9.}

_{h/t @rachelmcr for the testing steps & @thehenrybyrd for the mobile request (internal reference: p4a5px-2pK-p2)}

[malinajirka]

Imho this issue can't be solved without updating the API (we could theoretically create a workaround which would work in most cases, but not a proper solution).

Proper solution is to introduce a new query parameter eg. lastModifiedDate to the "pushPost" endpoint. If the "lastModifiedDate" on the server is different then what was sent by the app, the server knows that the user edited an out-of-date version of the post. The server should return some kind of error. The user should be notified about this issue. We could for example reuse the existing "conflict resolution" dialog.

However, I tried to reproduce the issue and the changes made on the web weren't actually lost forever as they could be retrieved using the revision history. Did you lose your changes forever @designsimply ?

[designsimply]

I didn't lose changes forever! The changes are saved in revisions—the problem is about the flow and is definitely a _perceived_ content loss. The reason for filing this issue is because users have been reporting that drafts are overwriting published posts and we think this flow, as well as not being able to easily find revisions when in a panic, is what's tripping them up. It happens often enough to warrant looking into, and I like the sound of the solution you proposed.

[malinajirka]

@diegoreymendez We might want to consider adding this issue into our timeline. However, it requires a change in the API so I'm not sure how much feasible it is.

[diegoreymendez]

A few thoughts:

1. I don't think this fits into Offline Posting Improvements. Especially because we made a conscious decision that we couldn't tackle API changes in the time we have for this project.
2. I do feel this can fit into Conflict Resolution, if we want to push that as a project.
3. This ticket brings up an experience we'd like to avoid for the user, but it doesn't bring up what experience we want to provide the user. To achieve the latter I think we'll need input from @osullivanchris in terms of what the appropriate UX would be.

[designsimply]

I think conflict resolution is the experience we want to provide for the user _in this specific flow_ where they are accidentally overwriting published posts with drafts not-yet-updated in the app.

Adding the Needs Design label to get input from @osullivanchris on how to improve the user experience for this specific flow. @osullivanchris I think what is needed here is direction for this flow specifically and also any recommendations you have about whether to add this into separate project work on Conflict Resolution.

[malinajirka]

I don't think this fits into Offline Posting Improvements. Especially because we made a conscious decision that we couldn't tackle API changes in the time we have for this project.

Yep, I 💯 with this. I didn't mean to suggest including it in Offline Posting.

I do feel this can fit into Conflict Resolution, if we want to push that as a project.

Yep, it could fit there or it could be just a mini-project on its own.

This ticket brings up an experience we'd like to avoid for the user, but it doesn't bring up what experience we want to provide the user.

I agree, but I don't think we should discuss it now. Imho deciding how things will work and look should be part of the project (eg. its exploration phase). The design Chris comes up with now might be out-dated before we plan this task, so I personally wouldn't waste time on it until it's planned.

[osullivanchris]

Found this issue open in a little tab in my browser but I hadn't read it yet!

I agree with @malinajirka , we should go into the details when we pick this up in a project. I think it definitely fits within a proposed conflict resolution project.

I think the biggest issues will be technical rather than finding the right flow. Here are three ways we could catch this and avoid this flow:

1. Have the posts list refresh intermittently while you have it open / be more 'live'. (I could more understand users ending up in this state if they were still in the editor)
2. Have the versions talk to each other in some way. E.g. when I edit something on web, ping the information to the app to update (rather than needing intermittent updating)
3. Whenever a user taps on a post, to every time do a check for other more recent versions before letting them open it.

But all of these ideas sound like technical implementations and I imagine they're the kind of things that require API changes as mentioned.

My main approach would be to catch it as early in the flow as possible, before the user starts making changes and ending up in strange space-time paradoxes in the first place :)

[SiobhyB]

There's another example of this happening in 2438781-zen, resulting in disappointment and a loss of trust in the app.

[designsimply]

We shouldn't let an API change block us for a case like this. Please message me if you need help figuring out how to move forward when an API change is needed.

@bummytime can this issue be considered for a sprint or project within the next year?

[diegoreymendez]

We shouldn't let an API change block us for a case like this

It's not an API change that's blocking us. It's actually that it's not clear what needs to be done, so trying to address this as a bugfix can be double-edged and bring other problems.

If we really want to get this resolved, I agree this needs to be a project.

[designsimply]

I found an example of this reported in an app review:

If I make changes to a Draft post on my PC and come back to continue on android app, the changes aren't in the app version. It's not fetching the draft changes. How can this be fixed? This doesn't happen with Published posts, just drafts. Very annoying can't add a quick edit if think of something.

• Jan 5, 2021, 06:03
• Device: Google Pixel 3a
• Device language: English
• App version code: 968
• App version name: 16.3
• Android version (SDK): Android 11 (SDK 30)

^{(internal reference: play-store-previewId=gp%3AAOqpTOGHo-KMj_CqPBP8HMb_gdqmYiF5fe4IlVcnQikuUR7pYBLZjOvFaa8Hdru8hmhrcwtQjgbxXqE2zQuxCQ&corpus=PUBLIC_REVIEWS)}

[malinajirka]

@designsimply I'm not so sure this is the same issue the user is dealing with. It seems they have troubles syncing remote version into the app. They should be able to manually invoke the sync by using pull-to-refresh gesture on the post list when it's not syncing automatically. The app should either sync the content or show "Version conflict" label and let the user choose which version they want to edit. Wdyt?

[designsimply]

I think needing to manually invoke the sync is exactly the problem in these cases. Users expect that if they update a post on the web that the changes will immediately and automatically sync to the app without needing to pull-to-refresh on the posts list.

[designsimply]

Removing from high priority due to inactivity and because the fix for it is project level complex and hasn't had an opportunity to get picked up yet. We need conflict resolution! 😊