-
Archived Post
What It Is, Not What It Looks Like
Posted by Justin on Apr 21, 2008Web-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.
7 Responses to “What It Is, Not What It Looks Like”
Leave a Reply
- Text with Markdown formatting
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.