What It Is, Not What It Looks Like
Published by Justin Toupin
Web-based Text Editing
Website owners and managers need a simple way to edit the text within their websites. They need to add headings, make bold text, bulleted lists, and so forth. It's a fundamental need in Content Management implementations, and perhaps the most used feature of any CMS.
In spite of this, the solutions widely available today are horrible. JavaScript editors tend to be buggy, generate bad HTML, and produce inconsistent results between browsers. Requiring clients to learn HTML doesn't work. Often, they'll just say no... and even if they're up to the task, the website will almost certainly end up with broken code. Asking the marketing manager, department head, or whoever to learn HTML is a bit of stretch in the first place -- they just shouldn't have to.
Promoting Poor Habits
Even when JavaScript editors work well, they allow -- even encourage -- bad practice. Clients start thinking that a line of text needs to be just a bit bolder, or a slightly different color, or have more padding. With JavaScript text editors, they can make those changes. Moreover, the fact that the text editor is a WYSIWG, and visual in nature encourages those changes. Clients start focusing on what the text looks like, more than what it is. What starts as an exception or two often becomes widespread inconsistency. Extraneous tags (extra line breaks, span tags, or even font tags with color attributes) creep in.
And this, of course, impairs the quality of content. When tags are added to a particular piece of content to solve specific, isolated design goals, that content looses its ability to be used in broader applications. Then there is the issue of future redesigns. A few years ago, we were looking with a client at a simple redesign for a website and CMS upgrade; the biggest hurdle (and demise of the project) were the countless pages of text littered with font tags, extra paragraphs, and left-over classes pasted in from desktop word processors.
Example
A recent example involves a Drupal CMS multisite implementation providing a centralized admin environment for two distinctly different websites. We originally used TinyMCE, a JavaScript text editor, that was configured to use the visual style from the first website long before the second was ever launched. Headings are Georgia, and blue. Sub-headings are Arial, also blue. Bullets are simple discs
In the second website, though, the styling is different. We used background gifs for ornate bullets, and sub-headings are Georgia and gray.
We discussed the option of styling the editor to match the second site when content was published there -- but what about cases where content might be used in both places? What if the contributors had no idea where their content would be published, and were simply given a subject and tasked to write?
The problem became clear. Using the JavaScript WYSIWYG editor, contributors focussed on appearance rather than structure. This was confusing, particularly with the introduction of the second website.
So we began talking about thinking of content in terms of what it is, not what it looks like.
The Solution
As I mentioned above, requiring clients to learn HTML isn't realistic. And I've explained our problematic experience with WYSIWYG editors. We wanted a tool that doesn't require HTML experience and allows clients to edit text easily and perform simple formatting, while maintaining an emphasis on structure rather than presentation. So we've moved to a solution that uses simple formatting codes to add structure to text.
We use Markdown.
What is Markdown?
According to Wikipedia:
“Markdown is a lightweight markup language, originally created by John Gruber and Aaron Swartz, which aims for maximum readability and "publishability" of both its input and output forms, taking many cues from existing conventions for marking up plain text in email.
Markdown uses simple formatting codes to format text, rather than tags. Instead of <strong>bold</strong>, it's **bold**. Instead of <em>italics</em>, it's _italics_. An H1 heading would appear as:
H1 Heading
==========
One of the best things about Markdown is the fact that it makes plain-text more legible, unlike HTML. Take a look at the following examples:
- Text with Markdown formatting Headings read like headings, lists like lists.
- Same text, transformed to HTML Markdown transforms perfectly to semantic XHTML. Additional formatting can be added where it should be, in a CSS file, and can be easily altered for various unique applications.
- HTML output, showing HTML source code Notice that HTML code doesn't improve the legibility of the text. It doesn't read well, doesn't add meaning - or structure - to raw text input.
Markdown was originally developed by Gruber and Swartz as a software tool written in Perl, and can be downloaded from John Gruber's widely read website, http://daringfireball.net. An excellent PHP port was written by Michel Fortin, and is available for download at http://michelf.com/projects/php-markdown/. The Drupal module, built on Michel's PHP port, is available at http://drupal.org/project/marksmarty. Many other publishing tools have their own implementations.
What Clients Think
We have used Markdown in most of our CMS implementations. So far, there has been very little resistance. Those clients that may have resisted the idea at first typically embrace it once they actually use the syntax. Several clients have actually opted to switch, even in cases where we started them with a JavaScript WYSIWYG editor. Markdown is incredibly simple to use, helps avoid the problem of broken (or just bad) HTML creeping into content, and offers flexibility when it is needed.
OK, you've convinced me that markdown might be better than HTML with the argument that it makes plain text more legible.
Has anyone written a set of buttons for markdown that you can import into BUEditor? benjamin, Agaric Design Collective
Interesting. I'd very much like to think I could make this work. I suggested Textile/Markdown to a client a few months ago, but had it nixed because their internal workflow meant they needed to be able to write in Word. (And honestly, I don't blame them. You have to write where you're comfortable.) I ended up going with Xinha, which has pretty nice Word cleanup abilities, but no WYSIWYG is much to brag about, for all the reasons you cite. If there were some way to paste from Word and have it show up as Markdown, maybe it would be an easier sell.
If you haven't already, have a look at the WYMeditor: it works on the What You See Is What You Mean principle and starts with what a line of text means instead of what it looks like. It offers more visual feedback about what the editor is doing, without compromising the basic principle.
It's still in (very slow) development, but there's even a Drupal module to check out the basic functioning of the solution.
http://www.wymeditor.org/
Longtime fan of markdown. There's a marksmarty module for Drupal that works nicely.
Forcing people to learn Yet Another Markup Language defeats the object of simplicity(HTML/BBCode/Different Wiki markups/Markdown/other). It may work for one site where everyone is used to the markup, but does it scale?
Will newcomers/guests understand straight away, or learn a new markup? (and why does an underscore = italics and not underline?)
IMO while, most markups are ingenius, they fail at their goal - too many places have a slightly different-but-similar markups. It confuses users. It is probably easier to learn html than 10 different markup styles.
@ksenzee: great point. In my experience, the process of converting a Word document to Markdown syntax is about as quick as copying and pasting it, running the clean-up utility, making sure everything translated correctly, and fixing what didn't. We have had cases where clients started with Word and a WYSIWYG, then moved to Markdown when they saw the ill effects of pasting from Word and the simplicity of using simple formatting codes. That said, you're absolutely right... there are going to be cases where Word, or whatever other desktop editor, wins out; and in the end, the client's opinion is the one that matters.
@You: I hear you on not wanting another standard to keep up with, but this wouldn't be "Yet Another Markup Language" for most of the folks that we would point at Markdown. Chances are, they wouldn't know any others, wouldn't want to, and wouldn't need to. We wouldn't approach the subject from the perspective of teaching a markup syntax; rather, we would explain the benefit of using simple formatting codes instead of a WYSIWYG, then take about five minutes to show the most-used codes, and, finally, provide documentation for additional formatting codes for when (and if) they need them. If they want to use HTML, no problem -- HTML can be mixed in as desired. We encourage the use of Markdown because it provides an easy way to format text that doesn't require HTML knowledge, produces semantic code, and avoids the WYSIWYG mess.
The biggest selling point for clients is that they can just copy and paste text in frpm Word and, behold, paragraph formatting is done. They just need to do some formatting for titles, links etc... and they're done. Another bonus is that I can add html whenever I need to, Markdown knows the difference and leaves it alone. Nice article, I'm bookmarking this for future clients to read.
Hi,
I personally find markdown to be more confusing than anything. Half the "tags", or whatever u wanna call them, don't even make any sense. Like a person above posted, why does bla result in italic? wouldn't /bla/ make more sense?
I agree that tinyMCE makes a mess of ur code, which is why I usually prefer FCKeditor, unless the client demands on-site spellcheck, which is a nightmare to get set up in FCKeditor and really easy in tinyMCE.
In my opinion, if u set the FCKeditor to only allow styles like headers and paragraphs and such, u still have a cross-site solution which can easily be restyle with CSS. Just change the Drupal input filter to not allow span tags and font tags and such, so it's rly limited to <h1-6> <p> and the likes.
Also, regarding the classes that desktop texteditors seem to add when copy-pasting, are easily removed with the filtering or restyled to look like regular headers/paragraphs using CSS. Simply set the CSS rule to p, p.MsoNormal { ... } instead of just p {...}
Drupal filtering provides numerous ways to limit the abilities of contributors to screw up content formatting, there's really no need for annoying input formats that just make it hard on ppl to enter content.
I couldn't agree more with the original post, and I'm really encouraged to hear of the success you've had with your clients.
I've been implementing FCKEditor and TinyMCE in Drupal installations for a couple of years now, and they have never worked very well -- in fact, they've often broken spectactularly, which knocks the confidence of my clients in themselves and in their website.
There are lots of small problems with the full-on WYSIWYGs (Tiny and FCK, in my case). Small problems include inconsistencies in the ways they select and manipulate text. Creating a list seems to be the weirdest. But my clients get used to these and mostly work around them.
But the two Really Big problems are consistently the clients who paste directly in from MS Word, and the addition of spurious line and paragraph breaks.
Tiny and FCK both provide a paste-from-word option which aims to strip out the dangerous stuff from that most infamous of word processors. In addition, I always train my clients in using the editor, and leave documentation and guidance throughout their sites telling them never to paste directly from Word. But much of the time they forget, ignore the tips (even those written right above the editor) and horrid stuff gets in from Word.
The other thing is line breaks and paragraph breaks. Most normal people don't get the difference. They think a paragraph break is just two line breaks. Of course, I teach them the difference at training, but they forget, or new people come into their organisation who don't know. This leads to lots of paragraphs being double line breaks, or worse, having an empty paragraph between them. And I've often seen people creating one or two empty paragraphs deliberately as a way of creating extra white space in their article.
And then there's the Disability Discrimination Act. Under the DDA in the UK, companies need to treat disabled employees no less favourably than anyone else. But someone who cannot use JavaScript cannot use Tiny or FCK. Instead, they'd have to deal with the awful HTML their colleagues have been pasting in from Word. Even if their site content was miraculously free of the usual HTML faults, they'd still have to learn HTML where their colleagues would not.
In short, WYSIWYG for the web sucks. Certainly in most of its current implementations, anyway.
I've got a whole lot of confidence from your article, Justin. I've been using BUEditor/Markdown for a little while now, and I do think I'm going to make this the default company policy.
In future, it could be great to invent a very simple WYSIWYG editor that writes Markdown instead of HTML. This would be following the same principles of progressive enhancement that we're used to in every other aspect of web development.
I agree, for the most part. One solution I've found when using TinyMCE or the like is to strip down the options to a bare minimum. No need for font changes, color changes, or the like. Only a subset of headers, lists, link editor and maybe bold and italics, although I find them more crutches than tools.
Any argument that says "but I can't paste from Word" misses the point entirely: Word does everything natively that this article argues is wrong with a WYSIWYG editor, and then some. Margin changes? Page breaks? Fonts that won't be available on the web?
A great alternative: gui for markups like bbcode, wikitext and markdown. http://markitup.jaysalvat.com/ does it all and quite well. You're still writing markup and it's not hiding it from you, but it helps you when needed, especially great for the beginner.
There's a module that provides a set of Markdown buttons for BUEditor along with dialogs for advanced editing (tables among other things): http://drupal.org/project/markdowneditor