You can't be fired if you choose for these 10 wiki introduction rules

March 31st, 2010

The article "Top 10 Organizational Wiki Tips (and how to use them)" is already some time out there, but it has become somewhat of a special guidance to us.(See http://www.ikiw.org for more fine content on wikis)

In 10 points the do's and don'ts of introducing a wiki are clearly laid out. Introducing wikis can be darn hard, but also amazingly simple. If you don't do anything else, follow at least these rules. There are little other things that are not covered by them.

In the following set of articles to be published over the coming weeks, we'll be highlighting some of the pitfalls and advice we've learned the hard way.

Summarized the wiki tips revolve around following principles:

  • Lead by example. Relentlessly put content relevant for your organization in the wiki. Mail references to the wiki to everyone.
  • It's better to have an unstructured, unfinished page in the wiki about a topic than to have nothing at all. Mark text to be completed as 'to be completed...'
  • Know you are in for the long run, you'll get it up and running in a matter of months, not weeks.
  • Let the social aspect work, your wiki should not be something only you can write. Put incomplete sections in there that team members will need to complete. Give 'write' privileges as much as possible

Watch this space for more information in the coming weeks.

I am hurt

March 23rd, 2010

What am I to do? Everybody seems to hate my good old friend MSWord. I saved a twitter search on MSWord in my tweetdeck account, so I am confronted with it daily. About 95% of all tweets are about how people hate it. Especially the autocorrect seems to upset users. What I can't understand is why people act so irrational about the attempts Word makes in correcting what it finds.

Sometimes I help people by tweeting them back on some style issue or page numbering thing. Often it is quite useless: people have decided to hate it and some dude tweeting them advice won't change their determination to accuse Bill Gates of all the misery in their lives.

Honestly I feel helpless when the autocorrect feature isn't on. When typing in another language, or when using some other program than Word, there is nobody there to help you.

I would guess the Microsoft usability labs have made their homework. Most likely, the big majority of the user community likes how the thing helps you correcting errors. Big lesson for the marketing guys however, nobody's tweeting on how happy they are with MSWord. Maybe I need to go on a MSWord Good Will Pelgrimige. To honner my 15 year old friendship with the thing.

What about a daily #HappyHappyMSWord tweet? Spread the good vibes. Reassure the lonely writers like me they are not alone. Because honnestly, what other program is there to put all your thoughts through this creative process you call thinking and gets it outlined in bullets, tables, paragraphs and alike? Who wouldn't wish life had this magical ctrl+z to undo what you just said?

I guess there is little hope for those determined to be unhappy. I, for one, am very happy MSWord user. Please reply with what category you belong to.

50 tips to get your wiki up and running

March 19th, 2010

In the past few weeks we have tweeted daily on tips to start a wiki (#wikitip) and keep it alive. We have assembled the list here. For your reading comfort we have grouped them according to the theme. Let us know which ones you like best and make sure to comment and add your own.

How, when to start a wiki

  1. Name your wiki a knowledge base
  2. Whenever you need to get 4 or more people aligned on a topic: get yourself a wiki.
  3. Frequently asked questions are one of the best topics for a dedicated wiki.
  4. Share your wiki with your customers and suppliers for support issues.
  5. Don't have a crm system? Set up wiki page/customer and use search to find customers/contacts/projects/tel nrs.
  6. Member of a club? Set up a wiki to document club meetings, events, member pages
  7. Student? Set up wiki for old exam questions.
  8. Set up wiki for your unit's SOPs (standard operating procedures)
  9. Meeting room/overhead reservation: set up wiki page
  10. Organizing a course? Set up a wiki with all url's, background articles, section highlights,...
  11. How to use a wiki to set up a new website? Nice customer case on Industry Week.
  12. Create a dedicated wiki for any event: post agreements, agenda, participants, presentations
  13. If you have no formal bug/cr tracking, consider using a dedicated wiki.
  14. Crisis situation? Consider setting up a wiki.


Rules of thumb

  1. Read a wiki as a new employee on his/her first day: can he/she understand the work of the team?
  2. Demystify your wiki: Give everyone a personal page, everyone will at least update one page
  3. Lower the barrier to enter new information by agreeing on a [draft] flag in the page title.
  4. Agree on: "If it's not in the wiki, it is not agreed"
  5. Top 4 wiki enemies: intranets, knowledge bases, email and shared network drives
  6. First page in your wiki: personal page explaining who you are and what you do. It gets it going in the right way.
  7. Give as much as you can people update rights
  8. Add scaffolds to the wiki, that are outlines that will guide people
  9. Almost spring! Yet another reason to clean up that good'ol wiki main page


Get attention, keep attention

  1. If you get your wiki up and running, you'll to spend effort to get people coming back to the wiki.
  2. Create reasons to visit your wiki: Create meeting reservation page on the wiki
  3. Refresh your home page from time to time (e.g. announcements, new picture,..)
  4. Build up a glossary of terms in a wiki
  5. Mail important wiki updates to team members: mail the url, not the page.
  6. A project plan is more than tasks and deadlines. Enter all deliverables&task descriptions in a wiki.
  7. Create reasons to visit your wiki: Add all meeting agendas + minutes + actions on the wiki (this introduces edit cycles)
  8. Include wiki updates as regular project tasks. Assign task owners.
  9. Look on slideshare.com for fancy wiki introduction slides
  10. Add your company wiki url in every team member's email signature
  11. Add a team member's famous quotes page. Add all stuff too embarrassing for public tweeting
  12. Create reasons to visit your wiki: Create a staff list + contact info
  13. Create reasons to visit your wiki: Add team indicators to the wiki
  14. Put number of wiki updates as a team indicator on the team room's whiteboard


This should go to the wiki

  1. Watch out for emails with attachments, probably this can go in the wiki.
  2. Topics to be provided are best marked with: "please someone add this page on xyz"
  3. Agreements on processes, best practices,... add them on a wiki page
  4. Paste sections from the project methodology you are supposed to use in your project wiki
  5. Ask at least twice per day: can I find that in the wiki? If not, have someone add it.
  6. Create a few wiki pages with ideas for improvement. Note down decisions: reject, implement, onhold
  7. Migrate word documents with revision marks to a dedicated wiki page
  8. Add team members' holiday schedule in a wiki page


Get it rolling

  1. Add a phone book page with msn-id, skype-id, homepage,.. for all team members
  2. Add a recommended use page to set out wiki guidelines, terms of use, wiki purpose, etc
  3. Break up overly long pages into sub pages


Special category

  • Need a personal wiki? Use tiddlywiki, a wiki in a file, works everywhere&every time

Can WordonWiki be compared to MS SharePoint?

March 17th, 2010

In a blog post of Martin Seibert called MS SharePoint as a Wiki: Few Functions, less Compatibility the author gives his view if MS SharePoint could be used as a Wiki.

His answer is simply "No".

Being this Microsoft Word dependent webservice, we looked closely to see if any of his arguments could be applied to WordonWiki. Let's run down the main reasons the author gives to justify his view.

Speed

MS SharePoint's architecture allows for a multi-server setup, forcing libraries and documents to be downloaded from one server to another. As there is no preview function, the document needs to be opened before it is viewable.

Thankfully, WordonWiki operates slightly different. It only requires you to download the page in case you need to edit it.Further optimizations will buffer pages on the user's machine to speed up even further the edit operation.

User Productivity

We were surprised to know MS SharePoint does not have a full-text search feature. This was foreseen in WordonWiki right from day1, requiring us to foresee special full text tables that can be indexed by mySQL text indexes. Not only for the current version of the page, but across revisions as well.

Lack of compatibility

Clearly you need MS Office on your machine if you want to work with MS SharePoint or WordonWiki. However unlike MS SharePoint, WordonWiki works on all major browsers like IE, FF, Safari and Chrome.You wouldn't settle for less. Nor would we.

Hide or Share

By default, MS SharePoint's documents are hidden, you need to flag them as public to make them visible. Indeed the exact opposite of what we expect from a wiki.

Origin of the product

MS SharePoint originally was a 'portal' solution. It has some data centric features added and the recent addition is the wiki feature. I've been at customer workshops where people actually believe that SharePoint's Wiki solution is as good as any. Clearly a big hooray for Microsoft's marketing departments.

Another big nono that Microsoft faces is the fact that MS SharePoint is very 'document' centric. This document centric strategy is what made Microsoft great in the 90ties. However, a wiki is basically 'page' centric. Microsoft has become big on this document adagio, but it doesn't translate it well to wikis.

Usability

Overall, SharePoint has a considerable learning curve. It has too many bells and whistles. Granted, it can do everything from making coffee to walking the dog, but that is not always what you need. There is a definitive need for simplicity.

The conclusion

There are many more points the author makes, but we covered those relevant to WordonWiki. The view of the article is critical but offers many insights on the nature of how and why people use a wiki. We feel that we live up to that challenge with WordonWiki. However, the last word is always with the user. Please comment to give us feedback.

Wiki's haven't grown up yet

March 16th, 2010

Searching for some competitive wiki overviews, the top sites that google showed were:

What is strange about these overviews is that both use the product's programming language as its main or primary structure. Who would want to know that? I can understand the IT guy having to install it is wondering what prerequisite libraries to install, but no end-user, manager or project leader should be bothered by the programming language of the tool.

For us that is one more sign that wikis and wiki usage haven't grown up yet to meet the challenges of the corporate world. These products were created by the tech community and are still trying to grow beyond that. Up to this day, we are confronted with people arguing why anyboy would need Wysiwig editing in a wiki. Luckily most wiki tools have now a wysiwyg option in their offering.

Not to be underestimated is the effect of wikipedia. Wikipedia has such a status that when people talk about 'putting it in THE wiki', they implicitely mean 'wikipedia'. As a result, there is an huge number of mediawiki installations. Installed out of the box, mediawiki has no support for wysiwyg.

Looking at the advantages a wiki can bring in most teams, it's a pity we are still struggling with the 'techie' image of the wiki usage. We talked to many people and all too often you get the same complaints: 'If only our business users would be using the wiki', 'Why can't we get the people from the other departments on the wiki?'

One of the greatest resources on wiki selection is http://www.wikimatrix.org. The site offers great features to compare the different wikis and we are happy to say the programming language is just another feature you can use to compare wikis.

If you got on this blog post using google search on 'wiki' and 'programming language', we won't dissappoint you with the graph below as it is currently shown on wikimatrix (look for an up to date version on http://www.wikimatrix.org/statistic/Programming+Languages)

Top programming languages for wikis, see wikimatrix.org

Attack the collaboration emails

March 11th, 2010

I've seen on many projects how email communication is still the number 1 choice when it comes to online communication. The gigabytes of requirements, specifications, meeting minutes, user documentation, test cases send in emails must be staggering.

Yet it is probably one of the least effective forms of communication. It can get lost, you never find it when you need it, you're never sure who has the last version. I have done my fair share of consolidating feedback from multiple sources on the same document, only to find out that after I finished, there was another feedback with revision marks in my inbox.

The wiki page == the document == its url == its history

The key thing that makes wikis what they are is the simple truth that there is no other instance of the wiki page than the one pointed to by it's url. So project team members and the organization's management can only mail a pointer to the thing, not the thing it self.

How to set up a wiki for a project?

The most basic partitioning you can do is divide your projects into areas, each with its specific features, audience and content. I have see following categories in the more successful project wikis:

  • Customer information
    All that is linked to the customer, contact persons, contracts, security guidelines.

  • Team information
    Who is who, skype id, msn-names, mobile numbers, flickr user name, whatever topic you are unlikely to find in the company address book.

  • Project requirements
    The heavy stuff: requirements, specification, PID (Project Initiation Document), ...

  • Test, Deploy and Build
    In case of a software development team, how to build the software, prerequisites, steps to go through, automated or manual tests that need to be checked of before shipping.

  • Meeting corner
    One page per meeting type works best. E.g. list the weekly team review meetings on a page with the same name. The do's and don'ts on this meeting are consolidated on the summary page.

The idea to put up the spaces like this is that each question that arises is sure to fall into one of these categories. I am sure you get the idea and can come up with what you would list there.

To get the ball rolling and to kick some *ss, what about following, let's say, less likely choices:

  • Famous quotes page
    Posted by anonymous, to embarrassing to tweet, yet to memorable to forget.

  • Team member's bio page
    In this way you'll be sure there's at least one page written by everyone on the team.

  • Team Propaganda Corner
    The rules the team decides on should be listed in slogans on this page. Learnings that the team came up with, crucial customer feedback nobody should forget, the team's quality or productivity dashboard indicators go here.

You'll never return to email...

...when this is set up. You will need to do some selling, hard, relentless and sustained dedication is what it takes to get the content ball rolling. We hope that the tips above will help you get started.

Some interesting links

Is WordonWiki a wiki?

March 8th, 2010

The original article of Ward Cunningham defines a wiki as "The simplest online database that could possibly work.". There is also a longer version that goes as follows:

Wiki is a piece of server software that allows users
to freely create and edit Web page content using any Web browser.
Wiki supports hyperlinks and has a simple text syntax
for creating new pages and crosslinks between internal pages on the fly.

Wiki is unusual among group communication mechanisms in that
it allows the organization of contributions to be edited in addition to the content itself.

Like many simple concepts, "open editing" has some profound and subtle
effects on Wiki usage. Allowing everyday users to create and edit any
page in a Web site is exciting in that it encourages democratic use of
the Web and promotes content composition by nontechnical users.

We've read with interest this definition and verified if we could match WordonWiki to this definition. For the simple definition we could match that definition certainly. As indicated in previous posts, this software was developed out of a personal need. Textile or wysiwyg wikis simply did 'not work' for we wanted it to do.

The longer definition is more explicit. All things like on the fly creation of pages and links between pages are well supported by WordonWiki. We're not sure how to read the requirement of a 'page revision history' in the definition, but this is 'de rigeur' in today's wiki systems.

Where WordonWiki deviates from the pure form of the definition, is the 'edit Web page content using any Web browser' requirement. While WordonWiki certainly supports easy editing, it does not use 'the browser' for the editing process. Rather it uses the browser to trigger the editing process.

Purists have told us that we don't qualify as a pure wiki, exactly for this reason. However, we have argued that other wiki's also would not fit. There are a number of features that today are taken for granted, but that would disqualify a wiki taking this strict definition into account:

  • Login required for read or edit
  • Page templates
  • File attachments

The truth is that this definition which dates back to 1994 is, while visionary and extremely helpful to define the concept of a wiki, currently a bit outdated. We need to go beyond the original definition and look what makes the wikis of today work:

  • Create content that is easy to navigate and edit by all its authorized users.
  • Edits can always be reverted.
  • It is easy to create new pages and create links between pages.

There is no direct reason a wiki should be accessible through a browser, however as long as we don't have any other universal access, we need to stick to it. This is where we augment the rich editing feature of the standalone Microsoft Word document. Even when it is kept inside a sharepoint installation, it is impossible for anyone to know where the 'real' source of the page is kept. A confusion that is not even existing in a wiki as its page is equal to its location is equal to its content and is equal to its full revision.