I had an epiphany recently.

My company documented and implemented an ISO 9001:2008 compliant Quality Management System on a wiki (http://articles.geometrica.com/64.html).

The epiphany part is the realization of how incredibly, amazingly, unbelievably useful the wiki is to complete this process. In fact, it is so useful that I now feel this urge to evangelize. Hence my contribution here.

If one of you finds this half as useful as we did at Geometrica, my work is done. :)

Cheers!
Pancho

Pancho,

This is very well written, and quite an interesting concept. Thank you VERY much for sharing.

I'm glad to see someone else using a wiki for this task. We started using one for our QMS 3 years ago and it's been through ISO 9001 and ISO 13485 audits. We've reached almost 3,000 pages but the wiki is now used for every aspect of the business.

You have to be careful to identify "controlled" records and to show the approval state of some articles, alerting the reader if the article has changed since being reviewed - it may be in a state of flux during an edit when someone else takes instruction from it.

I'm glad to see someone else using a wiki for this task. We started using one for our QMS 3 years ago and it's been through ISO 9001 and ISO 13485 audits. We've reached almost 3,000 pages but the wiki is now used for every aspect of the business.

You have to be careful to identify "controlled" records and to show the approval state of some articles, alerting the reader if the article has changed since being reviewed - it may be in a state of flux during an edit when someone else takes instruction from it.

Where can a "rookie wiki" user find additional information?

Thanks.

Stijloor.

There's some detail in the thread "I need to know which wikis are ISO9001 compliant (http://elsmar.com/Forums/showthread.php?t=20282)", that I just added to the tag cloud with the term "wiki (http://elsmar.com/Forums/tags.php?tag=wiki)".

Where can a "rookie wiki" user find additional information?

Thanks.

Stijloor.

The term "wiki" has several related meanings. One is the website where information can be read and edited. A second is the body of information and cross-links. A third is the software that runs it. To differentiate, I sometimes call the first a "wiki space", the second the "wiki content" and the last the "wiki engine".

A wiki engine or space are not, by themselves, compliant or not with ISO 9001 or any other standard. The wiki content, as the body of documentation, of your implementation may be. And your organization gets to write it.

Wiki engines are many (http://www.wikimatrix.org/). The most popular is MediaWiki (http://www.mediawiki.org/wiki/MediaWiki). At Geometrica we used ProjectForum (http://www.projectforum.com) and found it very straightforward to install and use, which was a great advantage when we got started. (Neither I nor anyone at Geometrica is affiliated to ProjectForum in any way).

One of the first realizations that we came to was that hot-links are incredibly useful. Our wiki home page, very early on, became a list of links to pages of indices of documents organized by processes and functions (i.e. Sales, Engineering, Procurement, Manufacturing, Construction, etc.).

As we built the wiki content, we started to "include" on every document the index of docs of their corresponding or closest area (process or function). By "included" I mean that the page of indices is displayed on the document itself, but as a side bar. This way, anyone browsing, say, an engineering document has immediate access to all other engineering documents. We also "included" links to every area in a top navigation bar, so that anyone can jump from area to area very quickly.

To get started, I'd recommend that you download one of the many free wiki engines and play with it. Once you get it installed, you may, for example upload to the wiki the documents for one of your company's processes as initial content. Hotlink the heck out of this new content and let their users loose on them. If you have the authority, compell them initially to use the wiki for changes to the documents. With a little luck, one by one they will come around (this is probably the hardest part). After some 3 or 4 do, you will start to see some "wiki magic". And you are off.

Good luck!

That's good advice, there really is no better way to learn than to try it for yourself. Familiarity with other Wikis is helpful, even Wikipedia. I found the concept of articles and categories to be the most misunderstood. Some Wikis have few categories and hundreds of articles (like the *cough* Elsmar Cove Wiki (http://elsmar.com/wiki/index.php/Main_Page) *cough*), whereas others create content in categories that are otherwise empty of articles.

The meat of the Wiki should be made up of articles. Generally, information should be written in articles and not categories. These are organized by being included in categories. Create a category if you intend it to contain multiple instances of similar articles (e.g. "Test cases"). Each article should be included in at least one category, but don't get carried away. Include your new article in the most appropriate (or immediate) category and allow that category to make it a member of other broader categories.

Some Wikis have few categories and hundreds of articles (like the *cough* Elsmar Cove Wiki (http://elsmar.com/wiki/index.php/Main_Page) *cough*), whereas others create content in categories that are otherwise empty of articles.

Generally, information should be written in articles and not categories. Each article should be included in at least one category, but don't get carried away. Include your new article in the most appropriate (or immediate) category and allow that category to make it a member of other broader categories.

Agree, Le Chiffre. We gave up on Categories and substituted them with "wiki gnoming" to write up navigation indices. Its a bit more work, but in our experience categories were always so jumbled that they were useless.

BTW, in your opinion, why is the Cove's wiki not used much?

BTW, in your opinion, why is the Cove's wiki not used much?Primarily because these forums are so comprehensive and convenient. Assuming people come here in search of a solution to a problem, the forums offer a search utility to check for an existing similar question or they post a new one and generally get a fairly good response within 24hrs.

I think the wiki vs. forum debate has happened here before but I believe people are more inclined to post individual opinions, however incomplete rather than collaborate on a complete and definitive answer.

The wiki started as an alternative to the Definitions, Acronyms, Abbreviations and Interpretations forum (http://elsmar.com/Forums/forumdisplay.php?f=3). The initial content was from Bill Pflanz's General Quality Assurance Glossary (http://elsmar.com/Forums/showthread.php?t=12692) and grew from there. There are only a handful of Covers that learned wiki mark-up, so after the initial coding of the the glossary (done my Marc an myself on a previous version of the wiki), not much more has been done.

It's probably easier to find a quick definition of a term on the wiki, but if one wants to read interpretations and discussion, that is better served by the forums.

Thanks Pancho, Le Chiffre

I would never have thought to use a wiki for a QMS, I like the idea a lot.

We have both an intranet and a computerized QMS.

The problem here seems to be that the culture is "verbal", people "ask" and "get told" what to do.

Unfortunately in a verbal culture the power of a wiki (or any documented system) is lost.

Perhaps I can try this in my next job.

I see a business opportunity here to re sell an existing wiki software package with some value added ISO 9000 templates to get it started.

Just needs a snappy name for marketing.

How about TotalQualityWiki?

SixSigmaWiki?

Wiki9000?

I had an epiphany recently.

.... The epiphany part is the realization of how incredibly, amazingly, unbelievably useful the wiki is to complete this process. In fact, it is so useful that I now feel this urge to evangelize. Hence my contribution here.

If one of you finds this half as useful as we did at Geometrica, my work is done. :)

Cheers!
Pancho


Pancho
amazing - I had read about your wiki a while back and here we are in the same forum!

I am a quality manager at a steel plant where there may be 10,000 people working on any day and although there are some procedures that are only used by a few, there are a number that everyone has to follow. I wasn't sure if we let everyone edit a wiki system on our site - from the shop floor to the ceo as there are mainy procedures with significant safety risks eg explosions, confined space etc

however I am really interested in how a wiki approach could be used to do the document review more efficiently

we use Microsoft Sharepoint for some systems, EMC's Documentum and Intranent pages managed by Access databases

I can see that with Sharepoint that the Document Libraries could be used for the procedures - once they have been developed through Sharepoint's wiki function.

I am also interested in how you got people to participate in updating the wiki - I find it easy - but many others are more comfortable with adding useful articles to the Sharepoint Document Library without putting any context around why they think the article is useful.

also in terms of records management - we would find 6 months too short - some of our procedures need to be kept for at least 10 years after being made obsolete - especially if there is a legal case that can drag out to over 10 years beyond an incident

so I have been intrigued since I first saw a posting about your system

KerrieAnne aka machrk :bigwave:

The problem here seems to be that the culture is "verbal", people "ask" and "get told" what to do.

Unfortunately in a verbal culture the power of a wiki (or any documented system) is lost.


I think that if you manage to get at least one individual in Top Management to buy into the idea, the wiki will take off. As Top Management must buy into the QMS anyway, this may not be as hard as it seems. In reality the wiki is simply a tool for a much more effective QMS.

And the wiki (or rather, the QMS) should quickly shift the locus of power in an organization from the talkers to the writers.


I see a business opportunity here to re sell an existing wiki software package with some value added ISO 9000 templates to get it started.

Just needs a snappy name for marketing.


Yep. If I wasn’t at this moment building domes, I’d do it myself!

How about Qwiki - the Quality wiki? Go fer it and remember us when you’re rich, ok? :D

In all seriousness, one thing that we touched on in the article only tangentially is the remarkably low cost of the tools. Both the wiki engine and Bugzilla are available in open source. But there are many ways a business built on this idea may add value: for example, (a) helping an organization break its “wiki panic”, (b) building the initial network of links in the wiki and guiding subsequent growth, so that the information remains accessible, and, as you propose, (c) templating the common parts of the QMS.

Cheers,
Pancho

amazing - I had read about your wiki a while back and here we are in the same forum!

I am a quality manager at a steel plant where there may be 10,000 people working on any day and although there are some procedures that are only used by a few, there are a number that everyone has to follow. I wasn't sure if we let everyone edit a wiki system on our site - from the shop floor to the ceo as there are mainy procedures with significant safety risks eg explosions, confined space etc


Hi, KerrieAnne! Small world indeed!

Yes, yours is quite a different environment from Geometrica. Although I am not certain that our experience would scale 100 times, there are a few features of our implementation that help in minimizing the risk that erroneous or malicious contributions would derail the system. We described them in the article, but essentially:



Any edit is reported immediately to the document’s responsible person by RSS or email who is obligated to review.
All contributions are signed and dated, and can be rolled back.
There is a mechanism to report “bugs”, correct them and take corrective action. In our experience this quickly becomes very popular (and useful), since it is a “safer” vehicle for someone that is not certain whether an edit to a document that they are contemplating is indeed desirable.




I am also interested in how you got people to participate in updating the wiki


The initial participation is the most difficult, particularly since wiki content exhibits strong “network effects (http://en.wikipedia.org/wiki/Network_effect)”. In other words, before there is any wiki content, there is little incentive to use the tool. Fortunately for us, we had to write the documents for our QMS, wiki or not. We established weekly goals for documentation. Writing the documents on a wiki is initially no more difficult than writing them in Word, and we simply required the contributions to be on the wiki. Once we built a small but critical body of documents, the benefits of the wiki became compelling. Editing and new writing became much, much easier, and the documents were and are actually used!

One other advantage that we enjoyed at Geometrica is that we had been using a wiki for project management for over one year. All that had used that system were very enthusiastic when the QMS effort converted over to the wiki.

In the future, when we achieve collaboration utopia, all the brains in my organization will connect with wifi. In the meantime they can be on wiki.

Good luck!
Pancho

thanks Pancho
actually we have just been audited to the EU's CE Marking for Construction Products Directive CPD 89/106/eec plus singapore's steel products BC1 :2008 for factory production control

the CE CPD is a maze of documents and I used the wiki in Microsoft Sharepoint to keep track of all the details - it helped enormously - so I guess it was sort of like your using a wiki for project management

cheers
KerrieAnne

:agree1:

The wiki started as an alternative to the Definitions, Acronyms, Abbreviations and Interpretations forum (http://elsmar.com/Forums/forumdisplay.php?f=3). The initial content was from Bill Pflanz's General Quality Assurance Glossary (http://elsmar.com/Forums/showthread.php?t=12692) and grew from there. There are only a handful of Covers that learned wiki mark-up, so after the initial coding of the the glossary (done my Marc an myself on a previous version of the wiki), not much more has been done.

It's probably easier to find a quick definition of a term on the wiki, but if one wants to read interpretations and discussion, that is better served by the forums.
maybe there aren't always links to Elsmar Cove's in the forum discussions - eg I like this one - http://elsmar.com/wiki/index.php/Using_a_wiki_for_QMS_documentation :applause:

cheers
KerrieAnne aka machrk

Agree, Le Chiffre. We gave up on Categories and substituted them with "wiki gnoming" to write up navigation indices. Its a bit more work, but in our experience categories were always so jumbled that they were useless.

BTW, in your opinion, why is the Cove's wiki not used much?
maybe the link should be to here - http://elsmar.com/wiki/index.php/Special:Allpages - instead of the Wiki main pages link?:cool:

KerrieAnne

Hi this is hari and i am working on a proposal to implement wiki to give life to our static QMS.

We have ms excel record templates. Can wiki manage changes or allow changes on ms excel record.

Can anyone share their experience if they have dealt with such a situation

thank you
Hari

Hi, Hari, and Welcome to The Cove!

In our wiki we try to display all info in the wiki's format. If your wiki has a WYSIWIG editor, it should be possible to copy-paste the table into the wiki's editor. But the formulas do not copy-paste.

If you must have formulas in your controlled spreadsheets, then you will need to upload the Excel file itself to the wiki. We'd recommend that you do this in addition to (and not instead of) displaying the info as a wiki-table or as an image.

You might also look into a wiki that can display office documents natively. Atlassian's Confluence (http://www.atlassian.com/office/) can do that.

Good Luck!
Pancho

I agree entirely with Panchobook.

I suggest you decide whether you want (or need) to keep your data in Excel or make the leap to reproduce the records in wiki format. Using Excel templates can be powerful but it does lock you into Microsoft Office as these don't convert easily to other spreadsheet utilities. This can also be a problem when accessing from a station without a compatible version of MS Excel (.xlsx anyone?) and may cause confusion for less Excel-proficient users.

The wiki format is simple, which at first makes you feel like you're taking a step backwards, but if you successfully convert your data it is more accessible (from any web browser, even a mobile device) anywhere, without the need for MS Office, and because of its simplicity is not intimidating to new users.

We made the transition slowly, over a few years. Gradually switching from hyperlinked Excel/Word files to wiki articles. The lack of sophisticated formulas and interdependencies has actually made the system easier to understand and maintain.

I suggest you decide whether you want (or need) to keep your data in Excel or make the leap to reproduce the records in wiki format.

The wiki format is simple, which at first makes you feel like you're taking a step backwards, but if you successfully convert your data it is more accessible (from any web browser, even a mobile device) anywhere, without the need for MS Office, and because of its simplicity is not intimidating to new users.


That's excellent advice.

Also, a published file that is not immediately visible (wiki or not) promotes the distribution of uncontrolled copies because every time a user downloads the file to read it he or she is creating another such copy. Not good. :nope:

Hari, you should always try to make wiki content immediately visible (http://articles.geometrica.com/488.html#heading3).

Pancho

hi Pancho n Le chiffre...i am impressed with the guidance that you have provided..right now i am preparing a business case on this....and your information is great for my case

:thanks:

hi Pancho n Le chiffre...i am impressed with the guidance that you have provided..right now i am preparing a business case on this....and your information is great for my case

:thanks:

Will you be able to share it with other Participants here at The Cove Forums?

Stijloor.

Will you be able to share it with other Participants here at The Cove Forums?

Stijloor.

Ditto. I'm sure it would be of interest to many of the regulars here.

Sure...the case is bulding up..once done ..i will be happy to share with you guys.

Hari

Great concept. I am also looking at new web 2.0 tools to use for qualitymanagement. Wiki was the most obvious.

I have a few questions:

In your example it shows that the wiki page is growing fast is the amount of text. How do you assure that the QMS remains focussed on the critical to quality elements and is not used as a library?
Is there a link to registration of training when training is required?
In your experience, is the QMS consistent, do writer assure their pages are consistent with other wiki elements?
Has the wiki contributed to the social network within your company?


Thanks,

Hi, Jan,

Great questions. Here are my comments on each.

In your example it shows that the wiki page is growing fast is the amount of text. How do you assure that the QMS remains focussed on the critical to quality elements and is not used as a library?

Several points on this:


Our wiki-based management system has grown to encompass more than ISO 9001. OH&S, Financial and General Management systems are being implemented.
The optimal amount of documentation in a management system is very much dependent on its accessibility. A wiki provides great accessibility. We use indexes on every page (see Sample QMS Wiki Organization (http://articles.geometrica.com/574.html)) and encourage contributors to use plenty of contextual links in the docs themselves.
We try stick to the DRY (Don't Repeat Yourself) principle. Links and "includes" allow this. See Using a Wiki for Document Control (http://articles.geometrica.com/488.html).
Documentation in wiki grew very fast during initial implementation. It continues to grow, but at a more moderate pace.
Issue tracking software is a now-indispensable companion to our wiki. We use Bugzilla. If redundant or otherwise undesirable documents appear, they are eventually flagged and then merged with others, or corrected or deleted.


Is there a link to registration of training when training is required?


Yes. We keep many of our records right on the wiki, including this.

In your experience, is the QMS consistent, do writer assure their pages are consistent with other wiki elements?


Mostly yes. Our procedure to create and edit documents requires contributors to DRY and Bugzilla helps in catching inadvertent violations. We've found the system to be self-correcting.

Our group is relatively small (about 40), and that may help, but I believe the system can scale up.


Has the wiki contributed to the social network within your company?

Haven't really thought much about this one, but the wiki certainly increased tremendously network connectivity and made it asynchronous.

We haven't measured, but I believe internal email use has decreased. Firefighting has definitely decreased (as you'd expect with any QMS). Contributors to the wiki acquire "network status" as their contributions are visible to all.

We also have separate wiki spaces for uses outside the Management System, and all of them help in strengthening our internal "social network". One of them is a General wiki space, where, among other things, Geometrica employees keep a page on themselves and where we post news and links of general interest. Other applications where we use wiki spaces include Technical Notes, Project Management and Client interaction.


----


Hope the above is useful.

BTW I noticed that the link in the original post is redirecting to the wrong page, and I can't edit it here. Could a kind Cove moderator please change the link in the first comment of this thread to http://articles.geometrica.com/64.html ?

Cheers,
Pancho

<snip> BTW I noticed that the link in the original post is redirecting to the wrong page, and I can't edit it here. Could a kind Cove moderator please change the link in the first comment of this thread to http://articles.geometrica.com/64.html ?

Cheers,
Pancho

Pancho,

I have modified the link per your request. Please verify and confirm.

Have a great weekend. :agree1:

Stijloor.

<snip>Please verify and confirm.</snip>

Right on. Thanks, Stijloor!

Right on. Thanks, Stijloor!

Pancho,

You're very welcome..I'm just celebrating Labor Day here..:D

Stijloor.

Here's a good article on customizing MediaWiki:
Whether you're co-writing your NaNoWriMo (http://www.nanowrimo.org/) novel, setting up a company intranet, or just want an easy-to-update web site, MediaWiki fits the bill.
http://lifehacker.com/5396832/customize-mediawiki-into-your-ultimate-collaborative-web-site

ok, let me know if this is better for a separate-brand new thread.

Ever since I've found out about Geometrica using a WIKI to implement a QMS and gain their ISO 9001 certification I've been keen on taking the same route. I've been reading Panchobook's posts with great interest. I'd also love to see this business case worked on by harishankarpv.

I know that Panchobook's organization has used ProjectForum, and Le Chiffre MediaWiki and I found this thread elsewhere Wiki recommendations for QMS project documentation (http://www.wikimatrix.org/forum/t1045-wiki-recommendations-project-documentation) and I would basically like to repeat the thread here where I think there is more activity.

The poster on that forum, gregm, had created a list of features he thought were necessary for the project, being:
• Locally installed, not hosted
• Access controls
• Ability to edit documents and leave comments
• WYSIWYG editing, no code
• Good typographical tools
• Ability to export to either Word or PDF
• Change history (very important for audit trail)
• very good range of templates to help me built quickly (I'm not a coder)


Can we create our own list here, and are there more people than just Panchobook and Le Chiffre with their kind of experience?

Those who have used a wiki to post their favorite wiki features/most missed wiki features in the wiki software they chose?

Can we use this information to compile two lists,

Best features for optimal QMS implementation in compliance with ISO 9001
(login-ins/change history/roll backs/alerts of changes through email, ease of use for non-techies, great search feature etc-etc)
Using that to determine which wiki's are recommended

And an additional list with cool features that would be a bonus.
(For example I was wondering about a collaborative calendar that could be filtered... showed WHO made the edits, but allow for categories such as trade shows-travelling, company & dept meetings, various work schedules and vacation days of employees, bdays... allow for RSVPs.. much like outlook, but better. :) Perhaps considered social networking features...)
Determining from the recommended wikis, which may be the most desirable individually?

I know there are websites out there that do Wiki comparisons, but I'd like to get info from those who have personal experience in relation to building a QMS.

and/or, any comments on Jira by atlassian for such a project if anyone is familiar with it?
one of Panchobook's links Our Intranet, the Wiki: A Case Study of a Wiki Changing an Enterprise. (http://www.e-gineer.com/v2/blog/2007/08/our-intranet-wiki-case-study-of-wiki.htm)They chose to use Confluence by atlassian...

Are there any more links such as the one's Panchobook has shared (including the Motorola (http://www.twiki.org/cgi-bin/view/Main/TWikiSuccessStoryOfMotorola) using Twiki one too) that are of other company stories?

Thanks for any help! :)

Can we create our own list here?



Here are a few I found. Most have not written too much about their experience, but it seems to me that the wiki chasm is about to be bridged (http://www.jarche.com/2009/11/across-the-chasm/) (thanks for the link on Twitter, KerrieAnne).



InfoTecna (http://twiki.org/cgi-bin/view/Main/TWikiInstallation20021012081207)
Fluidsignal Group (http://twiki.org/cgi-bin/view/Main/TWikiInstallation20070404154236)
RW Freight Services (http://twiki.org/cgi-bin/view/Main/TWikiInstallation20090721153043)
(undisclosed co) (http://twiki.org/cgi-bin/view/Main/TWikiInstallation20021012081749)
(a global life science co) (http://cpoconsulting.net/ISO9001wiki_casestudy.aspx)
Centro Internacional de la Papa (http://www.icis.cgiar.org/icis/images/3/36/ICIS-2008_CIP_ISO17025.pdf)

The first four are from TWiki's list of corporate users (http://twiki.org/cgi-bin/view/Main/CorporateInstallations) of their engine. Their Motorola (http://www.twiki.org/cgi-bin/view/Main/TWikiSuccessStoryOfMotorola) case is listed but not as a QMS installation, so its likely that there are others also not naming that use even if they are.

As far as which wiki is "the best" for a QMS, I believe that almost any modern wiki engine will do. The most important component is the wiki gardener.

BTW today I saw a video that makes this plant analogy quite vivid:

http://www.youtube.com/watch?v=dCLc6oB3Q3o&feature=player_embedded

(still can't figure out how to embed a video here, sorry. Would appreciate the help of a kind Cove Moderator...).

any comments on Jira by atlassian for such a project if anyone is familiar with it?

We use Bugzilla to record and resolve CARs and PARs, but Jira looks very good. Haven't switched only because the conversion seems to involve more effort than I think we'd save.

Cool video!

This is a visualization of the evolution of wiki.tudelft.nl from the very beginning, 5 years ago. Each node is a page, links are connections between pages. Graph is laid out using a force-directed algorithm, where the edges (links between pages) pull the nodes (pages) together, and the nodes (pages) repel each other. This means that the more tightly connected nodes will be closer together than weakly connected ones, which are pushed to the outside. The entire thing is created using Prefuse (http://prefuse.org/), wiki is using the TWiki engine (http://twiki.org). The soundtrack is from DJ Cary's Eastern Grooves compilation from Magnatune.com. More info about this can be found at http://wiki.tudelft.nl/bin/view/Main/WikiGrowthOverTime
dCLc6oB3Q3o

Panchobook: Add videos like this by putting the YouTube id between [YOUTUBE] tags, for example the code this one looks like this (without the spaces):
[ YOUTUBE]dCLc6oB3Q3o[/YOUTUBE ]

Back on topic ;)

I just came across this article discussing the differences in Wiki tools:
http://www.editme.com/Wiki-Tools-Where-EditMe-Fits

The site also has a Wiki Choice Wizard (http://www.wikimatrix.org/wizard.php). I haven't tried it but it looks useful. It looks like the site is focusing on the hosted Wiki solutions hence the mention of $/mo.

I realy like the concept and is definetely 'thinking outside of the box'.

My company documented and implemented an ISO 9001:2008 compliant Quality Management System on a wiki (http://articles.geometrica.com/64.html).

The epiphany part is the realization of how incredibly, amazingly, unbelievably useful the wiki is to complete this process. In fact, it is so useful that I now feel this urge to evangelize. Hence my contribution here.

I would like some help and clarification on the concept, though. In my case, all procedures are in flowchart format and work instructions are visual. The organization diverted from the lengthy and boring 'text' approach because we wanted to have useful, concise, clear and comprehensive documents instead of 'dust collectors'. You can say that it is an organization of few words...

Anyway, would wiki be able to allow users to start/modify flow charts and add/delete pictures as processes change? I would like anyone's feedback on this. :thanx:

would wiki be able to allow users to start/modify flow charts and add/delete pictures as processes change?A few wiki engines allow version-controlled editing of vector graphics. See:

* TWiki Draw Plugin (http://twiki.org/cgi-bin/view/TWiki/TWikiDrawPlugin)
* JHotDraw (http://foswiki.org/Extensions/JHotDrawPlugin) (Foswiki)
* Gliffy (https://plugins.atlassian.com/plugin/details/254) (Confluence)

All wikis allow an alternative to editing the vector graphics on the wiki: Posting a pic with an accompanying source file. The editor downloads the source file, edits it, takes a screenshot, and re-uploads the pic and the source. This is the method we use for our graphics in the Geometrica wiki.

Good luck!
Pancho

Hi Pancho (and all the other people that have chimed in on this),

Very interesting thread, and very timely - we're just about to start moving to Confluence form Atlassian for our ISO 13485 quality and documentation systems. One question or concern that has come up; a fair chunk of our organisation is not technical staff and seem rather uncomfortable with the idea of writing wiki markup. Confluence does have a WYSIWYG editor, but you still need to drop into the markup at times. What has been people's experience with this cultural shift/learning curve? I can see it being possibly the largest hurdle we're going to have to get over in getting people to use it...

Cheers,
Shane

One question or concern that has come up; a fair chunk of our organisation is not technical staff and seem rather uncomfortable with the idea of writing wiki markup. Confluence does have a WYSIWYG editor, but you still need to drop into the markup at times. What has been people's experience with this cultural shift/learning curve? I can see it being possibly the largest hurdle we're going to have to get over in getting people to use it...


Hi, Shane,

Yes, that was a bit of a hurdle for us too. We overcame it with the following:

1)
Got a small group enthused about the wiki first. Our first wiki application wasn't the management system, but project to-do lists. This involved less users and they were a bit more of early-adopters.

2)
Training. We had a couple of sessions of hands-on training for every employee.

3)
Network effects. Once the wiki got past a critical mass, its benefits became so strong that (almost) everyone wants to use it.

Despite the above, there will always be some folks that do not contribute all they could or should. Any new tool provides an excellent excuse for that. Just yesterday I read something quite appropriate: "Wikis show not only how much internal experts know, but how eager they are to share their knowledge." [source (http://daretoshare.wordpress.com/2009/11/13/finding-in-house-experts-isnt-easy/)].

Our wiki engine supports both WYSIWIG and wiki markup, and our users' preferences are divided about equally.

Pancho

thanks for your candour - I too find there are some who are enthused - but many who feel they should only publish to a wiki if it their content is perfect without errors

I ran a wiki session at our Sharepoint Interest group last week- see attached document - please don't get hung up on my comments about wikis & controlled documents - basically I am distinguishing :agree1:wiki's purpose designed for standard procedures, manuals etc and others not in this category

cheers

@KerrieAnne & @SteelyQueen on Twitter


Hi, Shane,

Yes, that was a bit of a hurdle for us too. We overcame it with the following:

1)
Got a small group enthused about the wiki first. Our first wiki application wasn't the management system, but project to-do lists. This involved less users and they were a bit more of early-adopters.

2)
Training. We had a couple of sessions of hands-on training for every employee.

3)
Network effects. Once the wiki got past a critical mass, its benefits became so strong that (almost) everyone wants to use it.

Despite the above, there will always be some folks that do not contribute all they could or should. Any new tool provides an excellent excuse for that. Just yesterday I read something quite appropriate: "Wikis show not only how much internal experts know, but how eager they are to share their knowledge." [source (http://daretoshare.wordpress.com/2009/11/13/finding-in-house-experts-isnt-easy/)].

Our wiki engine supports both WYSIWIG and wiki markup, and our users' preferences are divided about equally.

I too find there are some who are enthused - but many who feel they should only publish to a wiki if it their content is perfect without errors

Indeed. Many a document that would be useful to an organization may never be released because it is too hard to get it right. It takes a while, but eventually folks realize that once on the wiki the documentation improves because collaboration is enabled.

please don't get hung up on my comments about wikis & controlled documents

What you say is true: "wiki is not a standard procedure...unless these were intended to be in a wiki intended for this purpose". Yet, what makes the wiki (or any other tool) fit to be a controlled document home is not the tool itelf, but a proper procedure for document control.