Page MenuHomePhabricator

Identify the best diff style (mobile or desktop) and use it on both mobile and desktop
Open, MediumPublic

Description

MobileFrontend uses a different diff style than core, reverting it to the pre-2012 colours. The MediaWiki core 2012 scheme was decided upon in T13374.

Can we please clarify once and for all which is the preferred style and standardise on it everywhere, including RSS feeds.

Proposal

Use desktop styles on mobile site.

del {
background: #ffe49c;
}
del::before { 
content: "-";
background-color: #fff;
font-weight: bold;
padding: 0 0.25em;
border-left: solid 1px #ffe49c;
}
ins {
background: #a3d3ff;
}
ins::before {
    content: "+";
    background-color: #fff;
    font-weight: bold;
    padding: 0 0.25em;
    border-left: solid 1px #a3d3ff;
}

Accessibility notes

  1. Let's not rely only on color
  2. Avoid red/green due to most prevalent color blindness

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Hi,

@gpaumier has indirectly asked me to give my opinion on this subject, as a Web accessibility expert.

There are basically two main concerns about color choices:

  1. an information cannot be conveyed only by color. This means that you cannot rely only on color to give an information -in this case, the addition or removal of content. This does not mean that color choices such as red/green are forbidden. You just have to make sure that there is another way to convey the information, a way that does not rely only on CSS formatting, but on HTML markup and/or plain text. Two elements are useful with this respect: del and ins. However, I am not sure of their support by assistive technologies. You may also use additional textual information such as a pair of +'s or -'s around the content added and removed for example, within an abbr element to help people understanding what's going on (for example <abbr title="section added">+</abbr>...<abbr title="end of section">+</abbr>)
  2. secondly, you have to ensure a sufficient contrast between the text and the background. There is a formula for this (based on numerous user feedbacks). I refer you to the "WCAG 2.0 Guideline G18" for more details

Can we dig out this documentation and get it in the style guide?

TheDJ linked it in (edited) the main description above; the discussion/decisions in 2012 were in T13374: Red .diffchange text in the green 'added' area may be hard to read for color-blind users see in particular Trevor's comments near the end. (with followup in T37923: Followup to bug 11374 - tweaks to mediawiki.action.history.diff.css).

(Sidenote: The changes were unhappily received at enwiki https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29/Archive_99#New_.22diff.22_view_is_horrible_and_illegible though I don't recall how fast the unhappiness died down (given that we still use those colors today).
Also, there are ~1,600 enwiki users using the old-diff gadget ("Display diffs with the old yellow/green colors and design"))


(Personally, I like wikEdDiff (gadget) which uses slightly-darker shades of yellow/blue (which I believe are a suitably professional and academic aesthetic, as well as being accessible), and also handles the diffs themselves a lot better!
See the screenshot, which is showing this random/recent diff in 3 ways:

  • wikEdDiff in top-left,
  • normal desktop in bottom-left
  • and mobile on the right.

It's a hell of a lot easier to see what changed, in wikEdDiff...

Screenshot_from_2015-03-12_18:30:47.png (1×1 px, 393 KB)

I would suggest that there is no "Best diff style" - different circumstances (in-line vs split-columns) (visual impairment) (hardware and background lighting) are differences that make a difference.
Options are appreciated. They can (and should) be standardized options, but not just a singular-default-with-no-alternative. A toggle at the top of the diff page, would be nice. :)

A toggle at the top of the diff page, would be nice. :)

Check out the toggle provided by the gadget available on Wikidata with description "diff: improved diff view between page versions (not needed if wikEd is used)". You can test it in a diff page such as https://www.wikidata.org/w/index.php?diff=123456

A toggle at the top of the diff page, would be nice. :)

Check out the toggle provided by the gadget available on Wikidata with description "diff: improved diff view between page versions (not needed if wikEd is used)". You can test it in a diff page such as https://www.wikidata.org/w/index.php?diff=123456

Fabulous! Screenshot for the lazy:

  • on left - logged-out default
  • on right - the 3 tabs of the diff view, that replace the normal diff view. (Standard-diff tab. Improved-diff tab. Settings tab.)

Screenshot_from_2015-03-12_19:25:37.png (1×1 px, 306 KB)

Compiling the sum of all human knowledge, is a f***ing complex task, and requires commensurately complex tools (in many circumstances, for various users). One size does not fit all.

  • We can tweak the colors so they don't hurt readability.
  • Blue and Yellow are meaningless semantically to most people. I have over 5,000 edits, and at this moment I can't tell you what blue means and what yellow means.
  • Color is not used consistently throughout the interface to mean addition and subtraction of content.

here are some samples…

diffs.png (2×2 px, 1018 KB)

This comment was removed by TheDJ.

Besides the colors, I just wish that we had never added those absolutely hideous-looking, space-wasting, rounded boxes around each single line of text in the diffs. Can we take this opportunity to do away with them?

If we are talking about ‘cultural’ considerations, one point that needs to be made is that it seems good that both additions and removals are marked with neutral and distinct colours that do not read as ‘X is bad, Y is good’. This is why so many different open source communities go away from the standard green-red colour scheme, to show that the additions and removals should not be treated as a win-lose situation. In that area, Wikimedia community probably did better by removing the old diff styling.

If we are talking about colour blindness issues, then it should be, as TheDJ pointed out, decided on whether inline diffs are legible and distinct to colour blind users. If they are not, then it should’ve been brought to standard, already decided colour scheme that is used on desktop. I, personally, don’t have colour blindness of any kind as far as I am aware, but I’ve tried to use diff colours from the mobile version on desktop some time ago (thought they looked ‘better’ at first glance) and after some time I’ve removed it because the diffs become really unreadable with very bright styling that mobile colours have.

[...] (It is the only working filter I could find, most online filters seem to have broken lately). [...]

Sidenote that I've updated the list of tools at w:WP:Color. Specific highlights are https://www.toptal.com/designers/colorfilter for webpage analysis or http://www.color-blindness.com/coblis-color-blindness-simulator/ for file analysis. Also these 2 browser-extensions: Colorblinding (chrome) NoCoffee (chrome) NoCoffee (firefox).

If we are talking about colour blindness issues, then it should be, as TheDJ pointed out, decided on whether inline diffs are legible and distinct to colour blind users.

Yes, all the existing official variations are accessible to people with almost all forms of color blindness. (with the very edge-case exception of people with achromatopsia, but that's one of the rarer forms and is generally accompanied by other severe vision impairments). The only slightly concerning color selection at the moment are the navpopups gadget diff colors.

If we are talking about ‘cultural’ considerations [...]

As mentioned above, yellow/blue can be unintuitive for inline diffs. E.g. this diff, when seen with WikEdDiff inline viewer, it is unclear whether the link is being added or removed.

image.png (461×757 px, 82 KB)

However, inline diffs are better at displaying other things. E.g. paragraph breaks.

image.png (907×1 px, 224 KB)


AFAICT, this task's actual goal is to decide on:
(1) which colors to use for the 2-column and the 1-column (inline) diffs, and
(2) whether they need to be the same colors as each other, and
(3) whether they should be any of the existing color variations.

To which my personal opinion/answers are:
(1) unclear,
(2) not necessarily, and
(3) possibly. :D
[As with much of life, if the answer seems simple/obvious, then we're probably not looking closely enough or have an ulterior motive!]

However, I lean towards:
(1) WikEdDiff's particular shades of yellow/blue for 2-column diffs, and a lighter variant of the red/green for 1-column diffs,
(2) no, and
(3) maybe, but we need a thorough overview of the existing variants first.
All of which is complicated by the fact that every diff-color variant is attached to a different diff-parser or visualization method, which completely influences the feedback anyone will give.
E.g. (clockwise) WikEdDiff, vector, navpopups, mobile (and there are more!):

image.png (606×1 px, 220 KB)

I imagine we will continue trying new things (such as the use of strikethrough which navpopups has done for years) and user-testing those variations and doing further external research, for at least a few more years.
I do hope we tweak the mobile diff colors to be slightly more subtle in the meantime, but I don't think they need to be consistent immediately. Ditto (in reverse) for navpopups. But none of it is urgently worth arguing over. HTH!

Yes, all the existing official variations are accessible to people with almost all forms of color blindness. (with the very edge-case exception of people with achromatopsia, but that's one of the rarer forms and is generally accompanied by other severe vision impairments). The only slightly concerning color selection at the moment are the navpopups gadget diff colors.

Accessible as in ‘pass WCAG 2.0’ or ‘look distinct and intelligble’? I’ve tested a diff page with Colour Filter and at least with deuteranopia the colours are awfully similar to be distinct enough. They are distinct in desktop diffs, however.

As mentioned above, yellow/blue can be unintuitive for inline diffs. E.g. this diff, when seen with WikEdDiff inline viewer, it is unclear whether the link is being added or removed.

That’s more of a downside of reliance on colour, not of colours themselves. This is a major accessibility problem − but it should be solved by having other visual signifiers in inline diffs, such as icons (+/−), a legend somewhere on the page or text decoration (strikethrough for deleted fragments, for example). The problem with them won’t be solved with just changing it back to green-red (or blue-orange, in the other direction).

Good points overall.

Jdlrobson renamed this task from Identify the best diff style and use it everywhere to Identify the best diff style (mobile or desktop) and use it on both mobile and desktop.Jul 29 2021, 12:09 AM
Jdlrobson added a subscriber: alexhollender_WMF.

I checked in with @alexhollender around this and he suggested the editing team would n eed to be involved in this change.

Seems there are too many considerations for us to do this right now as part of tech-debt.

Change 892990 had a related patch set uploaded (by Jforrester; author: Jforrester):

[mediawiki/extensions/MobileFrontend@master] Mobile diff: Change colours to the same accessible ones as desktop

https://gerrit.wikimedia.org/r/892990

Note from diff coordination meeting: With additional visual markers like +/- diffs don’t necessarily need to have strict contrast compliance on diffing colors!

…if those are applied consistently in inline settings as well, yes