Coda

Tuesday, 24 April 2007

One way to judge the scope of an app is to think about how much time you’re intended to spend using it. There’s plenty of room for apps you use here and there for a few minutes at a time, or which you launch just once or twice a week. There’s hardly any room at all, though, for apps you work in for hours at a time, every day.

By this measure, Coda, the new app from Panic, is an epic.

Panic introduces Coda thusly on their web site:¹

So, we code web sites by hand. And one day, it hit us: our web workflow was wonky. We’d have our text editor open, with Transmit open to save files to the server. We’d be previewing in Safari, running queries in Terminal, using a CSS editor, and reading references on the web. “This could be easier,” we realized. “And much cooler.”

I.e. so instead of doing web development and design with a collection of separate apps — text editor, remote file transfer, local file browser, terminal, web browser² — you just use Coda. That’s the what.

As for the why, Panic captures it with Coda’s slogan: “one-window web development”.

In terms of historical user interface traditions and conventions, Unix and the Mac could hardly be more different, but there is one similar philosophy shared by both cultures — a preference for using a collection of smaller, dedicated tools that work well together rather than using monolithic do-it-all apps.³

Coda seemingly swims in the face of this tradition, in that it ostensibly replaces a slew of dedicated apps. Coda’s premise, though, isn’t so much that it is one app that obviates several others, but rather that web development can and should be treated, conceptually, as a single task. That you don’t think, I need to download, edit, save, upload, and preview a change to the web site; you think, I need to make a change to the web site. Feature-wise, yes, web development comprises a variety of specific actions which are traditionally handled by separate specific apps. The appeal of any IDE isn’t so much functional as it is mental.

What Xcode is to app development and what Dashcode is to widget development — that’s what Coda is to web development. Replace Coda’s (lovely) green leaf icon with some sort of blueprint-with-a-tool-on-top and it’d be easy to convince someone that it’s “Webcode”, a new app from Apple itself.

The danger creating an ambitious IDE like this is kitchen-sink-itis. One problem with application bloat is that it has a gravity-like pull. Once you start edging closer to bloat, the pull gets stronger. Like an undertow, it’s easy to think you’re playing it safe — Us? Bloatware? Never! — when in fact you’re already being pulled out to sea.

If nothing else, Panic has clearly succeeded with Coda in two ways: (a) the app looks marvelous; and (b) it does many things but is almost devoid of bloat. (a) is the one most people will rave about, but (b) was the more difficult accomplishment.

The mistake that leads so many well-intentioned UI designers astray is underestimating the pull of bloat, creating designs that attempt to toe right up against the line. But when you get close, you get sucked in. Panic avoided this by not even trying to make Coda’s individual components feature-for-feature peers to the best-of-class dedicated apps.

Coda’s feature set has been trimmed significantly compared to a typical Mac web developer’s toolkit of some combination of BBEdit, TextMate, SubEthaEdit, CSSEdit, Style Master, Fetch, Interarchy, Transmit, Safari, Camino, OmniWeb, and Firefox. Most of the features Coda does include, however, are very well-done. A handful are super-plus crazy good. Tiny little details delight.

Trade-offs are inevitable; the trick is figuring out what to trade.

Consider Coda’s text editor. It’s the juiciest component in Coda, but it does and offers far less than either BBEdit or TextMate. It’s actually a licensed version of the editing engine from SubEthaEdit, replete with over-the-network collaborative editing. It does feature a handful of very clever custom features specific to Coda, but, on the whole, simply judged only as a text editor, Coda is “less than” SubEthaEdit, too — albeit less so than compared to BBEdit or TextMate, if only because SubEthaEdit is the only one that aspires to minimalism.

Each of Coda’s components offers decidedly fewer features than the leading standalone apps dedicated to those tasks. (With the possible exception of the terminal — I mean, come on, it’s a terminal.) This isn’t a dirty secret, or the unfortunate downside of Coda only being a 1.0. Surely Coda will sprout many new features in the future, but it’s never going to pursue any of these individual apps in terms of feature parity.

The appeal of Coda cannot be expressed solely by any comparison of features. The point is not what it does, but how it feels to use it. The essential aspects of Coda aren’t features in its components, but rather the connections between components.

Panic’s implicit argument with Coda is that there are limits to the experience of using a collection of separate apps; that they can offer a better experience — at least in certain regards — by writing a meta app comprising separate components than they could even by writing their own entire suite of standalone web apps. Ignore, for the moment, the time and resource limitations of a small company such as Panic, and imagine a Panic text editor app, a Panic CSS editor app, a Panic web browser, a Panic file transfer/file browser app⁴ — add them all together and you’d wind up with more features, but you’d miss the entire point.

Coda is ambitious not because of its size, because it isn’t all that big. It’s ambitious because Panic has taken into their own hands aspects of the user experience that are typically within the purview of the system itself.

The editor isn’t even scriptable,⁵ the file manager only offers a single hierarchical list view, and so on — Panic is conceding all of that but trying to make up for it by connecting these components in a better way than what you get from Mac OS X’s app and window switching and inter-application interaction.

It’s about reducing clutter and emphasizing the relationships between the different aspects of web development, making it easier to switch from source code to preview to files. Coda’s advantages are most obvious when you consider working with two or three projects at once. In Coda, each site gets its own window, grouping source code, browser previews, terminals, and file listings together.⁶ The idea is that all your stuff — file listing, source code, browser previews, terminals — for site A is here, all your stuff for site B is there. Coda groups and visually organizes these disparate elements by project, rather than by app.

It’s hard to get that sort of per-site (or per-project, if you will) organization with the “collection of separate apps” strategy. Click a Dock icon or Command-Tab to any single app — browser, text editor, terminal, whatever — and all of that apps’ windows come forward. Switching contexts on the Mac is conceptually based around apps, not projects. Coda is like OpenDoc, Panic-style.

In that sense, the most competitive thing to Coda on the horizon isn’t in any application, but in the interstices between applications in Mac OS X itself. Leopard’s Spaces is about just this sort of task/domain/project conceptual model for switching between and organizing windows — addressing the same problem in a decidedly different way.

There is some measure of irony in the fact that virtual desktops are the first major UI concept that the Mac is borrowing from Unix.