Wiki Patterns
grow your wiki
EditUse WYSIWYG
What is it?
Using a WYSIWYG editor allows people to start editing pages without needing to learn the details of even a simple wiki syntax. The success of a WYSIWYG editor is highly dependent on the quality of the editor provided. If the editor is not high enough quality, it is often better to avoid it altogether and simply use wiki markup directly.
Benefits Of WYSIWYG
- 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.
- 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.
- Allows users to achieve better results faster. Users will be more likely to create pages that are 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.
Common Problems
- 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.
- 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.
- 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 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.
- 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
Tips For A Successful WYSIWYG Editor
- Carefully evaluate the editor for quality and intuitiveness as well as speed.
- Avoid using HTML editors to edit wiki markup. Instead, use HTML as the storage format or use an editor that is specifically designed for wiki markup.
- Customize the editor for your specific needs. Disable unneeded functionality and provide shortcuts for common operations. If a common template is used on your wiki (for example, for comments within the page), provide a custom button in the editor to insert the template.
- Provide an easy way for users to disable the editor by default if they prefer writing markup directly.
| Rate this pattern? |
|
Related Patterns
Further Reading
- List of wiki tools with WYSIWYG editors - from WikiMatrix
- Creating Passionate Users: Attenuation and The Suck Threshold http://headrush.typepad.com/creating_passionate_users/2005/10/getting_users_p.html
- Jonathan Boutelle: Using Wikis with Software Developers http://www.jonathanboutelle.com/mt/archives/2005/11/using_wikis_wit.html
- Adrian Sutton: Making Wikis Work http://www.symphonious.net/2005/11/29/making-wikis-work/
Adoption Patterns
Adoption Anti-Patterns
Wikipatterns.com is sponsored by Atlassian Software, creators of JIRA, Confluence, Bamboo and Crowd
Designed by Headshift Ltd
This page needs a fair bit more work. It would be good to add in sections to make the key points clearer and it needs to find somewhere to tie into the rest of the wiki - it doesn't quite feel like a pattern at the moment so I'm not sure where it should go.
Some suggestions for related articles would be:
* Using Wikis with software developers
* Making Wikis Work
* Wiki Syntax Considered Harmful (the recommendation to use HTML doesn't apply as much here, but it has a number of thoughts about why WYSIWYG editors are a key benefit)
Hopefully I'll get some more time to flesh this out and improve it but I'd particularly appreciate others contributing.
Those last couple of links should have been:
* Making Wikis Work
* Wiki Syntax Considered Harmful
The Rich Text option for this wiki is a tad too slow so I find myself using the Wiki Markup view instead. There's more to be said about this Pattern but I'll have to think a bit more first.
Yeah, there needs to be a lot of emphasis on it being a good editor. It needs to be like the user is using their favorite editor. Of course some people will always want to switch to code view, so you need to provide that too, but the majority of people, when provided with a good quality WYISYWG editor, will use it as much as they can.
I've found it hard to get adoption of the WYISYWG editor because of its quirks. People will be typing or formatting and their changes will save oddly and will wind up having to go back and recreate the page. This can be daunting because editing poorly formated content with the editor is difficult. Teaching them how to fix issues using wiki markup seems counter productive.
Yep, this kind of problem often occurs when you try to use a HTML editor to edit wiki markup by converting between the two. HTML is far more powerful and flexible than wiki markup so the conversion back to wiki markup often fails and causes frustrations for users. The best success I've seen with WYSIWYG editors is either editors that were designed for wiki markup or wikis that used HTML as the markup language and a HTML editor.
It's definitely not cool to do things like what happened to my first comment where the links worked in the editor but disappeared when the comment was submitted. The second link by the way talks in depth about the benefits of using HTML in conjunction with a good WYSIWYG editor instead of wiki markup.
We probably should roll this pros and cons up into the actual page to provide a set of recommendations of when and how to use WYSIWYG editors.
I see this site uses TinyMCE as its WYSIWYG editor. It's definitely the best, and is what EditMe
has used for years now. It's got by far the most active developer community of the open source editors.
Another important requirement for WYSIWYG editors in wikis is integration. Just having an editor there plopped in doesn't get you very far. It needs to know about the other pages on the site, be able to insert images attached to pages, and so on. This is a big usability issue as attachments tend to befuddle users.