862080 - Create a mechanism for specifying a zone's navigation

Status: RESOLVED FIXED

(developer.mozilla.org Graveyard :: General, defect, P2)

Description

[Daniel Buchner [:dbuc]]

What problems would this solve?
===============================
Zones need to have their own navigation that persists throughout the user's interaction with that zone and its content.

Who would use this?
===================
People who have the auth level to create zones (or are admins for specific zones)

What would users see?
=====================
Admin users will see some kind of admin form that allows zone nav specification

Users will see the navigation of a zone via some form of in-zone UI, like a sidebar or hideaway nav element (just examples of possible UI)

What would users do? What would happen as a result?
===================================================
Admin users would use the form to CRUD items in a zone's nav

Regular users would interact with the nav to get from place to place within the zone

Is there anything else we should know?
======================================

Comment 1

[Holly Habstritt Gaal [:Habber]]

I want to make sure we are just adding this bug in order to discuss this as a possibility for each zone since we do not yet know if a persistent sub-nav is necessary in each zone. It's kind of putting the cart before the horse to determine a UI and interaction need before determining the content that it supports. Before deciding if a sub-navigation is necessary we need to evaluate the content within our parent navigation (or "zones"). 

UX presented the following parent/zone navigation last week - Learn, Tools, Community, Search. Let's be sure that we are all on the same page with what the zones are called at this time, determine the content within these sections, and then revisit this bug.

Comment 2

[Eric Shepherd [:sheppy]]

I think it's important to re-iterate that we don't want the zones to be so wildly different looking that they seem like totally different sites. The basic look and feel should stay the same; only colors and background artwork should change, by and large. The positioning of content should stay at least roughly the same. Otherwise you break the feeling of everything being under the MDN banner.

Comment 3

[Daniel Buchner [:dbuc]]

(In reply to Eric Shepherd [:sheppy] from comment #2)
> I think it's important to re-iterate that we don't want the zones to be so
> wildly different looking that they seem like totally different sites. The
> basic look and feel should stay the same; only colors and background artwork
> should change, by and large. The positioning of content should stay at least
> roughly the same. Otherwise you break the feeling of everything being under
> the MDN banner.

Here is a good example of the minimum amount of customization we need in the zones: http://xbox.create.msdn.com/en-US - they must be able to feel like sub-entities curated for a very defined purpose, or else we won't be able to create a true "App Hub" or "Game Center" that matches the compelling offerings our competitors do.

Comment 4

[Daniel Buchner [:dbuc]]

For further examples of zone differentiation while maintaining cohesive presentation, here are a few 'zones' on dev.google.com:

    https://developers.google.com/maps/
    https://developers.google.com/chrome/
    https://developers.google.com/games/
    https://developers.google.com/analytics/

Comment 5

[Luke Crouch [:groovecoder]]

Here I like the Google zones MUCH more than MSDN zones.

I also really like jQuery:

http://jquery.com/
http://jqueryui.com/
http://jquerymobile.com/
http://qunitjs.com/
http://sizzlejs.com/

Some have identical layout, some don't. But they all use consistent elements - Helvetica Neue, wordmark, etc.

Also worth noting: jQuery, jQuery UI, jQuery Mobile, and QUnit all have api domains running WordPress with a common theme. 

http://api.jquery.com/
http://api.jqueryui.com/
http://api.jquerymobile.com/
http://api.qunitjs.com/

Much like we've discussed running ReadTheDocs and/or Jekyll with a common theme.

Comment 6

[Luke Crouch [:groovecoder]]

Ugh, now that I look at MSDN I don't like it at all. Compare:

http://msdn.microsoft.com/en-US/
http://xbox.create.msdn.com/en-US
http://msdn.microsoft.com/en-US/vstudio/
http://msdn.microsoft.com/en-US/windows/default.aspx
http://dev.windowsphone.com/en-us/
https://www.windowsazure.com/en-us/documentation/?fb=en-us
http://msdn.microsoft.com/en-US/office/default.aspx

are completely and totally different: not just nav, but search box, wordmarks, colors are totally inconsistent. Even their fixed width differs from 880px to 1000px between the zones.

Comment 7

[Daniel Buchner [:dbuc]]

(In reply to Luke Crouch [:groovecoder] from comment #6)
> Ugh, now that I look at MSDN I don't like it at all. Compare:
> 
> http://msdn.microsoft.com/en-US/
> http://xbox.create.msdn.com/en-US
> http://msdn.microsoft.com/en-US/vstudio/
> http://msdn.microsoft.com/en-US/windows/default.aspx
> http://dev.windowsphone.com/en-us/
> https://www.windowsazure.com/en-us/documentation/?fb=en-us
> http://msdn.microsoft.com/en-US/office/default.aspx
> 
> are completely and totally different: not just nav, but search box,
> wordmarks, colors are totally inconsistent. Even their fixed width differs
> from 880px to 1000px between the zones.


I completely agree, and believe Google's model is far better.

Comment 8

[Holly Habstritt Gaal [:Habber]]

What I do like about msdn are the clean page templates and search results (which we are addressing in other bugs). 

Search results: http://social.msdn.microsoft.com/Search/en-US/windows/apps?query=html&Refinement=180&emptyWatermark=true&searchButtonTooltip=Search&ac=4

Docs template: http://msdn.microsoft.com/en-us/library/windows/apps/hh465380.aspx




However, when going between zones at msdn (if we are considering these products as their zones: http://cl.ly/image/2n1Y2l2J1A1x), the main nav is not consistent in IA or style. It is easy to get lost. We need to be sure our zones are within a consistent and recognizable MDN wrapper as our users navigate between them.

Comment 9

[Les Orchard [:lorchard]]

Implentation idea from the offsite:

Building on bug 907236, establish a markup convention within content zone root page content - ie. <ul class="quicklinks">. A list found matching this convention will be pulled out of the main body of the page and output into a sidebar. This content will be carried down from the root page into topic child pages in the zone.

Comment 10

[[github robot]]

Commits pushed to master at https://github.com/mozilla/kuma

https://github.com/mozilla/kuma/commit/cf956ade1a6f19d8454e7a121b790170b9ae758b
bug 862080: Tools to define and display zone nav

* (redesign only) Populate quick links sidebar from a "Quick Links"
  section in the current document, or any parent DocumentZone documents

* (redesign only) Hide any "Quick Links" section in the current
  document, since it should get moved into the sidebar

* Helpers to deal with extracting & hiding sections in document content
  (section_extract, zone_section_extract, section_hide)

* Tweak to wiki.content.{extract,replace}Section to ignore the heading
  that defines a section

* Add DocumentZone to admin dashboard, tweak unicode repr

* Tests

https://github.com/mozilla/kuma/commit/029183f84333414fbd80086a57e058feaff4d7a4
Merge pull request #1324 from lmorchard/862080-zone-navigation

bug 862080: Tools to define and display zone nav

Comment 11

[Les Orchard [:lorchard]]

We have a mechanism to specify zone nav, so going to say this one is done. Open follow up bugs for improvements.