
MDN’s new design is in Beta - omnifischer
https://blog.mozilla.org/opendesign/mdns-new-design-beta/
======
vladdanilov
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.

[1] [http://practicaltypography.com/line-
length.html](http://practicaltypography.com/line-length.html) [2]
[http://ianstormtaylor.com/design-tip-never-use-
black/](http://ianstormtaylor.com/design-tip-never-use-black/) [3]
[https://ux.stackexchange.com/questions/23965/is-there-a-
prob...](https://ux.stackexchange.com/questions/23965/is-there-a-problem-with-
using-black-text-on-white-backgrounds)

~~~
MikusR
Is putting adds in hacker news comments allowed? That practicaltypography link
leads to
[http://practicaltypography.com/graylist.html](http://practicaltypography.com/graylist.html),
has no content and asks to pay for something.

~~~
ballenf
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.

~~~
MikusR
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.

------
Aardwolf
Happy to see the new design looks similar to the old design, not an
experimental new UI that removes half the information or puts everything
behind things you need to expand or similar!

I always favor MDN over w3schools results when searching for a javascript,
HTML, DOM or CSS property :)

~~~
Semaphor
I love mdn. The old design was great and the new looks even better. There is
no documentation I've ever seen that's better it clearer.

~~~
scriptkiddy
> There is no documentation I've ever seen that's better it clearer.

You should check out Django's documentation:
[https://docs.djangoproject.com/en/1.11/](https://docs.djangoproject.com/en/1.11/)

In my opinion, it is the gold standard.

------
majewsky
I like how they're using the logo font for the headlines. As someone who
already knows the new logo, this helps me connect MDN to the Mozilla brand
more intuitively.

However, I'm just as concerned about the huge font sizes and high font weight
as the majority here. It really distracts from the actual content.

~~~
mintplant
The font is Zilla Slab:
[https://fonts.google.com/specimen/Zilla+Slab](https://fonts.google.com/specimen/Zilla+Slab)

In the "highlight bold" variant, if you type out "mozilla" it becomes the new
wordmark: [https://ffp4g1ylyit3jdyti1hqcvtb-wpengine.netdna-
ssl.com/ope...](https://ffp4g1ylyit3jdyti1hqcvtb-wpengine.netdna-
ssl.com/opendesign/files/2017/07/Logo_Animation.gif)

~~~
dlbucci
You know I saw that font last night near the top of google fonts and didn't
realize it was short for Mozilla. I generally prefer sans-serif fonts, but I
really like the Regular variant!

------
mintplant
There's an official thread for feedback over on the Mozilla Discourse:
[https://discourse.mozilla-community.org/t/beta-redesign-
feed...](https://discourse.mozilla-community.org/t/beta-redesign-
feedback/16544/21)

I've posted the link to this thread over there along with a couple main points
from the comments here so far, but if you really want to make sure your input
is heard, you might want to hop on over there to give it. You can log in with
a GitHub or Google account if you don't feel like signing up with your email.

------
greggman
That giant font works for Array.prototype.slice but what about
CanvasRenderingContext2D.prototype.createRadialGradient or
WebGL2RenderingContext.prototype.getActiveUniformBlockParameter?

~~~
MikusR
The WebGL2RenderingContext.getActiveUniformBlockParameter() fits
[https://pageshot.net/1pwSmFUZ4hnNcHlJ/developer.mozilla.org](https://pageshot.net/1pwSmFUZ4hnNcHlJ/developer.mozilla.org)

~~~
greggman
that's inconsistent with the other Array docs. The correct function is
WebGL2RenderingContext.prototype.getActiveUniformBlockParameter() if you're
trying to be consistent

~~~
carussell
Array.prototype.slice is specced out by the JS standard.
getActiveUniformBlockParameter is part of the DOM. The DOM is specced in terms
of interfaces—the only thing that the DOM guarantees is that when you're
interacting with an object that satisfies the interface, it will have a
getActiveUniformBlockParameter method.
WebGL2RenderingContext.prototype.getActiveUniformBlockParameter is a JS-ism
and isn't essential to the implementation of the spec.

~~~
greggman
what? it's required that setting
WebGL2RenderingContext.prototype.getActiveUniformBlockParameter to some other
function work. You set it before object creation. Objects created indirectly
get the new functionality through their prototype. This is true for all DOM
objects. maybe I don't understand your distinction

~~~
carussell
> Objects created indirectly get the new functionality through their prototype

Except most parts of the DOM in most engines is implemented in C++, not JS.

<whatever>.prototype is a JS-ism. But the DOM is not defined in terms of JS.
It's defined in terms of a language-agnostic set of interfaces. So when poking
around and seeing things like NodeIterator.prototype within JS, you're seeing
them because the browser is presenting it to you in a way that kind of
resembles the way things work for that runtime. <whatever>.prototype (when
<whatever> is some DOM interface) is a byproduct of that behavior. But that
those interfaces get implemented is the only essential characteristic of the
DOM, and the docs should reflect those interfaces, not the weird and
tangential byproducts of how the DOM gets projected into a JS runtime.

~~~
greggman
I'm not understanding the distinction from a JS programmer's perspective.

If I have

    
    
        a = {}
        a.foo = () => ();
    

foo is a member of a.

Where as if I have

    
    
        class A {
          foo() {}
        }
        a = new A();
    

foo is a member of the prototype for class A. This is important because I need
to know if replacing A.prototype.foo will effect all new As or none.
Documenting the function is defined on the prototype tells me this. So, I need
both Array.prototype.slice and WebGL2RenderingContext.prototype.
getActiveUniformBlockParameter documented the same.

If WebGL2RenderingContext.prototype.getActiveUniformBlockParameter is only
documented as WebGL2RenderingContext.getActiveUniformBlockParameter that
suggests to me that I can't do this

    
    
        WebGL2RenderingContext.prototype. 
        getActiveUniformBlockParameter = someNewFunc
        gl = someCanvas.getContext("webgl2")
    

Instead I must do this

    
    
        gl = someCanvas.getContext("webgl2")
        gl.getActiveUniformBlockParameter = someNewFunc
    

The first is far more useful because I can effect it indirectly. The second
requires me to modified code at creation, code that might be in a 3rd party
library.

So, if .prototype. is left out of the docs for
WebGL2RenderingContext.prototype.getActiveUniformBlockParameter that suggests
to me I can't do the first. Seems like those 2 things Array.prototype.slice
and WebGL2RenderingContext.prototype.getActiveUniformBlockParameter should be
documented consistently. In other words, a JS programmer does not care about
implementation details. They don't care one object is a DOM element vs a JS
Object (at least not in this case). They care how they can use it in a
program. To do that they need to know is the function on the prototype or on
the object itself and documenting as Class.prototype.func tells them that.

~~~
carussell
> foo is a member of a [...] foo is a member of the prototype for class A
> [...] they need to know is the function on the prototype or on the object
> itself and documenting as Class.prototype.func tells them that

I know how prototypes work, and I know why the `Array.prototype.slice` are
documented that way, because I wrote those docs—and caught a bunch of flak
along the way when making the move away from referring those and other methods
in the form `Array.slice`—in 2007.

It's hard to address the issue using your specific example, because it's so
contrived. (Who is replacing native implementations [don't], and why? [Once
again: don't.]) Here's the _actual_ motivating factor for why you see stuff
like `Array.prototype.slice` documented that way:

There are methods `fromCharCode` and `charCodeAt`. However, you call the
former as `String.fromCharCode` and the latter as `x.charCodeAt`, where `x` is
some string instance. That's an important distinction, which means it's
important that we not refer to them as `String.fromCharCode` and
`String.charCodeAt`. The former is a real method that actually existed, and
the latter is something that doesn't exist Which means if we tell readers "Use
`String.charCodeAt`", then what we're doing is giving readers bad, confusing,
and possibly frustrating information—not what you want when your goal is to be
explaining things to an already unsure or simply ignorant audience. This
distinction only became more important with ES5, since it started adding
things like `Object.keys` and `Object.defineOwnProperty`, rather than making
those methods available to all instances by adding them to the prototype.

But this is all besides the point, because we're talking about the DOM here.

> I'm not understanding the distinction from a JS programmer's perspective

That's the problem. Because what we're discussing is a reference for people
using the DOM, and once again your changes would force a bunch of JS-isms into
the scope of the documentation, and not only that, but a bunch of shaky, not-
at-all-well-understood-or-agreed-upon, cobweb-covered parts of how the
underlying objects get projected into JS.

> In other words, a JS programmer does not care about implementation details.

You understand that the thing you're asking for are that implementation
details surface through the docs, right? And that they should be a prominent
feature? That's what you're asking for.

------
bluedino
>> For MDN that means bold typography that highlights the structure of the
page, more contrast, and a reduction to the essentials.

And less actual content, forcing you to scroll or zoom out.

~~~
endemic
The layout in the screenshot looks pretty similar to what's already there...
just the header branding and a few fonts are different.

Comparison: [http://imgur.com/a/81cYg](http://imgur.com/a/81cYg)

~~~
jypepin
your image shows that almost half of the page content is under the fold.

~~~
debaserab2
So what? Is scrolling really that big of a deal?

The increased font size and more pronounced page hierarchy make it easier for
me to grok the page structure at a glance and navigate to the section I need
(since I'm probably not reading the entire page front to bottom if I'm at an
MDN link).

Why does all information need to be above the fold? It's not like I can
interpret everything on the page in the 1000ms necessary it would take me to
scroll.

~~~
teacup50
> _So what? Is scrolling really that big of a deal?_

Yes.

~~~
debaserab2
How?

~~~
teacup50
Cognitive load of paging.

This is not a new and unexplored concept.

~~~
debaserab2
I call B.S. --

Below the fold arguments only make sense when you can't grasp the purpose of
the page without scrolling.

You're not supposed to cram every piece of information you can above the fold.
The information that is getting cut off in this case is hardly pertinent to
the understanding or navigation of the site.

------
tonyhb
The bold headline steals attention away from the copy; it makes it much harder
to focus on the actual content.

IMO they could try making the bold header a lighter shade to stop stealing
focus. I much prefer the older one for readability.

------
randomfool
Unrelated to the design, it irks me to no end that MDN's top search result for
'Array' is [https://developer.mozilla.org/en-
US/docs/Glossary/array](https://developer.mozilla.org/en-
US/docs/Glossary/array) when the second result is so much better.

At least the ES6 Map has finally usurped the antiquated <map> as the top 'Map'
result :)

------
pbreit
I like the " reduction to the essentials". Not sure about the "high contrast".

------
Animats
That's not the problem with MDN. MDN's big problem has been a confusion of
out-of-date versions of documentation. It doesn't help that they've tried hard
to get developers to use Mozilla technologies, from Jetpack to Firefox OS,
which were then abandoned.

Firefox's drop to 15% market share has a big effect on developers. I've
watched my add-on usage drop in lockstep with Firefox's market decline.

~~~
mintplant
This is addressed in the previous post in the series [0], linked at the top of
this one. MDN is refocusing on exclusively providing solid, up-to-date web
documentation, and all the old, obsolete, and Mozilla-internal stuff will be
trimmed away or moved elsewhere.

[0] [https://blog.mozilla.org/opendesign/future-mdn-focus-web-
doc...](https://blog.mozilla.org/opendesign/future-mdn-focus-web-docs/)

------
jypepin
Those bold fonts and titles with black background are not working for me :\
Hopefully i'll get used to them.

~~~
tracker1
I don't mind the fonts nearly as much as the size seems about 150% of the size
it should be for the title and about 130% on the syntax... should reduce them
down a little.

------
microcolonel
I wish they would stop and reverse Mozilla Open Design. In my opinion it has
made all of their design worse and uglier and probably cost them money.

MDN looked and felt great to browse before, now the headline is absurdly
misproportioned and in the wrong place (not in the text column).

------
emilfihlman
A bad update, actually decreases value because of having to scroll about
constantly.

------
hajile
That logo in the upper left needs some padding love. It looks like someone
just found out about CSS background-color. A few pixels of padding would go a
long way.

------
johansch
There is such a thing as a too big font. I think it happens when you feel like
you physically have to move back from the screen to comfortably read the text.

------
MikusR
While this new design looks good for documentation, it's also used on Firefox
homepage where it makes it look like one of those domain squatter sites.

------
cosinetau
Thank you Mozilla!

------
kuschku
> \- Too much contrast? Reduce screen brightness. (This has the beneficial
> side effect of increasing battery life on mobile devices.)

So, I have to make the rest of my UI unreadable, just because you prefer to
use a cheap chinese 20$ screen which can’t even handle sRGB?

~~~
pikzen
What a genius idea, design only for people with expensive screens, make
software only people with a dual Xeon and a GTX1080 can run, and be sure to
make the minimum resolution 2560*1900. You're sure to make friends.

Welcome to reality, most people use cheap $20 chinese screens.

~~~
kuschku
And so the solution is to create content for people on 320x480 pixel screens
with no contrast? No.

We should try and create the content in the best possible formats, with the
highest available standards, and then the user agent, acting on behalf of the
user, should scale that to the user’s current system, increasing or decreasing
the contrast.

