Conflict Resolution Dialog

[diegoreymendez]

We've been receiving a lot of complaints of users confused about posts not being updated and displaying the "Local Changes" label (ref #9449).

To reproduce this issue:

1. Create a post using the app and save as a draft
2. Open the post, type some content and then close the app (without exiting the editor)
3. Go to the web, change the post content and publish it
4. Go back to the app, the post will have a "Local changes" label and will never update unless the user discards the changes

Our goal is to match the implemented behavior in Android, which displays a clear message to the user and prompts for an action:

Post list	Prompt

Acceptance criteria

Showing label

• When the user has a post with local changes
• That has been published with another device (ie.: web)
• The app shows "Version conflict" label

Showing prompt to the user

• When the user has a post with local changes
• That has been published with another device (ie.: web)
• And the user tap to edit the post
• We prompt the user to choose between the local version or the remote version

Choosing "Discard web"

• We update the post using the local post

Choosing "Discard local"

• We discard the local post

[designsimply]

Why does your screenshot of the prompt show the local and web with the exact same timestamp? I've noticed that during beta testing a few times and found it odd and a bit confusing actually. As a user, I also want to choose which option to keep and not which to discard.

[diegoreymendez]

Why does your screenshot of the prompt show the local and web with the exact same timestamp? I've noticed that during beta testing a few times and found it odd and a bit confusing actually.

Those are the timestamps of the last post modifications. If both versions were modified at the same time the timestamps will match.

As a side note, I didn't take that screenshot so I'm not sure about the context of it.

As a user, I also want to choose which option to keep and not which to discard.

@osullivanchris - did you work on this dialogue in Android? Any thoughts on this?

[designsimply]

Thanks for the clarification! I think it would be good to update but also feel the conflict resolution dialog would benefit from a redesign and we could discuss that elsewhere and talking about it here may hinder the progress of this step and I don't want to do that. 👍

[osullivanchris]

@osullivanchris - did you work on this dialogue in Android? Any thoughts on this?

Hey thanks for the ping! The dialog pre-dates me. But I did find it confusing and explored an alternative last summer on p2-paCBwp-dh

My exploration was a completely different way to resolve conflicts, where the user can actually have a look at the versions first, then decide which one to load. However, it would be quite a big thing to build, and we decided against it at the time.

So if we want a smaller, quicker fix, I agree with this comment from @designsimply

As a user, I also want to choose which option to keep and not which to discard.

Another option I had tried was to just let the user directly select the one to load, rather than this strange negative action we're asking them to do now. I had suggested we try using the row itself as a tap area. We didn't do it at the time on Android because we couldn't make a row like that tapable without building a custom dialog. Here's a rough wireframe

Two other assumptions I'd be open to challenging

• the Android one is not perfect at all, so we could find a slightly better version rather than replicating
• does the user need to discard one of them, or could they both exist in version history? Then we don't have such a destructive action

Sorry for opening any cans of worms rather than providing a simple yes/no answer 😄

[Deco354]

This autosave revision dialog PR seems very relevant to this task.

[Deco354]

I've done a bit of research on this task and thought I'd share it here to provide more background in to the problem. I'd welcome any input or corrections.

Types of Updates

There appear to be three different types of updates a post can undergo when first arriving at the post list.

Update Conflict Resolution

Each of these changes can happen to a post when it is in one of four states. I've highlighted the states that I believe are causing the errors the users are reporting in #9449 . The blue case has been solved within the PR I posted above.

The scope of this task is to fix the local autosave draft conflict, however the other issues need to be considered as they will touch similar code and there are resources within the remote autosave solution that could be reused. Plus in all likelihood the publish local autosave vs new remote published post issue will likely need to be fixed as a first step towards fixing the draft issue here.

Tasks

• Enable remote posts to be accessed by latest version of post (at present the remote data is saved to the original which is not displayed)
• Write tests to ensure remote posts are not hidden in future
• Create conflict prompt (likely reusing Restore autosave revision dialog #12947 )
• Create conflict label
• Create logic (and tests) for triggering prompt and displaying conflict label

Extras

It may be appropriate to have some form of ConflictResolver struct that encapsulates our conflict logic within one place although this may be better as a separate story once this bug is resolved.

[Deco354]

I think this is why the remote posts don't appear until we discard local changes.

PostListViewController.predicateForFetchRequest:403 displays the latest revision

let basePredicate = NSPredicate(format: "blog = %@ && revision = nil", blog)

PostService.findPostWithID:758 merges the remote post in to the original post not the latest revision

request.predicate = [NSPredicate predicateWithFormat:@"blog = %@ AND original = NULL AND postID = %@", blog, postID];

[Deco354]

I guess the main questions I have here regard whether the local autosave conflict resolution described in this issue should be kept separate to the existing solution for remote autosaves.

Should the conflict resolution design described in this issue apply only to local autosaves? Or now that we're handling remote and local autosave conflicts should we apply a dialog that covers both cases (the existing one appears to do this)?

The other issue is what should we do when we have both local and remote autosaves? I believe the current logic is to overwrite remote autosaves with local ones.

[osullivanchris]

Purely in terms of UI, the mockup I showed above was to get away from the original image in the issue description, where the user had to choose a negative action, quite confusing.

The same thing is solved in #12947 that you mentioned. I forgot we had already done that on iOS. I am fine with the UI used there.

Should the conflict resolution design described in this issue apply only to local autosaves? Or now that we're handling remote and local autosave conflicts should we apply a dialog that covers both cases (the existing one appears to do this)?

I think the same dialog can probably be applied to multiple cases. However its been a while since I was working on this stuff, so it would take me a while to reacquaint myself with all the different scenarios...well done for capturing them in the above table, its hard to get to the bottom of.

Not 100% sure how many of the above questions are UX v technical. But ping me again if you need design input.

[Deco354]

Hey @osullivanchris I've two design related questions regarding this I'd love to get your input on.

1. Assuming the new prompt covers both local and remote autosaves now what do you both think of differentiating between autosave/unsaved versions and regular versions within the prompt? We differentiate between local and remote but this doesn't tell us which was the version the user actually chose to save which seems like the most important factor to me.

2. Right now the prompts options are either Web or Local. Remote conflicts can come from other devices as well as the web. Given this would Remote or perhaps Web/Other device be an adequate replacement for Web

[osullivanchris]

Assuming the new prompt covers both local and remote autosaves now what do you both think of differentiating between autosave/unsaved versions and regular versions within the prompt? We differentiate between local and remote but this doesn't tell us which was the version the user actually chose to save which seems like the most important factor to me.

What do you mean by 'regular versions'? I'm not so certain that 'save' is much stronger than Autosave. In a way its confusing that we have both. If I become accustomed to Autosave, it might not seem important to me whether I saved or not. I do think changing it to published is a very strong action which we could highlight. But I'm not sure it will be easy to say 'this is one that autosaved', 'this is one you deliberately saved' and to be sure the distinction was important to the user.

Right now the prompts options are either Web or Local. Remote conflicts can come from other devices as well as the web. Given this would Remote or perhaps Web/Other device be an adequate replacement for Web

That's a good point. I think 'from another device' is good. I believe we used 'from another device' in one of these scenarios before. Maybe it was on Android.

[Deco354]

For how we resolve autosave conflicts it appears the Android version has two very different behaviors for these each type of conflict.

1. Resolving a local autosave conflict (this task)

• immediately discards the version the user chose to discard
• User remains on the PostList screen.
• Displays a toast/prompt message telling the user they've discarded the version they chose to discard

2. Resolving a remote autosave conflict

• opens the editor with the version the user chose to edit.
• When leaving the editor the user will be prompted a 2nd time to discard or keep their changes
• If the user discards their changes in the editor then the conflict remains and both versions are kept for the user to make a choice next time they click on it.

Do we want to keep these two different resolution behaviors for remote autosaves and local ones?

[diegoreymendez]

@Deco354 - For simplicity and to avoid scope creep, I think it would be best if we kept those separated and followed Android's lead for now. Does that sound good?

Let me know if you foresee any issue with this approach.

[designsimply]

Some feedback came in from a user about synchronization not working properly, including synchronizing content from various devices, and I am noting their feedback here for reference. 👍

Offline synchronization does not work correctly and leads to wasted time due to repetitions and unacceptable checks: The logical thing is that for a matter as critical as synchronizing content from various devices, confirmation was offered with an assistant that allows choosing between the conflicting versions (as does the web editor, much more complete in everything, without also suffering from certain inconsistencies, such as the coexistence of two parallel versions).

Translated from Spanish using Google Translate:

La sincronización offline no funciona correctamente y conlleva pérdidas de tiempo por reiteraciones y comprobaciones inaceptables: Lo lógico es que para una cuestión tan crítica como sincronizar contenidos desde varios dispositivos se ofreciera confirmación con un asistente que permita elegir entre las versiones en conflicto (como hace el editor web, mucho más completo en todo, sin adolecer también de ciertas incoherencias, como la convivencia de dos versiones paralelas).

^{2-star - Oct 10, 2020 - WPiOS 15.8 - app-store reviewId=6521434431}

[diegoreymendez]

I'm releasing this issue as I'm not currently working on it.

[kean]

The "local changes" scenario was eliminated in the scope of pcdRpT-6vS-p2 and the conflict detection and resolution were added – closing.