Last modified: 2009-09-23 18:18:08 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T17026, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 15026 - colour coding of diffs ought to be clearer, in multiple senses
colour coding of diffs ought to be clearer, in multiple senses
Status: RESOLVED INVALID
Product: MediaWiki
Classification: Unclassified
History/Diffs (Other open bugs)
1.14.x
PC Windows XP
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
http://en.wikipedia.org/w/index.php?t...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-03 20:30 UTC by Sampo Syreeni
Modified: 2009-09-23 18:18 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Sampo Syreeni 2008-08-03 20:30:26 UTC
extra version info from the source of en.wikipedia.org: <meta name="generator" content="MediaWiki 1.14alpha" />

The current user interface wrt diffs in wikipedia is *very* good, *except* for the initial impression which ought to let you know the simplest basics. That is:

-on the referred page, it is quite difficult to see "at first glance"/holistically (i.e. within the first .15sec or so, without reading anything) which column is the new and which the old version; this is a dire usability issue because edit histories are commonly used to quickly check:

--"what the hell just happened, should i perhaps revert", a function which should be easy and fast for a newbie even if the actual revert link is toned down a bit, and

--to check "what happened since i last edited this article, out of perhaps a thousand which i follow". in the second case you might think learning does its job, but visual guidance still helps that crucial millisecond or two per article, which compounds into usability for the expert editor.

-secondarily that sort of colour or symbolic coding should be extended to the primary "history" page, so that the common initial confusion about the roles of the two columns of checkboxes could be mitigated

--especially while browsing rapidly over many edit log entries, and perhaps not even seeing the first ones, it'd be worthwhile to get a single column division, and especially a consistent colour coding with the rest of the age markers inside wiki(p|m)edia; column coding helps in that a lot even for senior editors, i think

-tertiarily, it'd be *really* neat to get the edit history display to shade down the edits by timestamp; that'd let you easily decide which edits are the most recent against the baseline you chose, intensity shading against time ought to be easily implementable in your framework, it'd be perceivable by colour blind people as well, and it wouldn't disturb your colour scheme otherwise

--so by the above, i mean, do not touch colours, but just intensity values of them
Comment 1 Happy-melon 2009-01-13 11:34:48 UTC
I'm not sure what to make of this.  Given that for every one of the trillions of possible diffs on a large wiki (bar the few database irregularities which screw things up occasionally) the older revision is on the left and the newer one on the right, with arrows pointing to "previous diff" and "next diff", I think the interface should be abundantly easy to comprehend.  How would you propose to implement the diff colourscheme on the history page, exactly? Unlike the diff page, there is no obvious place for the "earlier" colour to end and the "newer" colour to begin.  And given that you can extend the history screen to 5000 entries, colour gradation is a complete nonstarter: there isn't enough gradation in the web colour scheme to even colour them in blocks of ten, and the painfully strong colours at either end would be an eyesore.  

Removing keywords that aren't really applicable (coding the colour gradation would be pretty messy); the "accessibility" one *might* be appropriate. Recommend WONTFIX.
Comment 2 Michael Daly 2009-01-13 16:50:05 UTC
As far as colours go - they should be changed.  The red-on-green scheme for the new text is virtually unreadable to those with the most common form of colourblindness.

I would recommend *not* using a text colour change on a constant background colour.  It would be better to have a constant text colour with the background colour changing.
Comment 3 Niklas Laxström 2009-08-13 08:37:44 UTC
This bug report is not useful (as-is). Please split it into small clear bug reports with only one issue in each.
Comment 4 Chad H. 2009-09-23 18:18:08 UTC
(In reply to comment #2)
> As far as colours go - they should be changed.  The red-on-green scheme for the
> new text is virtually unreadable to those with the most common form of
> colourblindness.
> 

That's bug 11374.

(In reply to comment #3)
> This bug report is not useful (as-is). Please split it into small clear bug
> reports with only one issue in each.
> 

Closing as INVALID per this.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links