Some Ideas for structuring wikis to help orient people within them

Regional nesting topic initiated by KenManheimer, 4/14/00

As wikis grow I crave some kind of orienting structure. For the wiki we've been using for our consulting project development i've been playing with regional nesting - and been having great success making our wiki more approachable, for us and our clients!

By regional nesting, i mean local regions contained within more global regions, and so on. What this produces is something like an extension of classic document structuring, suitable for a table of contents - with the addition that the nesting isn't limited by a small set of document entities (book/chapter/section/paragraph, or whatever), subparts can exist in multiple places, where appropriate, the structure can be assessed from any location, and so forth.

What we are doing is a simple parent/child relationships between pages, organized around the backlinks. The page from which a new page was created is the initial parent, and the parentage can be adjusted on the backlinks page. (This enables designation of multiple parents, or divorce/adoption, etc, and nicely constrains the parentage to existing backlinks.) The title bar then gets an outline of the page's ancestry, and there is a way to see all the offspring of a page, a map of the entire wiki, etc.

We have had great success with this - we even have our clients braving the fairly extensive territory of our wiki and wading in to add and change things. We had no success getting them to approach it before that point, aside from going to specific pages and maybe wandering around a little. The specifically identified the organization and locational cues as making the difference. I suspect that the degree to which designating the relationships and having the maps helped us improve the organization helped make it more approachable - it makes a quite noticable difference for us, as well!

We've discussed these changes with simon, who seems quite interested. This may be just a beginning - this use of the doubly-directed links (wiki refs and backlinks) is sparking thoughts about implementing the double links more explicitly, rather than having the backlinks be implicit. We'll see - in any case, we're certainly interested in making the changes available for everyone to play, it's just a matter of having the time to formulate and put them out there...

Afternote - simon has incorporated the parenting stuff to ZWiki, yay! The title bar hierarchy, and the "(contents)" link shown below the page titles is part of the scheme, though the nesting isn't shown in the default view. klm.


See WikiPaths for another linking scheme - EvanSimpson

Based on (mostly successful) efforts to describe medical protocols using ZWiki, I am (slowly) working on the following three enhancements (here I am taking for granted all of the map/tree views of ZWiki 0.6, since that is the first version that I worked with):

submitted 7/25 - Jeff Risberg

Why not let the most frequently used navigation paths define the parent-child relationships? For example, if you always get to WikiPaths from WikiStructuringIdeas, then WikiStructuringIdeas should be a parent to WikiPaths. The key is to capture the navigation events, and then to use the captured information to display the paths as a map. I'm new to Zope, but one idea is to make a page keep track of its parents via properties. Each time someone follows the WikiPaths link on the WikiStructuringIdeas page, the WikiPaths object should get a parameter indicating WikiStructuringIdeas was the source of the traversal. Then the WikiPaths object could increase the value of its fromWikiStructuringIdeas property by 1 (you would have to create it if it didn't already exist, which would mean this was the first time you got here from there). Then you could easily display the parentage by using the fromXXX property values with some statistical analysis. - RonDagostino

I like the idea outlined by RonDagostino: if the most frequent navigation events are recorded and displayed as suggested paths, they will be reinforced by new visitors. They will get positive feedback. In effects, the navigation system would develop and change through evolution. This sounds exiting. - AlexR

You can get a WorldWideWikiWeb? going this way. You can define a WikiWebTransferProtocol? that includes the ability to optionally specify the source of the traversal (Do you agree you would need to leave the source blank when you traverse the parentage link?), and then any WikiWeb? that obeys the protocol and displays the parentage information as traversible links would automatically join something that would end up growing bigger than even the WikiWikiWeb. You could even get cute and skip over popular parents that recently tested as failed; permanently bad links would eventually fall behind the new parents. It's pretty elegant, actually. All it takes is a good protocol.

I just posted this idea to WikiWikiWeb:WorldWideWikiWeb to see if anybody over there likes it...

I love the hierarchical view! Thank you, thank you, thank you! One comment: Singletons should appear after the main table of contents because singletons provide less information due to their lack of context. Show the stuff with the most information (i.e the hierarchy) first. Here is a quick set of changes to ZWikiPage.py that switches the order. Note also that the singletons as programmed before were missing the li list-item tags, which I put in. Again, thank you, thank you, thank you!

RonDagostino:

        for i in map:
            if type(i) == StringType:
                singletons.append('<li><a href="%s/%s">%s</a>'
                                  % (rel, quote(i), i))
            else:
                combos.append(i)
        return ("<h3>Table of Contents</h3> %s <h3>Singleton Pages</h3> <ul> %s </ul></p>"
                % (present_nesting(self.id(), combos, rel),string.join(singletons," ")))
        return ("<h3>Singletons</h3> <ul> %s </ul><h3>The rest</h3> %s </p>"
                % (string.join(singletons," "),
                   present_nesting(self.id(), combos, rel)))

Not sure where this should go - but - how can I get the map views to include all the relevant headers and footers - the map view is too bald. -jc


Other kinds of WikiStructuringIdeas: CliffordAdams' MeatballWiki:ViewPoint, UseModWiki:SubPages.


FlorianKonnertz, 2002/09/17 16:21 GMT (via web):
Could someone tell me briefly, if a subpage feature (/subpage) is planned to implement in the near future or if i could help to?! -FloK