The computer is a writing tool. Tweets, papers, email: They’re all composed in what is, at least in part, writing software. Even GChat is a writing tool. Writing tools are everywhere.
At the same time, many writing tools which are only writing tools are old. Microsoft Word is 30. It’s hampered by legacy requirements and restrictions.
What if we started from scratch? What should a digital writing tool be? How should it shape choices and beliefs? What should it help the user do?
Editorially, a new piece of writing software which opened to the public last week, proposes its own set of answers to those questions. It was clearly built with a thesis: Designed by veterans of digital publishing, it aims to “make collaborative writing easy.”
To find out more, I interviewed Editorially’s CEO and co-founder, Mandy Brown. I interviewed her by writing in Editorially itself (meta!) and, during the course of our interview, she asked Editorially’s CTO, David Yee, and another editor who frequently uses the service, Nicole Fenton, to pitch in. All three of them, using Editorially, contributed paragraphs of their own and edited them together — a kind of further statement about how writing should work. The product of that process is below; the bolded words are mine.
Editorially’s website says that it “makes collaborative writing easy.” Its features include commenting, annotation, and revision control. Is there a pitch for Editorially, or a way of describing it, which you can’t put on the website (because it eludes immediate understanding) but which you find interesting or especially compelling?
E.g., Early on, Flickr described itself as a way to share photos, but it was also designed as a kind of game. Is there a secret or insider sell to Editorially?
One of the things we think a lot about is the process by which a shitty first draft gets reworked into something great. (In fact, an internal version of our website read, “Everything you need to bring a shitty first draft to final publication.”) So many of the questions we ask ourselves come back to that: how does a draft evolve over time? How do we — writers and editors — identify what a draft needs and encourage each other to get there? How can we be critical of each other’s work in a way that is constructive rather than dispiriting?
Part of Editorially’s (not terribly) secret goal is to create a history of that process — a path of drafts and revisions and conversations — that can be unwound and observed and learned from. We want to help people work better, but we also want to help them improve their craft in ways they can articulate and share with others. So, we don’t just want better writing, but better writers, too.
Editorially allows for version control, a feature best known for its implementation in the software Git (and the website GitHub). Version control allows for authors to save “versions,” not files. So a file’s first draft is marked as version #1, its second draft marked #2, etc. Here’s what that process looks like in Editorially:
In what ways was Git or GitHub an inspiration, and in what ways did Editorially’s handling of version control differ?
“GitHub for writers” is a phrase that gets peddled around from time to time, and it’s very appealing. Git had a transformative effect on the collaborative design of software, so it’s tempting to think it could do the same for text. But Git has a few things working against it as far as writing goes: it’s very difficult to learn, and its approach to version control is simultaneously too sophisticated and too crude. It can do a lot, but it doesn’t do the few things writers need especially well.
That said, the hub part of GitHub is a different matter. Facilitating a conversation around the work is what makes GitHub indispensable. The challenge, then, is in how to take that ethos and build a toolset for writers, from the ground up.
One of my personal bailiwicks is cross-disciplinary pollination: the interesting things that happen when ideas or patterns from one field are carried over and adapted in another. But it has to work as pollination, and not a graft; that is, you can’t pluck a tool for developers and stick it onto another field and expect it to work. Instead, you can take the values that infuse that tool and use them to inform the approach towards a different problem in a different space. And that’s where things get really exciting.
Editorially draws upon ideas from remote culture and software development, but it couples them with an earnest respect for the history of the editorial process.
Let’s talk more about other inspirations. Editorially not only allows for version control, but also for commenting and annotation. Those are features known well for their implementation in Google Docs and Microsoft Word. But Editorially seems more a text editor than a word processor — a difference between it and Google Docs or Writely, the web software which Google Docs is based on.
Where do you see it fitting in?
We’re definitely a text editor, and not a word processor, and unabashedly so. We’re also very focused on writing for the web: that is, writing for the medium that is HTML, which includes everything on the web as well as ebooks (which are just packages of HTML files with a few other things thrown in). So one way of looking at us is as a web-first approach to collaborative text editing.