Talk:Community Wishlist Survey 2022/Better diff handling of paragraph splits

Add topic
Active discussions

2023?Edit

Out of curiosity, why is this under Community Wishlist Survey 2023? --Matěj Suchánek (talk) 12:48, 12 November 2022 (UTC)

Thanks for pointing this out! We moved the page to the right path, since the wish was voted on in 2022. NRodriguez (WMF) (talk) 18:40, 14 November 2022 (UTC)

ScopeEdit

Super excited for this! In the interest of seeing this long-standing wish come true, it might be worth cutting scope to just the paragraph handling within the wikitext diff (mw:Wikidiff2).

Just to clarify re: those usability materials, is the focus of this project just on handling paragraph breaks better (per the wish) or to revisit the general usability of diffs? I could see some of the proposed changes for the latter being controversial whereas the former is universally needed (and supported by the usability test scoring). Similarly, if the mw:VisualEditor mw:visual diff is still in beta, I would worry that good insights from the presentation like the usability of the carriage return symbol mid-sentence could bloat the scope of this project whereas the feedback could be passed to the team working on the VE visual diff (there are existing extensions that already implement some of the research's advice like strikethroughs). I'd be curious to see usage numbers but I imagine most users are seeing wikitext diffs (Wikidiff2) and their biggest issue is the paragraph breaks. czar 04:25, 28 November 2022 (UTC)

Interest in researchEdit

Open Questions: Are you interested in conducing user research on the new proposed interface to diff paragraph splits? If so, will you please post that you're interested in the Talk Page?

  • Is this asking if we want to participate in the research or if we want to conduct it ourselves? If the former, I'd be interested, and I would recommend pinging those who participated in the wish if you'd like other participants. czar 04:27, 28 November 2022 (UTC)

Other pain points when viewing the diffEdit

Open Questions: What other pain points manifest themselves when you view the diff?

  • In the example of the wikitext diff paragraph breaks, one important distinction is not just understanding that text was removed and re-added but understanding what happened within that text move. For example, if someone cut a part of a paragraph and moved it later down the page, that whole part will show as a removal and not show whether words or references were changed within the moved text. This gives the misleading impression that the text was simply moved from one place to another when it's possible that the text was changed. And since it's hard to compare the text, I think many don't try, which hurts the text-source integrity of Wikipedia. Okay, hope that helps! czar 04:25, 28 November 2022 (UTC)
Hello! This is to acknowledge your feedback in all three sections. –– STei (WMF) (talk) 13:42, 1 December 2022 (UTC)
  • Another issue I’ve found is that I’ve found that if a a number of lines are all changed with no added or deleted lines, the diff works really well. But if additionally a line is added or removed immediately before the block of changed lines, the tool compares corresponding lines, eg the 23rd-29th lines in the left file with the 23rd-29th lines in the right file, when it really should be comparing 23 with 24 and so on because the 23rd line in the right file was an insertion. This is really apparent if you add a new row to a pipe markup table. The tool matches the pipe-dash row marker that matches and then gets confused. YBG (talk) 04:10, 2 December 2022 (UTC)
    Your feedback has been well received. –– STei (WMF) (talk) 08:30, 6 December 2022 (UTC)

Ideas for addressing confusion around paragraph splitsEdit

Open Questions: How might we address the root pain points that address the confusion around paragraph splits?

  • Darker highlight within a highlight[1][2] seems like an elegant solution to showing what within the affected line was changed. Also if the "added" (i.e., moved) text was highlighted, similar to the examples I just linked, it would indicate a direct substitution rather than how the current diff currently looks like some text was removed and an unrelated new paragraph happened to be written beneath it. czar 04:38, 28 November 2022 (UTC)

Use of colorEdit

Open Questions: How does the use of color indicate what is

  • The proposal to use red and green for removals/additions makes sense. This is what GitHub Desktop's diff viewer and the popular delta viewer does. Even better would be to put a color toggle in user settings. As for strikethrough, I think it makes a lot more sense in the VE visual diff than the wikitext diff, whose side-by-side comparison view makes the strikethrough redundant and would make the text harder to read. czar 04:38, 28 November 2022 (UTC)

Better diffs updateEdit

Hello, thank you for your involvement in Better diff handling for paragraph splits, the #1 wish in the Community Wishlist Survey 2022! So far, we have been working on different design alternatives, and we would love your valuable feedback at this stage of the process.

We are inviting you to sign up for usability tests where you can share your thoughts and insights. If you are interested, here is how to participate: please reply to this message and we will email you a form on wiki. You will provide us with your username and email address, and also agree to the general privacy statement for the survey and user tests.

For discoverability, we will be selecting 5 users out of the responders and contacting them via email via usertesting.com.

We look forward to hearing from you –– The Community Tech team. –– STei (WMF) (talk) 13:47, 1 December 2022 (UTC)

👍 Lectrician1 (talk) 13:54, 1 December 2022 (UTC)
I would be interested OwenBlacker (Talk) 14:43, 1 December 2022 (UTC)
✔️ Virum Mundi (talk) 14:49, 1 December 2022 (UTC)
--YodinT 15:08, 2 December 2022 (UTC)

Pinging users: STei (WMF) (talk) 13:48, 1 December 2022 (UTC)

I'd be interested. Tol (talk | contribs) @ 21:19, 1 December 2022 (UTC)

Pinging more users: STei (WMF) (talk) 13:48, 1 December 2022 (UTC)

Pinging more users: STei (WMF) (talk) 13:49, 1 December 2022 (UTC)

I'm interested! The Grid (talk) 19:48, 1 December 2022 (UTC)
Sure, I'm interested. Geniac (talk) 00:00, 2 December 2022 (UTC)

Pinging last group of users: STei (WMF) (talk) 13:50, 1 December 2022 (UTC)

+1 Mako001 (talk) 13:55, 1 December 2022 (UTC)
I'm in! --Waldyrious (talk) 14:03, 1 December 2022 (UTC)
I'm interested. Geraki TL 14:05, 1 December 2022 (UTC)
Would be happy to help. Best, Barkeep49 (talk) 14:50, 1 December 2022 (UTC)
I'm interested. Qwerfjkl (talk) 16:53, 1 December 2022 (UTC)
I'm interested. -BRAINULATOR9 (TALK) 17:02, 1 December 2022 (UTC)
I'm interested. —The Editor's Apprentice (talk) 17:35, 1 December 2022 (UTC)
I'm interested. Betseg (talk) 09:06, 2 December 2022 (UTC)
I'm interested. {{u|Sdkb}}talk 22:58, 2 December 2022 (UTC)
I'm interested. Thingofme (talk) 11:11, 3 December 2022 (UTC)
I'm interested. Shuipzv3 (talk) 12:51, 3 December 2022 (UTC)
I'm interested. Fakescientist8000 (talk) 14:49, 4 December 2022 (UTC)
I'm interested. - Darwin Ahoy! 19:31, 4 December 2022 (UTC)

Thank you all so much. We will contact 5 responders via email via usertesting.com and we will keep everyone updated. –– STei (WMF) (talk) 08:32, 6 December 2022 (UTC)

How paragraph moves get mangledEdit

I run into this issue multiple times a week so I wanted to share an example here, if it would help to illuminate the trouble:

  • I took an edit I would normally make as a single commit and broke it into two steps to show how the diff viewer handles it. I moved sentences from the first paragraph into the second, and then swapped the order of those two paragraphs. But from this diff, it's impossible to tell.
  • Breaking this into two parts, in part one you can see the sentences moved and where they went.
  • In part two, you can see the paragraphs swapped with no content changes.
  • Yet when combined (or made in the same diff, which is the same function), the diff viewer make it look like a bunch of random words were changed in the original (on how it works around the template curly brace format) rather than a part copy/pasted verbatim elsewhere in the article.

As an editor, I want to see where text is moved verbatim without having to manually check each passage side-by-side. At the very least, it should look like a combination of those two-step diffs, but I would think there are smarter ways to portray this content, per the examples of how other sites' diff viewers do it (in sections above). czar 18:39, 18 December 2022 (UTC)

Here's another example in which I removed two headings and edited paragraphs without changing their order but the diff viewer interprets it as the removal and addition of new paragraphs rather than side-by-side comparisons. czar 02:48, 23 December 2022 (UTC)

Better Diff Updates and Feedback RequestEdit

Hey everyone!

Thanks so much for your involvement in the Better diff handling of paragraph splits wish.

We wanted to provide you all with an update on where we are at now, along with a feedback request for our design explorations!

We launched user tests last week– we received three recordings providing feedback on our proposed designs. We would like to thank users @Barkeep49, @Brainulator9 and @The Editor's Apprentice for sharing their input with us! We listened to your thoughts and are working on improvements based on what you told us. On the other hand, engineers are working on looking at the codebase in order to improve how the diff recognizes and renders certain changes.

We would now like to share our design explorations on a larger scale here in the talk page with all of you so that we can get wider feedback!

Things we would like you to knowEdit

We would like to list some discoveries we came across while doing research for this project, since this will impact the work we do and the decisions we make.

  • At the start of this project, we carried out an unmoderated user testing with people that were new to diffs. This led us to gather insights on how difficult it was for new users to understand the changes in an article and how to read those changes in the diff. We then decided to try and make some improvements to other elements of the diff, to make it more friendly to new users.
  • We learned that there is a difference in how the diff is represented when you press enter once vs. when you press enter twice. When you press enter once, the diff does not takes it as adding a new line. There isn’t a paragraph break. When you press enter twice, the diff takes it as a new line, and the paragraph is broken. We needed to differentiate these two different cases in our designs.
  • We also learned that besides the two columns approach, there’s also an in-line approach if you add &diff-type=inline to the URL. We decided to also expose this in our designs.

Design proposalsEdit

Paragraph improvementsEdit

Following the main request on the wish, one of the main improvements we will introduce is to paragraph splits. As we mentioned above, there is a difference between pressing enter once and pressing enter twice– when you press enter twice, the paragraph is indeed split into two separate paragraphs.

Our design explorations for these two cases are:

#1 This is an exploration for pressing enter once, where the paragraph is not broken. This exploration is for the two columns diff.

 


#2 This is an exploration for pressing enter once, where the paragraph is not broken. This exploration is for the inline diff.

 


#3 This is an exploration for pressing enter twice, where the paragraph is effectively separated into two. This exploration is for the two columns diff.

 


#4 This is an exploration for pressing enter twice, where the paragraph is effectively separated into two. This exploration is for the inline diff.  

 

Addition and deletion improvements

Another proposal we would like to introduce is related to addition and deletion of content. We noticed new users got confused about what the yellow and blue meant, why those two colors were appearing at the same time, why the two symbols (minus and plus) were appearing at the same time too, etc. We tried to simplify this:

#5 Design proposal for addition of content on the two columns diff. To expose this change, we would only use the blue highlight and plus sign – we would not make use of the yellow highlight and the minus sign to solely represent addition.

 

#6 Design proposal for addition of content on the inline diff. To expose this change, we would use a blue highlight.

 

#7 Design proposal for deletion of content on the two columns diff. To expose this change, we would only use the yellow highlight and minus sign – we would not make use of the blue highlight and the plus sign to solely represent deletion.

 

#8 Design proposal for deletion of content on the inline diff. To expose this change, we would use a yellow highlight and a strikethrough.

 

Switching between wikitext in two columns, wikitext inline, and Visual Editor diffs (the last one only if applicable: if the user has enabled “Visual differences” in their Beta preferences).Edit

#9 Design proposal for switching between the 3 different diffs – dropdown in its default state would inform the user which diff they’re seeing at the moment.

 


#10 Design proposal for switching between the 3 different diffs – dropdown in its active state would show the different options.

 


Call for feedback and disclaimer

We are looking forward to hearing from you on this talk page about what you think about our explorations, and especially about the following questions:

  • What do you think about the approaches outlined above?
  • Do you think each design proposal accurately represents the change that was made to the article?
  • Some of the design explorations are referred to, for example, content addition and deletion. Given a request for an improvement on these diff representations wasn’t mentioned on the original wish, what are your thoughts on the team also working on design alternatives for them?
  • Dropdown: What are your thoughts on it? Do you think it’s easy or difficult to find?
  • Take a look at the different options. Do you think they are clear or difficult to understand?

Please understand that design decisions are subjective and we consider an aggregate of what is most intuitive to most users. While you may individually prefer an option over the other, we will select the designs that are most intuitive to most users.

–– Thank you, Community Tech Team STei (WMF) (talk) 21:44, 1 February 2023 (UTC)

  • #1 and #3 work confusingly differently: #1 makes the first and second part of the paragraph blue, #3 leaves them gray (only the blank line is highlighted). I have no preference, but either unchanged lines of split/merged paragraphs should be highlighted regardless of the presence of the empty line, or they should not be highlighted regardless of the presence of the empty line.
  • #2 and #4 are also different: #2 highlights the rest of the line, #4 doesn’t. As a long-time wikEdDiff user, not highlighting the rest of the line seems more natural to me.
  • It’s strange at first that only one half of the diff is colored, but I can probably get used to it.
  • Dropdown: the “Visual Editor” explanation looks strange, especially given that the other two explanations are “Wikitext” and not “Wikitext editor”. I think they should be real explanations, like:
    Visual
    Highlight differences in the rendered content (beta, may miss some changes)
    Two columns
    Highlight differences in the wikitext, shown in two columns
    In-line
    Highlight differences in the wikitext, shown in-line
Tacsipacsi (talk) 16:30, 3 February 2023 (UTC)
Return to "Community Wishlist Survey 2022/Better diff handling of paragraph splits" page.