Closed Bug 1561020 Opened 5 years ago Closed 4 years ago

Tracker for bugs and suggestions for beta.developer.mozilla.org

Categories

(developer.mozilla.org Graveyard :: General, task)

Product:
developer.mozilla.org Graveyard
Component:
General
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: dflanagan+bugzilla, Assigned: espressive)

References

Details

(Keywords: in-triage)

MDN Beta Feedback

We are beta testing a new version of MDN on https://beta.developer.mozilla.org

If you've found a bug or have other feedback about the site, please leave a
comment here. Or, file a new bug and link it to this one.

Assignee: nobody → djf
Depends on: 1561054
Depends on: 1561031
Depends on: 1561033
Depends on: 1561034
Depends on: 1561035
Depends on: 1561037
Depends on: 1561081
Depends on: 1561975

We should try to preserve scroll position for client-side navigation. When the user goes back to a page, they should see the same part they were seeing before.

Filed bug 1562271 for this

Make sure we are compatible with google translate
Filed bug 1562293 for this.

Consider delaying the start of the load progress indicator for 100ms
I'm not filing a bug for this one, but see https://github.com/mozilla/kuma/pull/5528

Depends on: 1562271
Depends on: 1562293
Depends on: 1562807
Depends on: 1562853
Depends on: 1562858
Depends on: 1562861
Depends on: 1563210
Depends on: 1563256
Depends on: 1563461
Depends on: 1563464
Depends on: 1563466
Depends on: 1563467
Depends on: 1563468
Depends on: 1563469
Depends on: 1563471
Depends on: 1563473
Depends on: 1563476
Depends on: 1563478
Depends on: 1563481
Depends on: 1563511
Keywords: in-triage
Depends on: 1564836
Depends on: 1565618
Depends on: 1565639
Depends on: 1551214
Depends on: 1566246

Schalk: I'm reassigning this to you, since you're working on many of these bugs and since you're been handling triage. (Sorry I didn't think to ask for your permission first!)

Assignee: dflanagan+bugzilla → schalk.neethling.bugs

this is probably not on the table, but for good sake make the links shorter.
here is a current example:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/filter

it can be marginally shortened like this currently:

https://developer.mozilla.org/JavaScript/Reference/Global_Objects/Array/filter

but I could see some further changes:

https://dev.mozilla.org/JavaScript/Array/filter

Depends on: 1566302
Depends on: 1566327
Depends on: 1566401
Depends on: 1566447
Depends on: 1566426

Hello,
when Javascript is disabled, the progress bar is shown and never disappears. It is quite distracting. I'd suggest creating the progress bar using Javascript so it never shows when Javascript is disabled.

Search does not work on Javascript. Other main features seem working, including when using Netsurf. Congratulations for that :-)

Depends on: 1566429
No longer depends on: 1566401
Depends on: 1566381

if the site continues to work without javascript, that is fine. If Javascript is a requirement for the site to function, that is HORRIBLE and this should be scrapped.

Slogan on https://wiki.developer.mozilla.org/pl/ is gender discrimination.
The slogan appeals to males and males only. It should be made gender-neutral.
This is the fault of the Polish translation. Unfortunately, I was unable to find a place to suggest an edit.

(In reply to michal from comment #9)

Slogan on https://wiki.developer.mozilla.org/pl/ is gender discrimination.
The slogan appeals to males and males only. It should be made gender-neutral.
This is the fault of the Polish translation. Unfortunately, I was unable to find a place to suggest an edit.

That phrase is maintained in Mozilla's Pontoon localization tool, here: https://pontoon.mozilla.org/pl/mdn/LC_MESSAGES/django.po/?search=developers&string=168368

It is not specific to the beta test, as it exists in the production site as well: https://developer.mozilla.org/pl/

Links to lists of tags do not resolve. See https://github.com/mdn/sprints/issues/1844
The reported case is an in-text link to "/en-US/docs/tag/Web". That page does not exist on beta.developer.mozilla.org. If tag lists are going to be implemented in the read-only site, then it will stop being a problem when the beta ends; if they are not, then they need to redirect to the wiki site.

A few accessibility related notes on the new header:

  • The navigation dropdowns do not seem to be toggleable via keyboard
  • The logo lacks focus styles
  • For the logo SVG, alt is not a valid attribute on SVG and it is set to aria-hidden, find another way to label it as right now it is being treated as an empty link. This article may be helpful

Thanks for the report, Nic! Some of these are already dealt with in dependent bugs. Schalk has been super thorough and found a few more even, like missing labels on the main page's inputs etc. Schalk, could you see if any of what Nic said in comment #12 haven't been filed yet?

Flags: needinfo?(schalk.neethling.bugs)

(In reply to Marco Zehe (:MarcoZ) from comment #13)

Thanks for the report, Nic! Some of these are already dealt with in dependent bugs. Schalk has been super thorough and found a few more even, like missing labels on the main page's inputs etc. Schalk, could you see if any of what Nic said in comment #12 haven't been filed yet?

Thanks Nic and Marco. The navigation is known, and I am working on it at the moment. This is the related bug https://bugzilla.mozilla.org/show_bug.cgi?id=1563467

Flags: needinfo?(schalk.neethling.bugs)

(In reply to Nic Chan from comment #12)

A few accessibility related notes on the new header:

  • The navigation dropdowns do not seem to be toggleable via keyboard
  • The logo lacks focus styles

I will address this one

  • For the logo SVG, alt is not a valid attribute on SVG and it is set to aria-hidden, find another way to label it as right now it is being treated as an empty link. This article may be helpful

This has been resolved but might still need to be pushed to production.

I had already reported with the previous version with no answer. The problem still persists: the access to Mozilla dev sites related is not allowed in many countries (In my case Cuba) due to unilateral (often illegal regarding international laws) American economical embargo on these countries. I am not here to talk politics but I find quite ironic that an entity claiming to protect the openness of the web arbitrary blocks users based on their location. I understand it is not easy to change hosting service for such an infrastructure and I can use a VPN, however I believe the symbol is very strong

I tried using the beta site on Firefox for Android. ("Fennec", I think. The one you get when you download the regular orange-and-blue Firefox app from the Play Store.) There are a couple minor issues with page navigation:

  • Using the browser's Back/Forward buttons results in an awkward "two-step" navigation. First, the page scrolls up or down to match the scroll position on the previous page. Then, the page's content is replaced.
  • Clicking on an external link then pressing Back scrolls you back up to the top of the page

Neither of these issues are present on non-beta MDN or other web pages, which makes me think that they're happing because beta MDN is reimplementing standard browser navigation features like links and history in JavaScript. You should probably update https://beta.developer.mozilla.org/en-US/docs/Web/HTML/Element/a with a deprecation warning of some kind -- that way, other web developers won't mistakenly rely on the default <a> tag for their intra-site navigation and run into the same problems that you did with it.

(In reply to Carter Sande from comment #17)

I tried using the beta site on Firefox for Android. ("Fennec", I think. The one you get when you download the regular orange-and-blue Firefox app from the Play Store.) There are a couple minor issues with page navigation:

  • Using the browser's Back/Forward buttons results in an awkward "two-step" navigation. First, the page scrolls up or down to match the scroll position on the previous page. Then, the page's content is replaced.
  • Clicking on an external link then pressing Back scrolls you back up to the top of the page

Neither of these issues are present on non-beta MDN or other web pages, which makes me think that they're happing because beta MDN is reimplementing standard browser navigation features like links and history in JavaScript.

Yes, we're using pushState to implement client-side navigation. Shame that it doesn't work great on Firefox for Android. I'll file a new bug based on your description.
It's not an excuse but the good news is that back and forth works great here on my iPhone XR iOS Safari (latest version). Perhaps my phone is "too fast" to notice.

I tried clicking back between beta.developer.mozilla.org pages and I also tried clicking an external link (The "Privacy" link in the footer) and then the back button took me back to where I was without a problem.

You should probably update https://beta.developer.mozilla.org/en-US/docs/Web/HTML/Element/a with a deprecation warning of some kind -- that way, other web developers won't mistakenly rely on the default <a> tag for their intra-site navigation and run into the same problems that you did with it.

I'm sorry but I don't understand that comment. Would you mind trying to rephrase yourself so my slow brain can understand the connection.

Depends on: 1566944

(In reply to Peter Bengtsson [:peterbe] from comment #18)

You should probably update https://beta.developer.mozilla.org/en-US/docs/Web/HTML/Element/a with a deprecation warning of some kind -- that way, other web developers won't mistakenly rely on the default <a> tag for their intra-site navigation and run into the same problems that you did with it.

I'm sorry but I don't understand that comment. Would you mind trying to rephrase yourself so my slow brain can understand the connection.

No worries! Sorry for being unclear.

The new version of MDN uses JavaScript pushState navigation instead of normal <a> tags. This is surprising to me, because I thought the standard <a> tag was the best way to let users move from page to page on a website, and JavaScript navigation is usually kind of hard to implement, doesn't handle edge cases (e.g. really slow connections) very well, doesn't integrate with browser chrome loading UI, etc. But MDN probably knows better than me because you're, like, the foremost authority on web standards. So you should update the page about the <a> tag with information about why the <a> tag doesn't work well enough for the MDN website, and provide recommendations about the JavaScript we should be using instead.

(In reply to Carter Sande from comment #19)

(In reply to Peter Bengtsson [:peterbe] from comment #18)

You should probably update https://beta.developer.mozilla.org/en-US/docs/Web/HTML/Element/a with a deprecation warning of some kind -- that way, other web developers won't mistakenly rely on the default <a> tag for their intra-site navigation and run into the same problems that you did with it.

I'm sorry but I don't understand that comment. Would you mind trying to rephrase yourself so my slow brain can understand the connection.

No worries! Sorry for being unclear.

The new version of MDN uses JavaScript pushState navigation instead of normal <a> tags. This is surprising to me, because I thought the standard <a> tag was the best way to let users move from page to page on a website, and JavaScript navigation is usually kind of hard to implement, doesn't handle edge cases (e.g. really slow connections) very well, doesn't integrate with browser chrome loading UI, etc. But MDN probably knows better than me because you're, like, the foremost authority on web standards. So you should update the page about the <a> tag with information about why the <a> tag doesn't work well enough for the MDN website, and provide recommendations about the JavaScript we should be using instead.

Hey Carter,

We still use anchor(<a>) links on the MDN Web Docs Beta but, those elements' default behavior is intercepted by React[1] allowing us to do client-side navigation[2]. What I mean by that is, instead of doing normal browser navigation that involves requesting a new URL from the server and then reloading the entirety of the new page, we get a JSON response from the server that contains only the new main content of the document. Using JavaScript, we then replace the current content with the new content without reloading the entire page.

This makes transitions between pages on MDN much faster but, this by itself breaks the browsers back and forward button behavior, which is bad (we should not break the web and user expectation). We, therefore, combine this with pushState[3], to ensure that we keep the browser history in sync with our client-side navigation. This then gives our users the best of both worlds. Quicker page loads, and back/forward browser buttons that still works.

The good old anchor(<a>) tag is still the basis and workhorse of the web, and should never be abandoned ;) Thank you for your bug report and I hope this helps explain our use of this element. Please also find links below for further reading on the above topics.

[1] https://reactjs.org/
[2] https://medium.com/@marcellamaki/a-brief-overview-of-react-router-and-client-side-routing-70eb420e8cde
[3] https://developer.mozilla.org/en-US/docs/Web/API/History_API

Depends on: 1567193
Depends on: 1567195
Depends on: 1567218
No longer depends on: 1564836
Depends on: 1567470
Depends on: 1567482
Depends on: 1567720

I started using the beta today and found it performs considerably better when scripts are disabled (I installed noscript to test this). You may want to consider using react only for SSR, and letting the client experience just be normal HTML.

(In reply to Schalk Neethling [:espressive] from comment #20)

instead of doing normal browser navigation that involves requesting a new URL from the server and then reloading the entirety of the new page, we get a JSON response from the server that contains only the new main content of the document. Using JavaScript, we then replace the current content with the new content without reloading the entire page.

This makes transitions between pages on MDN much faster (...)

Hi Schalk,
Could you please point me to the performance test methodology and results that confirmed the page transitions are faster? Some users report that it actually slows page rendering down for them, so I would like to make sure this was properly tested.

Also, if there is any document where the need for client-side navigation on MDN website was discussed, it would be great if you could send it my way.

Thanks,
Tom

Flags: needinfo?(schalk.neethling.bugs)

(In reply to Tom Grabowski [:TomGrab] from comment #22)

(In reply to Schalk Neethling [:espressive] from comment #20)

instead of doing normal browser navigation that involves requesting a new URL from the server and then reloading the entirety of the new page, we get a JSON response from the server that contains only the new main content of the document. Using JavaScript, we then replace the current content with the new content without reloading the entire page.

This makes transitions between pages on MDN much faster (...)

Hi Schalk,
Could you please point me to the performance test methodology and results that confirmed the page transitions are faster? Some users report that it actually slows page rendering down for them, so I would like to make sure this was properly tested.

Also, if there is any document where the need for client-side navigation on MDN website was discussed, it would be great if you could send it my way.

Thanks,
Tom

Hello,

One document discussing the lack of need for client-side navigation can be found at https://carter.sande.duodecima.technology/javascript-page-navigation.

I don't know what the intended supported browser versions are, but on iOS 10.3 Safari, the entire browser hangs for 10-20 seconds when navigating from https://beta.developer.mozilla.org/en-US/docs/Web/API/Element to HTMLElement. I've never seen this browser hang like that before.

(In reply to Tom Grabowski [:TomGrab] from comment #22)

(In reply to Schalk Neethling [:espressive] from comment #20)
Hi Schalk,
Could you please point me to the performance test methodology and results that confirmed the page transitions are faster? Some users report that it actually slows page rendering down for them, so I would like to make sure this was properly tested.

We use Speedcurve to measure the impact of changes in synthetic testing. We have number of metrics and a KPI [0] we monitor for that. Measuring that for the first page load didn't show any degradation [0]. We extended that measurement to client side navigation and testing indicated much better performance [1]. We might want to look into that again though, to make sure we didn't miss anything.

Also, if there is any document where the need for client-side navigation on MDN website was discussed, it would be great if you could send it my way.

Unfortunately this is not documented. It was assumed we could get it as an almost free feature of the frontend change. We've already been working through a few issues related to that and we'll have to reassess the costs and benefits before a final launch.

[0] https://github.com/mdn/mdn-fiori/wiki
[1] https://github.com/mdn/sprints/issues/1419
[2] https://github.com/mdn/sprints/issues/1703

(In reply to Gus Caplan from comment #21)

I started using the beta today and found it performs considerably better when scripts are disabled (I installed noscript to test this). You may want to consider using react only for SSR, and letting the client experience just be normal HTML.

That's a really useful comment. Thank you.
Mind you, this topic might be more complicated than it seems. It's very possible that there are some other scripts that block rendering when it shouldn't. And this wouldn't be a fair thing to redirect the attention to the React bundle on.
Ideally, we're trying to make the pages are useful as possible and ideally, the pages should load just fine without JS but without some "bells and whistles".

Keep an eye out. Just last week we managed to isolate a script tag that rather unfairly was blocking rendering and we managed to turn it into an async one. We're trying to work hard on this and the improvements will be trickling in.

(In reply to Kadir Topal [:atopal] from comment #25)

We use Speedcurve to measure the impact of changes in synthetic testing. We have number of metrics and a KPI [0] we monitor for that. Measuring that for the first page load didn't show any degradation [0]. We extended that measurement to client side navigation and testing indicated much better performance [1]. We might want to look into that again though, to make sure we didn't miss anything.

Thank you Kadir. It's great to see that you keep measuring the performance. I took a look at some of the details there. My only question is wheter you do any tests with network speed throttling enabled? I saw CPU throttling mentioned there, but I have not seen anything about bandwidth throttling.
I did a few bandwidth throttling tests myself, and on those pages I tested, client-side navigation was a bit faster, which is an encouraging sign. That seemed to be mostly because the browser had to load less data. But I'm not sure if that's the case for all links there, and I only tested with Firefox. Other browsers might behave differently. So if you are not doing any tests with throttled bandwidth, this could be one area to look into.

Flags: needinfo?(schalk.neethling.bugs)
Depends on: 1568040
Depends on: 1568146

(In reply to Tom Grabowski [:TomGrab] from comment #27)

(In reply to Kadir Topal [:atopal] from comment #25)

We use Speedcurve to measure the impact of changes in synthetic testing. We have number of metrics and a KPI [0] we monitor for that. Measuring that for the first page load didn't show any degradation [0]. We extended that measurement to client side navigation and testing indicated much better performance [1]. We might want to look into that again though, to make sure we didn't miss anything.

Thank you Kadir. It's great to see that you keep measuring the performance. I took a look at some of the details there. My only question is wheter you do any tests with network speed throttling enabled? I saw CPU throttling mentioned there, but I have not seen anything about bandwidth throttling.

Yeah, we are looking at CPU performance, because that's where we have seen issues in our measurements. All tests run with the CPU throttled 3x. Additionally, all tests are ran from India, since that's where we are slow and where the distance to our data center is the most obvious.

Re network speed: due to how people use MDN, 95% of our traffic is from desktop computers. Similarly, 95% of our users have a 4G connection or faster, 5% are on a 3G connection, and 0% are on slower connections. That's why we didn't specify network speeds in our KPI specifically.

Depends on: 1568254

(In reply to Kadir Topal [:atopal] from comment #28)

Re network speed: due to how people use MDN, 95% of our traffic is from desktop computers. Similarly, 95% of our users have a 4G connection or faster, 5% are on a 3G connection, and 0% are on slower connections. That's why we didn't specify network speeds in our KPI specifically.

Makes sense. Thank you.

Depends on: 1569167
Depends on: 1569794

A bug in the layout.
Page https://beta.developer.mozilla.org/ru/docs/Web/CSS/CSS_Grid_Layout/Box_Alignment_in_CSS_Grid_Layout
When window's width is from 750px to 765px, "nav.main-nav" and "titlebarContainer" overlap.

No content on page.
When I open https://beta.developer.mozilla.org/en-US/docs/Learn/HTML/Forms/Form_validation I briefly see its content but then it disappears.

(In reply to alejo.elnorte from comment #30)

A bug in the layout.
Page https://beta.developer.mozilla.org/ru/docs/Web/CSS/CSS_Grid_Layout/Box_Alignment_in_CSS_Grid_Layout
When window's width is from 750px to 765px, "nav.main-nav" and "titlebarContainer" overlap.

Thank you for reporting dtalanina, we will look into this.

(In reply to dtalanina from comment #31)

No content on page.
When I open https://beta.developer.mozilla.org/en-US/docs/Learn/HTML/Forms/Form_validation I briefly see its content but then it disappears.

Thank you for reporting. Which browser did this happen in? Are you able to consistently reproduce it on this page? Have you seen it happen on any other pages?

(In reply to Schalk Neethling [:espressive] from comment #33)

(In reply to dtalanina from comment #31)

No content on page.
When I open https://beta.developer.mozilla.org/en-US/docs/Learn/HTML/Forms/Form_validation I briefly see its content but then it disappears.

Thank you for reporting. Which browser did this happen in? Are you able to consistently reproduce it on this page? Have you seen it happen on any other pages?

It was on Chrome version 70.***
I've update Chrome since then I can no longer reproduce the bug.

UI/UX Thoughts

I've always (for years) found the UI and "navigation"/ "Related Articles" Sidebar confusing. Are they just related articles or part of a Table of Contents?

The whole MDN is essentially a book. Keep it simple and treat it like one! Front matter, table of contents, content, index, coda.

I would much rather have a Table of Contents along the left sidebar with the current section heading highlighted and have "Related Articles" along the bottom.

Nothing is more frustrating than being "thrown around," seemingly systematically, by clicking on a related article link, but feeling like "Where the ___ am I?"

Simply adding highlighted text to the current sidebar would be helpful.

The breadcrumb under the Header and the Previous, Overview, and Next are great, but would be better if they were absolutely positioned so that it can always been seen, no matter how deeply scrolled into an article. Again. They still leave me unaware of where I am in the "big picture." It's like being dropped into a Google Map, all the way zoomed in with only the ability to move left or right and zoom out one step at a time. No one uses a map that way. You zoom in, zoom way out, go back in, follow a path, zoom out again. etc.

Try and think of this from the perspective of someone coming to it fresh - it's confusing even though all the information is right there. Most of the people reading this are working on this project and are very used to the navigation and orientation. New and novice users find it disorienting.

It's essentially a book with volumes. Keep it simple and semantic

Depends on: 1583146
MDN Web Docs' bug reporting has now moved to GitHub. From now on, please file content bugs at https://github.com/mdn/sprints/issues/ and platform bugs at https://github.com/mdn/kuma/issues/.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.