inessential by Brent Simmons

October 2004

Can’t toss the keyboard

I have an old Apple Extended keyboard in my office closet. I can’t throw it away—it’s so much better than any other keyboard I’ve ever used.

But it’s ADB, not USB, so I can’t use it without an adapter—and I’ve read enough to know that using an ADB adapter with one of those old keyboards has enough problems to make it a bad idea.

So today I ordered a Matias Tactile Pro keyboard. I’m so looking forward its arrival.

But I still can’t toss the old Apple Extended keyboard. I’m no packrat—quite the opposite—but that old keyboard was quite the thing of beauty. I just went and pressed some of its keys. Still sweet.

If you make your living by typing, you know what I’m talking about. A great keyboard inspires great affection.

Idea for an app

Here’s an idea for an app I’ve had for about a year. But we’re not going to do it because we can’t make the economics work (for us, that is—it may work for you).

Also: it’s possible there’s an already an app that does this, but I just don’t know about it. (If such an app exists, please let me know what it is!)

The problem

If you’re in an office or at a conference, making files available to other people can be a pain. Yes, you could use the built-in file-sharing or Apache, but there are too many steps for setting this up—and there are too many steps for people who want to download your files.

(I was reminded of this idea at Daniel Steinberg’s session on Rendezvous at the OS X conference. He mentioned at one point that someone emailed him a file just to get the file 20 feet across the room. I’ve done this many times myself. It’s dumb, but it’s easy.)

The solution: user interface

The problem here isn’t that we lack file-sharing or web servers or networking: the problem is purely user interface. It’s just plain too difficult to access machines that you don’t access all the time.

So I imagine something very much like iChat’s Rendezvous buddy list. It would list people—people with files you can download—who are available via Rendezvous. When you select a person, you see a list of files that they’ve made available. Double-click a file to download it to your desktop. (You might also have a file-centric view instead of a person-centric view. And a search field, of course.)

You might also add some kind of special thing for URLs—because how many times have you tried to spell out a URL to the person sitting next to you, or pasted it into an email and let it fly around the country before coming to the person sitting next to you. It should be easier!

Under the hood

Whether this is just a front-end to standard file-sharing or Apache or something custom is something you’d have to work out. It’s the least interesting part of the application, but it should be done well, of course, with security very much in mind. (I’d make the file-sharing read-only, so you can’t put anything on someone else’s machine.)


Something like this is useful only if pretty much everybody has it.

It would have to be free for use at conferences, and you’d probably want to make it free for home and non-profit use, too. You could charge for business-office use—but the problem with that is some people just wouldn’t pay, or it would be a popular app everywhere except for in offices.

However, my take on the economics could be all wrong—or someone might like to do it as a for-glory thing. (It might make a cool open source project, and it could be an app about which people say, “Look, sometimes open source projects do have great user interfaces.”)

Coolest utilities for OS X?

What are the coolest desktop organization/launcher utilities—DragThing, LaunchBar, QuickSilver, PathFinder, etc.—for OS X right now?

What do you use and why?

Audio of How To Run Your Own Software Business presentation

Niall Kennedy posted an audio file of the How to Run your Own Software Business panel at the OS X conference.

When talking about getting started as an OS X developer, certain subjects often get more time than they need: dealing with piracy and legal issues get an unrepresentative amount of time. (Maybe because these are easy to talk about?) If you’re a developer, you spend more time working on your software than you do anything else. Then there are other very important issues such as customer support, marketing, figuring out pricing, building a website, and so on.

If worrying that your software will get cracked prevents you from taking the plunge, don’t worry. Your software will get cracked. But you can have a successful business anyway.

(If your software doesn’t get cracked, then that’s probably something to worry about. It means you either spent way too much time making it uncrackable—or it wasn’t interesting enough to crack.)

A panel is too short to talk about everything, so (when I have time) I’ll elaborate on some of what was said and mention some things that didn’t get covered.

Ryan’s cool hack

Ryan Wilcox: “About 30 minutes later, with thanks to PyRSS2Gen I had my todo list items in my newsreader.”

This is one of the cool things about adding scripting support to an application—people find ways to use it that you never expected. I can’t recommend enough to other developers that they look seriously at adding scripting support. (And then keep adding more.)

It doesn’t make sense for every app, but for things like browsers, email apps, aggregators, databases, editors, Usenet newsreaders, outliners, and so on, it’s very important, because it lets people put things together in new ways that make sense for them.


O’Reilly’s Mac OS X Conference starts Monday. See you there?

In case you’re going, but haven’t been to a conference like this before, here’s a tip: turn on iChat and log into Rendezvous. It’s a great way to find people you’d like to meet. You see that so-and-so is logged in, so you say, “Hey! I’d like to meet you—where are you?” It works.

Update 11:23 p.m.: Dori Smith elaborates on iChat privacy settings and adds a bonus tip about using SubEthaEdit.

2 + 2 = ?

It’s become fairly common to state that one of the problems with the professional news media is how they cover things: they report what both sides say but (often) skip reporting the truth.

One candidate says, “Two plus two equals four, but just barely. I used to think it equaled five before I decided it equaled four. However, for large values of two, or small values of five, it could still conceivably equal five. Or, if you redefine five as the sum of two twos, then it would equal five, yes. I performed addition for my country as a young man and I will perform it now.”

And another candidate says, “Two plus two equals five. Simple as that. To say that it equals four is to have a pre-9/11 mindset.”

How do you report on that? You can report what the candidates say. You could also report that two plus two does indeed equal four, but then you have the whole critique-of-objective-reality thing to deal with, so you skip it.

During my own journalism training (college newspaper, early ’90s) I was taught to discard the idea of an unbiased, objective reality. I was taught that there was no such thing as truth: there are only points of view, and it was my job to present the points of view. Forget objectivity, it’s impossible, was the lesson. Instead we had “fairness.”

In other words, there is no truth, there is only what people say.

Here are my questions:

1. Is this wrong?

2. How did we get here?

3. How can we fix it?

Big list o’ browsers

Noticed in my referers: Darrel E. Knutson’s list of Macintosh Web Browsers.

Lots of them I’d never heard of, but some of them—NCSA Mosaic, MacWeb, CyberDog, Spyglass—I remember using.

NCSA Mosaic, even though it lacked the features of Netscape 1.0, was probably my favorite.

I was never that big a fan of OpenDoc, or else I might have liked CyberDog more.

But the first web browser I ever used was Lynx. My Internet connection was by dialing into Eskimo, a local ISP. (I used ZTerm to dial in. I think.) You got a UNIX shell account, so you could run lynx and pine and whatever.

I remember, at the time (1994), debating with people which would be bigger: Gopher or the World Wide Web. I thought it would be the web. But I did like Gopher quite a bit.

And I still like Lynx. I even use it sometimes.

MarsEdit 1.0b4

MarsEdit 1.0 icon

MarsEdit 1.0b4 can be downloaded from the MarsEdit home page.

Here are the change notes.

The goal of this release was to fix a couple high-priority bugs: 1) the bug with applying default settings when you choose post-to-weblog in another app and 2) sending trackbacks.

Some of you are eager for Markdown preview support and for customizing the list of sites to ping. Both of those features are still on the to-do list for 1.0, but they’re not in this beta.

WordPress is kind of a special case, since its external weblog editor support is a work-in-progress. (Make no mistake: I think WordPress is fantastic software, and I recognize that they’re working on fixing bugs with external editor support.)

So when we say that you can send trackbacks now, I’m not actually sure that it works with WordPress yet. It might—or, it might work with some versions and not others.

NetNewsWire 2.0b6 (full and Lite versions) released

NetNewsWire 2.0 icon

We posted new betas of NetNewsWire (full and Lite versions) to the beta page.

The main goals of this release were to fix some important bugs—including crashing bugs, a memory-use bug, and the demo-expiration bug—and to make the Find panel work.

Read the change notes to see what’s changed since the previous beta.

We’re continuing to work on other new features and bug fixes, of course—there will be more betas. So if a feature you’re waiting for isn’t there yet, or if a bug you reported hasn’t been fixed, worry not—we’re still at work.

The Find panel seems like a little thing, but it’s an important feature. In NetNewsWire 1.x, the Find panel was what we had instead of searching. It searched through all your headlines. Now that we have searching in the toolbar, the Find panel can be a more traditional Find panel—it does a search in whatever has focus.

This means that, for the first time in NetNewsWire, you can do a find in your Subscriptions list, in news item descriptions, in web pages, and in the Sites Drawer.

Important: for NetNewsWire Demo Users

Note to people running the NetNewsWire 2.0b3 demo:

If you’re using a demo version of NetNewsWire, and you think it’s anywhere near expiring—don’t quit the program. There is a bug in the beta where if you quit, then launch it after it’s expired, you could lose your flagged items and read/unread status.

We’re going to release a new beta that fixes this bug tomorrow.

You can tell when your demo expires by choosing License... from the NetNewsWire menu.

Curse of A-Rod?

“I moved to Dallas-Fort Worth to improve my future. So should you.”
-Alex Rodriguez, March 2001, in a letter to Boeing executives

It may be that there’s a curse of A-Rod—that he himself is cursed, self-cursed—and that, by not getting him, the Red Sox removed the curse of the Bambino. (Call it ironic symmetry.)

I can’t help but notice that losing A-Rod has a powerfully good effect on a team’s won-loss record. Just look at the Mariners 116 wins in 2001 and the Rangers 89 wins this year.

It may be that the Yankees, in order to win the World Series again, may need to deal A-Rod to another team.

On the other hand, I could be totally nuts. Baseball is tricky, and baseball karma is a mysterious thing.

How to run your own software business

Next Tuesday at the OS X Conference I’ll be on a panel that Dan Wood put together: How to run your own software business.

One of the great things about running a small, independent software business is that it takes so little investment to get going. You need some computers—which I bet you already have. The developer tools are free. You need a website and email accounts and internet access, all of which are fairly inexpensive.

Depending on your goals, you don’t necessarily need to hire employees or rent an office or any of that traditional business stuff. The overhead is low, absurdly low.

But that doesn’t mean it’s a piece of cake. You still have to create a product that people will like, and then you have to deal with paying taxes, keeping records, finding a payment processor, creating a website, helping customers—and a million details. It’s no slam-dunk, for sure.

It’s possible to succeed, and it’s possible to fail—but, the more you know, the better your chances of success.

Blogger get-together

Damien Barrett, Dori Smith, and Tom Negrino are hosting a blogger get-together at the OS X conference a week from today. “Everyone is welcome. You don’t have to be a blogger to come hang with us! We’ll likely be piling into vehicles and going for a late dinner and drinks.”

I’ll be there—it sounds like fun.

RSS Roundtable no audio

I’ve had some queries about an audio file of the RSS Roundtable interview. The interview was, however, conducted via email.

I’m not sure you could have gotten everyone to agree with any other method. Email is useful as a common denominator with things like this.


This is presented as an instance of internet culture rather than as cogent political argument. (Which should go without saying, but I felt like I should say it.)

It’s one of those passed-around-via-email things.

Doesn’t this confirm just about every stereotype of liberals?

Every time you vote Republic, God kills a kitten.

RSS roundtable

DrunkenBatman did a roundtable interview with several OS X aggregator developers. It turned out pretty cool, I think. It was a pleasure to be a part of it.

(If you want to ask me any follow-up questions, feel free to do so in the comments here.)

VoodooPad and NetNewsWire

Gus Mueller has VoodooPad working as an external editor for NetNewsWire—plus a script that sends a URL from NetNewsWire to VoodooPad so you can save it for reading later.

I love stuff like this. I love it when apps work together to create personalized systems that are greater than the sum of their parts.

Rolling back workarounds

As the overall quality level of feeds improves, I’ve been considering removing some of the workarounds in NetNewsWire for messed-up feeds.

Any workaround that either affects performance or has strange side effects is on the top of the to-remove list.

It’s a tricky issue, because there are passionate feelings on both sides. I’m taking what I think is a reasonable path, considering each workaround on a case-by-case basis.

Users expect things to just plain work. Quite rightly. It’s my responsibility to make things work. But, at the same time, there is more than one way to do that.

One way is to write code to work around every possible feed bug, and keep adding to this code as new bugs are found.

Another way is to allow NetNewsWire to fail to parse really bad feeds, and move in the direction of strictness. This doesn’t have the instant gratification of just parsing everything, but it does have some positive influence: it’s another way of getting things to just plain work, via the longer but better route of encouraging people to fix their feeds.

(Before anyone thinks this is an RSS vs. Atom thing, it’s not. I’m talking about feeds in general.)


Before you interpret this to mean that I’m making NetNewsWire 2.0 a strict parser, let me be clear: I’m not going anywhere near there. (I wish I could.)

I have removed one workaround so far—it was a performance hit: for each news item, NetNewsWire 1.0.8 checked to see if its unique ID was truly unique. That check was removed in 2.0b3. This isn’t a bug that shows up often, so the performance hit totally wasn’t worth it.

Note that Yahoo’s search feeds did have this bug—and the Yahoo folks, when they were alerted to the problem, fixed it. How did I get alerted to the problem? Because a 2.0b3 user noticed that their Yahoo feeds were messed up and they let me know.

In other words, the process worked exactly as it should. NetNewsWire workaround removed, bug now visible, bug fixed by feed provider.

Now Yahoo search feeds “just work”—to the benefit of NetNewsWire users and everybody else who uses those feeds with any software on any platform.

My sense is that this means I’m doing the right thing for NetNewsWire users and I’m doing the right thing regarding my responsibility to other developers and users.

Considering removing another workaround

I’m thinking about removing one other workaround in 2.0: it’s a workaround that we employ when a feed isn’t well-formed XML.

An occasional side effect of this workaround is that the HTML is visible in NetNewsWire. And then we get bug reports like “NetNewsWire doesn’t render HTML!” which of course isn’t true.

Why did we even do this in the first place? This goes back to when NetNewsWire was very young. We tried to set our parsing bar at the same place other aggregators did. Radio UserLand handled feeds that were not well-formed XML due to containing unencoded ampersands. We tried to handle that case too, but I never put the time in to handle it as smoothly as Radio.

(I discovered later that it was Radio’s XML parser that wasn’t strict about unencoded ampersands, so the fact that their aggregator handled this case smoothly was a side effect of their XML parser, not any decision on the part of the aggregator developers. But I didn’t realize that at the time—and anyway it wouldn’t have mattered.)

I’m thinking of removing this workaround. NetNewsWire would require well-formed XML. There are people who would argue against this, but I think it’s a more-than-reasonable minimum level of expectation that an XML document would actually be well-formed XML.

Frankly, we don’t see non-well-formed feeds that often anymore. A year ago we couldn’t have removed this workaround, but today I think we can. Here’s my rationale:

1. The cure is worse than the disease. (Seeing the HTML markup isn’t very cool, and it just results in bug reports.) I could do a better cure, but that feels deeply wrong to me.

2. It’s another opportunity to help encourage higher-quality feeds. This process is already happening, but it’s nonetheless true that we can help.

Postel’s Law

Much is made of Postel’s Law—that you should be strict in what you create and liberal in what you accept.

The law is correct.

But there always has to be limits in the implementation. If you’re expecting an XML document, you can’t handle a cow. And you can’t handle an MP3 file, either. You need something at least fairly close to an XML document.

The question is: what lines do you draw? Of course you have to draw lines.

Anyway... all this, and I still haven’t decided whether or not to remove this particular workaround. I’m just considering it.

Frankly, it excites me that we may be at the point where we even could require that feeds be well-formed XML. That’s progress, an unalloyed Good Thing.

Small MarsEdit Badge

We’ve gotten a few requests for a MarsEdit badge you can use on your website—and Bryan Bell is indeed working on one.

But Shawn Neal already created one of those cool 80x15 badges. (Does this style have a name?) You can use this one if you like—it fits in especially well if you have other badges in this same style.


You can copy the image to your own server or serve it from ours. Here’s the HTML:

<a href=""><img src="" height="15" width="80" alt="MarsEdit" border="0" /></a>

(Change the image source URL if you’re serving it from your site.)

Sentimental sap

Science fiction brings out the sentimental sap in me.

I was watching a TV show last night. The folks on the ship had been away from Earth—lost in space and time—fighting the bad guys. Things looked bleak. Except when they looked worse than bleak.

But somehow—with heart and brains, sheer pluck, and the aid of crack Hollywood scriptwriters—they triumphed!

As the ship returns to Earth they see it in the viewscreen. Big and blue and beautiful, it looks like home.

But they’re not sure it’s their Earth in their time yet, until the radio operator says, “Lunar Colony One, orbital platforms, San Francisco—they’re all calling in, sir.”

And, no exaggeration, my eyes well up with water.

Don’t even try to watch Blade Runner with me. I lose it at the end when Roy Baty deactivates. Every time.


When I was 18 years old I liked to try to convince people of the correctness of my political beliefs.

But that was years ago—Ronald Reagan was president—and I no longer enjoy it. In fact, I pretty much hate doing it.

But what if I think this election is very important, far more important than the average election, and our choice is not about four years of one style or the other but about two very different futures for our country?

I tell myself that writing software that allows so many people to read and write about politics is a good thing itself—and it is—but does that get me out of having to take my own stand?

Russell Beattie quotes Dante: “The hottest places in hell are reserved for those who, in time of great moral crisis, maintain their neutrality.”

William Gibson quotes Unamuno: “At times, to be silent is to lie.”

As much as I don’t want to get into this, I’m going to get into this. You can jump out now.

I’m a moderate, not registered with any party. I’m neither pacifist nor hawk. Sometimes I agree with Democrats, sometimes with Republicans, depending on the issue.

My values match most everybody else’s: I want the most freedom and opportunity for the most people. I want our country to be safe and prosperous. I want a society that helps people who need it, but I want that help to be more “teach a man to fish” rather than just “here’s some fish.” I want America to be a force for good in the world.

At this high level there’s nothing controversial. Both Bush and Kerry would agree with the above paragraph, I’m sure.

I could go through every one of these basic values—but I’ll pick just one: safety. Safety because, right now, this is the most pressing issue.

I want a president who will:

1. Actively fight terrorists where they are.

2. Use every weapon at his disposal: military, diplomatic, and economic.

3. Prevent attacks on America.

In other words, I want John Kerry to be president.

George Bush has hurt the cause of safety.

1. He has not killed or captured Osama bin Laden. Al-Qaeda remains a threat. By diverting energy to Iraq, he skipped out on the job of getting the people who attacked us.

2. By being continually hostile and condescending to our allies—our friends—Bush has put us in a position where we must do everything ourselves. That’s like fighting with one hand tied behind your back. I want to fight with both hands—and both feet, teeth, and brains.

3. Bush has insufficiently helped efforts at home to prevent terrorism. The emphasis has been on things like the Patriot Act rather than on the more boring but very important issues of securities in ports, trains, airplane cargo holds, and so on. First responders are under-funded. Tax breaks get priority over common-sense security, which is inexcusable in this time of asymmetrical warfare.

Were this an episode of The Apprentice, Donald Trump might say, “I like this guy. He has a lot of potential. But he didn’t get the guys who attacked us, and he made too many bad decisions and didn’t take responsibility.”

So I have to say, George, you’re fired.

Would Kerry be better? A new president is always a gamble.

But Kerry talks about going after Al-Qaeda, finishing the job in Iraq (we broke it, we bought it), and fixing our relationships with our allies so we’re no longer hamstrung by going it alone. He talks about increasing security inside the United States and funding our first responders.

I don’t think he’s lying about his plans. He might have trouble getting Congress to go along—but that’s a risk every President faces. At least he knows Congress. (Face it: being an “outsider” in Washington means that, well, you’re an outsider.)

They say to always trust your gut. My gut said, “Don’t write this piece!”

But my moral sense tells me that taking a stand is the right thing to do. So, with great reluctance, I will now hit the Post button.

Tim Jarrett’s blogging style

Tim Jarrett writes about his blogging style.

I like posts like this—I learn different ways people use aggregators and weblog editors, which helps me keep improving our software.

One thing we’ve learned from all the feedback we’ve gotten is that there is no one ideal reading/blogging workflow: different people have very different ways.

Weblog editors and crashing

One of the benefits of using a desktop weblog editor is crash protection.

Say you’re writing a post in your browser, and your browser crashes. The post is gone.

Say you’re writing in MarsEdit instead. You can save as a draft periodically so you can prevent a crash from losing your post.

But—even more—MarsEdit automatically recovers your post in the event of a crash, even if you didn’t save it as a draft. When you re-launch MarsEdit it will re-open the post or posts you were working on.

We very rarely get crash logs for MarsEdit, but no application is crash-proof, if for no other reason than circumstances outside the control of the application can cause a crash in even the most stable software.

P.S. Ecto may also have this feature. (If it doesn’t have it already, I bet Adriaan will add it.) My point is more that this crash-protection is a feature of desktop weblog editors that browsers don’t have. Usually we talk about the UI and scriptability and all that as benefits of desktop weblog editors—but this one thing, however unromantic, may be the single best reason to use such an app.

MarsEdit development notes

As you might imagine, we’ve been getting lots of feature requests and bug reports for MarsEdit. When we released the beta, we had a pretty good idea what the to-do list for 1.0 was, but it’s even more clear now that we’ve had so much great feedback.

Here are some of the main things we’ve been hearing from people—and what the plan is. (There are tons of little things I’m not going to mention, so if your bug report isn’t mentioned below, it’s cool, we’re on it.)

Markdown, Textile, etc. preview support

Originally we planned to do this for 1.0.1, but that’s because I underestimated the demand. More people use these plugins than I thought, so we’re going to add support in 1.0.

Trackbacks bug

Many people have reported a bug that sending trackbacks doesn’t appear to work. I’m not sure yet if this is all the time or just some of the time, or if it’s with some systems but not others.

But this is the highest priority bug to fix.

It’s darn hard to test, because we don’t want to litter the blogosphere with bogus testing trackbacks. (But, fear not, we’ll find a way.)

Customizable pings list

MarsEdit supports pinging, technorati, and Lots of people have asked for a customizable pings list. It’s important to enough people that we’ll add this to 1.0 also.

Blogger titles

Supporting titles for Blogger requires that MarsEdit use the Atom editing API—which we’re not going to do in 1.0. But it’s an extremely high priority for after 1.0.

Thanks, Yahoo!

Remember how the other day I was picking on Yahoo because its search feeds had non-unique unique IDs?

Now today I notice that the bug has been fixed. (They also switched to using RSS 2.0.) Here’s the feed I was looking at in my previous post.

Thanks! Good job!

Now I can add Yahoo to the list of search engine feed providers in NetNewsWire, which is something folks have been asking for, and I’m glad to be able to do.

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 later.

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 <h(x)> tags. Another person would say that it has to reflect the style sheet they use for their site. Another person would absolutely need <pre> 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.)

Update 8:20 PM Pacific: I certainly don’t mean to imply that Adriaan or any other developer who has added WYSIWYG editing is wrong to do so before a full-featured WYSIWYG editing component is available. A black hole for one developer with one product is not necessarily a black hole for another. Not at all. (See the comments for more on this.)

MarsEdit user interface notes

I like writing about user interface—I like to write about the choices we made and why we made them.

Since MarsEdit is new, you might be curious about the thinking behind it.

Here’s the story...

But first, some background

My history with weblog editors goes back a few years. I helped write what may have been the first external weblog editor: UserLand Pike, a precursor to Radio UserLand. It was unveiled at a conference for Manila users back in early 2000.

I’m not sure if it pre-dated the Blogger API, but it used Manila’s own XML-RPC API, and it was fairly sophisticated: you could edit weblog entries but also other pages and templates and so on. It used multiple windows: each document opened in a separate window.

Unlike Radio, Pike didn’t create weblogs: it was an external editor for Manila.

Which is to say I’ve been writing and using external weblog editors for going on five years now. (My own weblogs don’t even have a browser-based UI.)

And the same themes that existed then exist now.

Why can’t it be like email?

Back when we were working on Pike—and later, too—one refrain kept coming up: weblog writing should be like writing email. Type cmd-N, get a new window, write something, click the send button.

By the year 2000 people were comfortable writing email. You could even tell in the writing: people wrote email better than they wrote for their weblog. (Not everybody, not all the time, but in general.)

Their email was often relaxed and clear in a way that their weblog writing wasn’t. Maybe it’s something about writing for the public—but I’m not sure about that since people sent well-written email to public mailing lists.

So perhaps it was the tools. Perhaps software with an email-like feel would make it easier to write.

The idea behind MarsEdit is this: the value of having an email-like user interface is not just that it’s easy-to-learn—it’s that it helps people get into a more email-like frame of mind, where they’re more likely to be relaxed, less pressured to Write Something Good.

I can’t stress this enough. The importance of the email-like interface is that it makes weblog writing feel more like writing email.

The problem of cmd-N

Above I wrote “Type cmd-N, get a new window, write something, click the send button.” That in a nutshell was the design of MarsEdit.

But at first we still pictured it as part of NetNewsWire. The weblog editor already was part of NetNewsWire, and we didn’t really want to do the risky thing of monkeying with a product that was already so successful.

But cmd-N was a problem. In any app, cmd-N—the File > New command—should create a new instance of the most important thing you create in the app. NetNewsWire 1.x didn’t have a New command, but it seemed obvious to me that cmd-N should create a new subscription.

But if cmd-N creates a new weblog post instead, then that says that the most important new thing you create in NetNewsWire is a weblog post, which means it’s more a weblog editor than a newsreader. That would have been the wrong direction.

We kept thinking about it. NetNewsWire should have a File menu that’s all about subscriptions, since that’s what you manage in a newsreader.

But a weblog editor that’s going to use an email-like interface needs a File menu that’s all about managing weblog posts.

The more we thought about it, the more it was obvious that the weblog editor had to be a separate application. In order to improve both NetNewsWire and the weblog editor, we needed to induce mitosis.

Initial design

I did the initial design work—actually sitting down with Interface Builder and laying out the app—almost a year ago, on the second floor of the Westin Santa Clara, during idle moments at the OS X Conference. (If you look over my shoulder this year, who knows what you might see!)

MarsEdit screen shot

(In case you haven’t used MarsEdit, click the screen shot to see its main window and document windows.)

The initial design used a three-pane interface closer to NetNewsWire. Later we switched to using a drawer for the weblogs list—but the principle is the same. We mapped weblogs to mailboxes and weblog posts to emails. Obviously, the mapping isn’t perfect—weblog editing is not exactly the same as email (nor is RSS/Atom exactly the same as email)—but it was close enough to make this interface possible.

The document windows were also designed then—and they were designed to look like compose-email windows in

One of the significant changes between the initial design and the final design was how previews were done. Originally the preview appeared in a drawer at the bottom of each document window. (Mail doesn’t have a preview. That’s just one of many little things that are not the same. Email apps don’t need a preview.)

We switched away from the in-drawer preview mainly because—for most people—being able to resize the preview independently of the editing window was important. (We also considered doing the preview as a splitview, but that still had the problem of not being able to resize completely independently.)

The one thing I liked about the in-drawer preview was that it linked together the document and the preview, and using a separate window gets rid of that link. (That right there is a classic example of a trade-off.)


By December I was actually using MarsEdit to write for my weblogs. The basics were done. A very small amount of code from NetNewsWire was retained, some of the most low-level plumbing code, but even that was re-architected and simplified.

January: ecto released

When Kung-Log was rewritten as ecto—which was released last January, if I recall correctly—I checked to see if ecto was doing an email-like interface with multiple windows. It wasn’t.

But now it is! Which I take as further confirmation that the email-like interface is the right direction. I also learned that Phil Ulrich was making Userspace a multiple-document app. So it sounds like we were thinking on parallel lines.

External editor interface

MarsEdit didn’t go into testing until closer to the summer. The first release to testers was the first real test of whether mitosis was the right thing to do and whether or not MarsEdit was, well, likable. (A big yes on both counts. Whew!)

We had already planned to do an external-weblog-editor interface for NetNewsWire (long before we came up with MarsEdit), and we realized this should happen along with the shipment of MarsEdit, so it’s clear that people have choices. (To make it so that NetNewsWire could only use MarsEdit sounded like a Microsoft thing to do. Yuck. Since Sheila and I run our own business, we can actually have morals and ideals if we want to.)

The big UI challenge

I’ve said before that weblog editing is like email, but that it doesn’t match exactly. It’s actually much more complicated than email.

So we had a principle: keep it as simple as possible, but still support the features people need.

In email, for any given message, you have the following options:

Body (the actual message)

In a weblog post, you have some combination of the following:

Extended entry
Excerpt entry
Main category
Multiple categories
Trackbacks to send
Whether or not to accept trackbacks
Text formatting
Whether or not to accept comments
Whether or not to post to the home page

That’s, well, more. Not only that, but some of the things are relatively large. Categories requires some way to display a list and select items. URL, extended, excerpt, and keywords entries mean more text fields. You have to be able to enter trackback URLs somewhere. Etc.

It’s not nearly as simple as email. Our ideal was still “Type cmd-N, get a new window, write something, click the send button”—but we had to support all these features too.

I looked around at other document-based apps that have such a huge number of different options to set with each document. I couldn’t find any. They may exist, but I don’t know what they are. Whether other such apps exist or not, weblog editing is an extreme case.


Part one of the solution was morphing: a document window should change what options it presents based on the type of weblog you’re posting to.

For instance, if you’re writing for a Radio weblog, you don’t see options for extended, excerpt, and keyword entries. If you’re writing for a Blogger weblog you don’t see Radio’s post-to-home-page checkbox. If you’re writing for a TypePad weblog you don’t get a URL field.

I’m not normally a fan of morphing. I like interfaces that stand still and don’t do weird, automatic things. But in this case morphing was totally the way to go. (It was also one of the first things I coded in MarsEdit, and it just plain felt right.)

You can see it in action if you have several different types of weblogs you post to. Open a document window, then choose different weblogs from the weblogs popup menu. (If you go from a Movable Type to a Blogger to a Radio to a Blosxom weblog you’ll see the morphing in action. Note the animation: that was a key to making it feel right.)

This allowed us to do something important: the interface could exactly match your weblog choice. It wouldn’t be more complex than it needs to be. With so many potential options, it had to be done: just disabling things wouldn’t have done the trick. (And it’s one my favorite features, by the way.)

The extreme case

But, even with morphing, there was still the extreme case: Movable-Type-compatible weblogs.

They use almost all the options in the list farther up—they’re complex systems. (I don’t mean that in a bad way. People love Movable Type, TypePad, and WordPress, quite rightly. I just mean that the user interface was a challenge because there are so many options.)

MarsEdit options drawer screen shot

The first thing to handle was categories. The obvious thing to do was what we’d done in NetNewsWire: put them in a drawer. It was also obvious that we could put the little options (text formatting, accept comments, accept trackbacks) in the drawer too.

That left trackback URLs—and the biggie: extended, excerpt, and keywords entries.


We couldn’t fit trackbacks into the document window, not without cluttering it up too much.

And, since this is a feature not everyone uses all the time, it was okay if it was slightly less accessible than categories. So we created a separate window and added a trackbacks icon to the toolbar to open it. We made the trackbacks editor modal. Which may seem like an odd choice. I don’t generally like modal windows, but setting trackbacks seems like something most people do modally anyway, so it fits.

Extended, excerpt, keywords

A new feature in Panther helped us out here: segmented views, those little capsule-like things you click to change the view.

We put those in the same place puts the signature popup. Does it map? No, not the way the weblogs popup maps to the account popup in Mail. But there was space there, so we went with it.

We could have used a real tab view, but that felt too heavy to me when I tried it.

This, as much as morphing, was a key to MarsEdit’s design. (The way we had done it in NetNewsWire 1.x—a separate window with the various fields—bit.)

Most of MarsEdit’s pre-beta testers liked this solution. (Especially when I added the ability to set different background and text colors for the different fields.) But one tester suggested that mimicking the browser-based UI was the right thing to do here—we could have made the separate fields all visible at once.

Arguments for mimicking the browser-based UI:

1. It’s what people are used to, so there’s a familiarity thing that would be good.

2. It allows you to see what you’ve typed in one field while you’re typing in another.

Arguments against:

1. It removes the entire this-is-email feel. You’re writing in a form rather than in an email-like document window—and the email-like-feel is the core philosophy behind the app.

2. It means too many widgets, and we’re going for maximum elegance.

3. It gives you less room for writing. In fact, on smaller displays, you would have little, tiny fields to write in.

We made the call to stick with the segmented view instead of having all fields visible at once.

Keeping it simple

We also worked hard to keep menus and other things as simple as they could be made. Note that the menu bar is fairly narrow (compared to Safari or NetNewsWire) and the menus aren’t very long.

Part of this is just good UI practices—less is more—and part of it is because weblog editing is already surprisingly complex and we needed to balance that out.

But there was another reason behind it: many people using MarsEdit will be using a desktop weblog editor for the first time.

Options create anxiety. When people are trying something new it’s extra-important to remember this, because there’s already a built-in level of anxiety when trying something new.

If MarsEdit seems like a small, non-intimidating app then it means we’ve done our job.

Not just us but our testers too—who often pointed out where we could cut redundant widgets and menu commands to the benefit of the app. (Our testers are totally key. To say that this was a collaborative process would be to understate their contribution. Check out the About box.)

“...and, in conclusion...”

This is a hugely long post, so I’m going to conclude by just thanking you for reading it. Thanks!


trackbacks toolbar icon

Not mentioned above is Bryan Bell’s contribution. His icons play a big role in the feel of the app.

My favorite may be the trackbacks icon. I had no idea what he’d come up with—and I was happily stunned when I saw it. Radar! With a document in the middle! Very clever.

Alternate NetNewsWire icons

Wolfgang Bartelme posted an alternate NetNewsWire app icon. Veerle Pieters was I think the first to post alternate icons—and she includes instructions on how to replace the current icon.

There may be a business case to make for not linking to these, for saying, “Hey, this is our look, don’t mess with it”—but actually I think it’s quite cool that people would make alternate icons.

While I totally dig Bryan’s icons, not everybody has the same taste, and an icon that looks good on one display in one person’s Dock will look different elsewhere. No problem.

Non-unique unique IDs (which Joe?)

The biggest time-waster in writing aggregators is the issue of unique IDs.

One thing that separates RSS and Atom from email is that items can change. So, when an item changes, how does your aggregator know it’s a change rather than a new item? It looks at the item’s unique ID.

Unfortunately, not all feeds have unique IDs. Which is too bad. But what’s worse—what’s far worse, what makes me foam at the mouth and blow steam out my eyeballs—is when a feed has unique IDs that are not actually unique. That’s just perverse.

I don’t want to pick on an individual or small company—so I’ll pick on Yahoo. Consider this feed that does a news search on “apple.”

If you look at the source, you’ll note that each news item begins with <item rdf:about="*">. The URL is supposed to be unique in the feed.

From the RSS 1.0 spec: “{item_uri} must be unique with respect to any other rdf:about attributes in the RSS document and is a URI which identifies the item. {item_uri} should be identical to the value of the <link> sub-element of the <item> element, if possible.”

I’ll say it again: the URL must be unique. If the URL isn’t unique, you get a situation like where you have ten guys named Joe in a room, and you say, “Hey, Joe!” and they all turn around to look at you.

It would be better if they didn’t even have names, so you could say, “Hey, brown-haired guy with the wire-rim glasses wearing a polka-dot shirt!”

Yahoo isn’t the only creator of feeds that makes this mistake. This isn’t a case where fixing Yahoo’s feed fixes the problem as a whole, because it occurs other places too.

(But it would be nice if Yahoo fixed the bug, so I could include Yahoo as a search engine provider in NetNewsWire the way we include Blogdigger, Daypop, and Feedster. In Yahoo’s case, the easy thing for them to do is probably make the rdf:about URL match the link URL.)

P.S. I’m calm again now. I just have to vent about this occasionally. Breathe in, breathe out...

SpaceShipOne wins X Prize

SpaceShipOne wins X Prize!

It may seem like a small story—but I don’t think it is. My hope is that private space flight means we’re for real this time, we aren’t just tip-toeing.

I love NASA, but, for whatever reasons, they’ve been soooo slooow. As a boy in the ’70s I thought for sure we’d be on Mars by now. I thought we’d have a lunar colony. By the year 2000? Heck yeah, it was a cinch.

And then the Apollo missions ended, and then we got the space shuttle—which was never nearly as inexpensive and safe as it was supposed to be—and it looked like we lost interest in space.

But today is a new start.

Things you might not know about MarsEdit

In any software, some features are more immediately visible than other features. You can’t make everything front-and-center without making a confusing mess.

So here are some features in MarsEdit you may not have run across yet.

Works with web browsers

If you want to blog the current page in your browser, you can click a bookmarklet to send the page to MarsEdit.

In MarsEdit, choose Install Bookmarklet from the MarsEdit menu.

By the way—in NetNewsWire you can also choose the Post-to-Weblog command when a web page is in front. This just uses the standard Post-to-Weblog command in NetNewsWire, not the bookmarklet. And it works with other weblog editors too.

Edit with BBEdit, SubEthaEdit

This may be my favorite feature—possibly because I was a Frontier user when Dave Winer and Rich Siegel first worked out this interface, possibly because I just plain love it when apps work together.

Look in the File menu for the external-editor commands.

Default settings for comments, accept trackbacks

You can tell MarsEdit what should be the default settings for comments, accepting trackbacks, and text formatting. (For Movable-Type-compatible weblogs.)

In the weblogs drawer, double-click the weblog to open its settings window, then click the Defaults tab to set the default settings.

Customizable keyboard shortcuts

In a document window, choose Edit Shortcuts from the bottom of the HTML pulldown in the toolbar. You can set keyboard shortcuts for both HTML tags and for your custom tags.

Set default window size

You can set the default window size for document windows. When you have a document window whose size you want to be default, choose Save Window Size from the Window menu.

(We went around about this on the testing list. Some people preferred that it be automatic, that it just remember the size of the last window edited. Others preferred that it be explicit, so you can change the size of a single document window without making that the default size for subsequent windows. I agreed with that.)

Previews can look like your weblog

Your previews in MarsEdit can look as much like your weblog as you want, using your own layout and style sheets and so on. Each weblog has its own preview template.

Check out this screen shot to see what I mean.

Quick link adding

If you have a URL on the clipboard, typing shift-cmd-A will add a link using the selected text in a post. No sheet appears—it uses what’s on the clipboard.

Setting categories etc. for a post

To set the categories and other options for a post you’re writing or editing, click the Options icon in the toolbar. A drawer appears with options available to the type of weblog you’re posting to.

Help book

Yes, we’re Mac users, and we don’t need no stinkin’ help book. True.

But it’s there, and it’s fairly extensive, and it’s meant to be useful. Most of it is pretty short pages that just tell you step-by-step how to do something you might not have known you can do.

No margins

NetNewsWire w/o marginsConsider this screen shot (click for a large version)...

What’s different about is that there are no margins on the left and right side and the splitviews are narrower.

I post this not because this is what the next build will look like, but to talk about one of the challenges of software development.

Earlier betas

For a long time during earlier NetNewsWire beta testing, the margins were indeed collapsed as shown. Some people thought that the layout was cramped this way. So we tried it for a while and then went back to having margins.

And yet... some people preferred the no-margins look. It’s cleaner, you might argue, and it means you have more available horizontal space. Look at Mail, for instance—no margins. (And look at MarsEdit: same layout as Mail.)

And yet, again... if you look at iTunes, iCal and other Apple apps, they have margins. Sure, they’re metal, and that’s a difference, but still it shows that there isn’t a hard rule about margins that applies everywhere.

The real point

The real point is that there are some people who prefer margins and some who prefer no-margins. As a software developer who wants to please users, what do you do? Create yet another preference? If I added this to the preferences, people would (quite rightly!) complain that it’s really not needed. Just choose one and stick with it, they’d say.

Another option is a hidden, Terminal-accessed pref. The drawback there is that many of the people who might like the option wouldn’t know about it.

The last option is just to go with margins (or no-margins, one or the other) and hope that people who would have preferred the other way still like the software for a bunch of other reasons, even if this one thing isn’t ideal for them.

Thinking radically

But then... I can’t help but start thinking out of the box. What about a more radical change? After all, I get feature requests to put the subscriptions list in a drawer, to make it a column view like in the Finder, and to put it in a separate window entirely.

The people who make such requests aren’t making them just for fun, they’d like to see these things happen.

But at the same time the different ideas are mutually exclusive (unless I have a whole bunch of prefs and support a whole bunch of different layouts).

(I can hear my former boss’s voice saying, “Brent, you’re off in the weeds. Come back.”)

Flexibility: good or bad?

So then say I did support more layouts. NetNewsWire is already a fairly flexible program, and this would be going in that same direction.

Lots of people love that—they dig apps that they can customize, that they can to get to work just the way they want them to work. When they call an app a “Swiss-army knife” they mean it as praise.

But then there are people who don’t like that: they’d rather have less flexibility. (I think the implication is that flexibility means bad design, or that a desire to please everybody is incorrect.) When these folks call an app a “Swiss-army knife” it means they don’t like it.

What I mean by all this is that software developers are always in “damned-if-you-do, damned-if-you don’t” situations.

Reducing it to the absurd: you can’t please everybody—because, if you try, you’ll then find there are people who are displeased by apps that try to please everybody.

(“That’s some catch, that Catch-22,” he observed. “It’s the best there is,” Doc Daneeka agreed.)

So you take a middle road and look at things on a case-by-case basis (but, importantly, without ever losing the forest for the trees).

Software is about execution and trade-offs. Assuming equal execution, the difference between two apps is the different trade-offs they made. There’s no avoiding trade-offs.

The other real point

The other real point of this post is that every single little thing in the user interface of an app is sweated over to an obsessive degree. (I myself often go to sleep at night thinking about splitviews and scrollbars and which toolbar items should be in the default list and on and on.)

If I could write 700 words just about the margins—let’s face it, a very small detail—I could write a novel about the embedded browser.