Jump to content

Talk:WMDE Technical Wishes/Edit Conflicts/Feedback Round Test Page

Add topic
From Meta, a Wikimedia project coordination wiki
As this project originates from the German-speaking community's Technical Wishlist, there was an additional feedback round on German Wikipedia & in German language.
Please see the content page for general informations.

Welcome to the Two Column Edit Conflict View feedback round! Thank you for having taken the time to test the new Two Column Edit Conflict interface!

Two Column Edit Conflict View aims to improve the current interface to resolve edit conflicts. Feedback on the following questions would help us to learn if the new interface works well for you or if there is anything that should be further improved. It would be great if you could add your feedback by Nov 9, 2017 and sign your comments with ~~~~. Thanks a lot!

1: Two Column View
2: Difference between "your version" and "User X's version"
3: Hide Changes
4: Selection of the base version

Was it easy to understand how the Two Column Edit Conflict interface works?

[edit]
Latest comment: 7 years ago4 comments4 people in discussion

If yes, what made it easy? If not, what was confusing?

  • As a long time Wikipedist, not so easy. It may be I'm used to the old conflict system. There are too many different colours, and too many different font sizes. Also too many options to choose (unchanged text, what do you want to see initially). Try to make it simplier. Also make it easier to copy the text from the left side (maybe a button like "copy this version"). In the right box if I mistakenly chosen to show currently published version, then I can't change it anymore to show "my version" during this conflict. If I have made changes to many sections on page it's time wasting to copy and paste my changes and find a correct place to paste them to the version shown on right side. Stryn (talk) 12:52, 13 October 2017 (UTC)Reply
  • It was not easy for me to understand the interface. I was searching a long time before I found out, where the differences could be seen. The differences in the coloured boxes on the left column where hard to be compared to each other. In one chapter I changed only one word and I only found the difference, because I was knowing where I had to search. Then I searched pretty long for a way to transfer the text from the left column to the right column. I think now, that I have to copy and paste it. Is this right? I than had to search pretty long in the right column to find the right place to paste the text. It was, over all, very confusing and I would not use the tool. --Sebastian Wallroth (talk) 13:34, 13 October 2017 (UTC)Reply
  • Compact the changes to only see the changed elements is more readable than the current diff system. But those non-matching colors have disrupted me a lot. The explanations say my text is in yellow and the current version is in turquoise blue. So why the most visible elements (borders) are in plain blue and orange? I had the same issues as Sebastian Wallroth to understand what I was supposed to do. Maybe two columns should have clear labels, like "differences" for the left one, "editor" for the right one? Trizek from FR 14:35, 13 October 2017 (UTC)Reply
  • It is very hard to understand. (I'm very familiar with the old interface). Note that meeting this new interface by definition is a stressful situation: I want to save my text (in both senses), and I didn't understand the screen (choices, required choices, diff presentations), and I could not solve it. A very good thing is the Special:SimulateTwoColEditConflict page, to allow experienced editors(!) to learn the change. Best be advertised all around ;-).
It is very hard to find my own text, which is the anchor for my eye & mind. There is two columns, three+ meaningful colors, and a required choice to even see half of the page. That's three dimensions to get in one screen. I don't think that's Good Interface Design (probably needs being broken up in steps, like a Wizard?).
There are three versions in play (Pre-text, Others text, My text). The blue color does not signal a version to me, because it is also the general page support color (buttons Save, OK). So blue is not well associated with a version (better use like purple). Looking once again, I see blue is used for both "currently saved" version and "OtherUser changes". I don't think this double meaning is helpful; to me it is confusing (I want to know what I'm up against. The Pre-text is what I know & reply/edit to).
Then, MyText is framed in orange, but has text highlight yellow. Of course these two should be similar.
"Similar colors": currently, three shades of blue are used for the conflict text (frame bg, text bg, radio-button; not counting the generic OK button). That's one too much anyway, and when using shades for a similar meaning (border, text bg) I learned one should stick to the same hue and vary the S and V/L (in HSV/HSL). Today, the blue hues are 155, 138 and 156. Maybe this HSV route is too old-fashioned for modern webpage design, but the similar-ness is to be supported some way I guess. -DePiep (talk) 09:20, 4 November 2017 (UTC)Reply

Could you solve the edit conflict?

[edit]
Latest comment: 7 years ago3 comments3 people in discussion

How did you solve the conflict? What were the steps you made? - you could refer to the images on the right side to explain the different steps. Was there a frustrating moment or something especially positive? Did the result meet your expectations?

Did you encounter any technical problems/bugs?

[edit]
Latest comment: 7 years ago2 comments2 people in discussion

If yes, please describe what happened. Screenshots would be very helpful, too. Other useful informations: Operating system, browser, devise ... .

Hi Stryn, this is actually intended behaviour of the test page: Your edit creates half of the conflict, the test page makes random changes, too - this is creating the edit that you are conflicting with. So even if you are not making any changes, the testpage will add random changes to provide "the other half" of the conflict. The latter is definitely confusing and should have been explained better. I added more information to WMDE_Technical_Wishes/Edit_Conflicts/Feedback_Round_Test_Page#How_it_works, hope that makes it clearer. So, thanks a lot for letting us know! --Birgit Müller (WMDE) (talk) 16:57, 13 October 2017 (UTC)Reply

Usefullness in numbers

[edit]
Latest comment: 7 years ago3 comments3 people in discussion

On a scale from 1 (very useful) to 6 (not useful at all) how would you rate the feature?

Other remarks

[edit]
Latest comment: 7 years ago11 comments2 people in discussion
OTOH, the most complicated conflicts are those within one sentence or paragraph. -DePiep (talk) 11:24, 16 November 2017 (UTC)Reply
  • Maybe these comments here signal a more abstract problem: what was the overall design for this solving an ec? IOW, before designing the screen, what process is thought best for the editor to solve it? Today, old and new form still rely on re-editing the source text, with only two options available (start re-edit with Other Text or with My Text, all). Isn't there a sensible merge to be proposed right away (for example: when in different paragraphs or other unrelated parts, perform and propose both changes in the re-editbox)? I think there always is a level of conflict (grade of contradiction) that can be determined and then used by the Solver. When there is actually little contradiction, the Solver can suggest solutions more advanced. Is there any analysis on all ec's, a classification for example? -DePiep (talk) 10:07, 4 November 2017 (UTC)Reply
  • Interestingly, I found this on the dewiki feedback page (user:TMg): I'd expect when I click/doubleclick on a lefthand-side text block, that block would be inderted (used) in the re-editbox. -DePiep (talk) 10:07, 4 November 2017 (UTC)Reply
  • I hope this new Edit Conflict Solver adds a tag to the editsummary. -DePiep (talk) 10:10, 4 November 2017 (UTC)Reply
  • Running the Special testcase in mobile view, the setup does not show (not two columns, no colors, no overview of the various texts). Which is a bit unexpected, since I'd think the new interface applies modern webpage design (as opposed to the Y2000 2D flat webpages), which would include mobile view from the start. -DePiep (talk) 11:08, 16 November 2017 (UTC)Reply
  • To me, this is another source of difficulty ("don't understand what I see situation"): when I delete text (words), these appear as being added in the Other Text (blue). Logically correct, but not intuitive IMO. Is it just me, expecting those words in the orange/yellow box, marked like yellow & struck? -DePiep (talk) 11:19, 16 November 2017 (UTC)Reply
  • I think it would be most helpful if the yellow/blue colors reappear in the re-editbox (righthand column). As it is now, it's like a full restart. It adds the very difficult search (search again) for the conflicting edits to be solved, in a b/w colored text. -DePiep (talk) 11:31, 16 November 2017 (UTC)Reply
  • Allow me these thoughts on the designed page & process. So we have two columns, left=problem, right=solving. Sounds reasonable. But we also have two color boxes: My edits and Other User edits (orange/yellow & blue). So to get it and solve it I must look at three places for the same paragraph: two color boxes on the left + one unmarked place in the re-edit box. That's a bit much.
Is this a possible improvement: the lefthand column has only one box combining the two colors. So I see yellow and blue marks in the same textbox. Next step: edit the re-edit box to solve & save (righthand column). Could this work: per single colored text part, (be it a letter, word, sentence, paragraph, ...), I can click (doubleclick? drag&drop?) to add that to the re-edit box. I can pick blues and yellows. (todo: what with removed text?). -DePiep (talk) 12:18, 16 November 2017 (UTC)Reply
  • ...

Thanks!

[edit]
Latest comment: 7 years ago1 comment1 person in discussion

Hi DePiep, Sebastian Wallroth, Stryn, Trizek, thank you so much for having taken the time to test the feature and for your comments and ideas! This is much appreciated :-) So, we started reviewing the feedback we've received here, on German Wikipedia and some other places and we will discuss the feedback and possible next steps with the team in the next weeks. Any updates will be posted here. In case you want to test the feature more: We will keep the test page up longer, so that people can continue trying it out. Thanks again, --Birgit Müller (WMDE) (talk) 17:18, 21 November 2017 (UTC)Reply

Late remarks

[edit]
Latest comment: 7 years ago1 comment1 person in discussion

I know the window has closed, so I note this here in the blind.

I noticed that the re-edit box (righthand window) has the full page code, while the conflicting edits were in a single section. This adds to the complexity (of finding the target texts and locations). -DePiep (talk) 11:05, 2 December 2017 (UTC)Reply

New prototype ready for testing

[edit]
Latest comment: 6 years ago2 comments2 people in discussion

Hi DePiep, Sebastian Wallroth, Stryn, Trizek, based on the feedback we've gathered end of last year, further research and more tests :-) we finally have developed a new prototype that now can be tested. It would be great if you could find the time to try it out! Please see WMDE_Technical_Wishes/Edit_Conflicts/Feedback_Round_Paragraph-Based_Prototype for how it works. Thanks a lot, --Birgit Müller (WMDE) (talk) 18:08, 12 February 2018 (UTC)Reply

P.S.: There is a German-speaking version of the feedback round and prototype on deWP as well, in case anyone is interested!
Yay! Thank you Birgit! Trizek from FR 20:49, 12 February 2018 (UTC)Reply
Retrieved from "https://meta.wikimedia.org/w/index.php?title=Talk:WMDE_Technical_Wishes/Edit_Conflicts/Feedback_Round_Test_Page&oldid=17733222"