• Print

You may not be writing software, but someday you'll probably write like the people who do

Hugh McGuire’s post yesterday raised some great points about what a really effective web-friendly distributed and inherently social writing platform should look like. When it comes to the software tools we use for certain classes of tasks, I always look to the software developers themselves for insight into what those tools will look and feel like. It’s usually the developers who experience the particular pain point first (and most acutely), and who have the skills to build tools that solve those problems.

Writing (and “publishing”) are among the most relevant and appropriate tasks to which we can turn to software developers for insight. After all, no one (no one) does as much collaborative and distributed writing, editing, and revising of complex, interrelated, long-form textual works than software developers. It’s only natural they’d build tools to make the associated tasks easier and the problems more manageable.

I am not saying that everyone can, should, or will use the same tools that developers use today. But I do think Hugh is right on the mark to look toward something like WordPress as being in the right direction (as opposed to Word or InDesign, however hacked). I’d go a step further and suggest looking at GitHub as a model to examine very closely for ways to provide the infrastructure for easy and effective distributed collaborative writing (and ‘publishing’), as well as enable the social recognition and validation that are so important for many authors.

(I’d also like to think our own Open Feedback Publishing System is a step forward in the evolution of web-based book writing tools, though for now it requires authors write using DocBook XML or AsciiDoc, a high bar for non-technical writers.)

  • bowerbird

    andrew said:
    > Hugh is right on the mark to look toward
    > something like WordPress as being
    > in the right direction (as opposed to
    > Word or InDesign, however hacked)

    what does “something like wordpress” mean,
    and what kind of “hacking” do you think that
    word or indesign needs to be subjected to?

    and “github” is simply ludicrous as a “model”,
    since it’s two orders of magnitude too obtuse.

    as for “effective distributed collaborative writing”
    – you forfeited “easy” when you said “github” –
    i’m still waiting to see the need for that manifest.
    (but google docs is already working well, isn’t it?)

    -bowerbird

  • Mary Tod

    One of the hidden gems in this post is the link to Simon Fraser University’s Book of Mpub (http://tkbr.ccsp.sfu.ca/bookofmpub/ ), an interesting series of articles on publishing, blogging and writing.

    Writers are facing significant challenge to master new technologies and skills in this dynamic world. And we think writing is difficult!

    I plan to write about some of these challenges in my personal blog available soon at onewritersvoice.com.

    Mary

  • http://hughmcguire.net Hugh McGuire

    Ed Felten just wrote a great great post on this topic not long ago:
    http://www.freedom-to-tinker.com/blog/felten/developing-texts-we-develop-software

  • bowerbird

    um, hugh? please allow me to say that you’re badly misguided.
    that post by ed felten is wrong-headed, just like this post here.
    so for you to call it “a great great post” is, well…, it’s just wrong.

    most books are (and will continue to be) written by individuals,
    who have very little need for a “content management system”.
    so these ideas here will never even get any starting traction…

    and even for those books which _are_ written by a committee,
    a much better approach to the coordination problem is given by
    tim poston in his “one specific tool” comment on felton’s post.

    -bowerbird

  • http://tkbr.ccsp.sfu.ca/ John Maxwell

    I’m with Bowerbird on this one. The single-author vs committee distinction is one axis this turns on; but another important one is the granularity of the content.

    Code management systems for years have relied on the “line” as a basic unit of management. One line of code = 1 meaningful unit of expression. Version control systems which are based on line-by-line comparisons are venerable and very robust.

    Maybe if we all start writing in verse this will be adaptable… but we don’t. Prose is really messy compared to code. The closest thing would be to have tree (e.g., DOM)-based diffs at the heart of it, but paragraphs are big, indistinct things… you don’t really want a revision system that only sees dozen-line chunks. And while it’s certainly possible using XML-ish technologies to go deeper than the paragraph, we have no standard practices (as in, what writers, editors, taggers actually DO) for defining sentence-level (or smaller) structures — and that’s what you’d really need to make code-like revision control work.

    OK, go ahead… tell me why I’m wrong…

  • http://toc.oreily.com Andrew Savikas

    @John — I’m not sure I understand why a version control system like Subversion or Git wouldn’t be usable for prose. In fact, many of our authors use (and indeed we provide) Subversion to manage manuscripts while they’re being written. (All of the books written using our open feedback system are written using SVN — even the reader comments are committed into the repository.) Even copy editing, proofreading, and indexing is done off of the repository, and as with code, with reasonable coordination, conflicts requiring manual intervention are rare. Certainly our authors are special, in that many of them are developers themselves, and I’m not arguing Git or SVN is the right tool for the job for most authors, but those who are comfortable using them seem generally satisfied. (FWIW, we’ve done some promising experiments using DeltaXML, using the DocBook XSL stylesheets to produce PDF output that mimics the redlining feature of word processors, but it’s not something we do regularly.)

    Cory Doctorow also discusses using Git to track his manuscripts in process over at his blog.

  • bowerbird

    if o’reilly can persuade the corporate publishing houses to use
    version-control systems on their books, by all means, please do!

    it will be one more expensive albatross around their necks that
    keeps the dinosaurs from keeping up with the nimble mammals.

    plus if you can sell them this boondoggle “to boost efficiency”,
    that’ll put a very big and amusing mark in the “irony” column…

    -bowerbird

  • http://hughmcguire.net Hugh McGuire

    @johnmaxwell:

    JM: The single-author vs committee distinction is one axis this turns on;

    HM: challenge:
    -name 10 books that were written, edited, proofread, designed, and “published” by one person.
    -now name 10 that were written by an author, edited & proofread by others, designed by yet more people & then published.

    then answer:
    -which is more common for books – a single author doing everyone, or a “committee”?

    JM: but another important one is the granularity of the content.

    HM: xml handles paras – an excellent start for granularity of content you might want to edit. Bite-Size Edits works on sentences. Well or not is another question.

    JM: Code management systems for years have relied on the “line” as a basic unit of management. One line of code = 1 meaningful unit of expression. Version control systems which are based on line-by-line comparisons are venerable and very robust.

    HM: so what would a similar system look like for a book? based on paras & sentences probably. hard to make tools that manage that? not in theory anyway, though certainly it has challenges, ones we found at Book Oven & BiteSizeEdits.

    JM: Maybe if we all start writing in verse this will be adaptable…

    HM: or sentences…

    JM: but we don’t. Prose is really messy compared to code. The closest thing would be to have tree (e.g., DOM)-based diffs at the heart of it, but paragraphs are big, indistinct things…

    HM: why are paras indistinct?

    JM: you don’t really want a revision system that only sees dozen-line chunks. And while it’s certainly possible using XML-ish technologies to go deeper than the paragraph, we have no standard practices (as in, what writers, editors, taggers actually DO) for defining sentence-level (or smaller) structures

    HM: but perhaps we should, no?

    JM: — and that’s what you’d really need to make code-like revision control work.

    HM: yes, would be lovely, no?

    JM: OK, go ahead… tell me why I’m wrong…

    HM: because: the fact that the tools don’t do this well now (since they were built for another purpose), doesn’t mean it wouldn’t be useful to have such tools adapted specifically for managing prose writing.

  • bowerbird

    in the past, most books were produced by publishers,
    because publishers knew how to get books to readers.
    publishers also took the lion’s share of the proceeds…

    from now on, authors will make our books ourselves,
    because we have a direct connection to our readers…
    so we don’t have to let publishers siphon off the cash.

    so, the question: are we living in the past or the future?

    -bowerbird

  • bowerbird

    in the past, most books were produced by publishers,
    because publishers knew how to get books to readers.
    publishers also took the lion’s share of the proceeds…

    from now on, authors will make our books ourselves,
    because we have a direct connection to our readers…
    so we don’t have to let publishers siphon off the cash.

    so, the question: are we living in the past or the future?

    -bowerbird