Showing posts with label Twiki. Show all posts
Showing posts with label Twiki. Show all posts

Saturday, March 24, 2012

Twiki - Open Source Enterprise Wiki

In my last post on wiki applications, I mentioned that there are three types of wiki applications: public wiki, enterprise wiki, personal wiki. One of enterprise wiki is Twiki which is open source wiki. In my today's post, I am going to describe Twiki.

TWiki is a flexible, powerful, and easy to use enterprise wiki, enterprise collaboration and web application platform. It is a Structured Wiki, typically used to run a project management system, a document management system, a knowledge base, a team portal or any other groupware tool, on an intranet, extranet or the Internet. Users without programming skills can create web applications.

Developers can extend the functionality of TWiki with plugins. Users can create wiki applications using the TWiki Markup Language. TWiki looks and feels like a normal Intranet or Internet web site. However it also has a Edit link at the bottom of every topic (web page); everybody can change a topic or add content by just using a browser. TWiki fosters information flow within an organization, lets distributed teams work together seamlessly and productively, and eliminates the one webmaster syndrome of outdated intranet content.

TWiki has been downloaded over 500,000 times and is used daily by millions of people in over 100 countries. Some larger deployments have several 100,000 pages and over 10,000 users. TWiki is developed by an active open source community.

TWiki is installed on many web sites, mainly behind corporate firewalls. Many major companies use TWiki because it is very user friendly compared to some well established commercial groupware systems. Companies are deploying TWiki in different ways, and TWiki is quite flexible to adapt to different needs.

This is a non- comprehensive list of how TWiki is being used:

  • to replace a static intranet. Content is maintained by the employees, thus eliminating the "one webmaster syndrome" of outdated and insufficient intranet content;
  • as a knowledge base and FAQ system;
  • to design and document software projects;
  • to track issues (i.e. bugs) and features;
  • as a document management tool;
  • to collaborate on common goals;
  • as a software archive, i.e. the TWiki Plugins archive;
  • as a company internal message board, i.e. for job listings.

Twiki Major Features
  • Any web browser: Edit existing pages or create new pages by using any web browser. There is no need for ftp or http put to upload pages.
  • Edit link: to edit a page, simply click on the Edit link at the bottom of every page.
  • Auto links: web pages are linked automatically. You do not need to learn HTML commands to link pages.
  • Text formatting: simple, powerful and easy to learn text formatting rules. You write text like you would write an e-mail.
  • Webs: Pages are grouped into TWiki webs (or collections). This allows you to set up separate collaboration groups.
  • Search: full text search with/without regular expressions.
  • E-mail notification: get automatically notified when something has changed in a TWiki web.
  • Structured content: use TWiki forms to classify and categorize unstructured web pages and to create simple workflow systems.
  • File attachments: upload and download any file as an attachment to a page by using your browser. This is similar to file attachments in an e-mail, but it happens on web pages.
  • Revision control: all changes to pages and attachments are tracked. Retrieve previous page revisions and differences between them. Find out who changed what and when.
  • Access control: define groups and impose fine grained read and write access permissions based on groups and users.
  • Variables: use variables to dynamically compose your pages. This allows you to dynamically build a table of contents, include other pages or show a search result embedded in a page.
  • TWiki Plugins: enhance the TWiki functionality with server side Plugin modules. Developers can create Perl Plugins using the TWiki Plugin API.
  • Application Wiki: contributors use the TWiki platform to create web applications. The TWiki Variables, Plugins and sample applications offer a rich environment where domain-specific applications can be built efficiently by contributors with moderate skill sets. Developers can create new Plugins to enhance the functionality of TWiki even further.

  • Some example applications:
    • Call Center Status Board: simple status board where time and person can be picked from a list.
    • Change Request: generic change request application.
    • Meeting Minutes: keep track of meeting minutes with action items.
    • Search Book Titles: simple application to search a library of books.
    • Simple FAQ: FAQ with all questions on one page and an automatic TOC.
  • Templates and skins: a flexible templating system separates program logic and presentation. Skins overwrite template headers and footers; page content is unaffected.
  • Managing pages: individual pages can be renamed, moved and deleted through the browser.
  • Managing users: web based user registration and change of password.
  • What's new: see recent changes of TWiki webs. The change log can also be exported in XML RSS format for news syndication.
  • Statistics: create statistics of TWiki webs. Find out most popular pages and top contributors.
  • Preferences: four levels of preferences: TWikiPreferences for site-level; WebPreferences for each web; user level preferences; and page level preferences.
  • Conflict resolution: content is merged automatically if more than one user edits a page at the same time. In rare cases where a conflict cannot be resolved automatically, users are warned and guided to resolve the conflict manually.
  • Referred-By: find out back-links to a page.

TWiki has a plugin API that has spawned over 400 extensions to link into databases, create charts, tags, sort tables, write spreadsheets, create image gallery and slideshows, make drawings, write blogs, plot graphs, interface to many different authentication schemes, track Extreme Programming projects and so on.

TWiki as a structured wiki provides database-like manipulation of fields stored on pages, and offers a SQL-like query language to embed reports in wiki pages. Wiki applications are also called situational applications because they are created ad-hoc by the users for very specific needs. Users have built TWiki applications that include call center status boards, to-do lists, inventory systems, employee handbooks, bug trackers, blog applications, discussion forums, status reports with rollups and more.

The interface of TWiki is completely skinnable in templates, themes and CSS. It includes support for internationalization with support for multiple character sets, UTF-8 URLs, and the user interface has been translated into Chinese, Czech, Danish, Dutch, French, German, Italian, Japanese, Polish, Portuguese, Russian, Spanish and Swedish.

TWiki is primarily used at the workplace as a corporate wiki to coordinate team activities, track projects, implement workflows and as an Intranet Wiki. The TWiki community estimates 40,000 corporate wiki sites as of March 2007, and 20,000 public TWiki sites. TWiki customers include Fortune 500 such as Disney, Google, Motorola, Nokia, Oracle Corporation and Yahoo!, as well as small and medium enterprises,such as ARM Holdings, and DHL. TWiki has also been used to create collaborative internet sites, such as the City of Melbourne's FutureMelbourne wiki where citizens can collaborate on the future plan.

TWiki is implemented in Perl. TWiki is a cgi-bin script written in Perl. It reads a text file, hyperlinks it and converts it to HTML on the fly.Wiki pages are stored in plain text files. Everything, including metadata such as access control settings, are version controlled using RCS. RCS is optional since an all-Perl version control system is provided. TWiki scales reasonably well even though it uses plain text files and no relational database to store page data. Many corporate TWiki installations have several hundred thousand pages and tens of thousands of users. Load balancing and caching can be used to improve performance on high traffic sites.

TWiki has database features built into the engine. A TWiki Form is attached to a page as metadata. This represents a database record. A set of pages that share the same type of form build a database table. A formatted search with a SQL-like query can be embedded into a page to construct dynamic presentation of data from multiple pages. This allows for building wiki applications and constitutes the TWiki's notion of a structured wiki.

Friday, March 9, 2012

Case Study - Wind River - Twiki Information Architecture

In the "Case Studies" series of my posts, I describe the projects that I worked on and lessons learned from them. In this post, I am going to describe the project of re-structuring content and information architecture of a content management system based on Twiki in Wind River.

Wind River is a software engineering company that used Twiki as their content management system. TWiki is a Perl-based structured wiki application, typically used to run a collaboration platform, content management system, a knowledge base, or a team portal.

Content organization and information architecture in Twiki were such that users had difficulty in finding information they were looking for. This situation made it difficult to find, re-use, and update content.

This also discouraged further adding of the new content and thus created areas where no documentation existed and the knowledge instead of being shared was being stored in personal computers. Storing the content in personal computers presented a risk of it being lost because it was not backed-up.

There was a lot of obsolete content because no content owners have been formally identified and no retention schedule has been set up. Collaborative work on the documents and projects was accomplished by users sending links to Twiki pages. Without these links it was very difficult to find information. There was no information governance in place and so content management processes were very sporadic.

The task was to re-organize the content organization and information architecture of the system and to set up information governance to solve these problems.

I strongly believe in user-centered design, so I performed the users study. I identified stakeholders within each Wind River team and created the questionnaire for collecting users' requirements for the system re-organization and the usability issues.

Based on these requirements, I re-organized the content structure and information architecture of the system. The major key to this re-organization was that the structure is very simple and intuitive. I made navigation very simple, created very intuitive labels, made sure that there is not too much information on one page and a user does not have to scroll down a very long page, that each page has a correct breadcrumb, and created taxonomy of webs (the building blocks of Twiki). Based on this taxonomy, I re-organized the location of documents. I also enhanced the system search.

For each content type, document owners were identified and retention schedule was set up with the function to flag the content that would reach an expiration date according to the retention schedule. This flag function would send an email notification to the content administrator that a certain document reached an expiration date. This alert allowed the content administrator to contact the document owner for the decision on what should be done with this document: review and update, move to an archive, or delete.

User acceptance testing of the system was performed. Users were satisfied with the system's new information architecture and indicated that it became much easier to find information.

The system with new content structure and information architecture was deployed.

Information governance was set up. Group and individual training was conducted on ongoing basis.

The project was a success. Company management and users were very cooperative in helping to make this project a success. It helped to increase efficiency and productivity and thus saved Wind River cost because employees did not waste any time on searching for documents or recreating documents that already exist.

Lessons learned

1. User-centered design is paramount to the project success. When you design and build the system based on users’ requirements, they are going to use it. Users have the sense of ownership of the system which provides excellent starting point. They know that the system you are building will be what they need.

2. Top-down support is critical for the project success. Management support is a huge factor in employees' encouragement to use the system and in setting up and enforcing procedures for information governance.

3. Assurance of users from the very beginning that they will not be left alone with the system provided their cooperation.

4. User acceptance testing helped to encourage employees to start using the system. When they participate in this process, this gives them the feeling of ownership of the system.

5. Ongoing training after the system deployment with the new content structure and information architecture made user adoption smooth.