Talk:WMDE Technical Wishes/Edit Conflicts/Archive 1

Since "improving edit conflicts" is originally a wish from the German-speaking community wishlist, most of the discussion so far has happened in German. Now we are really looking forward to getting feedback from non-German speakers, too! It would be great, if you gave us feedback about details on the one hand, but also your overall position on the other hand. This makes it easier for us to understand, if some of your detailed feedback is a break point, or just a nice to have addition.

Feedback to prototype (August 2016)

Update September 15th: We have officially closed this feedback round. Our conclusions can be found here.

Update September 1st: The display of the changes has been slightly changed to better reflect the current way diffs are being displayed --Lea Voget (WMDE) (talk) 12:56, 1 September 2016 (UTC)

Lea Voget (WMDE), how do you plan to handle a diff like this one? It's three lines added, two lines moved, and a simple 1-character indentation fix affecting 21 lines. It's a fairly minor edit which happens to generate a relatively ugly diff. Alsee (talk) 21:30, 1 September 2016 (UTC)

Hi Alsee, the solution is not changing the way diffs currently work (there is another wish on our wishlist about that, though). Therefore, the diff you mentioned would result in multiple instances of "your change" and "Grashüpfer's change" right above each other. What you would be able to do, though, is hide all changes from one party to copy all your changes in one go (the "your change" title is not copyable). Best, Lea Voget (WMDE) (talk) 13:29, 2 September 2016 (UTC)

You're not changing the diff engine, but you are trying to invent a new way to show diffs. You plan multiple instances of "your change" and "Grashüpfer's change" right above each other, except that assumes the two changes actually are a pair. It assume the two changes are different versions of the same line. That assumption doesn't hold. Sometimes the diff engine WILL be feeding you mismatched lines.[1] Your software for showing the changes won't know that it's mis-matched. Your software will happily display a series of mis-matched changes for completely unrelated lines. You also drop the "redundant" pre-change version of the text to save space, but that makes it impossible to see what is going on in either of the mismatched diffs. We almost certainly need at least one genuine diff. Alsee (talk) 14:38, 3 September 2016 (UTC)

Just concerning the pre-change version: With JavaScript, you would be able to see your version by hiding all changes by the other person (see the javascript mock). Best, Lea Voget (WMDE) (talk) 13:47, 5 September 2016 (UTC)

1.) Would the new interface help me more to resolve edit conflicts? Why (not)?

• Sure if the edit conflict is a honest search of the most equilibrate formulation. --Rical (talk) 07:32, 23 August 2016 (UTC)

Don't expect anything better than a standard diff. If they could do better than a standard diff then that could be used to update/replace our standard diff! Alsee (talk) 16:16, 23 August 2016 (UTC)

• Ok, i like it. The interface is enough simple and friendly. The situation is clear and the user has all the elements for modify the page.
• ...

2.) If the prototype were to become the new solution, I would really suggest this aspect:

• A double view, in code and in preview, could be usefull. Or a choose between visual editor and code editor. --Rical (talk) 07:32, 23 August 2016 (UTC)

• Perhaps highlight the differences like in gerrit help to miss some detail. --Rical (talk) 07:32, 23 August 2016 (UTC)

• It would help if the vertical-scroll could be pre-set to the right spot. If possible, pre-scroll it so there are two lines of non-empty unchanged text visible at the top. Alsee (talk) 16:16, 23 August 2016 (UTC)
• Per my comment in Other remarks, the left window mock-up is broken. We almost certainly need My_Wikitext on the left. Having access to genuine diffs is desirable. Probably the best way to do this is with radio-buttons for what is displayed on one or both sides. The radio-options could include My_Wikitext, Their_Wikitext, diff Original->Mine, diff Original->Their, and diff between Mine&Their. This approach may also make it possible to merge the conflicting changes into My_Wikitext when it's simpler to work in that direction. It would be a bonus if the view options included half-screen rendered-view of each version, although I realize that might be ambitious to include. Alsee (talk) 16:16, 23 August 2016 (UTC)

• In the JavaScript version, the highlighted changes could have a button to include the whole change at the current text insertion point. In mobile, having to select, copy and paste the text is painful. This would help mostly for cases where the conflicted edits added full paragraphs of different content at different points of the page. 83.35.12.195 10:30, 5 November 2016 (UTC)

• ...

3.) These are the things I especially like about the new interface:

• The side to side comparison is usefull. --Rical (talk) 07:32, 23 August 2016 (UTC)

• The left/right view split is the most important improvement! The current top/bottom split is painful. Alsee (talk) 16:16, 23 August 2016 (UTC)

• ...

4.) Other remarks

• Is it possible to set up a system that determines whether the edit you were going to make interacts with any of the text from the conflicting edit, and (to the extent that it does not) allows you to go ahead and make the edit with respect to the unaffected text? BD2412 T 15:56, 19 August 2016 (UTC)

• The source text on the test page has hard line breaks, which makes it difficult to parse the two edit windows that result from the edit conflict. I use the source editor, not the visual editor, if it makes a difference. Can you please make the test page source text look like a normal WP page by removing the line breaks from within paragraphs? Also, the "Changes" header should be called "Conflicting changes", and the other window should be called something different from "Editor", like "Publish this version". Jonesey95 (talk) 21:46, 22 August 2016 (UTC)

Jonesey95 Thanks for the suggestions! We have noted the suggestions for the window titles. I'm sorry about the line breaks, this is a short coming of the prototype that cannot easily be fixed, but would of course not be there in the finished version.--Lea Voget (WMDE) (talk) 16:03, 23 August 2016 (UTC)

• I don't understand anything at all in the screenshot proposed. It would be useful to add a screenshot that actually explains what it's contained in it and what the user would do. Nemo 15:18, 23 August 2016 (UTC)

  Nemo Thanks for the feedback. I expanded the section that explains what is the difference between the JavaScript and the non-JavaScript version (ie. the screenshot and the prototype) a bit more, I hope that helps!--Lea Voget (WMDE) (talk) 16:03, 23 August 2016 (UTC)

  Is phabricator:F4399301 what I'm supposed to see? Initially I thought the page just contained my version and the current version side by side (rather than one above the other as in MediaWiki). Then I realised that I have to scroll to see something. I have some problems:

  • a diff style different from the default one is used;
  • you suppressed the initial box with the diff, which provided an immediate way to see what caused the diff, so I'm completely lost when I see the error and I don't know how to proceed.

  Nemo 10:02, 25 August 2016 (UTC)

  Nemo, the prototype is merely a series of pre-built webpages. It ignores the edit you make, assuming you will make the exact change they expect you to make. You are expected to put quotes around C and G in the specified sentence. After saving you need to scroll down to find the strange "diff". It shows that you added quotes, and it shows the conflict-edit completely changed the sentence. I think the designer imagined what a nice diff would look like, without realizing the software can't really handle general case changes like that. Then the prototype silently assumes you will fix the conflict by adding quotes to C in the other person's sentence. Alsee (talk) 18:50, 26 August 2016 (UTC)

  I know what the prototype is, I did exactly what I was told to, and I commented on the results. Nemo 07:15, 2 September 2016 (UTC)

• The left side of the mock-up looks extremely fictional and flawed. It uses two inconsistent ways to theoretically show a specific pair of simple changes. You pretty much have to use the existing diff engine for any changes you want to show. Consider an edit that merely capitalizes all instances of a single word. That can hit every paragraph. That can generates a +/- diff over twice the length of the page. Two conflicting edits could both trigger long diffs, even when they are both "simple" changes. That means your mock-up's left side text would be four times as long as the original page. The left view is only half-width, therefore the vertical scroll would be more than eight times the height of the original page! I proposed an alternative in the suggestion section above. Alsee (talk) 16:16, 23 August 2016 (UTC)
• I checked the new version and I'm not sure what changed, but I'm sure that I'm still completely lost when I get the edit conflict page, because there is no diff visible above the fold: phabricator:F4425505. Nemo 07:18, 2 September 2016 (UTC)

Hi Nemo, the new version shows exactly what the current diff would show side by side, only in the new layout (i.e. above each other). Have a good weekend! --Lea Voget (WMDE) (talk) 13:36, 2 September 2016 (UTC)

By "new version", do you mean something different from what I tested and took a screenshot of (phabricator:F4425505)? If not, I confirm what I said above. Nemo 17:44, 2 September 2016 (UTC)

5.) Multiple changes to final change

• The first tool was about "2 changes produce 1 change.". But some last talks are about "several changes cooperate to form the composite change". I agree this usefull ability. The coloration like in Gerrit can help, using a different color for parts coming from each change proposition and combined in the final form. --Rical (talk) 19:15, 27 August 2016 (UTC)

• ...

Communication channel is closed

Where can the development team be contacted? This page says "the feedback round is closed", but doesn't provide directions of a place where the development can be followed or further problems can be reported. 83.35.12.195 10:34, 5 November 2016 (UTC)