I like Wikis. I don't mind Wiki markup so much. Recently I had to investigate using the Sharepoint 2007 Wiki, and found that it goes directly to HTML. This led me to formulate the following rule of thumb:
Any documentation system that forces you to edit HTML is a failure.
Involved Discussion:
True, Sharepoint has a limited WYSIWYG editor that you can use, but the data is stored largely in HTML format (Wiki words being the exception). For many tasks, or to get a consistent appearance across documents, you'll have to work with the HTML tags.
Why is this a bad thing? Googling around, I found a few people who actually thought this was a strength of Sharepoint. Total control of the output, right?
Three points:
- HTML is verbose
- HTML is exceedingly error-prone
- HTML is not 100% portable
Say you want to create a level one header on Sharepoint, I see two alternatives:
- In the WYSIWYG editor, type in the text, select it, bold it, enlarge it.
- In the HTML editor, bracket the text with
…
tags.
With the first technique, everyone could build the header differently, leading to inconsistent appearance. And it gets ugly if you do have to drop into HTML mode:
<DIV align=center><STRONG><FONT size=4>This is a Title</FONT></STRONG></DIV>
(Don't even think about documenting HTML in the Wiki page!)
The second technique gives a consistent appearance, but you have to work in HTML, which can become a major distraction from getting work done.
In the Media Wiki, the text is bracketed with “==”.
==This is a Title==
All the nested tags in HTML leads to endless problems with unbalanced or mismatched tags. Complicating this is the way different Web browsers will handle those errors. Some will render the text the way you expect, others are less forgiving.
And having brought up different browsers, there's always the possibility that as you add a greater variety of HTML tags to your document, your page could render very differently for users of Safari vs those using IE.
