Page MenuHomePhabricator

Colour-coding of items in page histories
Closed, DeclinedPublic

Description

Author: liquid.2003

Description:
In order ton make history reading easier, it will be cool (yep !) to mark
contribs with colors. I'm trying to explain better :/

  • in <font color="c080e0"><u>pink</u></font>, IP contributions
  • in <font color="red"><u>red</u></font>, sysop contributions (when they clicked

on "revert", "rename" for example)

  • in <font color="green"><u>green</u></font> modifications made by user viewing

history (hmm ... I want to say everyone should see his own modifications in a
specific color, like green here).

  • and default colors for others modifications.

Is it possible to add a little option in ''preferences'' to diplay or not
colored histories ? Will be usefull for sysop ! And funny :) ...


Version: unspecified
Severity: enhancement

Details

Reference
bz5491

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:11 PM
bzimport set Reference to bz5491.

johan.uhle wrote:

First Try On Adding This Feature

attachment bug_5491_johanuhle.patch ignored as obsolete

johan.uhle wrote:

Picture on how this looks

attachment history.png ignored as obsolete

johan.uhle wrote:

Hi There,
this looks like a nice enhancement to me, improving overview in history view, so I made a patch for this. It changes the backgroundcolor of the line, according to the user who made the revision:

Not logged in User -> White
Some logged in User -> Yellow
Currently logged in User -> Green
Sysop -> Pink

Of course, it uses CSS. Changes have been made to shared.css, so skins can override this. I tested it with various skins and it works fine. Image of the looks attached. Feedback appreciated.

Re-opening. WFM is for closing bugs about errors that no one can re-produce/don't seem to exist.

Adding the classes might be a good idea, but I don't think assigning default colors is necessary. I think that should be left up to individual sites or skin designers. Additionally, color combinations with the link+background text could potentially have accessibility issues for visually impaired users, especially things like red text on pink background, blue/green might have the same issue.

johan.uhle wrote:

@#5
I orientated the default colors to the default colors in /skins/common/diff.css.
I thought, "If they have default colors their, why shouldn't I use them, too"? Furthermore, can't the skin designers just override my colors with their own if they want to?

I do totally agree with your critisicm about the bad color combination. I may think of a different color combinations, after we have clarified the "default colors"-issue.

Futhermore, there is the question of how to document this color scheme to the user on the history page.

johan.uhle wrote:

Second Revision of the Patch with no colors but borders used

First thing I want to point out, that this patch would be a nice enhancement for the history view, because one would be able to check the involvement of sysops and registered user in changing a site with one glance.

I have thought about the colorblindness-thing a lot more and don some research on the web about this issue and read a lot of stuff. I've done some checking with this tool: http://www.paciellogroup.com/resources/contrast-analyser.html which implements the Accessibility Guidelines of the WC3 http://www.w3.org/TR/2007/WD-WCAG20-TECHS-20070517/Overview.html

My conclusion is, that there is no good color-scheme to be picked, matching the criteria of having a color in the background, that leaves the foreground text 100 % readable appart from plain white. Not even the "grey" (#F9F9F9) used at the moment in the background of the "Compare Selected Versions" Boxes is 100 % WC3 Contrast Ratio proof (Contrast Ratio against Red is 3,8:1 but should be 5:1).

So i thought of a different solution using borders.

  1. IP-User have just plain white background
  2. Logged-In-Users have the same "grey" background as already used
  3. SysOPs have "grey" background and a 1px solid border
  4. The current logged-in user has a grey background and a 2px border (i want to see what i have done with this page)

attachment bug_5491_johanuhle2.patch ignored as obsolete

johan.uhle wrote:

Picture of how it looks with borders

attachment picture_bug5491_revision2.png ignored as obsolete

johan.uhle wrote:

The color solution and the border solution do not work as they should. A solution with dedicated icons runs into the problem that skin developers would have to do new icons for this. Could any skin developer please comment on this? If not, I guess it would be better to close this bug.

liquid.2003 wrote:

(In reply to comment #9)

The color solution and the border solution do not work as they should. A
solution with dedicated icons runs into the problem that skin developers would
have to do new icons for this. Could any skin developer please comment on this?
If not, I guess it would be better to close this bug.

There is a feature created by some wikipedians that I've added to my Monobook here :
http://fr.wikipedia.org/wiki/Utilisateur:Liquid_2003/monobook.css
A few days ago, there was icons too, from the Crystal Clear pack.

john wrote:

Comment on attachment 5559
Second Revision of the Patch with no colors but borders used

Thanks for submitting a patch to MediaWiki. Unfortunately I'm going to have to mark them as obsolete because they no longer merge into our current code. However I would like to touch on two things about the patch:

  1. MediaWiki has a strict guideline on how code should be formatted. Mainly, single line if statements are highly discouraged as they aren't very readable.

http://www.mediawiki.org/wiki/Manual:Coding_conventions

  1. The following code is worrying

    User::newFromId($revUserId)->getGroups()

Although it may not look like much it can possibly add a large amount of Queries to the page. You're loading up a user object which requires a separate database query for each revision. Ouch. If you were to re-implement this today you should look at creating a JOIN in the query to get user groups

Thank you very much though for submitting this patch, any bit helps. =)

Changing to RESOLVED WONTFIX as this is issue is both stale and also sounds like all it would do is turn the history page into an assault on the senses.