Help us test MDN's new React Front-End Beta

First, @caseymetz, welcome! Second – I see what you’re referring to. In general, I think we are doing some odd things with focus boxes in this beta that didn’t happen on the old site and do not look good.

Another example, in Firefox, is when we highlight the arrow widgets in the compatibility table when a browser has footnotes associated with it. On the old site, after clicking the widget, you see this:

old-site

On the new site, in the same Firefox browser, you get:

new-site

This is not attractive at all (and less so when you move the mouse and the box un-highlights, leaving just the blue outline (which is terribly lopsided when the notes are visible). In addition, the new site is using this shade of blue that matches the default Mac highlight color, despite the fact that my Mac is configured with purple as the highlight color.

I much prefer the old style, which highlights just using black, and doesn’t draw a big outline around the widget. The old style does draw a simple, subtle dotted line right around the very edge of the black box, but otherwise that’s it.

That said, I do like that the triangle widget reorients to point the opposite direction when clicked. It would be even nicer if it animated a rotation while opening, but that’s a nitpick compared the issue I take with the highlight color and the focus ring.

Thanks, Fernando. That may help track down the issue. Sounds like it’s some kind of weird regional thing coming into play.

1 Like

As others have stated we seem to have a problem reaching the http://beta.developer.mozilla.org/ URL from outside the USA.

I’m able to access it without issue when using Tor with an exit node in the US.

Yesterday as soon as the post went live I was able to access Beta MDN from here in Germany without an issue.

However, as the others mentioned it seems we’re having connectivity issues for those of us outside the US.

> traceroute -d http://beta.developer.mozilla.org/
> traceroute: unknown host http://beta.developer.mozilla.org/

> ping http://beta.developer.mozilla.org/
> ping: cannot resolve http://beta.developer.mozilla.org/: Unknown host

Hi all,
I can access beta.developer.mozilla.org from France on Firefox 68. I cannot access wiki.developer.mozilla.org, I get a message that the connection has timed out.
I checked the B2GOS pages and they do not appear with the orange “archive” background which they do on the current website. I presume this is not intentional and that the orange background should still be present?
Cheers :slight_smile:

Same here, from Japan. I can see beta.developer.mozilla.org but wiki.develper.mozilla.org doesn’t load on browser and end up with timeout.
host command ( for DNS query) showed me beta.developer.mozilla.org resolved to d1avawhiqh9uo1.cloudfront.net, and wiki.developer.mozilla.org to somewhere on .us-west-2.elb.amazonaws.com.

Technical question regarding the UX for authors:

Is it possible to serve both pages under the same domain and distinguish which one to show based on whether the user is logged in or not?
That would avoid any UX issues resulting from serving them from different domains, e.g. having to click twice to start editing an article or access the article’s history.

I guess that should be possible by checking the session cookie in a rewrite condition and serve from the different vhost based on that. (Stack Overflow answer regarding how this can be done in Apache.)

And sorry for coming up with that question about basic functionality so late in the process!

Sebastian

Disclaimer: I’m not involved in the site development, but I can answer this question anyway.

Is it possible to serve both pages under the same domain

You could try to do that, but things would get ugly pretty fast. The issue is, only the logged-out reading UI is updated right now (the logged-in contributor UI is staying the same for the foreseeable future). So it would not be a temporary inconvenience, but rather constant maintenance headache. The problem is, they use entirely different frameworks (jQuery vs React) so to serve both from the same domain, one would have to make sure to clear the browser cache based on logged-in/logged-out state. Probably, disabling cache altogether is not an option. That seems cumbersome and error-prone and likely not worth the hassle.

That would avoid … e.g. having to click twice to start editing an article or access the article’s history.

I think this is easier to solve by adding a simple check to the redesigned reader mode: on page load check whether the user has a logged-in cookie and if so, redirect to the old editor website.

(Stack Overflow answer regarding how this can be done in Apache.)

I think they use meinheld because the redesign site sends response header

server: meinheld/0.6.1

1 Like

Don’t use the URL. Use the domain:

▶ traceroute -d beta.developer.mozilla.org
traceroute: Warning: beta.developer.mozilla.org has multiple addresses; using 99.84.216.63
traceroute to d1avawhiqh9uo1.cloudfront.net (99.84.216.63), 64 hops max, 52 byte packets
 1  192.168.1.254 (192.168.1.254)  0.414 ms  0.149 ms  0.143 ms
 2  75-40-88-1.lightspeed.chtnsc.sbcglobal.net (75.40.88.1)  1.440 ms  0.992 ms  1.310 ms
 3  99.94.0.114 (99.94.0.114)  1.620 ms  1.421 ms  1.592 ms
^C

▶ ping beta.developer.mozilla.org
PING d1avawhiqh9uo1.cloudfront.net (99.84.216.63): 56 data bytes
64 bytes from 99.84.216.63: icmp_seq=0 ttl=240 time=25.759 ms

I think it could be possible. Mind you, we’re using AWS CloudFront but I supposed it would technically be possible to have dynamically redirects based on cookies. But it all feels pretty fragile. Probably best to keep it explicit and simple.
A possible bad side-effect is if you’re in the wiki to editing (“wearing the wiki hat”) but then you open the read-only site in another tab to see it “as non-editors would see it”. If that’s the case, it would keep redirecting you back to the wiki site.

1 Like

I can’t reproduce this. Do you maybe have a link to a page where you are seeing this?

Hey Takeshi, would you mind trying it again? We made some changes we think should fix this.

Hi Kadir,
Now Firefox loads both pages and I can see beta.developer.mozilla.org and wiki.developer.mozilla.org .

I can login to wiki.developer.mozilla.org while I can’t login to beta.developer.mozilla.org from the link placed upper right corner of top page: https://beta.developer.mozilla.org/users/github/login/?next=/ja/ .

BTW, is the login link necessary on beta.developer.mozilla.org? Beta is for viewing.

Thanks for the quick feedback Takeshi! Can you tell me what happens when you click the login button on beta.developer.mozilla.org?

Login is not necessary to view the beta page. We will offer additional features for logged in users later though.

After I click login link on the beta site, https://beta.developer.mozilla.org/ja/ , browser seems to be loading some page, but 2 or 3 seconds later it eventually comes to same page.

The URL Transition took by Network Monitor is as following image:

I expect that whoever made the top navbar in https://beta.developer.mozilla.org was probably some junior software engineer, because it’s definitely not the quality I would expect for a site aimed at providing frontend guides and resources. I mean that search input is just terrible, and that login link and those dropdowns. I’d expect the quality to be nothing short of exemplary.

How will these benefits be felt?
What tangible aspects of this conversion are aimed at users explicitly?

1 Like

I don’t get it either.
Why do you make a new front-end to a totally fine site?

1 Like

In the past, logging in to MDN meant that all further requests would bypass the CDN for documents. That’s not necessarily so bad for people living close to our servers in Portland, but would be a severe degradation of performance for people living further away. With this change, we can offer features that will require users to login without degrading their user experience.

One example of such a feature is a browser compatibility banner on top of the page that shows you compat info for the browsers you have to support. In the past, we wouldn’t have been able to cache those pages, since they’d be specific to each logged-in user, even though only a small part of the page is customized. With the new front end, we can have the documents on the CDN – same for everyone – and insert the features that are unique to any given user.

1 Like

as a heavy user of mdn, thats nothing i would ever request, desire, or think of.
how many requests for that did you all receive?

in doing so you’ve upped the barriers of entry for new users.
the difference in trade-offs seems incredibly contrary to mozilla’s mission.

Hmm, I don’t think I understand what the upped barrier is referring to. Would you mind expanding on that?

1 Like

using react is not as easy as editing plain web platform documents.
moreover, check out these screenshots of users who you claim to be supporting, not liking this at all