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

We need your help!

MDN is changing. For a long time MDN has been the same experience for everyone, but developers aren’t all the same and we want MDN to adjust to our users. Over the last few months we’ve been working hard to implement a new MDN frontend to offer people a customized MDN experience while still providing a fast page load time, whether people are logged in or not. Our previous implementation wasn’t able to support that and had dependencies on some rather old jQuery and jQuery UI versions.

MDN supports two modes: editing and viewing. Almost all users of MDN use the viewing mode, only a small fraction use the editing mode. As part of this rewrite we broke those two use cases into different domains. The editing is now done on wiki.developer.mozilla.org the viewing on beta.developer.mozilla.org.

The biggest benefit of a new frontend will be felt by end users, so that’s where we focused our efforts. Once our testing is complete, we’ll decommission beta.developer.mozilla.org and have everyone use the new frontend. The editing on the other hand will continue to be served by the old frontend on wiki.developer.mozilla.org.

Now we need your help to make sure our new front-end is ready to be turned on for all users. Please change your bookmarks and start using beta.developer.mozilla.org as your daily reference and guide page and report any issue that you notice.

You can file a bug, reply to this post, or message me on Twitter. We’ll triage bugs daily during our beta phase.

Many thanks!
Kadir

8 Likes

Hi, on this page the custom properties syntax colour is does not make the code sample easy to read:
image

Hello @virtualsoup, it seems to me that I get the same result when I read the page from the “production”/non-beta site: https://developer.mozilla.org/en-US/docs/Web/CSS/--*#Syntax

Thus, I’d say it’s not strictly related to the beta.
That being written, you still can file a bug in this regard.

1 Like

The wiki page is not working as of when I’m making this comment, so I cannot review it.

The beta link is okay, page loading is okay too. Since the layout is almost similar, I think it will provide a great user experience as always.
Looking forward to the stable release

Brian, you said the wiki page is not working. Can you tell me a bit more about that? Does it not load at all, or is some functionality broken?

It is not loading at all

Hmm, that’s odd. I can access it from multiple browsers here.

err-wikidev

I’m not sure where the problem might be then.

Below are my connection details:
Region: Africa- Kenya
ISP: Safaricom
Browser Chromium Version 75.0.3770.100 (Official Build) Built on Ubuntu , running on Ubuntu 19.04 (64-bit)

The last connection attempt (from 3 mins agon) is still just loading…

Same for me. Wiki page does not work.

I tried to log into the new MDN via GitHub, and received an internal server error after the OAuth flow redirected back to the Beta site.

Where are you located, Fernando?

Tiny thing: On latest Chrome, the focus state (looks like maybe the browser default styles?) on these menu items is getting cut off a little bit:

San Salvador, El Salvador. I’m using Firefox 68.0

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