Closed Bug 926853 Opened 11 years ago Closed 11 years ago

[Zone navigation] Intrazone navigation is difficult because the side menu doesn't show where we are.

Categories

(developer.mozilla.org Graveyard :: Design, defect)

Product:
developer.mozilla.org Graveyard
Component:
Design
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: teoli, Unassigned)

References

(
URL
)

Details

This took me some times to figure out why I felt something was broken with intra-zone navigation: The intra-zone navigation is based on a menu, prominently displayed in a quick-links menu with a nice look. These menu are really a multi-article table of content. When being deep in the menu hierarchy and navigating to a new item, the new page loses where we were. In other terms, if I want to see the next page in order, I have to make several click in the left menu until I reach the point I am and click on the next item. This is very complex. How to solve this: one _possible_ solution (but I don't want to constrain you about it) is to have the accordion widget opened at the current page by default (and the current page being highlighted in some way). cc: Ali and Holly because I think this need to be discussed and studied before to be implemented in any way.
Another of seeing the problem. 1. Go to https://developer.mozilla.org/en-US/Apps/Developing/gather_and_modify_data 2. Navigate to the next page in the left menu order.
This was working until the URL alias thing went into effect. Your subnav addresses are the real addresses ("/docs/Menu/Sub/SubSub") and but the page URL is not a match ("/Menu/Sub/SubSub").
This problem exists even if you're not using the alias thing.
Blocks: MDNLaunchBlockers
No longer blocks: 910513, 924357
Example of where the page doesn't open to the matching URL in the subnav?
The example provided in this ticket does not match "https://developer.mozilla.org/en-US/docs/Web/Apps/Developing/gather_and_modify_data" , which is in the sidebar.
I still consider this a writer issue. URLs in the sidebar need to match their aliased URLs. From a dev perspective, we would need to find every link in the subnav, ensure it was using a zone alias URL but also find each link's real URL, then try to match both of those via the JS that opens a section. Additionally, for the sake of SEO and URL sharing, we should be using the alias.
The actual problem here is that the page you are on does not highlight in the left navigation, so it is unclear where you are in the hierarchy. The fix that was made so the menu stays open when you navigate to a new page in the sub-tree is a good one, but not adequate to keep your sense of place in the hierarchy.
Emailed Martell for detailed styles. Will completed when I hear back from him.
Commits pushed to master at https://github.com/mozilla/kuma https://github.com/mozilla/kuma/commit/471f961cb174f6f2254503c664dd1cb80c34c20a fix bug 926853 - Better display the current page in the subnav https://github.com/mozilla/kuma/commit/0271f773733aca376be604ea7082c3d4341134aa Merge pull request #1597 from darkwing/subnav-current-926853 fix bug 926853 - Better display the current page in the subnav
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.