What problems would this solve? =============================== This would solve 2 main issues. 1) It would simplify our navigation to allow a more clear path for users that are more likely to "browse" rather than "search". 2) More prominently display search as an option for navigating MDN content. Who would use this? =================== Users either landing directly on the MDN homepage or those navigating to homepage via deeper sections within site. (ie: docs or demos) Both users that search and users that browse. What would users see? ===================== 1) Docs (modified taxonomy TBD) 2) Demos (phase 1 retains current taxonomy) 3) Community (phase 1 retains current taxonomy) 4) Hack Blog (new within MDN) 5) More prominent search + interaction (details in separate bugs for design, IxD, and elastic search) What would users do? What would happen as a result? =================================================== More efficiently be directed to the content they are looking for. Understand all that MDN has to offer. Is there anything else we should know? ======================================
I will provide a sitemap and wireframe. TBD: - Taxonomy for Docs section - Search details for interaction and results display. This bug will be marked as dependent on UX bug for search details. The level of visual design effected in this phase is dependent on availability of a visual design resource.
Component: General → Design / user experience
Summary: Phase 1: Navigation Redesign → Phase 1 Redesign: Navigation
Assignee: nobody → hhabstritt.bugzilla
Priority: -- → P1
Whiteboard: [specification][type:feature] → [specification][type:feature][dev-ecosystem]
Will this include sub-navigation? Dan asked for this in a recent meeting. I believe he was referring to the kind of navigation that you can see to the left here, but I will let him confirm. https://marketplace.firefox.com/developers/docs/concept If this bug will not include that work, we should open a separate bug for it (and remember to add [dev-ecosystem] to the whiteboard).
Forgot to copy Dan. Please see above.
My description for this bug was created a month ago and does not apply to the larger developer ecosystem redesign that this project has become. It only applied to the much smaller MDN only (as it exists in its current state) redesign. This smaller project has now become much larger to include content across all of our dev properties. Therefore, the navigation that I described in this bug's first comment under "what would users see" does not apply. Stay tuned for navigation and taxonomy.
Dan, could you please open a bug about sub-navigation and tag it with [dev-ecosystem] in the whiteboard? I think you could describe it better than I could.
(In reply to John Karahalis [:openjck] (PTO until April 29, 2013) from comment #5) > Dan, could you please open a bug about sub-navigation and tag it with > [dev-ecosystem] in the whiteboard? I think you could describe it better than > I could. Done, see bug 862080
"Dan asked for this in a recent meeting." is not a reason to create a bug. Bugs should not be created unless they support the direction we are taking a project and have validation/consensus from the others involved. Please create a bug when we know it is something we want to implement so that people do not get confused and/or start doing wasted work. Something else that may be helpful is that when a bug is created, UX is ready to support it by attaching a visual or something tangible to react to so we don't misunderstand semantics. I know this is just one bug, but if bug creation in this manner continues, this project will be very difficult.
"Dan asked for this in a recent meeting." - this is not accurate, and quite disingenuous. After almost a month of meetings, direct developer testing (Nick), Sony all-but telling us "This is a joke, where do I find the apps developer center?", agreement among Bill, Mike, Ali and myself (and I believed, UX), alignment and codification of what was discussed in a PRD that Ali and I jointly developed, we have begun the process of filing the bugs that move the product in the direction it needs to go. Please read the PRD and formulate a experience and UI that aligns with it.
and me* - grammar fail, ugg
I am going to close this bug since the MDN redesign goals have changed a bit. I don't want anyone being confused with the out-dated problem statement or goals that are being proposed here. We will create a new UX bug in the future for this if necessary.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INVALID
(In reply to Holly Habstritt [:Habber] from comment #7) > "Dan asked for this in a recent meeting." is not a reason to create a bug. > Bugs should not be created unless they support the direction we are taking a > project and have validation/consensus from the others involved. > > Please create a bug when we know it is something we want to implement so > that people do not get confused and/or start doing wasted work. Something > else that may be helpful is that when a bug is created, UX is ready to > support it by attaching a visual or something tangible to react to so we > don't misunderstand semantics. > > I know this is just one bug, but if bug creation in this manner continues, > this project will be very difficult. Just wanted to quickly explain how we manage bugs on MDN. We open bugs for most requests so that we can collect feedback in one place. Not all requests are implemented. If relevant parties (including user experience) agree that a request should be completed and is ready for completion, it is prioritized and ultimately completed. If it is decided that a bug should not be completed, it is closed. Bug 839306 is an example of the latter. We collected ideas in one place, decided that the request should not be completed, and closed the bug.
Wanted to clarify one more thing. Holly, please let us know if you believe a request should not be completed. You can even close the corresponding bug yourself. Again, requests are just ideas. We want to close requests that do not contribute to the user experience you and your team have been designing, and you can own that decision. If a bug describes a request that is counter to what you have been working on, that bug should be closed.
Whiteboard: [specification][type:feature][dev-ecosystem] → [specification][type:feature][redesign]
You need to log in before you can comment on or make changes to this bug.