extract_idea1Add my vote for this tag create new tag
, view all tags

Several issues raised during meeting to place TWiki on intranet

I am listing this as a bug because, well, they are limitations of twiki or the users using twiki, and felt they should be documented. Some of this is covered in parts of the twiki docs already, w/r/t organizations accepting this type of server.

I have followed wiki's for some time. After examining several posted on sourceforge I decided to go with twiki (main pluses in my opinion are: all perl cgi, good plugin support, uses rcs backend for version control, allows attachments, has security features, active bug report/support). The purpose of this install was to have an intranet software engineering knowledgebase.

I proceeded as follows.

  • install twiki dec2001
  • configure for .htaccess authentication
  • restrict editting to any registered user
  • allow viewing by all
  • implemented a plugin for intranet documentation serving (our docs have a specific doc id, which can be regex'ed easily and served via URL).
  • implemented another plugin for intranet bug report/defect serving (our defects are run via mysql database, and served via URL)

Note that all of the above took at most only 25-35 hours of my time. Setting up the entire system was incredibly easy.

I then placed some content on the server, probably around 50 topics, all under a single new web. This content included:

  • engineering knowledgebase information (product information descriptions, bug lists, etc)
  • some tables of documents which were auto-linked by the custom plugin to the intranet doc server
  • some .gif's which were exported from engineering documentation, with brief summary of a technical nature

I worked on this in the background with one other person for several weeks, so the content had some time to mature.

At this point I held a demonstration of the system to 20 or so engineers (below me and above me in seniority). Several valid critical points were raised against the twiki server, which might be addressed in the future releases of twiki. I found some of them surprising, given the nature of the audience (software engineers with 10+ years experience). Please do not dismiss any of these, since the idea of wiki is to allow anyone to generate content smoothly and to in fact encourage people to generate information (of course maybe my own presentation of the system was at fault for some of these critical arguments against the system, but YMMV). They were, in order of priority:

  1. ease of use
    • No one understood the concept of editting text within the browser. This is odd, since we have MS Word (for example) plugged into MS IE, and etc.
    • No one understood the concept of a wiki word which links to a topic.
      • I bet a burrito that this is a semantic misunderstanding. If I had called it something dot-com-ish or microsoft-ish, perhaps it would have gone over better, like "link word" or, well, I dunno, I never was much of a marketting person. Yes, I know why it's called wiki, but a newbie does not (nor should they care, if it doesn't help them generate content).
    • Complete newbies to the system did not know (intuitively) to click the form buttons to save a topic. Several people tried going to File->Save in the browser instead.
    • I still have not convinced anyone to go through the 20 minute tutorial. "20 minutes? Why so long?" (The tutorial only took me 5 minutes to go through, but I guess I'm just a child of the internet or something, hah.)
    • I have seen several people go to a topic, manually cut and paste the content into word, create a *.pdf with adobe, and email the *.pdf result to another person on the intranet. (Completely silly, since they should just email the URL.)
      • This points to a need for a better way to capture the topic(s) off-line, through the twiki interface itself, rather than using genhtml, with some way of defining the exported depth. This captured content should link to the original URL everywhere, kind of like google does with it's cached pages: "this is a cached version of the page, the real page is here: xxx".
  2. professionalism
    • Ok, everyone in open source land will hate this, however mission critical IT systems usually look stuffy. "tweekie? what kind of name is that? Does it stand for something?"
  3. security
    • Recall that I installed with "all viewable", "edittable with registration" permissions, so some of the fault is my own.
    • professional IT departments are tied to business operations which have proprietary/confidential information. "what do you mean anyone can read or modify this information".
      • A seperate install process which creates "highest security", "medium security", or "anarchy" might solve this problem. Or maybe this is impossible. (I handled the security configuration, after all).
    • Perhaps add better docs on how to integrate twiki security with MS NT server security (typical in most brainwashed IT departments), etc ?
  4. backup
    • no automatic means of backup.
      • this one is easy; I can imagine a plugin which creates either snapshot backups or incremental backups and then e-mails them or auto-ftp's them to some person/site specified.
      • this is a bit site specific since the particular server I installed the twiki on did not yet have a tape backup.
    • perhaps a method of mirroring to another twiki is possible.
  5. concerns over duplication of content
    • since we have a few "knowledgebase servers" already (though really they are static web pages with documents) it was thought that twiki duplicates information or becomes yet-another-place-to-look for information.
      • Of course, my idea is to take over these servers and steal all their content.
    • Once I changed the colors and configuration on twiki around and made it look a bit more like the other intranet servers, this attitude died down a bit.
      • I changed the name of the twiki base directory to "lib". Simple change, but now no one sees "twiki/bin/view" in the URL, they see "lib/bin/view". This has turned out to be important. I'd say the default base directory could be renamed.
      • all references to twiki are now "lib" or "Library".
      • I removed the "webs table" at the end of the main topic webs, so the page is smaller, and people have LESS choice of where to go. Previously, everyone was getting lost.
  6. Too scary
    • Not sure how to categorize this, but some of the (what I would think are) best engineers had snide comments about why they would want to use twiki, if they could use microsoft word instead, and just e-mail out the final document.
      • This is a misunderstanding of the rapid edit/revise/edit idea, I suppose. How can people be convinced that rapid text generation is the way to go, until the information needs to be published (vs. the other way: edit document, email it out, wait for comments back, edit document, repeat).
    • Too much information.
      • Previously, users around here would go to my main web page and then stare blankly, completely lost. If any topic has more than 10 other topics, people are lost. So I have nested topics more to hide the amount of information presented. This has worked so far.

Ok, so that was the bad stuff. Here's what impressed people:

  • attachments.
    • the ability to rapidly attach a *.pdf to a topic, such as an explaination of some technical stuff and then a *.pdf spec.
  • tables.
    • rapid generation of table markup when I typed in a quick three column table
  • differencing versions / revision control
    • this quietted the argument regarding someone toasting a topic. Since there's revision control, this isn't an issue at all.

Test case

  • Place twiki server on intranet.
  • Put up some content.
  • have a management meeting to discuss the twiki.


TWiki version: dec2001
TWiki plugins: none
Server OS: red hat 7.1
Web server: apache
Perl version:  
Client OS: win nt sp 6
Web Browser: ms ie

-- TWikiGuest - 16 Apr 2002 jcline(at)ieee.org

Just wanted to say thanks for sharing this! Useful information!

-- RandyKramer - 16 Apr 2002

I encountered many of the same arguments, where IT people were not willing to spend 10 minutes to learn TWikiShorthand (because they feel they know HTML), completely missing ease of publishing/sharing on net. OTOH, some biologists jumped right in.

I guess hackerish open-source origin is still visible on TWiki, and some people shrug at this, and other enjoy it. Probably we need to post somewhere here typical pricing scheme of proprietary application with TWiki reach and abilities, to show PHB managers PriceTag - then they might be more open-minded?

-- PeterMasiar - 17 Apr 2002

I had similar results (not exactly, but the theme was the same) when deploying the TWiki within our organization. It's actually quite depressing. We are a software group (20-30 people) within a large engineering firm (we make big planes and big satellites). Conclusions:

  • 95% of people (regardless of intelligence or background) are not motivated to experiment on their own ("Oh, there's a tutorial on the front page?" or "No, I haven't yet followed the second highlighted link that allows me to change my default password", etc,.).
  • 95% of people resist change at all costs. If it's different, they will go out of there way to shoot holes in it.
  • Just because something (TWiki) offers many things that current solutions don't, the fact that it doesn't offer everything to everybody will be enough to provide fodder for criticism.
  • Besides myself, only a couple of individuals used TWiki initially (it's not clear to me if the majority even bothered to spend 5 minutes investigating the site). It has since dropped down to just myself. I can live with that because I'm making great use of it to organize my work.
  • TWiki (or its like) is for enthusiasts.
  • I wouldn't make a very good evangelist.

-- MartyBacke - 17 Apr 2002

TWikiGuest, you raised some good points, and thanks for sharing this. I changed this from a bug entry to a TWikiDeployment question because this is what it basically is.

From my own experience it takes a lot of time and persistance to get TWiki rolling within a company. Quietly preparing content is a good start, but it is not possible to get the buy-in after just one meeting. Adressing some of your points:

  1. Easy of use:
    • Non-WYSIWYG and WikiWord linking is a sticky point mainly for non-technical folks. I tell them "treat TWiki like e-mail, getting content online is more important then formatting. Start simply with paragraphs and bullets; the more you use the system the more you will learn."
    • At my daytime job we have now non-technical folks use TWiki, like people from facilities and administration.
    • Internal consulting is key. Start with a small group and train/coach them. Other groups will get interested after they see a successful deployment. Nobody wants to be a guinea pig.
    • Make internal seminars for interested groups. NetMeeting or PlaceWare is helpful for virtual trainings.
  2. Professionalism:
    • I never got any negative feedback on the name, may be some jokes. Do names like Mozilla, Eudora, Java give a different impression?
  3. Security:
    • This boils down to consulting. What are your group's needs? Who are the consumers? Who is not supposed to see/change content. Depending on that set up restrictions for them or point them to the relevant docs.
  4. Backup:
    • This is out of scope for TWiki. Any server should be backed up. However, very important: Tell everyone that there is a backup plan and that the data is safe. Put this in the front page.
  5. Concerns over duplication of content:
    • Consulting and policy: Tell them that content should not be duplicated into TWiki, but that it is good practise to organize and link external content with TWiki content.
  6. Too scary:
    • Scary mainly for management. Tell them that TWiki.org is world writable and that there are very few issues. In case some clown deletes a paragraph it can be rolled back to the previous version; the admins get alerted by e-mail notification. Now transform that into corporate use. At my daytime job we have over 1000 registered users, 400 regular contributors per month, 7000 page chages per month and never had any issue for almost two years now.
  7. Too much information:
    • Get organized. Train the trainers. Mobilize knowledge activists (read Enabling Knowledge Creation, by Nonaka, ISBN:0195126165)

Overall you raised some good points, we will continue to enhance TWiki based on feedback like yours.

-- PeterThoeny - 18 Apr 2002

For backup, I have a simple solution. See BackupScripts.

PS: nice remarks. I got nearly the same here. Basically everywhere the people most opposed to TWiki were the systems people. They couldn't believe a non-technical user will want to use a non-WYSIWYG system, and were wary of the "everybody can write" feeling.

Basically you need somebody (you) animating the wiki, publishing news, helping people, refactoring contents. It is slow to start, start with a small team but be ready to be able to open webs for any other team that would want to try by word of mouth.

Basically It took 6 months here to be seen as a keeper.

-- ColasNahaboo - 18 Apr 2002

Regarding ease of use. Someone else other than myself above had the comment (maybe elsewhere) that people did not understand that hitting "edit" meant editing the page, because no one seems to grok edit-in-place document generation systems.

A solution to this problem might be the use of console windows (i.e. new browser window pops up to edit the content in seperate window) as follows..

  1. user clicks edit
  2. original topic browser window remains, new browser window opens (yes, some browsers like opera disable this, it may be a problem).
  3. 2nd browser window has edit box for text editting and "preview" button at bottom
  4. user edits text and hits "preview"
  5. 2nd browser window displays preview, has "edit again" button or "save" button
  6. user hits "save" button
  7. 2nd browser window displays "thank you" note and a "close this window" button and "edit again" button
  8. main browser window refreshes with new topic update

sounds like this would require javascript. In which case forget it. I'm sure this idea has been brought up before.

I do notice that when using twiki and adding content, I get slightly annoyed at the "type a little, click preview, click save, click edit to type a little more" cycle, especially when I am in a meeting and generating meeting minutes/action lists, since the meeting (i.e. content I am reporting on) never stops. I use this method of adding content because I want to verify my formatting and see the results of what I just typed. Having seperate browser windows for view/edit might allow this process to be more rapid. (Although if I used two browser windows now and just kept clicking "refresh" in one and editting in the other, I'd get a similar result, but not as automatic.)

  • The KoalaSkin comes with a "checkpoint" function that does what you want. It is a lot more professional looking that the plain skin, IMO.

-- TWikiGuest - 28 Apr 2002 jcline(at)ieee.org

One possible solution is the one used at http://www.perlmonks.org : preview has also edit window on the end, so you can see your preview, and continue editing. I am almost sure this exact solution was proposed before. However, this way we are sending text of the page twice: once in rendered form, and another copy for edit. Slower page download - will be bad especially for pages using table-based skins, which needs to wait to download whole table to start rendering. Classic TWiki skin is not affected, If I understand it correctly.

-- PeterMasiar - 29 Apr 2002

To follow up on this topic again, a large part of the twiki clash is cultural. One developer recently said in a conversation, "I'd rather not have my work sent to X or Y." I think this was largely due to the developer's fear of having his work read by specific people (i.e. due to office politics or insecurity).

I was part of a huge (multimillion $$) custom information-base deployment at a PC chip company, and there were multi-day training classes prior to the launch of the system. For every half-dozen developers (the content generators) there were assigned team leads (content reviewers or content managers). The content managers had seperate 2-day training plus 2 hour weekly meetings. Even after all of the training, which I felt was largely motivational/cultural, content generation was rather thin (I think I was consistently a top content generator, and only spent a half hour a day at it). After several months on the system, I thought it was a project failure. My point here is that even with significant effort to train and motivate content writers into generating material, many of my co-workers at that time had a fear of writing anything, since it was to be intranet-published material. (Professional darwinism: if you don't excell at your job, then lay low and hope you aren't noticed by management?)

Now if anyone has any solutions to this, I will buy lunch.

-- TWikiGuest - 07 Jul 2002 (jcline at ieee.org)

Fear of contribution: A successfull TWiki deployment is much more likely in a company with a culture which encourages information sharing; it is unlikely in an environment where people tend to hoard information and/or fear accountability.

An excellent book on fostering knowledge sharing is: Enabling Knowledge Creation, by Von Krogh, Nonaka and Ichijo, Oxford University Press, ISBN:0195126165. The book addresses managers and executives who are trying to foster knowledge contribution in their organization.

-- PeterThoeny - 07 Jul 2002

I've had similar problems with TWiki deployment in the corporate environment. We're basically a "branch office" of a big company. TWiki is the perfect tool for the job: We have lots of SOPs and undocumented stuff that people (sometimes) keep documented in their own notebooks.

I deployed TWiki some time ago, gave a brief explanation (we're all engineers) and said: "Just write the notes. Don't worry about formatting stuff. I'll change it for you and you'll learn slowly along the way...". A few months later and not a single "commit" to TWiki?!? I went around asking why nobody was using it and the general consensus seemed to be that it's a "pain in the ass" to document things.

My conclusion is that the failure is not in Wiki per se, but in the lazyness of most people to organize their thoughts and their work.

-- TWikiGuest - 25 Oct 2002

An excellent discussion around issues that are key to further TWiki dominance. wink

-- GrantBow - 09 Jan 2003

Yes, it's a good expansion of the third point I just added to the end of HowToGetInternalBuyInForTWiki:

  • ...made abundantly clear is that the solution to enable collaboration is not really a technical one (much beyond the simple tools). It's a management one.
    • this point is extremely relevant to us as it points directly to a weakness inherent in the wiki model. The people who run the wiki must provide structure and work flow ("governance architecture" in the parlance of the essay) else it turns into big chaotic morass of related-but-not-necessarily-relevant documents.

(yeah, I know, it's bad form to keep harping on the same point, especially verbatim, across multiple topics. I feel justified in this case because 1) the point is really important to any successful deployment, and 2) with all the housekeeping changes going on around here it slid of the changelog pretty quickly. smile

-- MattWilkie - 09 Jan 2003

An excellent discussion!

What about contacts/phone/fax/... formated stuff?

  • AddressBook
  • I am planning to use Twiki in a Accident and Emergency center in Norway.

  • The main task is to find (organize).
    • "i need the fax number to hospitalxxx"
    • "phone number to GP xxx"
    • " opening time of AA?"

  • What about to use Twik for this task?

-- VolkerLapczynski - 05 Feb 2003

Regarding jcline's comment above that relates to getting past the "I don't want X to know that I typed this", that finishes with...

> Now if anyone has any solutions to this, I will buy lunch.

Simplest solution of all: install the CommentPlugin, and make sure you have the comment box available on every page by default (change the default new topic template) and make don't require authorisation for adding of comments. (Don't switch on doRememberRemoteUser though at the same time - you'll get complaints)

This allows anyone to add comments, even comments considered "politically incorrect" for the company without fear. OK, it's not a complete solution, but it's a good step. Personally I think comment mode is often a bad idea - I tend to prefer targetted usage - since it tends to discourage refactoring/DocumentMode documents. It does reduce the barrier to entry (social, political, technical) quite, quite dramatically. (Heck even senior people can add comments which they might be dumb without losing face - quite a plus!)

Why is that safe? The comment plugin "can't" destroy content.

-- MichaelSparks - 02 Aug 2003

Moved AddressBook to Support Web.

-- ArthurClemens - 03 Sep 2003

I've had similar implementation problems in a smaller environment (several people). I agree that this is more a management problem. The IT Department might be unable to implement any solution without a hand from the Management. Anyway, the main idea is to simplify things. Twiki is... uhm... complex. Not for you nerds, obviously. But if I was to try Twiki in a 'non-technical' environment... phew. As long as it is an e-mail message, it's not "centralized" and the responsibility is smaller. Twiki is centralized (everything is editable and viewable to everyone) and users are afraid to make a mistake that could humiliate them in some manner.

Adding typical knowledge sharing difficulties... (Davenport / Prusak) Though case it is.

-- LechAmbrzykowski - 21 Sep 2005

Thanks for having this discussion! Taking the notion of wikis to a major financial institution in order to energize complex projects is getting reactions from "deer in the headlights" to fear of loss of control. Just glad to know I'm not alone and that there is a place for support!

-- DavidMichaelPhillips - 10 Mar 2006

Edit | Attach | Watch | Print version | History: r24 < r23 < r22 < r21 < r20 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r24 - 2006-03-10 - DavidMichaelPhillips
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.