Wikis

Sue Fidler explains how the Wikipedia model is making the web more democratic.

Although we think of the web as a huge knowledge base, it is actually 'read-only' space. We can find a million online answers, but we are reading what other people have put onto their sites. This has become known as 'one webmaster syndrome': individuals publish content that many people might read but cannot contribute to.

That is fine for the one-to-many requirement of an organisational website, but it doesn't enable us to learn from each other. It is a huge textbook rather than a conversation.


Some thought that having an intranet would encourage learning by allowing people to load documents into a private space. For most of us, that concept died when we found that very few people would contribute.

Suddenly, the pattern has changed: the advent of blogs and 'wikis' (such as reference website Wikipedia, which allows users to update entries) has opened up the internet to an iterative and collaborative process.

Blogs can be collaborative, but they do tend to be personal, both in style and content. They are a great social commentary, but unlikely to be used for knowledge management.

A wiki (from the Hawaiian for 'fast') is designed to allow people to build, manage and share documents and learning. Every user can help shape navigation and content.

Wikis also offer the opportunity to make tacit knowledge explicit. We often bemoan the loss of learning and experience that staff turnover causes, but if we allow people the time and space, and give them the permission to share their knowledge, a wiki can become the repository of a vast amount of institutional learning.

For many it is a scary thought. Allowing everyone to know everything is hard. Giving up the reins of the webmaster and allowing everyone to contribute is even harder.

HTML emails (part two)

It's a common misconception that emails and web pages share the same design principles. There are significant differences. Take the HTML itself. It does not work exactly the same in emails as it does on web pages, so don't assume that your beautifully designed HTML page will come across in an email.

CSSs (cascading style sheets) are a classic example. Webmail tools modify the HTML to fit their own styles and window sizes. They strip out external CSS links as potential security risks. Most also strip out embedded style sheets. The only way to include CSSs is line by line, or to wrap your email in a "div" tag and use the style attribute. Similarly, all webmail tools replace your link colours with standard blue and purple. You can overcome this by using the "font" tag in your links.


Background images are stripped out by many systems, as are images controlled by CSS layouts, so keep things simple. Most importantly, make sure your email is readable without the images. Open it in your browser with the images turned off and see if it still makes sense.

Another thing to think about is forms. If Outlook users don't use Internet Explorer, they won't submit. Hotmail strips out the form tag completely so the data doesn't go anywhere. Mozilla, Yahoo and Gmail work, but the user gets a pop-up warning. For best practice, send the user a link to a web-based form; don't include the form in the email.

JavaScript, ActiveX and Flash never work the same way in emails, so avoid them. Similarly, frames and Iframes display wrongly or get stripped out by spam-blockers. If you must have moving images, use animated GIF instead of Flash.

So keep to basic HTML, leave forms and Flash on the website and keep the email as text and images.