MarsEdit report

In the spirit of Gus Mueller’s after-development report on VoodooPad 2.0, here’s mine on MarsEdit 1.0...

(Note: I may ramble a bit. And: this is mostly about programming.)

Mitosis

The genesis of MarsEdit was the idea of mitosis, that we could remove NetNewsWire’s weblog editor and create a new, separate weblog editor—and thereby create a better newsreader and a better weblog editor.

We had long planned to support external weblog editors in NetNewsWire—but it wasn’t until autumn 2003 that we considered supporting only external weblog editors. That’s when we first sketched out MarsEdit’s user interface.

To my delight, the final version of MarsEdit looks very, very much like our original vision, done originally as a non-functioning prototype in Interface Builder.

Splitting up NetNewsWire like this was a big risk, though, and we didn’t know how it would be received. (It turned out that the feedback far surpassed our hopes.)

We not only split up the product but created an open interface so that various combinations of newsreader and weblog editor could work together. This is something we’re very proud of—even though it increased the risk.

Programming stuff

Early on, before testers even saw it, I had a few challenges...

1. Morphing user interface

I had to develop an adaptable user interface that morphs based on the capabilities of different weblog systems—and not have the morphing be obnoxious.

This was a response to one of the major problems with NetNewsWire’s weblog editor: fields that a given system couldn’t use were just disabled rather than disappeared. This led to lots of email and bug reports. Though I’m not generally a fan of UIs that morph, it had to be done here—and I was utterly pleased with the result.

At first, actually, I was entranced—I used to just keep changing the weblog system to watch the animation of fields appearing and disappearing. But I got over it and went to work on the next thing.

2. Asynchronous XML-RPC

I had to do a better job dealing with asynchronous XML-RPC calls than I did in NetNewsWire.

Here’s the deal—you click a button like Post or Refresh, it kicks off a call to the server to do something. MarsEdit waits for the response—but it can’t lock up while waiting, it has to be responsive to your commands, and it has to do things like run a progress indicator. And calls have to be chainable: make a second call after the first completes, but not before.

Well, I had this working in NetNewsWire’s old weblog editor, but I was never pleased with it, and there were times when the UI would miss the response, and a progress indicator would run forever.

This was just an architecture job. I ended up with a system both cleaner and better than what was in NetNewsWire. (The second time is usually better than the first, after all.)

What I ended up with was solid plumbing. With leaky plumbing, you spend all your time patching it and not enough time working on the UI—and the UI is where you need to spend your time.

I have barely touched this code (except to add a minor feature or two) since MarsEdit first went into private testing, which says alot for the code.

From a high level, every net operation looks like an Objective-C method call that, instead of returning a value, returns immediately and calls back to a method when it’s done. Since the code is object-oriented, maintaining state is almost not even an issue. (Simple stuff, nothing revolutionary, just plain old-fashioned goodness.)

3. Documents

Cocoa has wonderful built-in support for document-based applications.

The only trouble is, that support assumes that you’re saving documents to disk.

The whole point of MarsEdit was to be document-centered, like email—but, also like email, you don’t save files to disk, you send your document to the internet somewhere.

I had to learn about Cocoa’s document-based app features—and, at the same time, I had to learn how and where to over-ride it so that it didn’t think it was loading and saving disk-based documents. This turned out to be difficult—lots of trial-and-error. The docs don’t talk about this much.

And the early, private testers would tell you that I didn’t have all the kinks worked out in the first versions they saw.

Design philosophy: maximum elegance

Throughout the process of working on MarsEdit, the phrase “maximum elegance” repeated in my head. The idea was to keep it as simple and focused as possible.

As I’ve written before, weblog editing is far more complex than email: you have things like categories and text filters and trackbacks and all this stuff you don’t have with email.

The phrase “maximum elegance” was just a personal reminder to myself to simplify as much as possible. With something as complicated as weblog editing, you have to be relentless about simplification, or it will get away from you.

Note, for instance, how short and small MarsEdit’s menu is. How many other productivity apps do you use have such a small menu? Note how the design of document windows is influenced by Apple Mail rather than, say, Microsoft Word.

The “lightness” of an application is a matter of feel rather than number of lines of code or number of resources. It’s a design issue. I wanted MarsEdit to feel weightless in order to balance the heavy complexity of weblog editing.

Note to developers—regular folks, please skip this—there is, oddly, a danger to making an app feel light. People sometimes get the impression that it’s not light but slight—that it can’t possibly have very many features and couldn’t have taken much time to develop, so it can’t possibly be worth paying money for. That’s not true, of course. (It’s like that old line about not having enough time to write a short letter.) However, even though there’s this danger, it’s better to go for lightness, because the vast majority of Mac users appreciate quality.

The early, private testers were a huge help with this. I simplified—but they simplified even more. There was lots of feedback about stuff that could be removed from these early versions, and I think I used all of it. (I’m a strong proponent of development-by-subtraction—after all, MarsEdit exists because we removed the weblog editor from NetNewsWire.)

Of course, there’s no design nirvana. MarsEdit is very close to my original vision, and that’s wonderful—as long as the original vision is good. But is there room for improvement? Could the user interface be better still? Yes, of course. (And I already have plenty of ideas for how to make it better.)

Last-minute features

Once MarsEdit was in public beta, it was fairly close to what 1.0 would become, but of course there were bugs to fix.

And it turned out that there were a couple features I was putting off until after 1.0 that really needed to be in 1.0:

1. Preview with text filters—Markdown and similar.

2. Customizable list of URLs to ping.

That’s not to say there weren’t plenty of other feature requests, but so many people asked for these two that it became apparent that they had to be in 1.0. If I could have waited on these, I would have.

Before deciding to implement them, I had to answer a few questions for each feature:

1. How much time would it take to develop?

2. How much time would it take to test?

3. Is this feature a likely site of bugs, or will it be straightforward?

4. Can it fit in the existing user interface without major disruption?

For text-filter-preview and customizable pings list, I guessed (and all you can do is make an educated guess) that they would be quick to develop and test, that they’re straightforward, and that the user interface wouldn’t require many changes.

Another popular feature request was supporting titles for Blogger. This we didn’t do in 1.0, because it would take too long to develop and test and it would be a likely site of bugs. It sounds crazy—we’re just talking about titles, no big thing, right?—but it required adopting the Atom editing API, which is a big job. (Now that 1.0 has shipped, this is MarsEdit’s top priority, by the way.)

Wrong turns

There weren’t many features pursued that I had to drop or change drastically. Just a few things:

1. At one point during the private beta I wanted to add what I thought was a cool Rendezvous-based feature—but it didn’t interest the testers, and finally it didn’t interest me personally that much, and I dropped it before spending programming time on it.

2. The first versions of MarsEdit did previews quite a bit differently: the preview appeared in a drawer attached to the document window. This was cool for one major reason: it tied the editing window and the preview together. In a way, this is much better than having a separate, single preview window. But it had a serious drawback: you couldn’t resize the preview independently of the size of the editing window.

At one point I considered doing the preview as a splitview in the document window, which would have let you semi-independently resize it—but I ended up going for a separate preview window. (There were testers on all sides of this issue, by the way: there was no consensus. Sometimes a solution is obvious to everyone but the developer, but not this time.)

3. For a long time during the beta process the app icon looked very much like the Firefox icon. (This was just coincidence—the MarsEdit icon was originally created before the Firefox icon was created. The final icon Bryan Bell created is fantastic. I love it.)

The real story behind the name MarsEdit

MarsEdit 1.0 icon

In an alternate universe, MarsEdit is an outliner instead of a weblog editor—and its name is MarsLiner. It has the exact same icon MarsEdit has.

When I first asked Bryan to make a Mars-with-spaceship icon—way back in early 2003 (I think—could have been 2002) it was for an application named MarsLiner. The idea was to do an outliner that could fill in for MORE.

It’s been a sore spot in my computing life that no outliner for OS X feels as good to me as MORE did. This is purely subjective, of course—there are several really great outliners for OS X. But I want MORE, and I was willing to write it myself. (Just the outliner, that is—I didn’t care about the presentation stuff in MORE.)

The idea was to have a text-oriented outliner—I didn’t care about embedding movies and sound clips and whatnot—that was designed for keyboard users, felt very light, and was super-fast.

The rough draft of this idea was the Notepad in NetNewsWire 1.x. But MarsLiner was to be a huge improvement, it was supposed to be the outliner of my dreams.

But then I discovered something important: most people don’t care about outliners. And the people who do care about outliners, many of them would want the embedded media features that I didn’t care about. So I realized that the market would be small, just a subset of the outliner market, which is small enough already—and there are already some great outliners already.

When we decided to bag MarsLiner and do a separate weblog editor instead, I wanted to use the name “Mars” somehow and use Bryan’s cool icon. Hence the name MarsEdit. We rationalized the name by saying it represents editing at a distance, since you’re not editing local documents, you’re editing documents that live on the web somewhere.

But really it was because I like Mars and spaceships and we already had a great Mars icon.

How much programming time had I spent on MarsLiner? Very little, thankfully—I built NetNewsWire’s Notepad as a stand-alone app. I didn’t even get as far as supporting multiple documents or doing a save command.

But still today I wish for the outliner of my dreams.

From time to time I’m tempted to do it as a Terminal-based thing, all done with ncurses. This way it would have to be purely keyboard-based; it wouldn’t be able to display pictures or movies; it would be fast.

Maybe you will do it. I can dream, right?

12 Dec 2004

Archive