fettig.net

I just realized that I completely neglected to announce that I’m speaking at the upcoming Ajax Experience conference in Boston. I’m going to be talking about WYSIWYG editing on the web: why it’s good in theory and sometimes bad in practice, and how to do it right in your apps. I’ll also get into some of the technical details of writing your own cross-browser editor, and show how you can save a ton of work by using the Dojo editor widget instead of starting from scratch.

Hope to see you there!

Today I was updating some Javascript code to support the rapidly-approaching Internet Explorer 7. There were a few places in the code where there were IE-specific workarounds, which happily are no longer needed in IE 7
thanks to its improved standards support. Yay position:fixed!

Where the code used to check for if (ie) { ... }, now I wanted it to check for if (ie6OrLower) { ... }. So how to you tell the difference between IE 6 and IE 7+? You could parse the user-agent string, but I’d rather detect changes in the javascript object model. Here’s what I came up with:

if (typeof document.body.style.maxHeight != "undefined") {
  // IE 7, mozilla, safari, opera 9
} else {
  // IE6, older browsers
}

This distinguishes between browsers based on the fact that IE 7 knows about the maxHeight css property, whereas previous versions of IE didn’t. Does that seem like a sane approach to you?

Update: over at Ajaxian Arjan points out that it’s a bit simpler to check for window.XmlHttpRequest, which is also new in IE 7.

This morning I was doing some Safari debugging, and wondered if there was a good javascript shell available for Safari these days. So I searched Google for “javascript shell for safari”. And there on the first page of results I saw this:

Yes, Google knew that out of all the billions of pages on the web, my very own del.icio.us bookmarks are one of the best sources of information on javascript shells for Safari. And it was right - months ago I bookmarked the Mochikit Interpreter, noted that it works great on Safari, and prompty forgot about it. Fortunately Google was there to remind me.

Unlike Mark, I dig iTunes 7. Not only is Coverflow cool eye candy, but it’s made it more fun for me to browse my music collection. With coverflow you can randomly flip through your album collection and pick out something you haven’t listened to in a while, without the soul-sucking drudgery of scrolling through a giant list of text.

I do have a question though: where is iTunes finding its cover art? The most obvious answer to that question would be “it downloads cover art from the iTunes music store”, but I’m seeing some cases where that doesn’t seem to be the case. For example, I have in my music collection Cat Power’s “Moon Pix” and Joanna Newsom’s “The Milk-Eyed Mender”, both of which are available in the iTunes store, but iTunes can’t seem to find the cover art (and yes, they’re tagged correctly). On the other hand, I have Danger Mouse’s The Grey Album, which definitely isn’t in the iTunes store, and it had no trouble displaying that cover art. Actually, now that I think about it, the Grey Album probably has the cover art embedded in the mp3s, so that would explain it.

Anybody else seeing inconsistent behavior with iTunes 7 and album covers?

Update: Today I tried downloading the cover art for those albums again, and it worked. Must have been an glitch with the iTunes store.

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 ;-)

Sadly, This American Life has asked Jon Udell to take down his podcast feed. And he has, while asking them to explain why posting links to publicly available mp3s is a copyright violation. It seems likely that the TAL tech people didn’t realize how easy it would be for people to download and play their files now that they’re in mp3 format.

Personally, I love This American Life (I even used to have a prized TAL coffee mug), but I’m not always home or in the car Sunday at 6:00 to hear it. They really should offer their own podcast feed. It could be limited to the most recent show, to discourage people from sucking down their entire archive*. C’mon, TAL, help us fans out. I think having shows available for free on mp3 is ultimately good for This American Life: just yesterday Hannah introduced her little brother to the show by playing him an episode off her iPod.

* as I’m doing right now while iTunes still has a cached copy of the old rss feed - got to grab those mp3’s while I can!

As an experiment I started using Flock Beta 1 instead of Firefox today. So far it’s going well, with one major issue.

Firefox (at least up to the current 1.5) has a close button over on the right hand side for closing the current tab. It looks like this:

To close the current tab, you click the X on the far right.

Flock, on the other hand, has a close button for each tab, like this:

To close the current tab, you click the X on that tab. Easy, right?

Unfortunately, after a couple years of using Firefox I’m pretty used to clicking that X on the far right side. And when you have a bunch of tabs open in Flock, there is an X on the far right side: the close button for the rightmost tab. So I see it, click it, wonder why my current tab is still there, and then realize that I just killed the rightmost background tab. Doh! I’ve done that about 10 times so far, and sometimes I don’t even remember what I had there other than that I was planning to read it.

Suggestion for browser developers: If you’re going to change the way tab closing works, add an “undo close tab” feature at the same time. That way people can at least recover from accidentally closing tabs until they get used to the change.

I’m sure glad I read through to the end of this Jon Udell post. Buried at the bottom is an amazing link: Jon’s home-brewed This American Life podcast! Apparently TAL episodes are now available as MP3s. That’s good news in itself, because they’ve always been RealAudio-only unless you paid through audible. They don’t offer an RSS feed though, so Jon whipped one up himself.

Here’s the link to the feed: http://udell.roninhouse.com/tal.xml. I’m subscribed! (iTunes users: Advanced -> Subscribe to Podcast, paste in that link).

My day just got a little better when I discovered this series of live concert recordings on the NPR website (via Hanna Wallach, via Planet Gnome). Lots of great bands, including Belle and Sebastian, M. Ward, Death Cab, Sigur Ros, the White Stripes, and even James Brown, who I, embarrasingly, thought was dead. Most of the shows are in realaudio, but you can grab the Belle and Sebastian show (and maybe others) as mp3. How did I not find out about this before?

Dave Winer pointed to this list of billionaires.

“Have I met any billionaires?” I wondered. “Yes”, I thought, “some of those guys at the Web 2.0 conference probably were billionaires.” But I was curious, and it was a long list, so I wrote a little tool to check. Now you too can check a web page for billionaires. Quick and dirty, regular expressions, etc.

Does using HTTP GET to two different web servers count as a web services mash-up?