It may be new but it is not a well-thought design.
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.
> 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…
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.
I would prefer if the background color were something other than pure white, though, or even better, if a night mode (light on dark) toggle were offered. Staring at large expanses of white is uncomfortable for my eyes.
That's exactly what I do on my personal website. At the bottom of every page is a button which inverts the color scheme to white text and black background.[1] It sets a cookie, so the setting should persist across all pages.
>> Pure black on white has been discussed many times
>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.
Thanks for the feedback! So, one thing we are doing differently this time around is updating the site incrementally instead of a big bang redesign. In the case of the article pages that means limited changes in the first phase to get them to conform to the new brand identity. The number of characters per line is an issue though. As stated in the blog post, we'll address the article page layout in the next phase. Article pages are where MDN users spend most of their time, we want to make sure we get those right, so we are setting aside time to focus on just them.
> 110+ characters per line is hard to read and ugly [1].
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.
> It may be new but it is not a well-thought design. 110+ characters per line is hard to read and ugly
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"
I was checking the blog page which has adopted the new design. MDN pages are already responsive but the line length goes far beyond that figure in some sections. The screenshot is at reduced window size.
I don't mean to be all, "ugh," but syntax should be at the top. Looking at that shot, as opposed to the one in the blog post, it will be common for syntax sections to fall off the bottom of the screen, "below the fold." This will make it less useful than sites that don't require the user to scroll to get the most basic information, such as method signatures, and MDN will continue to be a second choice.
OK, that all got a little sharp, but I do wonder what "design language" (per the blog post) is steering their information design.
I agree, but I don't think going through and reworking any actual content of the articles (these are all essentially wiki pages) is in scope for this stage of the redesign. 'atopal mentioned elsewhere in this thread [0] that they're doing this incrementally, and the next phase will be dedicated to article page layout.
You might want to mention this on the accompanying Discourse feedback thread [1] so it's noted for the next phase.
Is putting adds in hacker news comments allowed? That practicaltypography link leads to http://practicaltypography.com/graylist.html, has no content and asks to pay for something.
You got me curious enough to check it out. Ad or not, that is one of most incredible sites I've seen with deep resources that are very valuable. I learned a lot in the 20 minutes there. The 'interstitial' is just that -- a plea for donations to support the writer and hosting for an ad-free (it's ad-free for everyone, not just donors), high-quality resource. I had to read the page 3 times before I picked up on the instruction to input the root URL into the address bar, instead of being linked there. Haven't looked at the code, but is he just looking at referrers and dynamically routing based on being on his "graylist"?
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.
There could be valuable content there, but I will newer know that because I followed a link in comment, but all I got is an ad asking me to pay for something.
Wow. I wonder if that page actually has the intended overall effect. I've never seen this site before, but the actual content seems useful and (perhaps unsurprisingly) well presented. That said, hijacking me to another page to condescendingly nag me (and not even including a link back to the content I was originally linked to) really puts me off. I really think that the kind of people the author claims to want money from would be better reached by simply making it easy to donate.
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...