wiki of my heart

i've been using wiki's for about 4 years now to collect all sorts of information snippets. my first wiki was fpwiki and today i use mediawiki. i've worked a bit with jot, i've experimented with sharepoint's wiki, tikiwiki, twiki, recently pbwiki and a bunch besides.

i'm a wiki fan. but the thing about wiki's is that they still have some way to go.

there are shortcomings  i find it difficult to live with. some wiki's like pbwiki and jot go some way towards dealing with them. e.g. when it comes to linking to an existing wikipage from another page - they're much better than sharepoint's wiki at doing this. yet, none of them go as far as they could.

the 1st thing i want is bi-directional integration with static publication applications and the 2nd is more options to introduce structure to one's wiki page landscape. maybe the 3rd thing - and there is a lot more besides - is innovative ways of dealing with versions, approvals and electronic signatures.

1: i want to be able to take, say, a word document, and publish it as a wiki. be able to mark which parts of the doc i want to be editable, which parts i only want to have displayed (i.e. not editable) but still surrounding the editable, wiki parts. then easily convert it back to word or pdf once i'm done with it. and instead of having it in a file library, simply be able to integrate its contents into my wiki pages.

of course preserve the format as much as possible.

2: when i create a new page i would like many more options to link pages together. also, visual showing all pages allowing me to link them together, group them, tie them to files, pictures, static documents and web pages etc. be able to insert anything anywhere right easy. drag and drop, drag and relate, all of it. right now it's way to hard to have a user walk through a wiki page landscape in a logically constructed way. it's too hard to relate information and pages with each other.

the ability to easily break up pages into smaller ones and have all the existing relating follow without breaking the whole structure.

i remember Jeff Nolan speaking (probably years ago - one of many comments Jeff had over the years abt wiki's) of needing to structure and formalize the use of a wiki in an organization at some point to make sure it stays useful and clean (wildly paraphrasing). since he (via his blog) pointed me to pbwiki the other day and seems to be interested in wiki's still, i can't help wondering what he'd think today of how wiki's had progressed in helping with the structuring part. (and of course he meant more with 'structuring' than what i'm focusing on here.)

3. with something like a wiki one could in theory build a very fine-grained history tracking mechanism. something that could track the history of every word, every punctuation mark. track who added, removed, changed every one of these.

then, when displaying a history or a version difference, trim the changes according to whether the change is suspected to be stylistic, contentual and so on and present them *in context* to an approver. Who can then reject the changes of a specific user across all versions, or elect to see only the changes on the first page. Who can then approve whatever and set those approved changes as the new base version and add yet another flag to each word and each punctuation mark - 'approved by xyz'. that'd be better than word's change tracking mechanism imho.

so i haven't tried every wiki in the world. maybe yours can do this. maybe yours think it's besides the point. either way, be interested to know which it is at least.

Comments

[Jeff Nolan]

Leendert,
I think that wikis have advanced to being a standard offering in many collaboration environments, even if they just employ wiki-like characteristics.

A couple of examples you pointed out prove that when you give people "context" for editing or collaborating with others, the results are certain to be much better than a blank screen and "go figure it out".

PBwiki is a case in point, the "create new page" function gives users the options of selecting a prepackaged or custom template. The use of widgets in wiki pages increases functionality dramatically by integrating functionality and data from other applications in a predictable and reliable manner.

I like your point #3 very much and think that would be a great set of features in any wiki (or document editing tool for that matter).

The next stage for mature wiki products is to enable publishing of content from other applications, much like I can print to PDF today I would like to be able to turn a powerpoint presetation into a wiki or a Mind Manager map into a collection of wiki pages that are linked according to the connections of the map itself.

[Leendert van der Bijl]

Jeff,

Thanks for sharing your insights.

To embroider on what you said about the next stage: what we're looking for i think is basically a bi-directional collaboration and publishing platform. So eventually a wiki will need to have the power of providing access to the data of any local application - such as word or a web design platform - as well as the ability to combine data from multiple applications on a single page or in an interlinked fashion.

As an example: I could add to what I posted originally is that the way wiki's handle tables are sub-par. (The only thing that will satisfy me is essentially an excel-like table embedded in a word-like wiki page).

Tall orders these, of course. And now that I'm writing this down, I realize that I'm looking at wiki's as a kind of uber-application platform for collaboration.

I like your idea of being able to upload mindmaps as a set of interlinked pages. In terms of bi-directionality that would actually be a good way of making sense out of a disjointed set of pages right on a wiki-system. And allowing different folks to combine them differently would be great, interesting and maybe even useful.

This comment is already too long, but I also wanted to quickly say something about being able to take wiki-content off-line. One of Ray Ozzie' tenets with Groove was that not all users want to put their content online immediately for everyone to see. There are many other reasons for wanting to have wiki-content offline on a local system, and I miss not being able to do that even with Sharepoint's wiki, since WSS 3.0 and MOSS 2007 do allow offlining other content. (All of this probably comes back somewhat to being able to export wiki content to word, excel, pdf, openoffice etc.)

--lb

[Gedan Zuki]

Very interesting reading, Leendert.

I especially liek the idea of integrating with other software. Actually, the responsibility is on those software pacakges, is it not? Word's first foray in this realm (and maybe it's only foray) was to work with HTML. ANd granted, it didn't provide editable word files with selectively permissioned change areas, but the point is, maybe it's the application's responsibility to integrate with a wider standard.

Ooops, that brings up a reason for why, maybe, it hasn't happened. I haven't found a set standard for wiki syntax. It's all pretty close, but is it ((xxx)) or [[xxx]] for a link?

Full structure as you describe in #2 seems ideal, if not overpowerful. I do like tikiwiki's structure mechanism for overlaying multiple orders on a set of wiki pages. It's a little hard to administer, which is why I like your visual approach.

[Leendert van der Bijl]

hi Gedan,

you know, to get really specific, in theory it seems possible to me that already now integration between word 2007 and sharepoint 3.0 or 2007 is possible in the following way: i mark passages in a word document as editable and some as non-editable (maybe with a particular style). i save the doc to xml. then a web-part in sharepoint interprets those styles and displays the editable part in a wiki and the display-only parts on either side of the wiki. once the wiki is saved then the editable part is exported to xml and then used to reconstruct the the word 2007 document. et voila! :)