• View
• Edit
• History
• Print
• Backlinks

Henning

Henning - an enthusiastic PmWiki-User

Veni, vidi, wiki

I'm running PmWiki as intranet CMS. It's great! :-)

I discovered PmWiki and its suitability for my purposes using the Wiki:WikiChoicetree. (Access control was the reason why I initially picked PmWiki. PmWiki's features there proved quite useful.) There is a new wiki engine comparison tool at http://www.wikimatrix.org/ which looks sort of competent, too, though I didn't find access control listed there.

PmWiki has developed considerably since my first installation of the software. For a time, I was looking for a more powerful Wiki engine, but PmWiki is on the best way to fulfilling even my more ambitious requirements.

This is the functionality I need for my purposes:

• Upload protection - so that confidential documents can be put on the intranet (implemented)
• Upload versioning - for running an ISO 9000-compliant document management system (implemented)
• User access control - for making multiple small user groups possible without forcing users to remember multiple passwords (in progress)

(The last feature I'd like to see "fully implemented" like in MediaWiki or in the countless BBS implementations where users can register themselves and automatically retrieve lost passwords if necessary. A user-based access control is indeed implemented, but it really creates too much of a workload if you're dealing with a large user base.) --Henning November 08, 2006, at 12:39 PM

PmWiki is light, smart and elegant. The Cookbook recipes are great for additional functionality. My favourite at the moment:

• WikiForms - multiple instances in my wiki for tracking quality management issues and for running an ISO-9001 compliant document management system. Highly useful! :-)

Esoteric stuff

I analyzed the output of my wiki's AllRecentChanges and found the following:

The number of pages of a certain age in the wiki can be approximated by:

n ~ 2^(-Ct)

C is a wiki-specific constant which I call "assiduity factor".

T = 1/C is the half-life period of an unchanged page.

For C < 0, the wiki is saturated, there is an increasingly lower percentage of updated pages.

The assiduity factor of our company intranet currently is 12% per week which results in a half-life period of 8 weeks.

I'll keep an eye on the development to see whether the relationship is consistent :-)

--Henning April 01, 2005, at 09:07 AM

Well, half a year later, it seems that the exponential distribution is in fact typical for the age distribution of pages in our company intranet. However, it seems that the assiduity factor is constantly dropping. Maybe that's the result of having reached a limiting constant number of changes per time interval while new pages are still added?

--Henning October 14, 2005, at 09:27 AM

(If you'd like to leave me a message, you're invited to use the space below.)

Hi, I would be interested in how you set up an pmwiki for an ISO 9001 complient document management system. If you don't mind, I would appreciate if you could get in contact with me: pm.4.zook@spamgourmet.com. Thxalot.

If it's OK with you (and your corporate policy etc.), I think we can discuss this publicly :-) Else drop me a note here and we can take it to email just as well.

My document management system works as follows:

• One (password-protected) wiki group per department that publishes documents
• Each group uses the WikiForms recipe with an identical template
• The template lists all of the meta information for all versions of one document
• Each page generated by Wikiforms has attached
  • the current revision of the document (which is an MS Office document)
  • using Upload versioning, all old revisions of the documents

Notification of new revisions is done by the publishing departments sending emails "manually" and uploading the Outlook MSG file to the corresponding docuement page for archiving purposes. The idea is to reduce the number of notification emails, which was considered excessive with our old system. (We don't require any receipt.)

I would have liked to treat the documents as wiki pages and not as MS Office attachments, but there are two reasons I couldn't do this:

• Cultural inertia - people know MS Office but nothing else, and wouldn't understand why they'd have to learn something new.
• Forms - many documents provided by the system are forms or spread sheets that have to be provided as MS Office documents anyhow.

That's not perfect as the wiki text search and diff features don't work for attachments, but I don't see any way around this.

(I have prepared the migration from the old document management system to the wiki and actually filled the system with the automatically generated wiki pages for all documents - ca. 3000 pages -, but I have not actually completed the migration yet. Accordingly, I'm only talking about my plans and don't have any experience actually operating the new document management system. I hope it will become a natural extension of our extensive pmwiki-based intranet, though.) --Henning May 02, 2006, at 03:04 AM

ISO 9001-compliant document management sytem: migration complete

My migration from the old system to the Wiki is now complete :-) I had 3192 documents to move, and everything went just as planned (but took more work than I had expected).

Users seem to like the system quite well, though apparently a few of them are missing the automatic mail notification for document updates we had in the old system. I am aware of Notify, but as this only works from the Site.Notify page and I have about 50 separate groups of readers and the same number of authors, it's not a good option for me.

The ease of operation of the new system seems to be considered a big advantage over the old system, which has made it possible to go from some 15 highly-trained authors to 50 quickly-trained ones.

One thing that is not perfect is the search function. Though I created a special pagelist template, this template is a bit too dependent on the exact page structure for my liking, and I haven't managed to create working links on the documents from my template so the user has to surf over the referring Cookbook.WikiForms page to the document, which is not entirely ergonomical.

But minor issues aside, I'm in fact very happy with the new document management system :-) --Henning October 30, 2006, at 01:02 PM

(If you'd like to leave me a message, you're invited to use the space below.)

Hi, did you ever resolve how to get a wikilist to show for empty data? I need to do a lsit of all jobs that have not been closed out. i.e. the closed variable is empty eg wikilist closed="" or ='' or, What is it? thanks dan.raymond@optusnet.com.au

Hi Dan! Unfortunately, I didn't find a solution for using empty strings in wikilist strings. As a workaround, for one wikilist where it was important to use such a query, we used special characters ("§") to mark fields as empty, but of course this requires great care when entering the data, so it's not a truly good solution. --Henning March 14, 2007, at 07:46 AM

You showed interest in word level diffs in the past there is a new recipe: InlineDiff --Anno

Hi Anno! Thanks a lot for the recipe - that's really a great improvement, easy to find the changes now, very user-friendly :-) I have upgraded to PmWiki 2.2 immediately to be able to employ the recipe! --Henning May 16, 2007, at 10:38 AM

So were you able to successfully implement it or are you still having difficulties with it? Anno May 30, 2007, at 01:38 AM

Thanks for asking! The one problem I still haven't resolved is the "View source/view preview" link topic I mentioned on the recipe page. I thought it might be an effect of my XLPage internationalization effort, but even dropping the XLPage entries for a test did not resolve it. Since I have no clear idea where the page "prototype" is stored, I don't know what the reson might be.

(I'm using the recipe anyway, but I have already confused one or two users with it. Still, InlineDiff is a great improvement over the original! :-) --Henning May 30, 2007, at 05:10 AM

> I couldn`t find a template page for the change summary - it's hardcoded I guess? The "Show changes to markup" is in the file pagerevinline.php, originaly in scripts/pagerev.php . Anno May 30, 2007, at 07:54 AM

Hm, this file is one I used "out of the box", so I'd say it's probably not responsible for the links acting up. Do you have any suggestion which kind of customization could interfere with the recipe? Except for some other recipes, a custom template and the XLPage (which testing already ruled out as cause), I don't think there is anything non-standard about my wiki. --Henning May 30, 2007, at 10:02 AM

Thinking about it, my template calls the diff page by using "?action=diff" without any "&source=..." - I could probably change the template to generate the desired default behaviour. Without looking at your code, maybe it actually requires a parametrized call to produce the desired links? --Henning May 30, 2007, at 10:09 AM

>Without looking at your code, maybe it actually requires a parametrized call to produce the desired links?
No, it does whatever is the default behavior. Out of the box is shows the "normal" HTML diff, and if you then press "show markup" then it shows the highlighted markup. If you include

 if(!isset($_REQUEST['source'])) $DiffShow['source'] ='y';

then you change the default to "Show markup", when there is is no further specification in the url. I am lost at the cause of your problem.... Anno May 30, 2007, at 10:22 AM

Got it! :-) The "if(!isset(..." line has to be included before the main include, then everything is perfect! I worked my way down the instructions on the recipe page, so I added the optional line, which was mentioned last, at the bottom - I should have put it above the include of pagerevinline.php instead. Simple fix after all! :-) --Henning May 30, 2007, at 11:08 AM

(The Space Below)