WMDE Technical Wishes/Edit Conflicts

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search

Improve the resolution of edit conflicts is wish #1[edit]

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 prototype testing[edit]

Discussion of first ideas and usage research[edit]

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[edit]

Proposal for the new interface for edit conflict resolution (with java script)
Current interface for edit conflict resolution (August 2016)

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.


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


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[edit]

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.

Testing with the test page[edit]

As edit conflicts don't occur very often, it is hard to test the new interface and gather feedback to further improve it. This is why we're providing a test page on each wiki, where edit conflicts can be simulated under real life conditions. You can go to Special:SimulateTwoColEditConflict to test the new interface.

Feedback round from October 12 to November 9[edit]

After we've implemented the test page, we've asked for feedback on

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!

We will keep the test page for longer, so that more people can tryout the functionality.

Testing the paragraph-based prototype (Feb 2018)[edit]

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. 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 paragraphs editable (grey paragraphs)
  • rework the intro boxes

Furthermore, the team will deal with the question of how the editability of a paragraph 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!

Development: TwoColConflict Extension[edit]

TwoColConflict MediaWiki Extension.png

The first version (Beta Feature)[edit]

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.


All logged-in users can enable the new view for edit-conflict resolution in the beta feature section of their user preferences.

Two Column Edit Conflict View LTR 1.svg

This page helps you to resolve an edit conflict.
There are two columns: The first shows the conflicting changes and the second column is a text editor, whose content will be saved.

Two Column Edit Conflict View LTR 2.svg

Inside the box containing the conflicting changes, both the conflicting text and your text is shown, and the differences between the two are highlighted.

Two Column Edit Conflict View LTR 3.svg

When javascript is enabled, you can use buttons above the box which allow you to hide any unchanged parts of the text to make it easier to focus on the conflicting areas.

Two Column Edit Conflict View LTR 0.svg

The second column is an editor. When the page is opened, there is a selection box on top of the editor. It lets you decide which version should be in the editor. This is often the version where more changes were made.

Two Column Edit Conflict View LTR 4.svg

Copy and paste the desired parts of the other version into the text in the editor.
Only what is in the editor will be published, when you click the "Publish changes" button.

Deployment roadmap[edit]

As a beta feature:

  • Mediawiki.org: February 6, 2017 Yes check.svg Done
  • Meta: February 13, 2017 Yes check.svg Done
  • Dewiki: February 14, 2017 Yes check.svg Done
  • Arwiki: February 21, 2017 Yes check.svg Done
  • Hewiki: Feruary 23, 2017 Yes check.svg Done
  • Fiwiki: April 12, 2017 Yes check.svg Done
  • All other wikis: May 10, 2017 Yes check.svg Done