thank you very much for your comments.
Improving the performance of the MDN is one of our major concern. We
have a meta bug that track all the ideas. (
https://bugzilla.mozilla.org/show_bug.cgi?id=783527 ) Feel free to open
new bugs and make them depend on it. I replied in more details to some
of your specific points in the text below.
I also agree with you about navigability. It is currently very poor. I
often have problem to go back from a js method to the related js object.
The standard breadcrumbs are not useful for that, so several part added
a second level of breadcrumbs to fix this. This is a temporary fix and
we want to completely rework the navigability of the web site in the
Thank you for your help
On 26/09/2012 13:06, Anders Holb ll wrote:
> The primary problem, I think, is that the site feels slow. Quite a few
> things could be done to speed it up:
> - Don't use SSL
I'm not convinced by this one. At least not for the moment. I would like
to see the other speed improvements first (especially as these will
drastically lower the amount of connection to open).
We have a bug (bug 671794) filled for this one, it is on hold for the
Yes, this one is a big problem. I have filled bug 783534 and bug 783527
about these. It kills us outside the US.
> - - The google search api seems to be loaded on every page even though
> it is only used on the search page.
We plan to have our own search in the future, we will remove the script
at that point.
That's a possibility, I don't know how often it is changed. Anyway,
having an Expires time further away than 15 minutes is a must be (for
> - - Syntax-highlighting ought to be done on the server side
Yes, that's something that will help the perception of speed. I don't
think we have a bug opened for this one.
> editors or for few pages (e.g. the video players).
Can we be more specific? That way we can fill precise bugs :-) We
shouldn't load JS needed only by editors outside the $edit pages (we
have already fixed some).
> - The use of custom css-fonts seems to give a "flash of unstyled
> content" which might be one thing that makes the site *feel* heavy. So
> even though it is a cool feature, I think the price is to high in this
> case. I think MDN shouldn't be a demo of every bell and whistle, but
> rather aggressively strive to be the most useful, which in this case
> implies fastest, on the net.
We plan a redesign of the theme, so the FOUC effect should be taken care
on the new theme.
> But the site is also difficult to navigate and to get an overview of
> for several reasons:
> - The site lacks primary navigation. Some pages have a breadcrumb
> either in the top (in very dimmed colors) or in some non-standard way
> (e.g. PR_CreateThreadPool in the NSPR api reference, that BTW have
> many broken links), but it doesn't give a sense of what the related
> pages are.
The navigation is a catastrophe right now and is, with performance,
among the top priority for the redesign. I often got search after a
search, not able to navigate away, in a sensible way, from the page I found.
> - The tags in the bottom are close to useless for navigation. I assume
> the system/editorial tags (like MakeBrowserAgnostic or
> NeedsTechnicalReview) are useful for the editors, but none of the tags
> unstructured to be used for navigation.
The editorial tags are in the progress of going away, we have another
system now. We just don't had the time to remove the existing ones.
I proposed to redesign the tag pages to be more useful: bug 777312
> - The search is implemented such that it loads a new MDN page (which
> worst of both worlds. But it also returns non-relevant results, e.g.
> it returns results from other locales (at a minimum, translations
> should be folded in to one result item), "meta pages" (like
> "$history", "$compare" and talk) are included (although I think a
> blogpost mentioned some of this was being fixed). On the search
> results page the items are very tall and contains some variation of "|
> MDN - Mozilla Developer Network"/"| MDN"/" - Mozilla Developer
> Network" and the domain and url of the page, al of which is redundant
> and noisy.
We have blocked their indexing by Google, but it will take some time
until their will be de-indexed.
We changed the title of our pages to " | MDN", but this change has not
yet propagated to the whole Google cache, that's why you see some
- Obvious spam and junk content (e.g. /en-US/docs/aaaaaa), as well as
all the "... (External)"-pages should be completely deleted.
Yes, I completely agree. Deleting them is cumbersome now.
> The individual pages (to use an example
> ) also have some problems, I think:
> - The style of writing seems verbose with more of a prose-style than
> that of a reference. E.g. when I have used this page, it has often
> been to check the arguments for the callback. But this information is
> only found described as prose in the second paragraph of the forth
> section. If the syntax box (that doesn't really need to have its own
> header) was simply something like "array.map(callback(item, index,
> array)[, thisArg])", it would be easier and less error-prone to find
> the answer quickly.
In fact we need both. We need the pure quick reference info to get
quickly the information that we already knew but forgot, and a more
verbose text for the first time we encounter the info. The audience is
both the seasoned developer and the more beginner one (but not complete
beginner) discovering new concepts.
> - The "Implemented in"/"ECMAScript Edition"-box is very prominent on
> the page. But it is the least helpful information, since I suspect few
> know of the top of their head what browser versions included what
> version of the spec (or which part of the spec was included, and if it
> was bug free). So this should at least be moved to the browser
> compatibility section.
Yes, I agree, most of these banners must be removed and the info
positioned elsewhere in the page.
> - The table of contents, and especially the "tags"- and "files"-links
> under it, aren't really useful.
We now have the possibility to remove the TOC on a page basis. So if the
topic driver does agree, this can be done know. (And I agree that "tags"
and "files" are completely useless)
Thanks again for the comments!