MarsEdit and WYSIWYG editing

MarsEdit and WYSIWYG editing. An interesting question came up in the comments for the previous post: why doesn’t MarsEdit do WYSIWYG editing?

We plan to add WYSIWYG editing in the future, but it’s not there yet.

I’m not sure what more I can say publicly about it, because this
feature depends on another company making a WYSIWYG editor component
available. It’s a component we’ll be able to use but that we didn’t
write. (This isn’t hypothetical: it’s a real thing that’s in the works.)

The good thing about this component is that its support for HTML and
style sheets is fairly complete. It’s worth the wait—but it’s not worth
holding up MarsEdit 1.0 just to wait for it.

We could have done a limited WYSIWYG editor that supports the basics.
But it’s not a good idea to spend time writing code that we’d just toss

Another reason not to do a basic WYSIWYG editor is that it would be a black hole, sucking up all our time.

Why would it be a black hole? Because everybody who uses it would need
just one more feature than it has, and every “just one more feature”
would be a different feature.

Imagine if it supports the basics: bold, italics, links, and images. If
it didn’t support right-aligned images, people would ask for it.
Someone else would say that they need 
tags. Another person would say that it has to reflect the style sheet
they use for their site. Another person would absolutely need   tag support. And so on and so on. These would all be reasonable requests.
But there would be so many of them that I wouldn’t be able to stop
until I had written a full HTML parser, renderer, and editor—which is a
huge job.

The good news is that some other folks are doing that, and I don’t have to! (That news is more than good, it’s wonderful.) But the downside is that we have to wait a little while before we can use it.

Above I used the term “black hole” to describe a limited WYSIWYG
editor. The issue of development black holes is something I’m very
sensitive to, since I’ve been stuck in them before—though not for
several years, thank goodness.

One type of black hole is a feature that has no end and never pleases
enough people to be worth it. If you keep putting resources into it, it
gets more complete, but it never comes anywhere near the 80% mark you
want to reach. You keep thinking that you’re getting close to it, but
you’re not. You double your efforts, you work harder, you add features,
it feels like progress, but it isn’t.

Small, independent developers need to be especially careful to avoid
black holes, since one black hole can take out your business.

(Larger companies can handle a few black holes—but even then they
eventually cancel them, if they’re smart. Larger companies and
organizations also have the resources to tackle a feature that would be
a black hole to a small company.) []

Leave a comment