Archive for July, 2006

Jason Fried recently wrote that WYSIWYG editors get in the way of writing. Jason said:

When you’re about to write that’s all you should be ready to do: write. Leave the rest for another day.

I agree completely that when writing it’s bad to focus on formatting at the expense of content. And I don’t interpret Jason’s words as a wholesale condemnation of WYSIWYG. He was talking specifically about why he doesn’t think WYSIWYG would improve his product Writeboard, and I gather that Writeboard is meant to be used for the initial composition of documents that will eventually be formatted and published elsewhere. Still, Jason is clearly not excited about the potential of WYSIWYG editing on the web, and he didn’t offer any examples of where a WYSIWYG writing environment would be advantageous.

So today I want to talk about WYSIWYG editing, why it’s sometimes better then plain text with markup, and where you should use it in your applications.

What WYSIWYG means

WYSIWYG stands for “what you see is what you get”. That means that the output when you save is going to look exactly like what you see in your editor as you’re typing. Note that there’s nothing in that definition about rich formatting. If you write plain ASCII text, with the intent that what you’re writing is going to be viewed as plain ASCII text, that’s WYSIWYG. You know exactly what your document is going to look like: plain text.

What isn’t WYSIWYG is when you write plain text that includes some kind of markup: HTML, Markdown, Textile, etc. In this case what you see as you’re editing is input, which will be run through some kind of processing engine to produce output. What you get is the output of running your document through software. Here are a few examples that illustrate what I’m talking about:

 * One * Two

 * One * Two

 * One * Two

When the output matches what you saw when editing, it’s WYSIWYG. When the output is different than what you saw while editing, it’s not WYSIWYG.

Writing for HTML output

In Jason’s post he was talking about writing purely with plain text characters and newlines. That kind of writing fits my definition of WYSIWYG regardless of the capabilities of your editor: You input plain text, the output is plain text, during editing you see exactly what you’re going to get.

But when you write for the web, much of the time you want to produce something that has structure, formatting, or both. Most blog posts will include a link or two, or you might want to add structure to a long document using headings and sub-headings. If you’re doing this kind of writing, and publishing it on the web using HTML, you’re no longer producing plain text. You’re now writing with the goal of producing a rich web document. For good or bad, you have left the realm of thinking only about the words you are writing. You are thinking about formatting and structure: Should this be a heading or a subheading? Which words should be be part of my link? Should this be a numbered or bulleted list?

Why WYSIWYG

A good WYSIWYG editor should make it easier for a writer to concentrate on what they are writing. With WYSIWYG:

1. You don’t have to use part of your mind to envision what your document will look like.
2. You don’t have to worry that your document isn’t going to look the way you want.

Uncertainty, fear, and surprise are not things you want to be feeling while you’re writing. When you write using a markup language, you’re writing input to a computer program. That means that to some degree, depending on your level of proficiency with the markup language you’re using, you’re going to have doubts about exactly what your output is going to look like. You end up with a preview/re-edit cycle where you edit the input until it produces the output you’re looking for. This is distracting, and it gets in the way of your writing (thanks to Tim Mansfield, who pointed this out to me recently, inspiring this post).

Writing isn’t just about composing. A lot of writing, especially collaborative writing, is editing. That’s another place where WYSIWYG can make for a better experience. When you’re editing you start by viewing output. It’s jarring when you go to edit something and end up looking at markup that barely resembles the output you were looking at before. Contrast this with WYSIWYG editing in the new JotSpot wiki. For example, here’s a wiki page:

and here’s what you see when you press the “Edit Page” button:

The content looks exactly the same as it did before, except now it’s editable. You can keep your eye right on the part you want to change, hit edit, make the change (your text hasn’t moved!), hit save, and you’re done. If we weren’t using a WYSIWYG editor you’d be looking at markup source, which you’d have to re-scan to find the part you wanted to change. With the WYSIWYG editor you get the sense that you’re editing something tangible, and it feels good.

WYSIWYG for plain text fans

When programmers think about WYSIWYG vs. plain text they’re mentally comparing Microsoft Word to their favorite text editor, and the text editor always wins. There are two great advantages generally associated with editing plain text:

1. With plain text data is stored in an open format. Plain text can be be
   parsed and manipulated a million different ways. Put your writing in a
   Word file and its locked in and inaccessible to other programs.
2. You don’t have to take your hands off the keyboard. Nothing disrupts your flow like having to reach for the mouse. As Jason alluded to, a WYSIWYG editor has all those pretty icons and menus, just inviting you to take your hands off the home row.

When it comes to editing on the web, though, I think its possible for a WYSIWYG editor to do a good job in both of these areas. The first one is easy: you’re editing HTML, a completely open format that can be read and manipulated by tons of programs (in fact, HTML is probably easier to work with than a relatively new markup dialect like Textile or Markdown). On the second point, a WSIWYG editor can still be keyboard friendly. It’s not any more work to type <Ctrl-b>bold<Ctrl-b> then it would be to type *bold*. This is an area where the editors will continue to improve (at least I can promise you that the Dojo editor will).

And remember, when it comes to editing on the web you can’t compare an embedded WYSIWYG editor to Emacs, vi, or TextMate. You have to compare it to the alternative: A textarea, which is just about the least powerful editor available on any platform. I mean, c’mon, notepad is better.

When to use WYSIWYG

I think it would be hard to argue that WYSIWYG, as a concept, is inferior to non-WYSIWYG. All other things being equal, it’s better to be able to see what you’re creating as you create it. The reasons people have for not liking WYSIWYG are that they don’t like closed formats, or don’t like using the mouse, or don’t like structured documents, or don’t like ugly fonts. But those problems aren’t inherent to WYSIWYG.

WYSIWYG is just about letting people see what they’re doing, so they can concentrate on the end result of what they’re creating, not the markup syntax that will (hopefully) produce that result. If you’re building web applications, I think you should seriously consider using WYSIWYG whenever you have non-programmers producing web content.

JotSpot and 37signals

One last note that I feel compelled to include here: for some reason there seems to be a little bit of animosity between Jason and some past and present employees of JotSpot. I’m not sure what the whole story is there, but it seems silly to me. 37signals has been a leader in developing and bringing attention to web applications. They get a lot of attention and press. Good for them. I’ve had the pleasure of hanging out with Jason at a couple of conferences, and he was friendly and helpful before most people in the industry even knew my name.  So I think he’s a good guy.

Also, from where I’m standing JotSpot and 37signals are currently not competitors: we’re not losing any customers to 37signals, and I don’t think they’re losing any to us. We’re both companies making great web applications, and if anything we both will benefit as more and more people get comfortable with using software over the web, and paying for it as a service. That’s why I hope 37signals seriously considers adopting WYSIWYG editing: it will make their apps even better ;-)