a little madness

A man needs a little madness, or else he never dares cut the rope and be free -Nikos Kazantzakis

Zutubi

10 Things I Hate About Wikis

OK, so wikis are a great idea. I have “embraced the wiki” as a great communication tool, and there are many, many benefits. But still they manage to get to me. It’s almost always down to one thing: execution. Execution by the implementors of the wiki, and execution by the people creating the content. So here it is:

10 Things I Hate About Wikis

  1. Wikis are the easiest way to create awful documentation. Lowering the barrier to entry is good, but if I see another open source project throw up a wiki and think they now have documentation, I’m going to scream! Perhaps we should call it lowering the barrier to stupidity (arrogance mine ;) ).
  2. WikiWords. Not all wikis are affected by this blight, thankfully. But don’t you love those that are, especially the knots you tie yourself in to manufacture a WikiWord when you just want to use a single word!
  3. Every wiki has its own syntax. Sure, HTML is too verbose to be convenient for editing wikis – it ruins the whole idea. Unfortunately, however, this has led to a proliferation of custom wiki syntaxes, each with their own quirks. Hence, working with multiple wikis is a pain, and every wiki has its own learning curve.
  4. Wikis mark the return of the content management dark ages. Once upon a time, we formatted documents in our word processor with font sizes, bold text etc. Eventually we realised this was a Bad Idea, and styles were born. (OK, introduced. Back in your box now, Tex groupies. And make sure the troff monster stays in there.) These days, nobody in their right mind creates a significantly-sized document without using styles. Then there was the internet. Remember the early days? The <b> tags? Eventually we realise this was a Bad Idea, and stylesheets were born (easy there, troff monster). Now we are back where we started again. I hope there are no LISP programmers in the room, because they’re bound to mention they “told us so”…
  5. Inexplicably poor navigation. Come on, wiki implementors, this should be one of your strongest points! Too often I find myself deep in the bowels of a wiki without a sensible way to navigate around. Sure, some of this is down to the wiki author, but there are so many opportunities for convenient navigation that are missed, by either not allowing the navigation or by hiding it away somewhere.
  6. Could anything be harder to read than a table written in typical wiki syntax? This is where the simplicity of the syntax falls flat on its face. The syntax works for basic, inline elements, but start to create strutured data and you become lost in a sea of ascii art (and not the good kind).
  7. Editing in a browser text area sucks! Possibly the only thing that sucks more is the half-assed rich text editing facilities wikis sometimes offer. Unfortunately, we’re pretty stuck with this one. Maybe advances in web UIs will help…
  8. Poor support for versioning. One thing I always hated about creating documentation in word processors is the inability to track changes and merge documents (yes, I know Word has an “implementation” of this feature – if only it actually worked). On the face of it, wikis have both the opportunity (text-based format) and the motivation (strong chance of concurrent editing) to have strong versioning and merging support. However, most of them don’t. Wiki implementors: this is a (largely) solved problem! No excuses! :)
  9. Losing 30 minutes of typing because my browser crashed, or I closed the tab, or some other minor tragedy occured. Thank god wikis are starting to implement autosave! Dragging themselves just a bit out of the dark ages ;).
  10. Wiki discussions, e.g. those found in the original wiki. OK, so wikis were a cool new idea. That doesn’t override the fact that forums and newsgroups already existed as a much better medium for online discussion!

Phew, that felt good. Now wiki lovers everywhere, I’m ready for you to tell me how I “just don’t get it”.

——–
Into continuous integration? Want to be? Try pulse.

Liked this post? Share it!

29 Responses to “10 Things I Hate About Wikis”

  1. April 19th, 2006 at 6:45 am

    Carsten Saager says:

    Maybe the Wiki era is already over. A large Wiki page is hard to maintain – you cannot easily tell which paragraphs are up-to-date and which are old c**p no one even bothers to delete.

    That’s how our Wiki died. This Forrest stuff from Apache was quite sound to me as an inside tool.

  2. April 19th, 2006 at 8:31 pm

    Khalil Bouhamza says:

    I would suggest to give confluence a try, many gripes you have with wikis are very elegantly addressed, it has built-in versionning, link refactoring, navigation is eased by the parent child relationships between pages and while editing, content is saved each thirty seconds. The look and feel smacks of polish and a certain spartian aesthetic if such a thing exists. It is not open source but a personal licence is kindly offered ( I am using one myself ).

  3. April 19th, 2006 at 8:39 pm

    Khalil Bouhamza says:

    I would suggest to give confluence a try, many gripes you have with wikis are very elegantly addressed, it has built-in versionning, link refactoring, navigation is eased by the parent child relationships between pages and while editing, content is saved each thirty seconds. The look and feel smacks of polish and a certain spartian aesthetic if such a thing exists. It is not open source but a personal licence is kindly offered, I am using one myself.

  4. April 20th, 2006 at 12:14 am

    Ted Dziuba says:

    What’s so hard about \left ( \sum_{i=0}^{\infty}{\frac{x^{i}}{i!}} \right ) = e?

    ;-)

  5. April 20th, 2006 at 2:33 am

    Juan Reyero says:

    You can get rid of the browser textbox using mozex on Firefox. I use it, it works: right click on the textbox, and get your favorite text editor launched. There’s even an emacs mode for wikipedia.

  6. April 20th, 2006 at 4:23 am

    Haje says:

    I think you have a great point. For a Wiki to work properly, it needs to be properly maintained by a team of ardent editors. And that only happens one place I’ve seen so far – wikipedia.

  7. April 20th, 2006 at 4:37 am

    Steve Wainstead says:

    1. Wikis are probably best at *ad hoc* documentation for a
    project-in-progress. The only benefit in making all of a project’ts
    permanent documentation in a wiki would be to allow the users to
    update it; but to that end, PHP’s manual is a great example of
    something better. Better an open source project has a wiki than
    nothing at all, which is far more common.
    2. WikiWords serve a useful implementation purpose; if you have as
    many contributors as Wikipedia does, then you have legions of
    people ready to make redirect pages for every variation in spelling
    people come up with. For the lexicon of a single project it’s not
    hard to come up with a convention for CertainWords; if you really
    enjoy typing [[stuff like this]] all the time, fine.
    3. Every wiki syntax sucks. I doubt any wiki implementor will disagree
    (I had to write the engine after all; it’s a pain in the butt). It
    would be lovely if the W3C drafted a spec on a common
    language. Probably one will emerge anyway.
    4. Every new generation of text manipulation systems will suffer the
    same thing. This is a people issue, not a programming issue.
    5. A wiki is not a heirarchical web site, no matter how hard you want
    it to be. You can impose that kind of restriction on one but it’s
    not the wiki way of doing things. A wiki is a graph; to that end
    it’s developed its own navigation tools (badges, categories,
    RecentChanges) and if you can’t find what you want in .5 seconds
    then the search needs to be fixed. Every wiki implementation should
    follow the Jakob Nielson guidelines for a search box:
    http://www.useit.com/alertbox/20010513.html

    When was the last time you used Yahoo’s directory or dmoz.org to
    find something on the web? Or do you Google everything? Which is
    better?
    6. If you are doing HTML tables in a wiki… well… I fought for ages
    to keep HTML tables out of PhpWiki. In the end simple tabular data
    tables were permitted, and later HTML tables. Tables suck. Wikis
    are not good at tables and that will probably never change.
    7. The TEXTAREA is a very poor editing environment; no doubt about
    it. I like how Wikipedia breaks big documents into smaller ones;
    much more managable. You might look into MozEX:
    http://www.extensionsmirror.nl/index.php?showtopic=70
    8. Twiki uses CVS; PhpWiki has its own home grown versioning system;
    doubtless others are the same. I have never heard of this as a
    complaint. As far as merging… are you branching in your wiki?
    Even CVS books recommend avoiding branching if you can!
    9. I’m sure this is an AJAX feature now playing everywhere.
    10. Again, for small groups doing ad hoc documentation on a project in
    progress, this might be perfectly fine. For large discussion boards
    you are trying to turn the screw with a hammer!

    The bottom line is a wiki is a type of groupware, and it’s really hard
    to get people to use groupware the way it was intended, much less make
    it intuitive to use. Sure, it’s no excuse; the march goes on. I think
    MediaWiki has done a great job on a lot of these fronts. Ted Nelson’s
    original vision of a hypertext universe is still far away, and Tim
    Berners-Lee’s version almost as much. His original vision was a
    read/write web everywhere. Wikis are a stopgap measure, no more.

  8. April 20th, 2006 at 5:46 am

    beep says:

    correct

  9. April 20th, 2006 at 5:49 am

    Jon says:

    “Maybe the Wiki era is already over. A large Wiki page is hard to maintain”

    Oh totally–look how useless Wikipedia is.

    </sarcasm>

    Btw this “Security code” thing really sucks by the way. Took me multiple tries for it to even work.

  10. April 20th, 2006 at 5:51 am

    dude says:

    You’re forgetting the most important facet of wikis: the people. That is the worst part, that is the main problem. Yes wiki engines like moinmoin are horribly ugly and make things worse with WikiWords, but look at how some wikis are run (or not run). Seen the original wiki at c2.com anytime in the past few years? It’s a cesspool of crap just like usenet. I do commend the work at Wikipedia. Of course it’s got a myriad of people-related issues, too, but there are generally enough good people there to stave off the idiots.

  11. April 20th, 2006 at 6:50 am

    Julian Bond says:

    When are Wikis going to discover del.icio.us and start implementing tags? And don’t tell me they’ve already got them and they’re called categories. There’s a difference and it’s all in the implementation and UI.

  12. April 20th, 2006 at 7:31 am

    Sal Paradise says:

    RE: 7, 8 & 9

    These are the most likely reasons Google bought Writely: http://writely.blogspot.com/. If you’ve ever edited a document individually or collaboratively with Writely, it’s easy to forget you’re using a web-app. Versioning is built in, as are auto-save and rich text capabilites with easy export to many formats (pdf, doc, OO, html, etc.).

  13. April 20th, 2006 at 8:30 am

    Hermann Klinke says:

    I completely agree. And I thought I was the only one to think that the implementation of most wikis are total crap. I love the idea, but I hate bad developers that make it so hard to work with them.

    P.S. I also hate CAPTCHA boxes (your security code), because they cannot be read by humas so many times.

  14. April 20th, 2006 at 9:33 am

    Alex Bosworth says:

    You should look at Textile based wikis like instiki or confluence

    blogging is doing ok and a lot of people use textareas for that, and don’t have auto save either.

    Wikipedia has a model for wikiwords that doesn’t require single words, it seems to work pretty well.

  15. April 20th, 2006 at 1:59 pm

    Jonathan Owens says:

    Some of these complaints really depend on the software. MediaWiki, for all its considerable flaws, is on its way to solving about half of them.

    I think many commenters here are right to say that it really depends on the people. There are some fantastically well-organized and readable wikis built on totally awful software, and vice versa. They really form a blank slate.

    But yes, as a document management tool they haven’t grown into the features that most CMS/DM tools have had for years now. They’ll get there, it just takes a long time to do.

    I didn’t understand your point about styles. All the wiki software I’ve worked with had stylesheets and forced semantic markup. If you wanted to inline FONT tags you could, but it wasn’t rendered by the wiki itself. It seems to follow the XHTML/CSS model exactly. How do wikis abandon the stylesheets idea and go back to manual formatting?

  16. April 20th, 2006 at 2:11 pm

    Dan P. says:

    I agree in part, so much that I ended up writing my own. (Shameless Plug)sk – a (very) simple wiki(/Shameless Plug) Some of my complaints are the same as yours – non-standard syntax, dislike of textboxes, etc. I tried to address these in sk by: 1) having no syntax – if you want some styling, embed some HTML (it is the language of the web, after all), and 2) making the textboxes resizable via a little JavaScript. Give it a try!

    However, I disagree with some of your complaints and suggested approaches for dealing with them. For example (and as other posters have pointed out) use a version control system for version control. (sk’s approach to this is admittedly minimal here). And I don’t think rich-text editing will help styling issues.

    I also agree with the poster who said that for it to maintain reaonable organization and coherence the wiki needs continual maintenance.

  17. April 28th, 2006 at 1:50 am

    Mike F says:

    Why do libraries have librarians? :-)

    A good ‘living document’ Wiki requires a good taxonomy, and a taxonomy requires a maintainer….

  18. May 11th, 2006 at 9:50 pm

    Killer Content says:

    Wiki’s nature is really chaotic and they are full of inaccurcaies that make them not so convenient to use. If ” clever guyas” eliminate all the intricacies that cause the user’s confusion wikis may become the future of internent communication (though i doubt if they will replace forums, chats, blogs – most likely not).

  19. May 25th, 2006 at 1:58 am

    Ken says:

    Steve said it best, “A Wiki is better than nothing at all.” Many open source or even corporate developers (full time or temp) write code and don’t document. A Wiki is better than a bunch of unsearcheable, outdated, unmaneagable bunch of documents in closed formats sitting on some I/T server that everyone forgets about. A wiki is better than nothing at all. Try waking up on the other side of the bed.

  20. February 7th, 2007 at 3:07 am

    Jerry Bakewell says:

    Someone somewhere wrote: “IHateWikiWordsTheyMakeThePageShoutAtYou”. I agree!

  21. February 23rd, 2007 at 10:04 am

    Jessica says:

    Any experience transitioning documentation (e.g., for software) from one release to the next? Wikis get awful complicated -even Confluence- when trying to version between software releases, e.g., v1.0 and v1.1 – NOT just between edits on a particular page. As the head ‘librarian’ of material here, I’m herding cats… and each new release brings another litter of meows to align.

    Currently, wikis do not distinguish in this matter… as perhaps you have said, wikis aren’t meant for the purpose of documentation. I wish it was just as easy to migrate to a more sophisticated option.

    My colleagues are world-wide, and it is the most efficient and effective means to collaborate (read, No File Sharing; no track-changes, no waiting), while letting our users have access as soon as we ‘save’. I read your blog on methodology for documentation in wikis, but the Comment is closed. Any thoughts or tips would be greatly appreciated.

  22. February 27th, 2007 at 12:40 am

    Jason says:

    Hi Jessica,

    Yes, versioning between software releases sucks. We struggle with the same problem, and tackle it mostly by avoidance. That is, we avoid starting on the next version’s documentation until the previous has (all but) stabilised. Then we duplicate the previous version to create a new Space for the next version, and new work happens in the copy.

    Still, naturally there are times when we need to update both, and this needs to be done manually. This is why I would love to see a wiki with *real* version control in the backend, that would allow branching and merging. It is really quite sad to see all the wikis that have created their own, limited version control systems. Versioning is not easy, but there is enough work out in this domain that I expect a lot better from the top wikis. I notice with interest that the Google Code wiki actually *does* use Subversion in the back end, which is a first that I know of (though it seems so obvious that I bet there are more).

  23. August 10th, 2008 at 6:12 pm

    S A GOULD says:

    Hey guys… all I know is that I have only used Wiki SERIOUSLY twice and both times it was so incorrect and blatantly biased on specific individuals that- had I the time- or could EASILY post a comment (as I can here), I would have.

    But I seriously don’t believe that I should have the burden-of-proof in correcting factual errors (not opinions). I don’t have the time to jump through the hoops to correct information that is a matter of public record. And I don’t care how earnest they may/may not be in wanting to correct entries, I don’t care. I go by your actions and not your words.

    Any of you have serious reservations about Wiki, feel free to contact me.

  24. August 16th, 2008 at 8:36 am

    S A GOULD says:

    Looking further into wikiness, i find NO CONSISTENCY in specific repeating terms, and use incredibly poor photography that should have been, yes, EDITED/CROPPED. All of things that as a university publications person I try to maintain.
    As in, if I have a publication with twenty faculty members and 18 of the photos are acceptable quality and two want me to run a Polaroid with them, I cannot do that as it makes it seem that those TWO people are somehow lesser individuals.

    And it is just plain DAMN JARRING, trying to read an article on more than one person, when the terms are different. When they aren’t. As in:
    • XXX is “spouse”
    • XXX is “domestic partner”
    • XXX isn’t even FREAKIN’ MARRIED to the person they have been linked with.

    Drives me crazy. And I can do that by myself.

  25. December 5th, 2009 at 12:10 am

    Fred says:

    I just don’t understand the “try confluence” comments on here. What a terrible wiki. Templates in MediaWiki are a breeze; in confluence they either don’t exist or they are a mess. And what an AWFUL user interface from confluence. Just horrible.

  26. April 21st, 2010 at 7:24 am

    mikey says:

    As a web designer, wikis are perplexing on all levels. They seem like CMS’s but with all the admin functionality amputated so it’s nearly impossible to effectively manage the resultant content, users, extensions, configuration options and whatever else.

    A great example is MediaWiki: the default install tells you which PHP variable you should update in order to customize the logo. So, go ahead… do a search of the source code for that variable name. It’s not even in there! You have to first create that variable. But in which file? Dunno: no documentation.

  27. September 24th, 2010 at 5:14 pm

    Nikki May | Copywriting Services says:

    Great to this piece!

    I thought I was the only one who does not have a great appreciation of Wikis. I am into web design and set ups etc – and I find some wikis rather difficult to work with!

  28. February 18th, 2011 at 10:18 pm

    Max says:

    What you think about Confluence (http://www.atlassian.com/software/confluence/)? Is it useful for documentation process?

  29. March 18th, 2014 at 4:59 am

    Cubelodyte says:

    Confluence sucks for anything but the most *basic* text. They removed the ability to write in raw markup without a plugin, and their rich text editor is *terrible*. I used to believe strongly in Atlassian products, but the direction they’ve taken Confluence gives me pause.

Leave a Reply