MDN/Development/Brainstorming/Redesign: Difference between revisions

Jump to navigation Jump to search

MDN/Development/Brainstorming/Redesign (view source)

Revision as of 23:58, 18 September 2012

1,155 bytes added ,  18 September 2012
no edit summary
No edit summary
Line 1: Line 1:
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.
Now that we've got kuma launched, it's time to start thinking about the next steps for improving MDN. We'll be kicking off a project to redesign the site and achieve some high-level goals.  


== Editing==  
== Redesign Goals ==
* When we added the "Report a Bug" button, many people filed bug reports about minor content problems. Why didn't these people realize that they could have edited the MDN themselves?
*Improve performance
* 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.).
*Better site structure, navigation & ability to quickly find key content
*Clearer separation of product and Open Web Content
*Update the design to something dynamic, modern, & more consistent with the brand
*Improve user experience & usability
*Improve SEO
*More flexibility in how content is presented (especially the home page & landing pages)


=== Structure ===
== Redesign Ideas ==
* People are trying to build high level structure into the MDN (for example, the JavaScript guide is basically a book) but we don't support that kind of structure natively. What if we did?
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.
* Same thing with page order. We don't have any inherent concept of page order, forcing people to use templates to accomplish it.
 
=== Moving pages ===
* This feature was sometimes abused on Mindtouch (for example, a user moving the entire DOM tree).
* What do users really <em>need</em> from this feature? What does it help them accomplish?
* What about administrators? What do they need from this? What does it help them do?


== Localization ==
*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 [https://developer.mozilla.org/ca/docs/HTML/HTML5 in some cases].
* 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 [https://developer.mozilla.org/ca/docs/HTML/HTML5 in some cases].
* Localizers should be warned (or better yet, prevented) from localizing variable names. Doing so can cause an internal server error.
* Localizers should be warned (or better yet, prevented) from localizing variable names. Doing so can cause an internal server error.
== Information architecture ==
* Do we really need to keep the Community > Discussions menu item around?
== Demo Studio / Dev Derby ==
* 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.
* 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.
* 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.
== Getting help ==
* When we used UserVoice, dozens of people reported issues with Firefox and Thunderbird. Ali mentioned that we could 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.


== Some features that could use thoughts from the user experience team ==
== Some features that could use thoughts from the user experience team ==
Aspivak
canmove, Confirmed users
842

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/471717"

Navigation menu