Writing and Editing in the Browser
Skip other details (including permanent urls, DOI, citation information)
This work is protected by copyright and may be linked to without seeking permission. Permission must be received for subsequent distribution in print or electronically. Please contact : [email protected] for more information.
For more information, read Michigan Publishing's access and usage policy.
Abstract
In 2010, Mandy Brown joined Jason Santa Maria and Jeffrey Zeldman to create A Book Apart: a series of short books for people who make websites. Starting out as a side project, A Book Apart soon grew into a successful small press and today has published nine books, with many more on the way. Work on A Book Apart naturally led the team to think about the process, and in particular, their disillusionment with the tools that supported the editorial workflow. From that discontent grew the seeds of Editorially, a platform for collaborative writing. Based on the belief that writing gets better with company, and that everyone can and should write better, Editorially takes a web-first approach to writing and editing. Mandy Brown will talk about how Editorially came to be, what the team has learned so far, and where they are headed next.
Transcription
My name is Mandy Brown. I am the CEO and co-founder of Editorially. I’m also the co-founder of A Book Apart, which has been publishing books about web design for about five years now. The 10th book is coming out in a couple weeks. I previously worked at Typekit, which is a font service that was acquired by Adobe and is now influencing Creative Cloud, and at Norton, the independent publishing house known for Norton Critical Editions and Norton Anthologies, so I have a lot of experience across product, design, and editorial.
Editorially is a new collaborative writing and editing tool that I'm working on, and the first question I usually get when I tell people what I'm doing, that I’m building this new collaborative writing tool, is “why on earth would you do something like that?” Paul Ford, in fact, did a review in the MIT Press recently where he talked about us and a number of other tools: Medium, Fargo which is an outliner, Marquee, ——- kit. There's been a preponderance of new tools around composition and writing. He asked, I think, an important question which is why, when we have an abundance of tools for writing and editing, are we still looking at this problem, are we still dedicating a lot of time and effort to thinking about how it is that we write and edit together.
I have several answers to that question. First is that writing is really really important. It’s one of the most important things we do as human beings for each other and for people who come after us. Writing is a way of sharing information and knowledge and culture that extends past the boundaries of our own lives so that other people can learn from us. Neil Gaiman, writing in The Guardian recently, talking about libraries and the importance of libraries, also brought up I think a really salient point that language itself is a living thing, that we are constantly evolving and changing and growing with, so using and pushing the boundaries of that and thinking about how we work as writers and editors is a critical part of that. Writing, I don't think, is ever going to be a solved problem.
The second answer to this question I think comes around to how we read now and the fact that we are constantly reading across any number of devices and platforms in lots of different contexts at various points of the day. We probably read more now than in any previous point in human history, and that translates into more writing and, critically, more good writing. When you have a million things to choose from when you're reading, it's only the really good stuff that you're going to spend your time on, which translates back into thinking about what is the writing process that gets the best possible writing.
Finally, one of my other answers to this question comes down to what’s going on with publishing on the web today. We've shifted in recent years from a print first publishing platform, where the web was secondary, to a web first publishing system, where we’re publishing first to the web and maybe not to print all and thinking about what that means. One of the things that I think emerges from that is the fact that a lot of what we've done as writers and editors and publishers in the print world continues to be relevant, maybe even hyper-relevant, as we take those strategies and skills to the web and think about how to translate them and adapt them to a different environment.
So, that particular process of taking values and methodologies from one field or one area space and adapting them to others is something that I have a personal attraction to. I spent a number of my formative years as an undergrad bouncing back and forth between physics and English departments, getting degrees in both, and ventured into publishing specifically because it was a space where you could exercise a very Catholic set of interests. I think a lot of people who I speak to go into publishing because they are interested and curious about a lot of different topics. Many more hybrids in this field than specialists.
I want to talk a little bit about some of the other fields and areas that have informed the work they we’re doing with Editorially and how we think about writing and editing on the web today.
The first of those is the editorial tradition, so things we've learned over decades of publishing that continue to be relevant and how we approach those skills and that history and publishing to the web.
The second is the web standards movement, which has enabled the reading applications that we have now. The fact that we can read across thousands of different devices and platforms and shift reading from initial contexts into another context is in part because of the work the web standards movement accomplished in the last decade.
The third are remote workflows. In many ways, the editorial process is kind of one of the traditional remote distributed teams with an editor or publisher in New York and a writer in some other part of the world. Increasingly, I think that's how we're working. If you're not on a distributed team now, you probably will be. And thinking about how that affects our work as collaborators.
Fourth, and especially given our location here today, I think is thinking about data stewardship. How important it is, as people who are making and sharing content, to make sure that content has a really long life after we have gone, that we're leaving things behind him, and we’re not losing important parts of our culture.
Let me talk about the editorial tradition first. I think there is a lot of history around what it means to edit a text and evolve that text over time. You have to think about what happens when you bring that into the medium that is the web. So, we've adapted the traditional editorial workflow, thinking about cutting up paper and physically cutting and pasting, to a system on the web that takes some of its cues from collaborative software development. We have a version control tool, so as you work in Editorially, you can save versions. Then, those versions persist and are put together into a chronology that you can revisit at any time. You can go back and look at past versions. You can revert to past versions. All of the history becomes preserved. These milestones, in the process of working either by yourself or, critically, with other people, those dates become preserved. Once you have a version system, it becomes trivial to actually compare versions and let you see what's happening, so really a flexible process for looking at the changes between texts as things have evolved, letting you dip in and out of the text to let you see small things that have changed or big things that have changed at different point across the history of the text.
The next core influence for us is the web standards movement, which I have a lot of closeness to, given my work on A List Apart and A Book Apart. [video cuts out]
[Video resumes] possibly hundreds of different kinds of devices in this room. Tens of thousands of different kinds of devices out in the world that people could be using. That depends upon the web standards movement and the work that was done in the early part of the century. It's entirely possible now that when you look at something on the web, you could read it in a very composed, very beautiful, very styled environment. This is The Great Discontent, an interview site with beautiful layout work. You might look at this on your glossy 48 inch monitor, or you might shift it and read it in Instapaper at some other point in time when all of the styles have been completely stripped out.
This is the reality of publishing on the web today. The core content itself is going to look different to different users and different devices at different times. You have to author it in such a way that it is prepared for that journey. The only way to do that is to really think hard about the underlying markup. I think critically that markup is actually part of the job of the writer and editor. A lot of WYSIWYG tools have tried to obfuscate that work or say that it is the job of somebody else on the team. I think, if you're thinking hard about what the text means and how it's going to go out into the world, then the people who are closest to the words, the writers and editors, are the ones who need to be involved with that. That means authoring as close to the medium in which it’s going to be published, in this case HTML, as possible. HTML is a lovely publishing environment and awkward as an authoring environment, so we adopted markdown, which is a shorthand that lets you do things like use asterisks for bulleted lists and emphasis, paving some of the cow paths of the way we write over email and in plain text environments and letting us create an environment that allows you to author HTML really cleanly and easily. So, you know, when you’re done writing something like this, that it can be sent to Instapaper, and it's going to work.
The third tradition that we’re borrowing from are remote workflows. My team at Editorially is a good example of this. We have three people based in Brooklyn, one each in Boston, Austin, Boulder, Portland and San Francisco, and we fully expect that, as we add more people, we will be bringing on more cities, more oceans, and maybe more countries to that list. This is the nature of working on a team, whether you’re doing software development or publishing today. Increasingly, we're in different parts of the world. We’re commuting across spans of time and distance. There's a myth, I think, around how remote teams work that I want to dispel, which is that communication needs to be really efficient or really brief in order to work when you have a distributed team. You aren’t spending as much time face-to-face. You’re not bumping into each other in the hallways. Therefore, for all your engagement needs to be super-efficient. Actually, I don't think that's true. I think that one of the things that happens when a remote team gets together is that the team benefits from a certain kind of redundancy of communication that allows them to engage with one another and really hear what the other person is saying and understand, listen, and develop the kind of cues that you might see if you were in a room with someone that you don't have access to when you're communicating through text in different parts of the world at different times.
So how do we do this in Editorially? The first thing we do is offer [video cuts out]
[Video resumes] think of the document as in that state. This borrows a little bit from commit messages in software development, which leave a trail behind the work. You can go back and look at what happened, see how something evolved and understand the context for which changes were made.
The second part is you can leave notes and discussions around individual pieces of text, focusing not only on the ———— version or on the process, but looking at the language itself and exploring the discussions that can happen there. All of this stuff is preserved and made available to every person who participates in the document and comes along later. You can close a discussion after you’ve replied to it, but it remains available for everyone to catch up on and reopen it or contribute to it later. The door to discussion is always open.
Finally, there's a third place where you can communicate. We have activity feeds, which capture all the different activity that goes on in a particular document, and we also have another place for communication to talk about workflow or high-level feedback that doesn't fit into a text or into a version note.
There's a lot of potential overlap, different places where you could leave the same kind of information. I think that overlap, that redundancy, is actually really critical to remote teams understanding each other and engaging effectively.
The fourth: data stewardship. We’re crunching on the bones of Geocities as we walk around this building. I think it would be foolish of me to start a company or to stand in this room and not acknowledge the fact that a lot of people have come before us and a lot of data has been lost. I think that's something that we take really really seriously, both for our current users and thinking long-term. We want to build things that have really strong long-term cultural value, and that means you have to think about where it's going to go when you're not there to take care of it anymore.
I worked with a handful of people at Contents Magazine to put together a kind of special report around data preservation. We came up with three broad principles for startups and other organizations who are working in this space to adhere to. First, treat data like it matters. Second, no upload without download. Third, support data rescue. We take all three of these extremely importantly in terms of the way that we develop Editorially, with multiple redundant storage systems, so that if something goes wrong, we have a copy to restore work. We have both the version control system and an auto-save in the application itself. There are multiple ways for the work to be saved as its in progress. Our very first prototype had an export feature. It was one of the first things that he built, and we continue to iterate and provide more formats and opportunities to export to get out of the system. We’ve pledged that, regardless of where we end up as a team, we will always make sure that our users have access to the work that they produced within Editorially.
That last point, I think, offers some other opportunities in terms of thinking about what happens to a text once its been completed, once the writing process is done.