Wiki-based Portal, Using a Wiki as an Organizational Portal

This article and presentation were originally published as part of the Tri-XML 2006 conference.

{SUBMIT()}{SUBMIT}

Executive Summary

This article explores the use of wiki-based technology as an organizational portal. The corresponding presentation combines a demonstration of a wiki-based web site with a discussion of the process of its development. We explain why we chose a wiki-based content management system (CMS) as the basis for the portal for KeyContent.org. We compare various tools and discuss other sites that have implemented similar software for collaborative solutions. We combine a demo of a wiki-based web site, KeyContent.org, with the discussion of its development. We conclude with a summary of benefits of using wikis as an organization's portal.

This article and presentation were originally published as part of the Tri-XML 2006 conference; July 27-29, 2006 and is available online at: http://www.keycontent.org/tiki-editpage.php?page=Wiki-based Portal, including the slide show for the presentation. This content is published under a Creative Commons Attribution-NonCommercial-ShareAlike license.

Author Bios

Bill Albing has over 15 years experience in engineering and technical writing and is currently with FarPoint Technologies while pursuing interests in XML and wikis. Rick Sapir has almost as many years writing, editing, and designing technical communication and is currently with Oracle. Together, with Sherry Steward, they founded KeyContent.org.

Pick a More Social Portal

Signs that you have outgrown your web site

There are several indications that you have outgrown your existing HTML-based web site:

• Too many pages not searchable (or search databases not connected)
• Too many requests on IT dept or on web manager by content developers
• No sense of ownership of relevant parts of web site
• Other groups developing their own wiki or blog or other splinters

As organizations discover the social aspects of the web, many are moving their web sites from the defacto static HTML pages or client-server model of serving up pages to an interactive type of portal — more in line with a paradigm that allows a dynamic interplay of users and content.

Although many professional associations could be moving toward offering these more social forms of web interactivity, many are hesitant. Instead they continue to use a top-down model that is tightly controlled and slow to evolve.

Reasons to "Go Social"

We faced this problem and we had to answer the question: "Where is your organization going?" Because if it wants to do things the old-fashioned way, then don't change. But most organizations are realizing that to compete and to meet customer needs, they have to cooperate and collaborate with a host of partners and more "social" web portals are a way to work with that reality.

• Internal groups need more collaboration
• More groups need to cooperate, both internal and external
• Financial constraints dictate an economy of (social) scale
• Innovative groups need dynamic tool(s)

But there are several other reasons to make the move:

• Easier administration — more automation because of the software on the server and this includes version control, etc.
• Easier maintenance — with more direct ownership of the content, creators of the content edit their own pages directly.
• Easier collaboration — content development is now collaborative and social.

We offer a real-world example of a wiki-based site that is in use by professionals from around the world.

Our own decision to use a wiki came from seeing the limitations in existing solutions for professionals to share information.

KeyContent.org is not:

• A listserv or mailing list (techwr-l).
• A bulletin board forum (STC Forum)
• A repository (Eserver)
• A static site STC chapter site with HTML and PDF only.

Is Web 2.0 for Real?

Yes, though the change from existing web sites to new, more interactive portals is evolutionary not revolutionary and the line between Web 1.0 and Web 2.0 is not a sharp line. But many sites are becoming more social and more interactive and moving in that direction.

Yes, Web 2.0 is arriving, piecemeal, some technologies (like AJAX) and some companies (like Google) but not all at once. It is a move from HTML to interactive pages.
Yes, but only as real as you make it
The rest of the world is discovering it(and isn't going to wait for you)
Some are already planning Web 3.0, etc.

For more information, see "What is Web 2.0" by Tim O'Reilly.

Select a Wiki-Based CMS

What are the options

Once we made the decision to offer a social portal, we needed to select among a range of choices. Broadly, this includes several types of solutions:

1. SharePoint services based document environment
2. Wiki-based CMS packaged based portal
3. More complicated virtual community that incorporates documents, forums, etc.
4. Stand-alone, web-based, collaboration tools (such as Gliffy, Jot, Google, Writeboard, etc.)

And on top of this is the decision about whether to host it yourself on a server internal to the organization, or whether to allow a third-party hosting service to host the wiki (or whatever) as well as the web/internet service.

What is a wiki

A wiki, from the user's point of view, is a "website that allows users to add, remove, or otherwise edit and change content very quickly and easily" (source: Wikipedia).

From user point of view:

• Ability to edit content on the site
• Edit from Web browser

The keys here are:

• The ability to edit content
• Making it quick and easy

From the administrator's point of view:

• More installation and setup
• But freedom as package handles admin
• Users manage content
• User admin easy; version control etc.

From an administrator's point of view, there is more setup — setting up the software application on the server, but once setup, it removes you from having to worry about individual pages and moves the development effort to the content creators.

If you perform an internet search for CMS Software, you'll find more than 73 million matches. These range from enterprise solutions from Mircosoft and Oracle to smaller (but no less capable) opensource solutions.

Our requirements included:

• Opensource (GNU, LGPL, GPL, etc.) with active developer community
• Limited "forked" development (such as phpNuke and its clones)
• Database driven (as opposed to flat files)
• Limited hosted requirements (such as no root access)
• Lots of features: wiki, articles, forums (bulletin board), calendar, RSS generation and syndication, FAQs, and link directory management... but with a unified end-user experience.

The Opensource CMS site provides working demos of hundreds of opensource and CMS Review provides a side-by-side comparator of different systems.

What is TikiWiki?

After lots of searching and test installations, we found
Tiki CMS/Groupware, also known as TikiWiki. TikiWiki is "a web-based Groupware and Content Management System (CMS)... [that] can be used to create all sorts of web applications, sites, portals, intranets and extranets." TikiWiki supported all the features that we needed, plus many (many) more.

TikiWiki is a PHP application comprised of the following parts:

• The database stores all the information (settings, options, etc.) as well as the actual content (the text, graphics, comments, etc.) on each page. TikiWiki supports all the major databases including MySQL (used by KeyContent.org), Sybase, and Oracle.
• The application is written in PHP a scripting language that contains the "business logic" for running the portal. By using ADOdb (a database abstraction library for PHP), information is quickly and easily accessed the database.
• The presentation layer uses Smarty, a template engine for PHP. This allows the separation of application logic and content from its presentation.

Parts of TikiWiki:


We will look TikiWiki/CMS (http://www.tikiwiki.org), the technology behind KeyConentent.org, and compare our solution with others, including MediaWiki (the wiki engine behind Wikipedia, arguably one of the most successful collaboration projects).

Develop a Full-Featured Portal

So, to develop a full-featured, interactive, "more social" portal, follow these steps as we did:

• Pick the necessary tools
• Create "Key" areas
• Overcome user fear
• Define editorial control
• Handle installation
• Handle customization, choose theme
• Handle wiki package updates
• Fight spam

Pick the Necessary Tools

TikiWiki includes more than 50 "basic" features. To create our portal, we wanted to provide the maximum functionality (and flexibility) without overwhelming users. We chose:

• Articles (wiki pages)
• Sample page (sandbox)
• RSS feeds (both creating site-based feeds and syndicating feeds from other sources)
• Blogs
• Resources (links) (Categorization key)
• Events / Calendar
• Search
• i18n support

and why

• Collaborating with graphics
  • TikiWiki's internal graphics engine (JGraph)
  • Gliffy
• Syndicating other sites' RSS feeds
• Articles (wiki pages)
• Create a sample page (sandbox) for learning the syntax
• QuickTag buttons to automate the syntax
• Blogs

But what's the difference between posting an entry to a blog (and letting folks comment on it) and creating a wiki page (and letting folks comment on it)?

• Resources (links) - Categorization is the key.
• Events

Create "Key" Areas

(Bill to add content here.)

• Articles as wikis (Key Articles)
• Calendar events (Key Events)
• Resource links (Key Resources)
• Blog (right now just one, but in future, each user)

Overcome User Fear

(Bill to add content here.)

• Some users new to wiki
• Some users new to collaboration
• Some users new to our site
• Some users want ownership/control

Define Editorial Control

(Bill to add content here.)
Collaboration requires new editorial process
Several stages – some articles reviewed, some auto accepted
As site grows, assign editors to subsections of content areas

Handle Installation

TikiWiki installation is straighforward. Beyond the basic requirements of PHP, libraries for specific options (such as for image processing or webmail integration) and a database server, you'll simply need access to the webserver.

Depending on your web host, there are two options for installation:

• Using a control panel
• Manual (via FTP)

Web-based host control panel applet

If supported by your web host, you can use Fantastico to install TikiWiki. Fantastico is a CPanel (control panel) add-on for web hosting management software. It can automatically install third party applications, eliminating the need to upload files via FTP and manually create databases.

Sample Fantastico Control Panel


Some of the advantages of using Fantastico include:

• Quick and easy
• Installs all necessary files
• Creates and configures database
• Requires the web host to update the installer

Some disadvantages include:

• Unable to select a specific version to install
• Cannot overwrite defaults

Manual installation

Instead of selecting a Fantasico-based installation, you can manually install the necessary files yourself.

1. Download (~10MB) the latest release (from SourceForge.net).
2. UnZIP and and FTP to web host
3. Create a database
4. Use TikiWiki's installation script to connect to the database and create the table structure

Sample TikiWiki Installation Screen

Handle Customization

There are several ways to customize a package. One is to select a pre-defined theme. You want to establish a unique look apart from other users of the same package, a branding that identifies your organization.

We recommend that you avoid customizing the business logic (in the PHP code) and customize only the presentation level (through the Smarty templates).

TikiWiki ships with about 20 bundled themes. There is also a theme-specific TikiWiki site that allows you to review each theme. These themes run the gammet from standard, three-column layouts to interpretations of other popular themes (such as WikiMedia and Wordpress).

Sample TikiWiki Themes:
TikiWiki Simple: Click for full-size image.	MediaWiki: Click for full-size image.	Wordpress: Click for full-size image.

TikiWiki-based theme control: Site Identity

By using TikiWiki's Site Identity feature, you can easily customize your site from within TikiWiki. This means that:

• You only need to log into the site (no other software requried).
• All customizations are maintained within the database, as part of the site.

Some of the items you can customize with the Site Identity include:

• Adding custom HTML code
• Using breadcrumbs
• Adding a site search form
• Implementing banners/ads

Sample TikiWiki Site Identity Options:

Site-wide themes

You can create a custom site-wide theme by creating custom (or modifying the default) template files (TPL). These template files contain the XHTML markup (for presentation) and Smarty tags to obtain data from the PHP files (for business logic).

The following example shows a TPL file that will display a table of users; listing their name and email address. The PHP file that calls this template will pass the necessary variables and array that contains the actual data.

Example of a Template (TPL) File:
 <html>
  <head>
   <title>Page Name {$page}</title>
  </head>
 <body>
 <p>This table lists all users in {$sitename}:</p>
 {$if users ge '1'}
 <table>
  <th>
   <td>Username</td>
   <td>Email</td>
  </th>
 {section name=list loop=$listusers}
  <tr>
   <td>{$listusers[list].user}</td>
   <td>{$listusers[list].email}</td>
  </tr>
 {/section}
 </table>
 {else}
 <p>No users.</p>
 {/if}
 </body>
</html>

In addition to custom TPL files, you can can also create a custom CSS stylesheet.

You can select a site-wide theme (or simply select a different CSS stylesheet) from the Administration menu.

Sample Site Theme Options:

User themes

In addition to the site administrator's control, each user can customize their portal experiece. This includes selecting a unique theme for their visit and interface language.

Sample User Theme Control:

Providing translations and i18n support.

TikiWiki provides two levels of translation support:

• Translating the "standard" TikiWiki interface components
• Linking translated content pages

The base installation contains approximately 80 translations (in varying degrees of "completeness" for all of the interface elements. Users can select their interface language from their preferences page:


Content pages translations are actually separate wiki pages (for each language), then "associated" with each other. The interface provides an easy method to switch between page translations.

Handle Wiki Package Updates

TikiWiki has a very active developer community, with a 99.5% SourceForge.net activity rating . All releases (even x.x.x upgrades) are full installations. This means that the typical update process is:

1. Backup all customized files (TPL and PHP)
2. Backup the database
3. Install the TikiWIki version (unZIP and FTP all files)
4. Run the TikiWiki installation script to upgrade the database (typically running an SQL script)
5. Compare your customized files (TPL and PHP) with the new TikiWiki files and forward-port your customizations

Fight spam

As with any more social use of the Internet, a social portal will have spam as an issue. All forms of user inputs, article requests, event entry, etc., can result in spam. Filters are possible but not all of them are built in to the package you use.

• Requiring registration vs. openness — Require email validation to register
• Comment spam — Comments available only to registered, logged in users
• Directory submission — Uses CAPTCHA
• Event submissions — Uses CAPTCHA
• Sping (trackback pings) — Disabled trackback functionality
• "Closing" the sandbox
• Using image verification — Uses CAPTCHA

Learn from Our Implementation

Accept Wikis' Limitations

Package is not all things to everyone
Not HTML
Not WYSIWYG
No standard wiki syntax
Give up some control of admin
Give up some control of content

Although wikis can be powerful and useful, they are not without distinct drawbacks and limitations:

• Not HTML
  YAML (Yet Another Markup Language)
• Not WYSIWYG
  Wikis use a markup syntax – not the WYSIWYG (what you see is what you get) interface used by today's word processors and publishing software. Although there are many addins (such as Java applets) that can be used to give WYSIWYG editing, they come with their own (additional) requirements.
• No wiki syntax standardization.
  Different wikis use different syntax. For example, the syntax to create bold in TikiWiki is __bold__ . Many other wikis have their own syntax:

Wiki Software	Syntax for BOLD
TikiWiki	__bold__
Kwiki	*bold text*
Wikimedia	'''bold text'''
DocuWiki	**bold text**

See Microformats.org for additional information.

Maximize Wiki's Advantages

Create new pages on-the-fly
ANYONE can edit with only a browser
Automated admin
More direct ownership of content

• Creating new pages on-the-fly
  To create a new page, a user simply creates a link to the page (from an existing page), then follows the link. The wiki software automatically creates the new page (in the database).
• ANYONE can edit with only a browser
  Because wikis use a text-based markup interface (instead of WYSIWYG), you can edit the wiki using nothing more than a browser. No additional software or plugings (JavaScript, Flash, etc.) is required. It is truly cross-browser and cross-platform compatible.

Who Else Can Benefit from Using Wikis

• Any group!
• Local chapters of professional associations and user groups (Tri-XML, STC Chapters)
• Non-profit social agencies and homeowner groups
• Intranet inside a corporation

Conclusions

Wikis are powerful packages and perfect for collaborative publishing but really part of the picture. Social software is gaining acceptance as people discover that connectivity is one of the most important aspects of the web and the emphasis in the new "Web 2.0" is going to be much more about what people can do and how they can connect immediately to others. Wikis are a step in the right direction and they are the right tool for some situations. For KeyContent.org, which sees itself mainly as a white board for professionals to record and share their ideas, it is the right tool for the job.

• Wikis are powerful packages
• Social software gaining acceptance
• Wikipedia and KeyContent are success
• You can use wiki

---