What Should a Digital Writing Tool Be?
An interview with the creators of an audacious, collaborative new tool.
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.
Who is Editorially’s target audience? Professional writers? Amateurs? Students?
Any small team collaborating on any kind of medium- to long-form text. That includes professional writers and editors as well as amateurs, plus people writing documentation or content for businesses.
Editorially is definitely useful for solo writers, but we think the sweet spot is small groups of people who are collaborating to bring a work to publication. Some of those teams are static — i.e., groups of people who are routinely working together on the same publication; while many others come together for the purpose of a particular topic or piece, then scatter.
Editorially is famed (at least among people in digital publishing) for having a great remote working culture. Most of its team seems to live in different cities or on different coasts. What has made its remote working procedure or ethos work particularly well, if it has worked particularly well? How has that experience shaped the tool?
There are dozens of habits that go into making a remote culture work (and ours does work). But I’ll focus on two that I think are critical: transparency of the work and opportunities for discussion.
Much of a remote culture is dependent upon the ability of everyone on the team to know what’s going on and be able to proactively participate. (I actually think this is true of more traditional office cultures, too, but it’s especially critical when people are not in the same room.) We have a variety of tools — GitHub, Dropbox, various project management systems, so on — which make each person’s work visible and accessible to every one else. Feedback and collaboration are a natural side effect of that accessibility.
Additionally, we have lots of avenues for discussion. One of the ways I characterize how we communicate is that there are times when redundancy of communication is really valuable. That is, when a group of people are collectively thinking through ideas and trying to arrive at the right solution, the more and varied ways they discuss those ideas, the more likely they will end up with a work that is meaningful and good.
That experience of working remotely has definitely shaped Editorially: we’re keenly aware that transparency of the work and opportunities for communication are critical and have worked to bake those in wherever possible. The version system in Editorially ensures that everyone can see the work as it evolves and understand how each person contributes. It encourages a kind of observation and participation in the process, which make shared understanding and collaboration easier. Likewise, the app has several different ways to communicate: version notes let you share a bit of detail about what changed in a particular version; discussion threads serve as annotations on a particular bit of text but can continue through versions even if that text is deleted or changed; and status comments let the team talk about high-level feedback or workflow. There’s some overlap in between those various places, but it’s a very healthy, productive overlap.
The question I’ve been dancing around: In 2013, what do you think a digital writing tool should be? What should it do? What should it not do?
It should embrace the digital medium, which is (and will be for the foreseeable future) rooted in HTML. It should relinquish any connection to presentation, because that’s how digital works: the words you write might be read in the nicely designed website or app you built, or they might be read in Instapaper with every bit of design stripped out, or they might be read aloud by a speaking browser that’s blind to presentation completely. Our writing should respect that environment, just as good writing has always endeavored to respect its readers.
It should also encourage an iterative approach to writing. Writing has always been a messy process of writing and rewriting and rewriting again, but that’s especially true when the medium of publication is itself stubbornly unfinished. That unfinishedness permits us a greater amount of experimentation and revision, two things which make writing better.
Finally, it should embrace what the web is especially good at: distributed collaboration. Our ability to work together across distances (and cultures) has never been better. Writing is a kind of thinking, and thinking gets better when diverse groups of people are able to contribute to it. That is a singularly distinct advantage over prior generations and one we should grab with both hands.
It seems to me there’s a new flourishing of digital text-manipulation tools. People are making blogging tools again (which aren’t part of social networks!); they’re experimenting with commenting and discussion; there are new writing and editing tools. Do you think that’s true? (Maybe it’s not!) If so, why have things flourished now?
Did they ever stop flourishing? I think writing is one of the most important things we do as humans, so it seems appropriate that we should have an ever-present fascination with how we do it and how we can keep getting better at it.
It’s like cooking that way. At no point will anyone ever raise their hands and say, “Well, we’ve solved cooking! No more to do here.”
On a more practical front, I think we’ve spent a lot of years caught up in the “M” part of the CMS: lots of tools in the early days of the web threw themselves headlong into the distribution part of writing. Now that everyone can easily publish to the web, and everyone is doing it, there’s an appropriate turn towards how we can make that work better. I like to think we’re a part of that, and I’m delighted to see we’re not the only ones.