User:Prtksxna/VeDiff
This document looks at the new visual diffs at different levels:
- Very specific, like particular kinds of diffs that are hard to figure out.
- General comments on how the diffs are shown with some specific examples.
- High level, about the idea and scope of this feature.
Everything here could be on Phabricator, but I wasn't sure what should or should not. Some of the things here might already be 
Done, 
In progress, or tracked. Feel free to add Template:Tracked to relevant subheadings. The document doesn't offer alternative designs (only suggestions), if we do feel that something needs design work, we'll track and move that to Phabricator.
Scope[edit]
Is it a diff of all the visual changes on the page, or a visual way to see the diff of all the changes that have occurred on the page? Is the scope of this feature to also surface hidden changes like those to the metadata of the page or adding a comment?
The changes are currently being shown in two ways, the red and green diffs, or as a comment in the sidebar. There usually is a blue highlight in the diff that corresponds to a comment in the sidebar. How are we deciding which changes need to be shown in which way? The way I see it, it can be reasoned about in two ways:
- Visual change should be shown in the red/green way. This would mean that formatting changes, and converting some text to a link would show up in the diff.
- Text change should be shown in the red/green way. This would mean that formatting changes, and converting some text to link would not show up in the diff, and in the comment sidebar instead.
Picking an approach would depend on what a majority of users expect from it. We should be consistent about it either way.
- Visual diffs should probably highlight visual changes in the least confusing way. For example, if one were to show two wiki pages to a complete novice ( e.g. Zero knowledge of wikis or wikitext) with some changes, what would they immediately point out?
- Those are the most important ones. Meta-data or invisible changes are useful but they need to be clearly separated from the visual changes because these may sometimes be considerable and add a lot of unnecessary noise to the visual diff and confuse the user. As an example, a simple 1 letter change to a template markup may completely change the whole page or change loads of metadata. With the wikitext diff this is obvious, but it won't be with the VisualDiff if there are too many annotated invisible changes. 197.218.91.5 10:27, 20 July 2017 (UTC)
Scales[edit]
Different kinds of diffs can be rated at several scales. These can be used to reason about, and compare design solutions.
Effectiveness[edit]
How effectively can someoneâŚ
- trying to find a particular change spot it in the diff?
- not actively looking be able to spot the change (for eg, a mistake)?
How effectively does the diff...
- communicate what has changed?
- provide the context to understand the change?
- bring attention to itself?
Signal vs. Noise[edit]
While the visual diff is already a huge step in reducing noise, we should be wary about new kinds of noise that could surface. One could decide to hide certain information, show it when asked for, or on certain interactions, or show it all the time.
Accessibility[edit]
Color alone should not be an indicator for information? Certain critical changes that are small should be loud?
We'd usually increase effectiveness, decrease noise and maintain accessibility. But, there could be exceptions, those should be discussed and noted.
Showing the changes[edit]
Adding a link as a meta change[edit]
Adding a link to some existing text could be shown in the 'comments' instead of in the diff.
Simple formatting changes[edit]
Simple formatting changes like bold or italicized could be shown in the 'comments' instead of in the diff.
Done Link comments with the change in the diff[edit]
Sometimes it is hard to figure out what the comment is about. Like comments in Google Docs, it should be possible to select it and see what part of the document it is referring to.
Remove strike-through on hover[edit]
Will improve readability.
- ES: Seems reasonable - we should also have a touch input equivalent.
Showing comments[edit]
Currently a new comment shows up as an added space in the content. Should this be complemented with a 'comment'?
- ES: Yes - we haven't got around to fixing this properly. If there isn't a bug for it there should be.
<del> for paragraphs?[edit]
Is it possible to add the <del> tag inside paragraphs that are <p data-diff-action="remove">? This would make the interface consistent with simple word removals and more accessible.
- ES: Seem sensible.
Contrast of surrounding context text[edit]
The context text surrounding the actual change is black and at 40% opacity. The resulting color is about #989898 which has a contrast ratio of 2.88:1 against the white background. This does not pass the WCAG AA or AAA standard. Bumping up the opacity to 60%, makes the color #656565, which has a contrast ratio of 5.83:1. This passes WCAG AA.
- ES: Of course the surrounding text isn't really supposed to be read, but as long it is still clear it is unchanged, seems fine.
Vertical ellipsis[edit]
Templates on top[edit]
When there are templates on the top of the page, and the lead section of the article is edited, it adds a vertical ellipsis on the top which is confusing. This is one of the things that need to be discussed as part of scope, should we show the ellipsis for non-visual content?
- ES: If it's possible to performantly ignore non-visible content we probably should, but I don't think this is a particular big problem.
Functionality[edit]
The vertical ellipsis can be a bit confusing:
- They don't offer any interaction or information.
- The hover surface is small and doesn't give any information.
We could:
- Add hover text that tells how many lines/paragraphs have been skipped in between.
- Add gerrit like functionality that lets you see more context where needed.
- ES: Counting lines in a HTML document is a lot harder, what about tables or hidden content? Not sure it would make sense, but we could have some text and a click to reveal.
Moving paragraphs[edit]
The diffs produced when moving paragraphs and making some changes to the moved paragraph are great. It doesn't add the noise of completely removing and adding new lines. The representation, however, is unclear.
| Move paragraph up once | Move paragraph up twice |
|---|---|
|
|
It is hard to decipher visually if the chevrons are associated with the paragraph they are next to, the line they are next to, or are a different entity altogether. In the first example, at first glance, the two arrows resemble a scroll bar, and hovering over the arrows doesn't give you any information. When a paragraph is moved a large distance, every paragraph in between carries the arrow redundantly and there is no context clipping.
- ES: The latter is a bug we should file and fix, although it is non-trivial. Open to suggestions for more visible move indicators, although we don't want to interefere with the content too much. The thinking here (for non-historical diffs at least) is that the user will already be somewhat aware of the moving a paragraph, so the marking doesn't need to be particularly strong.
Confusing diffs[edit]
Removing a space[edit]
Removing a space is shown as a space with a red background and strike-through. This looks the same as removing a hyphen.
| Visual | Wikitext | |
|---|---|---|
| Remove space |  |
 |
| Remove hyphen |  |
 |
- ES: I supposed the hover feature would somewhat mitigate this.
Removing a space near a line-break[edit]
This change is really hard to spot. See the small red line at the end of the second line.
- ES: We should file and try to fix this with CSS somehow.
Edit first template[edit]
Editing the first template on the page shows a comment annotating an empty space and shows no content.
- ES: Can't reproduce on the same page. I just see the template highlighted, and the paragraph as context.
- PS: I still get this. Added a phab task with details.