WMDE Technical Wishes/Edit Conflicts

Wish: Improve the resolution of edit conflicts

On the 2015 German Technical Wishes survey, improving the current way of resolving edit conflicts was wish #1 with 39 votes.

Users are especially unhappy with the current options of copying and pasting their own conflicting text chunks. Other suggestions included: Being notified if somebody has saved the page you are working on, or having a merge-like option of choosing between "mine" and "their" text chunks.

Research and testing

Discussion of first ideas, usage research

In order to get a better understanding of the issues around edit conflicts, the WMDE's TCB team started conversations with interested editors on dewiki. First the team presented two versions of possible solutions as a basis for discussions. The discussions in German can be found here and here. The results of the first feedback round as well as of further research and conversations off-wiki can be found here. The plan is to introduce to first research results and invite to further discussions of possible solutions starting with the Wikimania in June: There was a session on Thursday, 6/23 at the Wikimania Hackathon and an "edit conflict and cookies corner" on Saturday, 6/25, 10-12 am at the WMDE booth in the community village.

Prototype testing

During the Wikimania 2016 we've gained valuable insights into how a solution for resolving edit conflicts should look like. Based on these learnings, we created a prototype and asked for feedback.

The prototype

We created a prototype to show the basic version that users without JavaScript would see. People who have JavaScript enabled would have some more features, as visible on the screenshot on the side. For comparison, you also find a screenshot of the current edit resolution screen on the side.

The scenario

The article about the letter "C" has a section called "History". The section starts with:

C comes from the same letter as G. The Semites named it gimel.

For testing, please edit the section and put the C and the G in quotation marks. After saving the edit, you will have an edit conflict in the new interface.

Differences between the versions with and without JavaScript (ie. prototype vs screenshot)

The prototype shows the JavaScript-free version. This is the base version for all users. With JavaScript additional features are supported: In the left text field, users may choose which changes they want to see: Only their changes, only the changes of the other person or both changes at the same time. Furthermore, text that has not been edited by anyone would be collapsed and could be expanded if that is desired. The changes that would be added with JavaScript can be seen in the screenshot on the side.

Feedback

The feedback round in German happened here. The English-language feedback can be found here.

Update

We changed the display of the changes in the left column slightly, to better reflect the current way diffs are being displayed. The new prototype is linked above, and here. If you want to have a look at the old prototype, you can still find it here.

Results of Prototype Testing and Next Steps

Thanks to everyone who commented on the prototype! There was not only a request for feedback here on meta, but also in the German Wikipedia. The following are the conclusions that the TCB-team drew from both feedback rounds as well as conversations offline:

The vast majority appreciated the two-column layout for editing
People also liked the possibility to copy their own text, without also copying unwanted characters (such as plus and minus)
The highlighting of changed text in the textfield was also considered an improvement. There was also the request to equally highlight the changed text areas in the text editor in the right column.
One obstacle that was mentioned by many people was the difficulty of finding changed text if it is not in the initial viewport.
Another challenge is having three scrollable areas on one page (left column, right column, overall page). This could be especially difficult when using a mouse wheel.
People requested to be able to switch to Visual Editor view on the edit merge screen.

Please note, that this project is focused on improving the UI. This is why problems with the current diff engine (although noted) do not appear in this list.

Based on the feedback, the team decided to start with the realization of the wish. The new functionality will be implemented as a beta feature to enable easy testing before deciding if it is going to become a proper feature. The new edit merge screen will look similar to the prototype. Furthermore, we will attempt that both the box with the text area and the box with the text editor automatically jump to the first occurring merge conflict. Therefore, at least for the first conflict there should not be any problems in finding the appropriate position. Unfortunately, it is not possible to implement highlighting within the text editor in a reasonable time frame. The challenge to have three scrollable areas on one page has not been solved yet, but we hope to find an acceptable solution. Since the current edit merge screen does not work with Visual Editor either, we will also start with the source code version. As a second step we then plan to evaluate to what extend it would be possible to adapt the solution for visual editing.

The first beta feature

The Two Column Edit Conflict screen provides an alternative two-column view for the edit conflict resolution page. One column shows the conflicted text passages, another column shows a text editor with the latest version of the page. It highlights differences between the editor's and the conflicting change directly in the text field for an easy possibility to copy and paste desired pieces of the text and resolving the conflict.

When the edit conflict resolution screen appears, both the column with the conflicting text and the column with the text editor that shows the latest version automatically jump to the area where the first own edit occurs. Originally it was planned to automatically jump to the first occurring conflict, but the first conflict doesn't have to match with the first own edit. As people are especially interested in finding and copying their own text parts, jumping to the first own edit occurred to be more useful.

The Beta Feature provides an advanced option to choose if "my text" or "the currently published version" should be shown in the editor as well as the option to hide all unchanged text. For this extra functionality, javascript must be enabled.

The team has started with the implementation phase of the "TwoColConflict extension" in October 2016. As of May 10, 2017, the feature is available for testing on all wikis.

Test page & feedback round

As edit conflicts don't occur very often, it is hard to test the new interface and gather feedback to further improve it. After we have implemented a test page, we've asked for feedback from October 12 to November 9.

Summary of the points that got mentioned several times:

It is hard to find own changes.
It is not clear which column is going to be saved so it is hard to figure out which version I should edit.
It should be easier to merge conflicting changes.
The selection of the base version is too complicated.

In addition, several problems got mentioned once. Several concrete ideas for improvements were made and also positive feedback was made, e.g. that the new two-column design requires less scrolling than the old design.

The feedback will be reviewed in detail by the team and we'll look into possible next steps.

Thanks to everyone who shared their feedback!

Line-based prototype

Screen video of the prototype in action

Based on the feedback of the 2017 feedback rounds and further research we have built a new prototype that introduces a different approach for the Two Column Edit Conflict view. This approach was tested in a feedback round on Meta and on German Wikipedia. You can go to Special:SimulateTwoColEditConflict to test the new interface. While the current beta feature shows all conflicting passages in one column, the new approach displays them separately, with the aim to improve clarity and orientation.

The results in a nutshell

In general, the core concept shown with the prototype received high approval. A clear majority both on Meta and on German Wikipedia found the new approach intuitive, usable and suitable for a quick solving of edit conflicts. Thereby the feedback from this round heads in the same direction as the insights from user tests, where people from different experience levels tried the new approach.
Some problems and ideas for improvement were pointed out (see next steps).

Next steps

The objective of the past months was to find out if the new approach, in general, represents an improvement. We now know that the answer is yes. In order to create a proper product from the prototype, the team will concentrate on the following tasks, based on the results from user tests and feedback rounds:

improve accessibility
make not-conflicting text passages editable (grey passages)
rework the intro boxes

Furthermore, the team will deal with the question of how the editability of a text passage can be indicated before a selection was done. Also, some individually mentioned aspects will be taken into account in the development of this product.

A big thanks to everyone who participated in this feedback round! Discussion text to be put into box.

Solution: Paragraph-based Edit Conflict Interface

Already default-feature on dewiki, arwiki, & fawiki. See roadmap.

Old name: Two Column Edit Conflict View

The following new interface has replaced the previous beta feature. If you have already activated the current beta feature, it was replaced automatically. In order to use beta features, activate them in your preferences.

This is how the new feature is looking and behaving:

In a nutshell

The edit conflict interface wants to help you merge your text with the one that’s currently online. It breaks down the differences between the two text versions visually:

Text passages that differ are displayed in pairs next to each other: The current version of the page is shown in yellow and your version in blue. Inside, text that was changed is highlighted.
Text passages that are identical in both versions are displayed as a grey bar, spanning the whole width.

How to solve an edit conflict

For each pair of text, select the version you want to keep.
Edit the selected text, if needed.
Click Publish changes. A new page version is created, combining all the text you selected and the grey boxes.

What the new interface looks like.

Step by step

1. Get oriented.

A tutorial guides you through the interface the first time you encounter an edit conflict. You can open it again by clicking on the help icon (?).

In order to help you solve the edit conflict, the interface breaks down the differences between the two revisions like this:

Text passages that differ are displayed in pairs next to each other: The current version of the page is shown in yellow and your version in blue. Inside, text that was changed is highlighted.
Text passages that are identical in both versions are displayed as a grey bar, spanning the whole width.
If you want to copy your version (the entire article text with your edits) of the article page, click on the 'copy full text' link next to the blue marked 'Your revision' headline on the top of the interface.

2. Build a new version by merging your text with the one that’s currently online.

Select the passages you want to keep by clicking on the radio buttons next to them. By default, none of the texts is preselected.
Edit passages, if needed.
- Click on the black pencil to open the editing mode for a text passage. If the pencil is grey, it means you need to select the text passage first. Otherwise, this version won’t be saved when you click publish.
- You can also edit text passages that are identical in both versions.
- The highlights that indicate the differences between the versions disappear when you edit a text passage.
- You can integrate parts from other text passages by copy and paste, either with the copy and paste function on your keyboard or with a right click.
- Click on the checkmark to apply changes to a text box and to close its editing mode.
- If you want to discard your changes and reset the contents of the text box to what it was when the edit conflict occurred, click on the back cross. This also restores the highlighting.

3. Publish a new page version.

When you’re done selecting and editing all of the passages, click “Publish changes”. This composes all of the text passages you selected and the grey boxes into a new page revision. As on all wiki pages, you can preview the changes first via the Preview button. On clicking Cancel, you return to the current version of the page.

Non-JS version

If you’re not using JavaScript, the look or behavior of the feature will be as follows:

All text passages are shown in editor boxes.
There are no buttons within the editor boxes.
Text passages that are identical in both versions are always expanded.

How to turn off the new interface (for dewiki/ arwiki/ fawiki)

If you want to stick to your old workflow, you can disable the Paragraph-based Edit Conflict interface for yourself. You can do so by following these steps:

Go to your Preferences.
Under General options, Disable the ‘Paragraph-based Edit Conflict interface’ check box (as shown in the picture).

You can enable the interface again by activating it in the same place.

Major changes since November 2018

Since the beta version from November 2018, two major adjustments have been added to the Paragraph-based Edit Conflict interface:

You can now preview the changes you have made to the page. This was not possible before.
You have to select a version for each of the conflicting paragraphs. If you don’t, a warning will pop up. In previous versions of the interface, the other person’s changes were preselected, which could lead to you accidentally losing your own edit.

Edit conflicts on talk pages

Is a default feature on dewiki, arwiki, and fawiki since June 24, 2020

For talk pages, a special form of the edit conflict interface was developed. We are inviting everyone to have a look at the planned feature and let us know what you think on our central feedback page.

This interface is shown to you when you write on a discussion page and another person writes a discussion post in the same line and saves it before you do. For all other edit conflicts occurring on talk pages, the regular edit conflict interface is shown (described above).

For people interested in knowing about other improvements being made to talk pages, you can read about the work the Wikimedia Foundation's Editing Team is doing on this wiki page: Talk pages project.

What does it look like?

You write a comment on a talk page. At the same time, another person edits this exact same line on the talk page as well. An edit conflict occurs and the special edit conflict interface for talk pages is shown to you. In this special interface, only the conflicting comments are highlighted. The rest of the page is collapsed in grey boxes. The comment of the person you have the edit conflict with is displayed in a yellow box, and your comment in a blue box underneath. Both comments are shown in wikitext (not Visual Editor).

Example Screenshot of the additional edit conflict on talk pages interface. The conflicting comment is shown in the yellow box. My comment is show in the blue box underneath.

How to solve an edit conflict?

When solving an edit conflict on a talk page, you have the following options:

You have the option to edit your comment. (Note: You cannot edit the comment of the person you have the edit conflict with.)
You can adjust the indentation manually by using colons (:) as it works on other talk pages as well.
You can switch the order of the conflicting comments by pushing the two arrows between 'Your Entry' and 'Conflicting Entry' (see picture).

As a last step, you can:

submit the changes you have made (Publish change),

→ This resolves the edit conflict and adds both texts (yours and the other persons) to the talk page.

preview what the whole talk page would look like with the changes you made (Show preview), or
cancel the entire process (Cancel).

→ A pop-up window will show up asking you whether you want to stay on the page or leave the page. Keep in mind, when deciding to leave the page, your text will not be saved on the talk page. You will return to the initial talk page.

Non-JS version

The additional interface for edit conflicts for non-JavaScript users works mainly the same as the interface for users who have enabled JavaScript. The conflicting edits are highlighted. Ones edit is shown framed in blue, the conflicting edit is shown framed in yellow.
The difference to JS version of the page is that the order of the discussion posts cannot be changed using the two arrows to the left of the text fields. To change the order of the comments in the non-JS version of the page, you have to select whether your own post should be inserted above or below the conflicting post below the grey, collapsed text field . The indentation of the edits can be done with colons (:).

Multiple (three or more) edit conflicts in special talk page interface

If three or more people edit the same line of a talk page at the same time, multiple edit conflicts will occur. The last person to save their text has to solved one edit conflict after another.

Deployment roadmap

Paragraph-based edit conflict interface

→ First beta feature:

Mediawiki.org: February 6, 2017 Done
Meta: February 13, 2017 Done
dewiki: February 14, 2017 Done
arwiki: February 21, 2017 Done
hewiki: February 23, 2017 Done
fiwiki: April 12, 2017 Done
All other wikis: May 10, 2017 Done

→ New beta feature:

The switch from the first to the new beta feature on all wikis: November 6-8, 2018 Done

→ Default feature on:

dewiki: March 25, 2020 Done
arwiki: March 25, 2020 Done
fawiki: March 25, 2020 Done

Take page edit conflict interface

→ Default feature on:

dewiki: June 24, 2020 Done
arwiki: June 24, 2020 Done
fawiki: June 24, 2020 Done

No further work on this feature

We plan to make this feature available on other Wikimedia wikis. Otherwise, no further work will be done on this project, as the focus of Technical Wishes will be on working in focus areas in the future.

We are aware that the interface in its current state is unfortunately not yet ideally usable for all use cases and that there is still room for improvement. However, to improve it would mean that we would have to fundamentally rework the interface again, which would be very extensive. Therefore, we have decided not to continue working on this feature. The only exceptions are fixing serious bugs (such as data loss caused by the feature) and bugs where the interface does not behave as intended. If the Technical Wishes team is to further improve the resolution of editing conflicts in the future, a corresponding topic would have to be selected in one of the future surveys on German Wikipedia.

Links

The workboard on Phabricator
The help page and the central feedback page for bug reports and suggestions for improvements of the beta feature on Mediawiki.org
The central project page in German language on deWP
The extension manual