[ZDP] Wiki Parser? (Was RE: [Zope] ZWiki)

[Ken Manheimer]

A digital creations team i'm on has been using a zwiki intensively on
a consulting project to collect our requirements/use cases, technical
research, project schedules, and so forth.  As our wiki grew we
encountered some serious problems managing the information in it -
keeping it approachable and discoverable for us as well as for our
clients.  I wound up implementing a kind of outline organization which 
seems to have made a real and positive impact.

What i did was implement a notion of parent and child in the wiki.

 - Any of pages with wiki references to some wiki page X - X's backlinks
   - can be designated as parents of X.  The backlinks page offers
   checkboxes for selecting and deselecting page parents.

 - When a new page is created in the wiki way, by following a new wiki
   reference from an existing page - the existing page is the first
   parent of that new page.

 - The title box for every page shows the "ancestry" for the page -
   the parents, and their parent, back to one fo the root pages in the 
   wiki (often the FrontPage, though it need not be).

 - The backlinks page also shows a more complete "ancestry", showing
   the siblings of the parents and the current page, as well as the
   parents, themselves.

 - There is a link above the title bar to show a "table of
   contents" for the wiki (showing isolated pages that have no
   children or parents, as well as the hierarchies from the roots)

 - And another link to show a complete map of the offspring of the
   current page.

(All the outline maps elide repeated entries for any page by
substiting a "..." for any repeats.  This reduces redundancy and also,
crucially, avoids any problems with recursion on containment loops.)

This yields a kind of region-oriented nesting - 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.

This has helped greatly with our use of the wiki.  Not only are our
clients now finding their way and even making changes and *adding
pages*, new people on the project have found it useful for getting
filled in on the project - whereas, before the enhancements, we
couldn't even get our clients to find their way in, and even we were
often having difficulties navigating and avoiding accumulation of
kruft.

It still takes discipline on the part of the content authors to deal
with accumulated kruft, and to keep the organization sensible.  (We
still to accumulate some kruft - but much less, and much less due to
findability problems.)  The wiki doesn't become intelligent - but the
authors can adjust the structure intelligently, and make it much
easier for visitors (including themselves!) to get oriented and
maneuver in the wiki.

Patrick phalen wrote:

> Or maybe there is some other tool available which already addresses
> this. E.g., there is wonderful application program called "Inspiration"
> (Win/Mac) which allows a user to bring up a graphical view and add boxes
> containing concepts (text and/or images), and then freely interconnect
> the boxes arbitrarily with lines to form a "concept map." Then, one
> mouse click can turn that into a collapsible/expandable outline view.

Interestingly, the upshot of my nesting changes yields a similar
structure.  It would be nice to employ the tree tag to do exposure
control, and how cool it would be to have a graphical editor to manage 
the various kinds of links.  But just having the structure, with some
decent presentation and control, is proving invaluable.  And it's all
in zope, which makes it quite useful for/with many things.

I'd like to see these changes propagated, but unfortunately we're all
in a crunch, and there's not a lot of time to (1) iron out exactly how 
general we want to make the changes (simon is considering what a
general framework for doing this kind of thing would be), and (2) none 
of us have had the time to package up the changes nicely.  We may see
this kind of thing more generally available sometime soon, though...

Ken Manheimer
klm@digicool.com