MDN/Development/Brainstorming/Redesign
From MozillaWiki
< MDN | Development | Brainstorming
Redesign Ideas
This is just a rough collection of things that we might want to consider when we start the MDN redesign. This is by no means a final list, and by no means well organized. Just a collection of ideas.
- Clean up CSS, JS, and templates
- JavaScript framework update (possibly move to something modular).
- Provide a property list, improved compatibility tables (by browser as well as by element) – similar to W3Schools concept
- Enable mobile/responsive design & printable pages
- Easier to find profiles/listings/ general information
- Better/clearer language selectors & navigation through translated pages
- Refresh demo section & integrate better with rest of content
- Sidebars in given parts of the site: if you're in the CSS reference, you have a sidebar of links to all the CSS properties; if you're in the HTML reference, a sidebar listing the elements.
- Remove discussions from the menu
- Ability to build high level structure & page order natively (w/o resorting to templates)
- Homepage should have a big search box in the middle
- Links to popular topics or a popular doc panel
- Autocomplete will show "canvas" and "css" at the top instead of just autocomplete), so it will still be easy to get to those popular pages from the search box.
- Better navigation within topics and subtopics. Provide clear navigation; if you hit almost any CSS page, for example, you get information about the given topic but it's not always clear where to go next. Or what pages would be related.
- Something like XBreadcrumbs (http://www.ajaxblender.com/script-sources/xbreadcrumbs/demo/index.html)
- Add "favorites". If a user is logged in, we can allow them to "favorite" documents within MDN (not bookmark in the browser) & access via a secondary computer or a mobile device.
- More guided documentation
- Refreshed & more flexible home page; able accommodate new products & technologies
- We might want to take a look at what editors are trying to accomplish with templates, and look at supporting those things natively. Firefox sometimes does the same thing, pulling in features that started out as extensions and gained popularity (bookmark sync, highlighting the domain in the address bar, etc.).
- When a user reaches a page that hasn't been translated yet, they get a message explaining the situation and asking them to help with localization. But this message itself needs to be localized, defeating the purpose in some cases.
- Localizers should be warned (or better yet, prevented) from localizing variable names. Doing so can cause an internal server error.
- The link between the Demo Studio and the Dev Derby is not especially obvious. Some people (even some people in Engagement) don't realize that they are complementary sister sites.
- It would be great to keep the long contest descriptions around even after the contest has ended. I spend a lot of time on these, and they usually provide pretty good guidance in getting started with the technology.
- have a "Help" link on the MDN, with a few options: I want to report an issue with documentation, I want to report an issue with the underlying software, I want to report an issue with Firefox. In the latter case, we could just bump people over to SUMO, saving us frustration and helping those users get the help they need more quickly.
- We should figure out how slugs should actually be used. See this IRC discussion on the topic.
- We get quite a few bug reports from people who don't realize that the MDN is a wiki. This could be due to the fact that we don't really follow convention in making this discoverable -- most wikis have an "Edit" button near the very top of the page, but ours is a bit further down and to the right.
- A user mentioned interested in using the MDN API mentioned the following. "Looking at my profile now, it shows an 'API Key' option already, but doesn’t outright give any examples of what it'd be used for."
- How should we break apart dashboards? (see this Bugzilla comment)
- Most MDN content can be localized using the MDN itself. Some other MDN content (like landing pages) can only be localized through Verbatim. This can be confusing to localizers, as evidenced by this bug.
- Using one tool to manage all site localization. See bug 845961, especially the last answer in the first comment, for more information on this.
- Some localizers accidentally overwrite the English version of an article with their translated version. These people should use the "Add translation" button instead, as it makes the translated version available while still preserving the original English version. Simply overwriting the English version is a relatively common mistake. A member of the writing team told me that when he sees people making this mistake, he just deletes their translations. Their work is simply lost.
Some features that could use thoughts from the user experience team
- https://bugzilla.mozilla.org/show_bug.cgi?id=773054
- https://bugzilla.mozilla.org/show_bug.cgi?id=770965#c3
- https://bugzilla.mozilla.org/show_bug.cgi?id=773502
- https://bugzilla.mozilla.org/show_bug.cgi?id=780224
- https://bugzilla.mozilla.org/show_bug.cgi?id=770739
- https://bugzilla.mozilla.org/show_bug.cgi?id=784564
- https://bugzilla.mozilla.org/show_bug.cgi?id=784719
- https://bugzilla.mozilla.org/show_bug.cgi?id=784758
- https://bugzilla.mozilla.org/show_bug.cgi?id=791842
- https://bugzilla.mozilla.org/show_bug.cgi?id=841735