Closed
Bug 710733
Opened 14 years ago
Closed 13 years ago
Implement breadcrumbs for page hierarchy navigation
Categories
(developer.mozilla.org Graveyard :: Editing, defect, P2)
Tracking
(Not tracked)
RESOLVED
FIXED
2.7
People
(Reporter: lorchard, Unassigned)
References
Details
(Whiteboard: u=user c=wiki)
MindTouch supports breadcrumbs for navigation between sections of page hierarchy. Kuma should probably support this, though we may also need to revise page models to accommodate breadcrumbs and hierarchy
| Reporter | ||
Comment 1•14 years ago
|
||
More thoughts: This might go beyond just breadcrumbs in the web UI. Mindtouch actually supports page hierarchy with paths in the slug/title.
We should support that and consider what that implies. ie. Access control to edit pages below a given path? Moving a whole section of pages? what else?
Comment 2•14 years ago
|
||
There should be a link between the breadcrumbs and the <title> of the page.
Example:
The page en/CSS/pointer-events should have a breadcrumbs:
MDN > Cascading Style Sheets (CSS) > pointer-events
and its (default) <title> should be:
pointer-events — CSS — MDN
This would help in cases of synonyms (title displayed as tab name) and for SEO, too.
Comment 3•14 years ago
|
||
That confuses me - the titles and url slugs are up to the authors. It seems we could implement a minimum-viable-breadcrumbs feature by splitting on '/' characters in the slug and linking to each token? That could cover all the migrated content until we decide to build out better page hierarchy, yes?
Comment 4•14 years ago
|
||
Currently (DekiWiki) the page name (<H1>) and title (<title>) are synchronous (with - MDN appended to the title).
This prevents us to make user-friendly title, which allows to differentiate Time - Javascript - MDN and Time - HTML - MDN in a tab bar. (Worse, the current situation is bad as some people adapt the H1 to have a search-engine-friendly title).
If these two entities are no more synchronized in Kuma, it is a good thing. But this creates a new problem: I don't want to go to all Javascript/HTML/XUL/CSS/... pages to manually edit the titles to something sensible. More I don't want to do this for each and every new created page (as most contributors don't care about such details), so we need a sensible default. And to populate, by default, the <title> with a part of the hierarchical structure, *like the breadcrumbs but in a reverse order*, is a possible solution.
Maybe it should be a different bug...
Updated•14 years ago
|
Target Milestone: --- → 2.6
Updated•14 years ago
|
Whiteboard: u=user c=wiki p=
Updated•14 years ago
|
Whiteboard: u=user c=wiki p= → u=user c=wiki p= s=2012-04-24
Updated•14 years ago
|
Whiteboard: u=user c=wiki p= s=2012-04-24 → u=user c=wiki p= s=2012-05-08
Updated•13 years ago
|
Whiteboard: u=user c=wiki p= s=2012-05-08 → u=user c=wiki p= s=2012-05-22
Comment 6•13 years ago
|
||
Would prefer not to use page title to define hierarchy
Currently the parent/child relationship is used for translation (English version = parent) so this would have to be addressed.
break into 4 subbugs:
1. implement page hierarchy in kuma (parent doc field in kuma)- add parent field.
2. migrate the relationship from MindTouch
3. draw breadcrumbs from that relationship
4. build UI to manage the relationships (set parent for this page, create child for this page)
turn this into tracking bug
Updated•13 years ago
|
Whiteboard: u=user c=wiki p= s=2012-05-22 → u=user c=wiki
Updated•13 years ago
|
Updated•13 years ago
|
Priority: -- → P2
| Reporter | ||
Comment 7•13 years ago
|
||
All blockers of this bug are closed... I think we're good for breadcrumbs as a feature, for now? File additional blockers of bug 756263, if there are must-have additions or things broken for pre-July
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
| Assignee | ||
Updated•13 years ago
|
Version: MDN → unspecified
| Assignee | ||
Updated•13 years ago
|
Component: Docs Platform → Editing
Updated•5 years ago
|
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•