What the experts say on wysiwyg editors in Wikis
June 18th, 2010
The great site wikipatterns has a full page dedicated to the benefits, problems and tips for a wysiwyg editor. We feel this page is written more for makers of wiki software than for the people wanting to introduce a wiki in their organization. Yet there is some interesting stuff in there we can pick up.
Wysiwyg Benefits
The site lists following benefits:
-
Avoids users having to learn the details of the wiki markup before they can contribute. For many users, particularly non-technical users, the learning required can be a significant barrier to participation.
We couldn't agree more. A wiki's success is directly proportional to its content. With all the focus on usability, the obscure textile or crappy wysiwyg editors seem counter intuitive to everything we learn from the Don't make me think mantra.
-
Better media integration. When users can see the page as they edit, they are often more inclined to include images and other media to assist in communication.
Again we are in full agreement. However, we still need to come across the wiki that let's you do this as easy as Microsoft Word.
-
Allows users to achieve better results faster. Users will be more likely to create pages that visually appealing if they can see the page as they edit it. While this may not add to the content, it can encourage users and give them more confidence with using the wiki.
No comment.
Of the common editor problems that wikis may have, we have looked at the following ones in detail:
-
Slow editors. A number of in-browser editors can feel sluggish to users. While this may seem like a small problem, it can become very frustrating for users over time.
We can testify this ourselves. This frustration has grown so big we ended up building this product for it.
-
Buggy or unintuitive editors. Many editors frustrate users over time because of bugs in the software or simply because they force the user to stop and think how to operate the editor instead of focusing on creating content.
Indeed, try to create a list in a list, one numbered and one unnumbered. Try to indent/unindent. If your editor is still behaving, try to add newlines within a bullet point. If you are really adventurous, try to make one list level use numbers and others bullet. Beware, try this at your own risk!
-
Inaccurate conversion between wiki markup and HTML. A number of wikis use a HTML editor but actually store the content as wiki markup. While it is straight-forward to convert wiki markup to HTML, it is very difficult to convert the HTML back to wiki markup. An alternative for private wikis is to use HTML as the storage format and this is supported by many wikis. Publicly editable wikis need to be cautious of security issues when allowing HTML content - it is possible to sanitize the HTML so it is safe, but most wikis pass the HTML through unfiltered.
In the WordonWiki case, this problem is actually solved for us by the wonderful engineering teams at Microsoft. While their generated html leaves a lot to be desired for, converting from and back the page edit and the page view works wonderfully well. Tables, lists, footnotes, embedded excels, revision marks,.. there seems to be nothing these engineering teams do not handle.
-
In a small number of cases, the user's focus may be drawn to the page layout and formatting instead of the content. If this happens, the simplest solution is often to disable advanced features of the editor to limit the options for authors and encourage them to focus on the content instead of the formatting.
One strange piece of advice indeed: if it doesn't work or if it hurts, simply disable it. We understand of course why the author has listed this as the best pragmatic advice. To be honest, for some users also Microsoft Word could do with some 'functionality limiting mode'.
-
Many wikis have sophisticated mechanisms for advanced content production (like page inclusions, page templates, plugins, ...). These are usually implemented through special syntax constructs which may not be available through the WYSIWYG editor, limiting the users to do trivial tasks
In the case of WordonWiki, that simply does not apply. The 'special syntax constructs' are not there.
To conclude this article, we would like to reference an article on the 'Kick-ass curve' that is also referenced on the wikimatrix page (we have to give them credit for always including very helpful links). Make sure to go to view this 'Kick-ass curve'. A thing we as software makers need to keep in mind.
Dare to say what nobody dares to say
December 26th, 2009
Some times I come across a blog post that is so ad rem that I wish I had written it myself. One such blog post is "Thoughts on wikis" which you can find on the iperimeter blog.
From the article:
All wiki platforms I have used appear to make the following assumptions:
1) Formatting, beyond a very basic level, doesn't matter
2) People are prepared to put time and effort into learning and using the platform and/or its WYSIWYG editor
3) All content fits cleanly into a predefined structure
4) Once the information is in the wiki, people don't need to get it out again
5) Users are IT literate and have a conceptual interest in the wiki as a platform
I'd like add:
6) Users are able to figure out where to upload pictures so they can reference it using an Url
Of course, none of that is true. We are genuinely convinced that the true potential of wikis haven't even emerged. Once people can start to add content, move stuff around, do true WYSIWYG, all within the luxury of their familiar word processor, that's when we will start to see true content appearing.
Strangely, that is not the kind of comments you should make. Somehow, wikis still remain up to today a tool for the happy few. The technical thresholds seem to prevent many people from participating. Not a very democratic view. Along that same line, here is an other assumption that everybody seems to be making:
7) Wikis should all be open source and be free
That is true of course for the mother of all wikis: our beloved http://www.wikipedia.com. But even there, the money needs to come from somewhere.
We were even believing that for some time. Numerous people said that WordonWiki should really offer OpenOffice as an alternative editor. While that is certainly a feature on our backlog, interviews and usability sessions with real users have learned us that this is only a marginal request.
Let us know what you think.
Roland.
PS.
I was busy commenting this information on the author's blog, but some strange registration system was used. I had to login with my existing google or wordpress account. I did not feel comfortable doing that.