Introducing jimboPad

by James Somers, June 26, 2012

I was wildly excited when I saw Paul Graham demonstrate Etherpad’s “timeslider” feature. Etherpad was a text editor built for real-time collaboration, and to do its thing, it had to record every one of your keystrokes; the timeslider, a simple feature bolted on at pg’s request, let you play those keystrokes back. Which meant you could fast-forward, rewind, and slide freely through the unfolding history of your text.

I was so taken by the idea that I wrote a breathless essay for the Atlantic about it called “The Simple Software That Could—But Probably Won’t—Change the Face of Writing.” I imagined a future in which great writers would write in Etherpad and we, their admiring students, would pore over the breadcrumbs. What better way to teach the craft than to expose a writer’s every micro decision?

Since then I have written a lot of words, but not very many of them in Etherpad. The problem is that Etherpad’s chief task is real-time collaboration—seamlessly merging the changes of many simultaneous users. Its source code is therefore preoccupied with that task (and all its attendant complications). The features that I care about as a private writer are not only neglected, but—precisely because the code is burdened by bigger problems—hard to hack on. There is just too much other code in the way.

So I have found myself writing in a variety of different editors, each for a different reason: WriteRoom for its “distraction-free” UI; Textmate for swift Markdown compilation; Google Docs so that I can work from any computer; Etherpad for dynamic playback. And I have found myself dreaming up a happy union of all their best features.

Then recently, I built it: a web-based editor I’ve taken to calling jimboPad. What’s it got?

1. Playback a la Etherpad:

  • With compact storage. Where Etherpad would store the entire text at each moment in time, jimboPad only stores the differences between each revision. Etherpad’s “histories” quickly grow into the gigabytes; jimboPad, which leans heavily on Google’s diff-match-patch library, gives a thousand-fold compression.
  • With snappy, colorful playback. In jimboPad the changes introduced in each revision are highlighted, and the playback page “snaps” to those changes. Etherpad’s playback forces you to scroll all over the place to see what’s changing. In jimboPad that happens automatically. Hit “play,” sit back, and watch yourself write.
  • With intelligent search. In jimboPad you can “slice” the document’s history to only those revisions containing a given search term. That way, in a massive months-long project with maybe hundreds of thousands of changes, you can interrogate certain sections, in a highly focused way, that may have only flickered in and out of existence.

2. A beautiful, unobtrusive, full-screen UI, just like WriteRoom.

3. An ever-present word count. (And when I select a passage, it only counts those words.)

4. A print view great for pencil and paper editing, with a large right margin and space between each paragraph.

5. Automatic markdown rendering so that I can write in plain text and see it formatted—with bold, italics, blockquotes, hyperlinks, bullets, etc.—for printing and playback.

6. The ability to save “important” revisions—a first draft sent to an editor, for instance, or a shortened version for publication—as Github gists, themselves easily accessible, printable, and diff-able using git.

7. The ability to work on the same document offline (on my own computer) and online (on any computer) without worrying about version conflicts, and without breaking the stream of micro-edits stored for playback.

The intangibles

Version control is an enormous boon for programmers. Git’s cheap branches and easy merges underwrite an ability to experiment with code, to feel out the shape of a problem with small sorties, unencumbered by the fear of losing code that works. At every moment you have “a sense of where you are.” Computer code is awfully complex (Dijkstra wrote that the programmer “has to be able to think in terms of conceptual hierarchies that are much deeper than a single mind ever needed to face before”) and yet with git your current working context can always be understood—is in fact treated as—a patch on top of a snapshot. The whole difficult business of programming is reduced to a diff. You’re never very far from the ground.

How to get the same feeling in prose? On the one hand it seems that natural language is too finely grained: the smallest sliver of a change, even the sort of change that looks to be just “style,” can drastically affect what a reader thinks while she reads. Reader’s brains are fragile that way—there is no fixed “point” that a sentence makes, no cognitive gestalt that can be held constant while you tinker, say, with cadence. Cadence is part of the point; everything in a sentence is part of the point.

This is why if you were to unfold a writer’s keystream, and play it back, every paragraph would look like a busy construction site, a chaos of small maneuvers. If you were to watch the composition of this very sentence, in fact, you’d see what must look like the visual equivalent of a stammer. My progress is halting—I write a small half-clause and then throw it away. I change key words constantly. I jump up a few sentences, maybe to the top of the paragraph, re-read it, and make changes there. There is a sense of forward motion but it’s always uncertain.

This is why if you were to do “version control” for writing, you would have to record everything. You would have to make it trivial for the writer to “branch” off from some articulation, fail, and fall back to what they had before. Their every half-overture would have to be saved—because every half-overture, like every “commit,” might have words they would want to get back to.

I saw this recently with a long article I wrote, much of it (gratefully) in Etherpad. I’d be working on a sentence, try something out, delete it, try something else out, shuffle things around, and see, suddenly, that the old way was just right in the new context. Such “firefly” sentences would be lost by most word processors; I’d have to recall them from memory. But in Etherpad I could just slide back a few minutes and find what I’d tried.

The same thing would also happen at a higher level. I would spend a brutally long time working out a whole section, and then I’d throw that section away. Later on—sometimes months later—I’d want some part of it back; it fit perfectly in a new context. Would I have to rewrite it? Would I have to have saved, alongside fourteen others, a version of my article called article-3-with-wright-brothers-section-2012-04-05-(good)? If I had been using jimboPad all I would have to do is search for a few key phrases—and instantly I’d be able to slide through the whole history of that section.

This is the chief benefit of jimboPad’s recording and playback. Aside from vividly making the point that flowful words don’t just spill out of a person—that they’re not supposed to—these tiny continuous snapshots do for me as a writer what git does for me as a programmer. They let me work with abandon.

Add to that the nifty side effect that I never have to worry about losing my work—because jimboPad saves it locally every two seconds, remotely every twenty, and somewhere else remotely at my discretion. And the fact that I can float seamlessly from my local computer to a friend’s, from work to home, without worrying about conflicts. And the fact that jimboPad in a full-screen browser window is remarkably difficult to escape, so that would-be distractions—impulsive alt-tabs—are cauterized before they hurt me. And, finally, the fact that in jimboPad I am encouraged to print and edit with a pen and paper—to change gears, as it were, and be jostled by a real full draft.

Show, don’t tell

Why should the micromechanics of writing be entirely private? Why do we expect students to learn how to write if we’ve never, not once, shown them a piece of writing grow out of a blank page?

What if it were a regular habit to write with a record, and to attach to your final draft a trace of how you got there?

jimboPad is a very simple piece of software. It is written almost entirely in Javascript, and the source lives in a folder that can be run immediately on even the wimpiest shared server. For storage it uses Google Chrome’s built-in file system, HTML5 localStorage, and, optionally, an arbitrary HTTP endpoint equipped with CORS for cross-site AJAX POST requests.

If you want to see it in action, you can click here to view the playback for this very blog post. If you want to use it yourself, let me know.