What criteria should I take into consideration when allowing users to enter rich text on my website?

Question

I've worked with several different types of "user-generated content" sites: wikis, a message board, blogs... These systems can differ greatly: a blog post editor allows more control over presentation than that for comments on the blog post, a wiki topic editor encourages wiki links over raw URLs, etc.

However, one key design decision is common to each: should I provide the user with a simplified markup language such as Wikitext, Markdown or BBCode, forcing users to learn that, or should I give them a WYSIWYG editor like CKEdit or TinyMCE and filter or transform the resulting HTML behind the scenes?

There was a time when I thought this was a simple matter of identifying my intended audience: tech-minded users get markup, non-technical get WYSIWYG. In practice, this hasn't worked out all that well, occasional users struggling with markup and the WYSIWYG editors providing at best a leaky abstraction for the underlying HTML.

So with my initial confidence throughly crushed, I come looking for advice:

• What factors should I be taking into account when making this decision?
• Have simple markup systems become commonplace enough that I can rely on most users having at least some familiarity with them?
• ...Or should I abandon them as merely a relic of the past, and work on finding ways to make WYSIWYG work more effectively...?

I'm not looking to go back and tear apart what I've already done. For better or worse, these systems are working, their few users comfortable or at least competent by now. But it would be nice to have some better guidelines when putting together future designs.

Answer 1

One approach that seems to work fairly well is the use of Markdown as done here on SO. Stupid and/or lazy people (with apologies to all who are) can simply throw text in the box; it comes out looking as messy but it's mostly there and readable. People who care about how their text looks can do some simple things that are for the most part almost intuitive (like leaving blank lines between paragraphs, putting asterisks or numbers before list items) and it Just Works™

This is Good Enough™ for a lot of applications and people. Some of the glitzier sites, such as Google Blogs, give you your choice (changeable at the click of a button) of editing raw HTML or using a WYSIWYG editor (that fails just often enough that I usually opt for raw HTML). In theory, you could even give your users 3 alternatives, such as Markdown, HTML and WYSIWYG; but at some point you'll be wondering why you even bothered. Some users will always struggle with some aspect of the interface and they'll blame you. I believe in finding a happy medium and not bothering to make everybody happy.

From my point of view, the most important considerations are those of security. If you allow raw HTML, your users can insert spam and malware and basically hijack your site for their purposes; so you have to carefully limit what's allowed. Another consideration is that if you allow, e.g. H1 headers, people can take up a lot of space and attention with posts that should really be subordinate. If you allow CSS (including style attributes in HTML tags) then again there are ways to deface your "real" content. Another big problem stems from unclosed or unmatched tags. These are the really serious problems, and you want to err on the side of strictness to avoid more serious problems.

Answer 2

"What factors should I be taking into account when making this decision?" What do your customers want? Can you not have a 'fall back' kind of system where the 'simplified' WYSIWYG can be used until they need the added features of raw markup? What kinds of things do the most users use most often? What features are used less often but, when they are needed, you customers cannot live without?

"Have simple markup systems become commonplace enough that I can rely on most users having at least some familiarity with them?" For people using wikis and blogs, I think the answer is yes. Even commenters on blogs to some extent for the simplest things but again, I think you should let them do markup in-line if they are able (or some common sub set of markup) and have the option of more power if they need it.

"..Or should I abandon them as merely a relic of the past, and work on finding ways to make WYSIWYG work more effectively...?" I would not take this all on at once. Work from a solid kernel of functionality and work outward to a complete system.