Entries tagged with “editing” from Tools of Change for Publishing
"Bite-Size Edits" from BookOven
Andrew Savikas
April 2, 2009
| Permalink
| Comments (12)
|
Listen 
Hugh McGuire's startup BookOven has opened up an alpha version of a project they're calling the Gutenberg Rally, an attempt to harness collective intelligence Mechanical-Turk style to proofread Project Gutenberg texts for typos and OCR (Optical Character Recognition) errors. In "divide and conquer" style, the system presents just one small snippet of text at a time (with some surrounding context), effectively breaking down a mountain of a task into easily managed molehills:
I had a nice chat with Hugh on Wednesday morning, and what he told me about what's to come from BookOven was quite exciting (though apparently still very much in development).
This isn't the first attempt to harness eyeballs for finding and fixing OCR errors (see ReCaptcha), but reviewing the text in context is a much more satisfying experience, and left me wanting to read more of several of the books I was seeing only in snippet form.
Software Development as Collaborative Writing
Andrew Savikas
March 31, 2009
| Permalink
| Comments (3)
|
Listen
Following a lively backchannel email discussion, I'd planned to blog about what writers, editors, and publishers can learn from software developers (specifically their tools and techniques) but Tim beat me to it over on the Radar blog.
As I said in my email, The more I think about it the more obvious it's becoming to me that the next generation of authoring/production tools will have much more in common with today's software development tools than with today's word processors.
Software developers spend enormous amounts of time creatively writing with text, editing, revising, refining multiple interconnected textual works -- and often doing so in a highly distributed way with many collaborators. Few writers or editors spend as much time as developers with text, and it only makes sense to apply the lessons developers have learned about managing collaborative writing and editing projects at scale.
Programmers faced with annoying problems like "how do I make sure that changes I make to this text don't conflict with someone else's changes" or "how do I tell who among several writers made a particular change to some text" solved those problems long ago (Wikis are a great example of applying some of those tools and techniques to the writing process; API-based offline blogging editors are another).
And while using those tools as-is probably won't make sense for a lot of non-technical writers, those willing to at least try them out will learn a lot about what the next generation of collaborative, distributed, digital publishing tools will look like.
BeyondPrint Offers Helpful Review of StartWithXML
Brian O'Leary
January 15, 2009
| Permalink
| Comments (26)
|
Listen
George Alexander, who attended the StartWithXML forum in New York on Tuesday and made quick work of reading the research paper (thank you!), offers a helpful review of both.
In his review, George also offers a view he shared with the StartWithXML team the day after the forum: the current tools are not yet ready for widespread use, and the forum and the research paper were largely silent on his concerns.
I think that George makes an important point about the tools for authoring and editing. I responded yesterday to say that what may have felt like a "middling" position at the forum reflects a range of opinion within the project team.
At the forum, O'Reilly's Andrew Savikas, for example, advocated use of XML authoring tools in his afternoon remarks, showing some examples of what worked. In contrast, Laura Dawson, who co-wrote the research paper, is more critical of the tools, something she made clear in her comments. I'm somewhat in the middle, feeling that the tools are not necessarily ready for widespread deployment, but that balanced changes in processes, technology/tools and organizational structures can provide a path to moving the tagging work upstream.
One thing less evident at the forum or in the paper is the healthy discussion that took place within the team about this issue. At one point in the e-mail exchanges, I wrote (paraphrasing) that "waiting until the tools are "ready" isn't the right answer; people developing the tools will improve them when publishers in adequate numbers use the tools and advocate for better and more features.
When I presented the "solutions" grid in the afternoon, I pointed out that the bulk of the most developed software and systems are in the production editorial and operational areas, but that upstream options were becoming more available. I stopped short of saying "not ready," in part because I don't want publishers to hear me and walk out saying "we'll wait until the tools come on line" and let production worry about tagging until then. Changing workflows is painful, and people are prone to avoiding pain. That's smart in the short term and potentially disastrous in the mid-term, so I stuck with the recommendation to push upstream as much and as fast as you can.
We view the research paper as a living document, and we expect to revise it based on feedback from the forum as well as an evolving understanding of the number of case studies that the paper and forum started to capture. Look for a subsequent draft to articulate a position on XML tools that may not match what George sees but more clearly captures the project team's thinking.
What We Talk About When We Talk About XML (Apologies to Raymond Carver)
Laura Dawson
September 30, 2008
| Permalink
| Comments (1)
|
Listen
Acronyms and initialisms are mysterious and potent, and frequently hide meaning and become shorthand for larger concepts. Just as ONIX became shorthand for "metadata,, XML (at least in book publishing land) is becoming shorthand for ... well, a lot of things. Repurposing content, creating templates for book design, tagging -- all of these are encompassed in the term "XML workflow."
So no wonder people get confused. Particularly people who are in the business of creating content, not formatting, categorizing, packaging and marketing it.
So what are we talking about when we're throwing around this term? It depends on what you do for a living.
If you're a writer, it might mean using Word a little differently, quite possibly according to specific author guidelines given to you by the publisher. It might also mean including lists of keywords along with your manuscript. It may mean including lists of keywords for each chapter.
If you're an acquisitions editor, an XML workflow may mean deciding whether you want a book to merely exist as a print product (as a single source of revenue), or whether it's also appropriate as an ebook, to sell by the chapter (as numerous textbook publishers are doing), to publish iteratively (as O'Reilly does with its Rough Cuts), to make excerpts available for free download, etc.
If you're a book production editor, an XML workflow will be very concrete -- you tag a manuscript according to its format ("chapter heading," "illustration," "copyright page"), and those tags are applied to a pre-defined style sheet.
If you're in marketing, an XML workflow allows you to work with the author's keywords, target specific audiences for the content, and package the content in appealing ways.
Could you do all of this without XML? Sure. You could use a relational database and shove your manuscript, chapter by chapter, into tables in SQL. You could assign keywords in a relational database. But you couldn't do formatting. You could use InDesign or Quark to do your formatting. But you couldn't break up your manuscript into "chunks" and repackage those "chunks" into new products with those programs. XML has the capacity to handle both, and handle them well.
Like most acronyms, XML is a tool. It's not a goal in itself, but a way to get to your goal.
- Stay Connected
-
TOC RSS Feeds
News Posts
Commentary Posts
Combined Feed
New to RSS?
Subscribe to the TOC newsletter. 
Follow TOC on Twitter. 
Join the TOC Facebook group. 
Join the TOC LinkedIn group. 
Get the TOC Headline Widget.
- Search
-
