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.
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):
- pre-configured pages: In this concept, if you indicate that you are entering a protocol, you automatically get regions on the page set up for: 1) assessment 2) intervention 3) record-keeping 4) expected outcome. If you are entering a policy, you get regions set up for: 1) scope 2) preconditions 3) record-keeping 4) details. If you are entering the assessment part of the protocol, you get other details. You get the idea. In this way, all protocol pages look similar and will be carried out correctly by the medical staff.
- report-print: In this concept, the users of the Wiki get to specify reports that are generated by traversing the linkage tree depth-first and combining all of the results. Essentially, the medical professionals are not entirely comfortable with having everything only on the web. This way they can get formatted, printed, versions of the protocol and related docs and put them into a binder. Saves doing this manually through a web browser, one document at a time.
- deep-docs: In this concept, the ZWiki pages are not Documents at all, but are Folders (with all of the usual Wiki linking). Documents in the folders hold the different sections of the documents, such as assessment, intervention, record-keeping, expected outcome. Rendering methods on the folder sequences the rendering of the docs, formatting according to an XSL-like stylesheet. The result is that when the viewer sees the containing view, he/she can expand and collapse the sub-contents. The degenerate case is that the folder has one document, in which case the system behaves as usual. This concept also has the benefit that the main ZWiki folder does not become crowded with multiple hundreds of documents, which means that it takes a long time to access over the Internet (we are already noticing slowness here).
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!
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)))
- klm 5/25/2000 - Glad you like it! Personally, i implemented it
because i felt it would be helpful, and now i don't want to do
I agree about putting the singletons lower down, in fact it's what i did on our slightly later internal version - see the wikis on zope.org. That said, singletons often should be considered aberrations in a wiki, so there's some merit to putting them up front, to be wiped out. (Hopefully soon, we'll see all the default wiki pages included in the default nesting, so singletons really are unusual...) (SM: that was done in 0.6)
Re the li tags - i much prefer to just collect together all the singletons in a single paragraph - they don't seem to need structuring, so separate (list item) lines for each seems to me to be wasted space. I put in the list container just to indent the bunch nicely...
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
- klm 5/25/2000: I meant to include the standard_wiki_header and standard_wiki_footer, but my simplistic approach failed and i ran out of time to figure out what was going wrong. This is something that should be done! But be careful saying "bald" as if it were a bad thing. Some of my best selves are bald! :->
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