719981 - Increase contrast of text and links

Status: VERIFIED FIXED

(support.mozilla.org :: General, defect, P2)

Description

[Verdi [:verdi] Best to slack me]

Attachment: Link example

We get complaints from users that the gray text of the website is too light against the white background. Also, links are difficult to distinguish — especially in a block of text.

We should make text easier to read and links easier to distinguish.

Comment 1

[Verdi [:verdi] Best to slack me]

Attachment: Another example

Comment 2

[Verdi [:verdi] Best to slack me]

Just to clarify - this should be for all text and links on SUMO, not just KB articles. This is a a big problem in our support forum too. Many of our contributors have to do things like: link <== Click that link

Comment 3

[Bram Pitoyo [:bram]]

I don’t know how easy it will be to make changes across all CSS files used on SUMO, but darkening the link text should be easy enough to do. We can get this done by the next sprint or earlier.

Comment 4

[Verdi [:verdi] Best to slack me]

Bram, I was hoping you or Crystal could give it some UX thought. Maybe the links need to be underlined or a totally different color, etc. also the body text probably needs to be darker too so that needs to be taken into account.

Comment 5

[Bram Pitoyo [:bram]]

Verdi

Comment 6

[David Weir (satdav)]

Hi guys if possible can we also get a way to make the text bigger like on http://www.gdaonline.co.uk/

it has the +A to make the text bigger on the top

Comment 7

[Kadir Topal [:atopal]]

David, that's another bug, feel free to file one though.

Bram, how about making it bold and darker? Also, we wanted to move to sans serif for a while, maybe we can make the move at the same time.

Comment 8

[Kadir Topal [:atopal]]

I suggest:

a { 
color: rgb(60, 105, 166);
font-weight: bold;
}

#doc-content {
color: rgb(65, 65, 65);
}

body {
13px/1.231 helvetica,sans-serif
}


I'll attach to compositions. In the first image, top is original, middle is with the changes to color and font-weight, and the bottom one is with the change to sans-serif.

In the second, smaller comparison for detail it's the same order from left to right.

Comment 9

[Kadir Topal [:atopal]]

Attachment: type-comparsion, large

Comment 10

[Kadir Topal [:atopal]]

Attachment: type-comparsion, small, detail

Comment 11

[Bram Pitoyo [:bram]]

Attachment: type comparison v1

Comment 12

[Bram Pitoyo [:bram]]

(In reply to Kadir Topal [:atopal] from comment #8)

Kadir, your both of your suggestions are great.

Color-wise, I’ve taken it and increased the contrast even more so it stands out well against light blue and yellow backgrounds.

Font-wise, I’ve eliminated the bold (because the color contrast is enough to make a different). I have also changed the font-family to Helvetica Neue (it renders better on Mac), then straight to Arial without going through Helvetica first. This is because some Windows computers have Helvetica installed, and it doesn’t render well. For Linux, we’re using Nimbus Sans, a font that was designed to look like Helvetica, but renders better under FreeType.


a { 
color: rgb(0, 81, 185);
font-weight: bold;
}

#doc-content {
color: rgb(40, 40, 40);
}

body {
13px/1.231 "Helvetica Neue", "Nimbus Sans L", Arial, sans-serif;
}

Comment 13

[Bram Pitoyo [:bram]]

Attachment: type comparison (Windows) v1

Top: no font smoothing
Bottom: ClearType font smoothing

Comment 14

[Ricky Rosario [:rrosario, :r1cky]]

This is just a matter of dropping in the CSS changes once they are decided => 1pt

Comment 15

[Bram Pitoyo [:bram]]

Just a heads up, we will also need to change the a:visited color value, so that people don’t click at the same KB articles over and over again (especially in the search result)

a:visited {
color: rgb(160,0,225);
}

This will provide enough contrast with our dark blue a color.

Comment 16

[James Socol [:jsocol, :james]]

(In reply to Bram Pitoyo [:bram] from comment #15)
> Just a heads up, we will also need to change the a:visited color value, so
> that people don’t click at the same KB articles over and over again
> (especially in the search result)

Huh, so, fun fact. Because of all the stuff we throw into the query string for metrics, a lot of this is going to look unvisited anyway. Changing the query string (or the hash/fragment) of the href attribute will make it a history "miss".

This is stuff like, e.g.: "?s=crash&r=0&e=es&as=s" which means:
* searched for <crash>
* this article was the first result
* the search engine was elastic search
* and the user found the article via search

(as=s could probably now be inferred from the other info but that doesn't help with this problem at all, and it's convenient for compare with other sources like as=u.)

I have no idea how to fix this except maybe we can trash some of those metrics, since I don't know that we're actually using any of them right now, and a lot could probably be gathered from logs and referrers.

It might be good, if we do that, to also do _something_ with as=u, like get rid of it and use referrers with matching #^/1/# to count those, so articles visited from the UI also show up as 'visited' in history.

Comment 17

[Kadir Topal [:atopal]]

James, that sounds like an issue indeed, and we should deal with it, breaking history as little as possible for our users. Can you file a new bug for that?

Comment 18

[James Socol [:jsocol, :james]]

Filed bug 727085.

Keep in mind that color changes should be within the guidelines of the One Mozilla styles.

Comment 19

[Bram Pitoyo [:bram]]

James, do you know if the One Mozilla design guideline is available anywhere? I kept hearing about it, but couldn’t find any concrete things (hex color values, typography, sizes, etc.)

Comment 20

[Kadir Topal [:atopal]]

Bram will get feedback from the One Mozilla team on this, please hold out on implementing the CSS till then.

Comment 21

[Kadir Topal [:atopal]]

Okay, got feedback, and based on bug 727927#c12 we can go ahead with Brams suggestion in #12 here. That said I hope that we can one day do easy A/B tests and change fonts colors etc to empirically close in on maximum readability.

Comment 22

[Bram Pitoyo [:bram]]

On common.css:

#doc-content {
color: rgb(40, 40, 40);
}

h1, h2, h3, h4, h5, h6 {
color: rgb(40,40,40);
}

.sd-module p {
color: rgb(40, 40, 40);
}

a, a:link, a:active { 
color: rgb(0, 81, 185);
}

a:visited {
color: rgb(160,0,225);
}


We should also make search.css colored consistently with the rest of the site:

html {
color: rgb(40,40,40)
}

.result p a {
color: rgb(40,40,40);
}

a, a:link, a:active { 
color: rgb(0, 81, 185);
}

a:visited {
color: rgb(160,0,225);
}

Comment 23

[Ricky Rosario [:rrosario, :r1cky]]

https://github.com/mozilla/kitsune/commit/8520eb5e91b3078da40db45f5afc9307b3d64bc3

Comment 24

[Rebecca Billings [:rbillings]]

Verified links are darker, and notably change color after visiting them- tested on questions, kb, forums