• CoActivate Users' Group discussion

Feature request for Wiki

from Richard Grevers on Oct 23, 2012 01:11 AM

I constantly find myself using the "Wiki" tab to navigate back to the
top level of the wiki for projects, because there is no other native
navigation and it takes determined effort to put some specific
navigation in place. Note that I don't use browser history, because
I've often made two or three edits to the page that I'm on. My most
frequent destination is the parent page of the page I've been editing
or reading. While the wiki remains small and shallow (only two levels
of hierarchy), navigating via the home page remains efficient, but if
a wiki grows to 3, 4 or more levels of hierarchical depth, it becomes
inefficient, and navigation an unnecessary load on the server.

I'm assuming that many, but not all, wiki will be organised on
hierarchical lines, with the home page linking to various sections.
But some people just write lots with occasional wikilinks. So I don't
think the solution should be to impose any sort of forced
structure/category system - both in terms of being a lot of work to
implement and an unnecessary restriction of the flexibility offered by
the wiki system.

So what could be a simple, optional, no-buy-in solution? How about a
minimal breadcrumb trail: a link to the top of the wiki plus one to
the parent page -> being the page on which the current page was first
named. This could be achieved by adding one more url parameter to the
((page+)) link to a nonexistant page - something like
&parent=[currentpage] . This info is used to populate the initial text
(currently "Enter some content for your page") of the new page with
((home)) | (([currentpage])) and maybe a horizontal rule beneath it.
Users who don't want the links simply delete them as they do the
current dummy content.

Sound like a can-do?

Richard Grevers
Return to date view: threaded or flat