More Thoughts on Collaborative Editing
Thanks for all your mail and comments about my “Calling Mac Developers: Request for a Collaborative Editor” article in the 24-Jul-06 issue of TidBITS. What with the comments on my article and Jason Snell’s post on Macworld.com, we’ve been having discussions both with users who desperately want the collaborative editor we’re proposing and with some developers who are potentially interested in writing it. That doesn’t mean we don’t want to hear from more developers; the more the merrier, and if someone were to start an open source project, I’m sure the extra coders would be welcome. However, we want to clear up a couple of common misconceptions that have arisen.
SubEthaEdit and Real-Time Tools — First, lots of people have asked if we’ve considered SubEthaEdit, from The Coding Monkeys. Yes and no – we know all about SubEthaEdit and use it occasionally, but it’s not at all suited for the kind of group collaboration we have in mind here for two main reasons:
- It’s only real-time, which demos incredibly well and is very useful in specific situations like group note taking and the occasional group writing situation. However, most writing and editing is done asynchronously and sequentially, where each person works on his or her own schedule and passes the file along when done.
- It loses track of who made what changes as soon as the document is closed – there’s no persistence, and no versioning capabilities. Saving is also somewhat confusing; since the person who shares the document should be saving, but if anything interrupts the connection, all the people connected to that document end up with a local-only version that they don’t know if they should save.
As I said, we do use SubEthaEdit whenever we’re working on an article as a group. For instance, for our coverage last week of the announcements from WWDC, we fired up SubEthaEdit and all wrote (or at least edited – several people find the presence of other activity in the same document highly distracting) into a shared document, divvying up specific bits of coverage. And this week, we wrote our Leopard Wish List article in SubEthaEdit as well, since it too had small contributions from a number of people.
We’re testing a workaround for the saving issue by having the person who creates the document use an auto-save utility; currently we’re trying GoldfishSoft’s $20 shareware SaveMe, and it would seem to fit the bill (although it’s hard to say how it would work over time, given that the demo times out after 30 saves). It’s also worth noting that the current version of SubEthaEdit itself is no longer free, but the notable changes between the free versions and the current SubEthaEdit 2.5 revolve around its capabilities as a text editor, not as a collaboration tool. Luckily, it turns out that you can still download older versions of SubEthaEdit for free.
A few people pointed us toward NoteShare from AquaMinds, but it too is a real-time tool, though with the added fillip that only one person can edit a particular shared notebook at a time. That eliminates the need for tracking multiple sets of changes simultaneously, but it also means that a collaborative editing team would have to store only a single document per notebook to avoid having one person lock everyone else out from all other documents in that notebook. NoteShare is definitely a 1.0 product, though it may evolve in useful ways given comments made by AquaMinds about future versions possibly allowing multiple simultaneous editors of a single notebook and providing versioning capabilities.
Text Creation, Not Publishing — Second, a number of people aren’t quite realizing where in the publishing process our proposed GroupEdit exists. In a professional publishing environment, text is written by an author, is edited and commented upon by one or more editors, goes back to the author, returns to a primary editor, goes to a copy editor/proofreader, and only at the very end of the process is sent to print publishing software and/or a Web content management system.
In most Internet publishing scenarios – particularly weblog and wiki approaches – collaboration happens at the very end of this process. Weblog entries only generate comments and links once they’re posted, and wiki entries are available for modification only after they’ve been published for the first time. That’s because weblogs evolved from the personal publishing paradigm, and although wikis have long been group-oriented, an entry in a public wiki like Wikipedia is available for public collaboration from the very moment it is created, not once it has been “published” officially.
So what we’re looking for in GroupEdit is a tool that supports the pre-publishing process, long before the public ever sees the end result. We don’t want a sausage, we want a sausage stuffer. And yes, the back-and-forth that results in a well-written, well-edited, thoroughly proofed publication is a case of sausage making – it isn’t always pretty, and it’s not something that most publications want exposed to readers. Although I haven’t been deeply involved in Wikipedia, my impression is that the manufacturing of a controversial Wikipedia entry reveals quite a bit of the sausage making, and while that may be fine for Wikipedia, it’s not something most publications want to do.
I say all this as a way of explaining the more basic reason why tools that enable Web publishing, like weblog utilities, wikis, and even programs like Macromedia Contribute, never quite provide what we’re looking for. All of them are tweaked to support that final aspect of the publishing process, rather than the early steps when a document is moving back and forth rapidly (and the more rapidly the better, though current tools hamper quick transitions tremendously) between an author and one or more editors.
The program that comes the closest to meeting our needs is probably Adobe InCopy, which integrates with InDesign to enable writers to work more fluidly with text that’s destined for InDesign layouts. Although InCopy would seem to have many of the basic features we want, it falls down in being focused primarily on integration with InDesign and on collaboration between writers and designers, not writers and editors. Plus, at $250 per copy, it’s not something we or Macworld could afford to provide to freelance writers.
Return to the RFP — Therefore I would once again encourage everyone to take a look at our RFP in QuickTopic Document Review, both with an eye toward making comments that could help refine or enhance the proposal and toward alerting Macintosh developers who might be interested in working on such a project or who might even have code that would benefit from features along the lines of those we outline in the RFP. The comments and discussions that the RFP has spawned so far have been helpful and are exactly what we hoped it would bring out. We’re looking forward to keeping the dialogue going and hopefully getting something along the lines of GroupEdit into development.