Page MenuHomePhabricator

Identify the best diff style and use it everywhere
Open, NormalPublic

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.

Event Timeline

Nemo_bis created this task.Feb 26 2015, 9:28 PM
Nemo_bis raised the priority of this task from to Needs Triage.
Nemo_bis updated the task description. (Show Details)
Nemo_bis added a subscriber: Nemo_bis.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 26 2015, 9:28 PM
Nemo_bis set Security to None.
Jdlrobson renamed this task from Use standard diff style in MobileFrontend to Identify the standard diff style and use it everywhere.Feb 27 2015, 12:25 AM
Jdlrobson updated the task description. (Show Details)
Jdlrobson added a subscriber: Jdlrobson.

I've updated the wording. This has come up numerous times and it's not clear what is the standard one.
https://lists.wikimedia.org/pipermail/mobile-l/2014-February/006489.html

Have added several projects to get this nailed down.

The html for diffs in Flow are generated with the code as core (DifferenceEngine), the differences will be in the header above each diff block and that the block is displayed inside a flow container, so receives a maximum width treatment(that is changing!)

@EBernhardson is the styling from Flow the same too these days?
See also https://lists.wikimedia.org/pipermail/mobile-l/2014-April/006845.html for background.

To be honest I'm tired of this continuously coming up and I'd like someone to clarify if this really is a problem or not. Just because MobileFrontend does it differently doesn't mean it wrong. These should be defined in the less variables colour file and used everywhere. The fact they haven't been standardised means this will continue to come up again and again.

Nemo_bis renamed this task from Identify the standard diff style and use it everywhere to Identify the best diff style and use it everywhere.Mar 7 2015, 8:33 PM

Core trumps extensions, so there is no doubt about what's the standard. It seems you want to propose a change? Having this tracked can't harm, either way.

Where does that logic come from? :)
Core was built ten years ago when we had different display technologies and lots of bad decisions were made in its development that I'm sure people regret. One of these problems was not building a style guide documenting the choice of colours and why.

It's just a colour so easy to change either way and to my knowledge both are highly accessible so do not cause any problems to our users.

Do let's not be hasty and make sure the research into the best colours for mobile diff's isn't ignored and if we do want to standardise on something ensure there is logic behind it documented in the code to avoid this happening again.

Once we have a style guide and it says what the diff colours should be I promise to switch over mobile to them if necessary.

Until that happens any changes are just wasting everyone's time.

TheDJ updated the task description. (Show Details)Mar 9 2015, 9:28 AM
TheDJ added a subscriber: TheDJ.Mar 9 2015, 1:50 PM

I can honestly say that the 2012 diff changes was probably one of the most discussed color changes in our history (only counting those that were NOT permanently reverted). I admit that it probably wasn't too well documented, as much of our development up to 2013/2014 was not.

The change mostly tried to address red/green colorblindness concerns, while at the same time keeping the general population somewhat at peace. The 'best' colors are a very relative distinction of course. Just because a large population prefers one thing in research, does not make it OK to ignore the needs of the rest of the population.

Running a filter script like:
https://github.com/Altreus/colourblind/blob/master/bookmarklet.min.js can help to some degree with 'visualizing' the problem for those blessed with 3 or 4 types of cones. (It is the only working filter I could find, most online filters seem to have broken lately). The good thing is, that the mobile colors do not seem to score as bad as the original core diff colors did on R/G colorblindness. The bad thing is, that as a color blind user, due to the inline representation of the diff, you won't have a clue about wether something is an addition or a removal, as there is no meaningful communication of the difference between the two colors (unless you happen to match the color in the "bytes removed/added" message to the background color of the diff, which seems rather difficult to me for some users.

Ignoring the inline problem, and limiting ourselves just to comparing the colors, the 2012 core colors score higher across the range of different types of colorblindness, mostly by preserving legibility due to higher contrast differences between background (lighter) and foreground (bold usage). The more vision problems you have (not limited to colorblindness), the more important this is.

I'm not sure if Gerrit/Github did much research and accounting for colorblindness. If anything, I suspect that Github 'might' have looked at this, since they seem to have done limited accessibility work on their site at several points in their history. Reaching out, might be an option.

At the very least, I would suggest to add a more comprehensive legenda to the mobile diff, because of it's inline diff style. If you have any form of colorblindness, especially R/G, it's probably very difficult right now to make the distinction between the addition vs the removal. Even though users can probably see a difference between the two colors, they will not be able to attach meaning to it because the different colors look alike. It's like seeing two forms of red to them.

Can we dig out this documentation and get it in the style guide? We should document it as a variable in mediawiki variables less file. This way we are all using the same colour and can be sure it is the right colour and use it for arguments when people say it is the wrong colour :-).

I don't really care which we go with as long as we are sure they are the right ones. I've pointed previously at colour blind tests the design team did for the mobile diff's and I'm no expert on this subject so they could be flawed or useful but they should be considered.

There's no point in just substituting the colour in mobile, but if there's a variable in
http://git.wikimedia.org/blob/mediawiki%2Fcore/7ba745f854d9f6058d09d719845b63a6c868caff/resources%2Fsrc%2Fmediawiki.less%2Fmediawiki.ui%2Fvariables.less called @colorDiffRemoved and @colorDiffAdded
it's very hard for me to argue not to use it :-)

He7d3r added a subscriber: He7d3r.

The most common type of color vision limitation Protanopia (red-green color blindness) is no longer an issue with the Mediawiki constructive and destructive semantic colors, these colors have been test with both color blindness simulators as well as shown to individuals who have this type of vision. I'm not sure why it keeps coming up that we can't use these colors due to color vision differences in users.

@Jaredzimmerman-WMF eh. that's like saying that color blind people should still be able to understand traffic lights if you put them on their side and remove the orange light.

Just because something is distinct enough in one situation doesn't automatically lead to the same conclusion in a totally different scenario.

@TheDJ, I totally get that, my point was that it seems like colorblindness was being used as a reason for keeping things inconsistant. where in reality I don't know that either set of colors is any more appropriate for that particular concern.

MaxSem closed this task as Invalid.Mar 12 2015, 12:34 AM
MaxSem claimed this task.
MaxSem added a subscriber: MaxSem.

As the partially colorblind guy who started all that fun in 2012: the semantics of side by side diffs of MediaWiki and inline diffs of MobileFrontend are absolutely different: for side by side diffs the only thing you need is to highlight added/removed text in context. Even different colors on the left and right don't really have to be different, it's just a nicety that we totally can do and therefore we do, its influence on intuitiveness of diffs is minimal because you already have diferent columns for "before" and "after". However, for inline diffs the situation is completely different: colors actually mean a lot. The only color scheme that's intuitively clear to people of all cultures is red for removals and green for additions. By changing it to anything else, you will simply make diffs stop making any sense. And not help the colorblind people a slightest bit. We can still discuss how we can make the diffs readable to the colorblind people (for example by striking out the removed text and bolding the additions), but simply changing the colors to match each other makes no sense. Therefore, I'm closing this bug.

Jaredzimmerman-WMF reopened this task as Open.Mar 12 2015, 2:13 AM

@MaxSem, I get what you're saying, and I totally think we should show in-line diffs. but the spirit of this bug still holds true, can we take what you've just said, red for deletions and green for additions and use that on the diff views we already have? its honestly very confusing to have green and red on mobile, green and red on the history page, and then suddenly yellow and blue on the actual "Difference between revisions" screen. Its the odd screen out…

Lets use this task to make the diff view have consistent colors with the other two instance, and ideally use the semantic green and red colors called as less variables so we don't have to deal with changing it here if those colors ever need to shift.

Jaredzimmerman-WMF triaged this task as Normal priority.Mar 12 2015, 3:06 AM
He7d3r updated the task description. (Show Details)Mar 12 2015, 1:47 PM
He7d3r added a project: User-notice.

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
Quiddity added a comment.EditedMar 13 2015, 2:00 AM

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...


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.)


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…

TheDJ removed a subscriber: TheDJ.Mar 13 2015, 7:07 AM
Nemo_bis updated the task description. (Show Details)Mar 13 2015, 5:42 PM
Nemo_bis removed a subscriber: Nemo_bis.
Restricted Application added a project: Readers-Web-Backlog. · View Herald TranscriptApr 8 2015, 7:17 AM
TheDJ added a subscriber: TheDJ.Apr 8 2015, 7:49 PM
This comment was removed by TheDJ.
TheDJ removed a subscriber: TheDJ.Apr 8 2015, 7:52 PM
Litlok removed a subscriber: Litlok.Apr 17 2015, 8:45 AM
MaxSem removed MaxSem as the assignee of this task.Aug 17 2015, 5:53 PM
Fito added a subscriber: Fito.Jan 18 2017, 11:13 AM
Fito added a comment.Aug 20 2017, 9:28 PM

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?

Qgil removed a subscriber: Qgil.Aug 29 2017, 7:51 PM
stjn added a subscriber: stjn.Apr 19 2018, 7:13 PM

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.

Quiddity added a subscriber: TheDJ.EditedApr 20 2018, 2:50 AM

[...] (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.

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


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!):

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!

stjn added a comment.Apr 20 2018, 11:20 AM

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.

gpaumier removed a subscriber: gpaumier.Jul 18 2018, 5:57 PM