Wiki as forum, FAQ, HTML editor, XML editor, or CMS?

Wiki as the new FAQ

I discovered and have been meaning to write about Wiki is the new FAQ, an excellent blog post talking about SAP’s use of a wiki featured in an article in the Wall Street Journal. I especially like the play on words in the title. Reminds me of “brown is the new black” or “pink is the new blog,” hee hee.

A wiki can be a Frequently Asked Questions repository, much like the knowledge bases in their heyday in the late 80s. My favorite line from the blog entry has to be its closer: “It’s about a different way of thinking around how to interact with the community.” And that is what I have explored with my wiki presentation, about how to build community with a wiki and be an active member of that community. But what are other uses of the wiki?

Wiki as the next-generation customer forum

For many information seekers, wikis are better than forums because they are more easily searched and once you get a hit, the articles are meant to be scannable. Compare and contrast this to a long thread on a support forum where the answer to your question might be buried in the middle of a discussion about the mysterious beep in someone’s house. In my beep example, there are literally 78 pages of forum discussion, and if you read through the threads, you discover that a group of people took it upon themselves to go to the person’s house to find the beep. It has probably two years of forum discussion around the possibilities. Quite a fun and entertaining read, though, but not that efficient. Still, consider the community that built up around beep troubleshooting. Great stuff there.

But consider that your software users might not have the time to read through even a few pages of a forum discussion about a solution to their problem. That is where a wiki could be more useful than a forum. While forums are a fun online community for many, wikis might be the new generation of forum and many wiki engines offer comments on each article which are the next evolution of a forum – you can discuss the article itself. Another blogger, Leigh Blackall of Learn Online, discovered “The gold in a wiki is often in the discussion pages.”

Wiki as an easy HTML editor

Wikis originated as the quickest way to create a website without having to know HTML code. Really, wikitext is all about quickly doing headings, paragraphs, and lists.

Unfortunately each wiki has different rules for how to indicate a heading or list item or type of list. For some, it might be easier to just learn HTML code. And in the case of the Drupal CMS, there’s the ability to either use a rich-text editor or hand-code the HTML. It’s easy to troubleshoot when you can just view the HTML code, but what’s odd is that sometimes the resulting <div> tags generated out of your webform entries in Drupal seem to overlap.

But most wiki engines offer the fastest and easiest way to make a web page with a URL that you can consistently refer to.

Wiki as the new book

Some folks are pre-populating their wikis with book content, which is always an interesting test of what parts of a book are considered essential for “bookness” or “wikiness” – do you keep a table of contents? Is there any index? What page metaphors do you subscribe to in the wiki? These questions can be answered by looking for examples and analyzing their success. I especially like using wikis for the wiki aspects that go above and beyond books. For example, I’ve been exploring the Meatball Wiki site (Thanks Janet!) – and they have an excellent page with all sorts of Indexing Schemes categorized, such as Readership and Authorship which are fascinating for use in wikis as opposed to books. The Ontology category seems the most book-like to me, and I really like how that page offers ideas for all the possibilities that wiki offers.

Wiki as the new website

Does any company use only a wiki as its public-facing website?

Wiki as the new Content Management System

Eventually, the wiki can be the source files for important content, and I would guess there are people moving towards this wiki-as-cms system already. With my work with the OLPC project, I am learning more about wikis as source files, and found that the compare is actually quite powerful visually. Take a look at two versions of the demo or release notes from a release done in September. There is color coding and side-by-side comparison of text that is easily scanned for what changed, was added, or deleted. I’m learning so much about wikis for localization and translation efforts as well with the OLPC project. For example, this past week, I added links to translated content, such as the Spanish translation of the Simplified User Guide. The wiki engine itself (in this case, WikiMedia), lets me list the additional language pages in a blue bar on the original page, and then each language page automatically links back to the main language page (in this case, the English page.) Automatic is nearly always useful.

Do you see wikis being the next generation of other documentation outlets? Do tell.

10 Comments

  • November 21, 2007 - 7:13 am | Permalink

    Great article! I have implemented a wiki as an FAQ but with a twist. We decided that people may not always want to ‘read’ the answer so we created an audio FAQ where the text is there (for searching purposes) but we also provide the answers as a voice file embedded in the page. The wiki we use is CoactLive.com (www.coactlive.com) which allows us to do this quite easily. We’ve received very positive responses from our users, who in this case are Realtors. Our next project is to use more video in this context. I believe that supplementing wiki content with video will greatly enhance the user experience and if it’s easy to do, people will embrace the concept. We shall soon find out…

  • November 21, 2007 - 9:11 am | Permalink

    Hi Andrew, what a great idea, especially for your audience. I’m glad they are embracing the idea.

    I agree, video for documentation should take off once the toolset is in place. At Quadralay’s WebWorks RoundUp, I attended a presentation by Videoblogging for Dummies author Stephanie Bryant and am really excited about the possibilities for certain audiences. Her user base, med students, or let’s call them professional learners, jumped for joy at the prospect of lining up videos to watch to learn medical software. So thanks for sharing!

  • ffeathers
    November 24, 2007 - 2:07 am | Permalink

    Hallo Anne, Lots of food for thought in your blog :) At Atlassian, we’re finding that people are very keen to use the Wiki for all sorts of feedback. We have some wiki spaces where customers can create their own FAQ and ask others to respond. And then we have the more formal docs, where customers can’t create pages but can still add comments and respond to comments from others. Both types of space are used very enthusiastically by customers and support staff. As a tech writer, I really enjoy this type of direct contact with all the people out there. It makes the docs live :)

  • November 29, 2007 - 12:03 am | Permalink

    Actually, I was rather disappointed– from the title of this post I thought there would be some discussion of XML authoring based on a Wiki, not just HTML authoring.

    I’ve actually been involved in planning (not yet implementing) a Wiki-based system for editing (a well-understood, somewhat constrained) structured API reference documentation, for an app where many of the contributors of content don’t have licenses for or skills with Framemaker.

    Dokuwiki would be the basis of this, then a few plugins, and when it’s time to publish, the Dokuwiki pages would be parsed and converted into an XML format, then imported into Framemaker and published.

    Has anyone ever done anything like this?

  • November 29, 2007 - 9:06 am | Permalink

    Well, shoot, you found a huge flaw in this post – my title not matching up to the headings. Sorry about that!

    Your scenario is a great one for using a wiki as an XML editor. Especially when the people with the content knowledge and expertise are more willing to contribute to a wiki than to get up and running on FrameMaker. It’s interesting that you note the licensing costs associated with Frame – you’re getting FrameMaker in the end but through a “free” tool kit. Interesting.

    I’m also talking to someone next week about a round-trip DITA to wiki and back again method (edited to add: not sure about back again). I can’t wait, it sounds exciting.

    Also, some folks at Freescale here in Austin are doing a similar workflow to the one you describe, but they are having their subject matter experts input hardware specifications that will then be used in Framemaker manuals, I believe. Email me and I’ll connect you to Bob Beims who has started a semiconductor DITA working group at OASIS. With a DITA-based wiki like DITA storm, perhaps they’d have a toolchain similar to your Dokuwiki one.

    Thanks for pointing out the hole I needed to fill. :)

  • November 9, 2008 - 2:57 pm | Permalink

    This is an enticing post… I am looking for the “right” platform to begin embedding the following into a conventional (and brittle) Web site) with the plan of gradually replacing the old site with the newer customer-interactive content:

    1. Blogs
    2. Wiki for books and other topics
    3. Discussions
    4. Ratings
    5. Reviews
    6. Videos
    7. Slideware
    8. LOTS of gadgets and widgets…

    I would love NOT to make my users have to log onto or join yet another social networking site in order to participate..

    So, here are my questions —
    1. Which Wiki platform(s) would you recommend at this point?
    2. Can you point me/us to some great examples of Wikis that have incorporated some of the features we’re looking to implement??

  • November 10, 2008 - 7:35 am | Permalink

    Hi Patty – Thanks so much for stopping by!

    I’m not a professional web designer, but the first platforms that come to mind are Drupal and Twiki. There’s also Ning.com which gives you portability to other social networking sites, but since you said you don’t want to make users log onto yet another site, well, Ning’s not it either. :) A customer-interactive website on the scale you describe would probably be beyond a wiki, although plenty of web CMSes incorporate all the content you describe. Now I’m just talking in circles. :) You may want to talk to someone at Duo Consulting (www.duoconsulting.com) such as Michael Silverman or Sonny Cohen (see http://www.duoconsulting.com/about/people.cfm) for good ideas and examples.

    The most famous Drupal installations that I know of are popsci.com and dooce.com, but they do not contain wikis. You might want to look at flossmanuals.net, which is a Twiki installation, for ideas as well. I’ll keep thinking about other examples and email you if I come up with anything.

  • Joseph
    October 27, 2009 - 9:17 pm | Permalink

    I certainly wish my experience mirrored yours. But as a content producer, I find a wiki to be an absolute nightmare. I wouldn’t be surprised if my experience is unusual.

    This is an internal wiki that engineering uses to 1) track the progress of feature sets for the Agile sprints and 2) document use cases and feature specs for the functionality that they are creating for a sprint.

    The wiki uses FCKeditor and its a living nightmare to use. There is a rich text editor mode that rarely renders formatting correctly and a wiki text editor or pure code mode. I wouldn’t mind using the wiki text editor except the semantics are completely meaningless and tags are horrible for eye tracking. The tables alone are a living nightmare — I couldn’t imagine finding a particular cell and don’t even think about using merged cells. And don’t even get me started on lists (bullet and numbered).

    I would kill for a pure HTML editor. I’ve done web design in Dreamweaver and created help systems in Robohelp. I find HTML authoring is clean, straight forward and perfectly suited for a wiki. Instead I get this unwieldy kludge.

    Sorry for the rant. :( I was curious to know if my experience is unusual and I just got really unlucky. I hear such nice things about wikis; I just wish they were true for me.

  • November 3, 2009 - 7:20 am | Permalink

    I don’t think your experience is all that unusual. I’ve found the same thing when trying to mark up complex procedures – the simple markup for popular wikis (MediaWiki, Confluence) is a real detriment to complex explanation. I think many wikis are trying to be web-based content management systems but falling short of expectations for markup in trying to be simple. I was looking to see if WikiMatrix.org offered a list of HTML-markup wikis, but the only way I could find to look for them was the Markup Comparison at http://www.wikimatrix.org/syntax.php?i=33. It doesn’t have a comparison for table markup, unfortunately.

  • December 10, 2009 - 4:43 pm | Permalink

    We set up a wiki as an authoring, publishing, and content management tool for software documentation a couple of years ago.

    Over 200 engineers across the world contribute content. The 250,000+ “pages” of content is single-sourced, version-controlled, conditionally published, and all that good stuff.

    You can read about how we did it at http://sites.google.com/site/moremiscellany/works/wiki-publishing

    You can see some of the documentation at
    http://www.agilent.com/find/eesof-docs

    Take a look. Your mileage may vary: we won a company award for innovation right before our collaborative documentation environment got us outsourced :)

  • Leave a Reply