Page MenuHomePhabricator

Improve wiki document hierarchy location
Closed, DuplicatePublic


I think that the current location of wiki Document Hierarchy area in the very bottom of wiki pages is not optimal. When browsing wiki pages, especially longer ones, it is easy to miss the fact of existence of some document hierarchy with child wiki documents, unless readers scroll to the very end of the parent wiki page. I would suggest moving the document hierarchy area to the top of the corresponding pages.

Event Timeline

ablekh updated the task description. (Show Details)
ablekh updated the task description. (Show Details)

Why isn't the inverse true on your statement? If people are missing there is a structure underneath, and we flipped the layout, wouldn't they then miss the fact there is content underneath? Wouldn't people be more confused by the fact that when they clicked on any page, that only a navigation element appeared?

Overall Phriction is simply a Wiki, and not so much a CMS, which is what I'd recommend if you have such needs. We may extend and add additional CMS-like features into Phriction during out next iteration, I'll merge this task over so your thoughts aren't lost.

In the meantime, our expectation is people will add into the document itself any supporting structure needed with Remarkup. We have some examples of this on our wiki here.

@chad Thank you for the comments and taking care of my request. But to reply to your (hopefully, not rhetorical :-) question on why the inverse statement is not true, it is IMHO quite simple: similarly to having any book's table of contents (ToC) in the beginning is natural, any long enough document will benefit from having its hierarchy (essentially, a ToC) placed prior to the main level content. An unlikely potential confusion might be further eliminated by adding an anchor hyperlink to the beginning of the said content as a part of the document structure.

I'm not disagreeing there is a need for built-in navigation in Phriction, just that we're not planning to solve that with "Document Hierarchy". It will likely be a first class feature the user can intentionally structure separate from how they manage the tree / document nodes.