I completely disagree with this. Consider the failure modes of erring in either direction:
- Too much contrast? Reduce screen brightness. (This has the beneficial side effect of increasing battery life on mobile devices.)
- Too little contrast? Uhh… squint more, or try to find software that lets you override the designer's intent.
Most people aren't using professional screens in low lighting, and not everyone has young eyes. Lower contrast can be a deal-breaker for these people. Even for those with perfect vision, low contrast can be incredibly annoying. It's so frustrating to view a screen in direct sunlight and be unable to see content because a designer didn't want to cause eye strain.
A side note: Amusingly, the first thing I did when looking at your second source (http://ianstormtaylor.com/design-tip-never-use-black/) was use my reader mode extension. I disliked the off-black sans-serif font.
1. e.g. scroll to the bottom of https://geoff.greer.fm/2017/02/28/software-rot/ and click "go dark".
>I completely disagree with this
Pure black on white has been reccommended against for some time, typically you'd use dark grey on a pure white bg
>Note: for low resolution screens, an overly strong contrast (full black and white) is not ideal either, as the text starts to flicker. Benchmark: #333 on #fff.
It's not that straightforward. While shorter line lengths may be preferrable for reading bodies of text[1], API pages are rarely read top to bottom. Reducing the number of characters per line makes less content visible on screen, necessitating extra scrolling and slowing down visual searching.
[1] Though it's quite possible to cherry-pick citations for either side: https://www.researchgate.net/profile/Barbara_Chaparro/public... (PDF)
Er, not sure if you're looking at the before and after screenshots the wrong way round? The new design appears to reduce the number of characters per line from ~100 to ~80 (by increasing the body font size).
Compare first line of Array#slice in the old design:
"The slice() method returns a shallow copy of a portion of an array into a new array object selected"
vs the new:
"The slice() method returns a shallow copy of a portion of an array into a new array"
OK, that all got a little sharp, but I do wonder what "design language" (per the blog post) is steering their information design.
You might want to mention this on the accompanying Discourse feedback thread [1] so it's noted for the next phase.
[0] https://news.ycombinator.com/item?id=14745947
[1] https://discourse.mozilla-community.org/t/beta-redesign-feed...
Can you explain why and what you would do?
If I find myself there more, I'd be inclined to send him something.
As to its effects, I think he'd prefer to drive off any and every reader who is offended by the ask. They are just costing him bandwidth with zero chance of any return. Maybe they share it with someone who ends up donating, but people who actually donate are much more inclined to be good sources of referrals to other people who may donate.
As to whether it equates to posting a link to an ad or promotion, I really don't think it crosses the line. This isn't one of those informercial sites that lead you on for an eternity without ever providing anything of substance. Instead this is just an interstitial on steroids meant to drive off undesirable traffic. It's 1000 times better than annoying ads and/or anti-blocking measures, imo.
110+ characters per line is hard to read and ugly [1].
Pure black on white has been discussed many times. While it satisfies min contrast requirements, it feels unnatural, and again, hard to read, causing eye strain [2][3]. Although this is not an issue on screens with automatic brightness adjustment, they are sadly not everywhere and it is wiser to target an average screen considering Mozilla auditory.
[1] http://practicaltypography.com/line-length.html [2] http://ianstormtaylor.com/design-tip-never-use-black/ [3] https://ux.stackexchange.com/questions/23965/is-there-a-prob...