“Piracy is the result of a bad API” — Brian O’Leary, Magellan Media Partners
This past Tuesday night, I made my way over to the Pilot Tavern for the first Code Meet Print TO meet-up.
I’m glad that I did.
Code Meet Print TO – “Where texts meet technology.” – is pulling together a number of very interesting strings. I’m loath to say it’s about “the future of the book” because, after hearing Brian O’Leary’s talk that night, I’m not sure that Code Meet Print is about books at all.
The talk, titled “Context First,” asks some interesting questions about what is broken in the publishing workflow of today. Cheap publishing tools, ubiquitous Internet, and new start-up entrants into the publishing market are changing the field entirely, and traditional publishers may want to up their game.
What’s really interesting to me, however, is that this same conversation is happening in the context of journalism and news.
It’s not surprising really – after all publishing is publishing – but it is eye-opening to see the two perspectives side-by-side.
This is all timely, because I’m pushing myself and my comrades on the Beautiful Trouble project to stop calling it a “book project.” We’re working differently, and we’re thinking Web-first. But what does that mean exactly when working with a book publisher, and contributors who are thinking “book”?
Here are a few quick ideas that we’re exploring:
Personalization: Andrew was the first to propose a mix-and-match model that would enable people to put together their own view of the content based on their interest. Perhaps they would download that? Perhaps they would print it out? I’m now questioning both. But it’s an interesting idea.
Background: As contributors work on their pieces, we should encourage them to capture as much of their research process as possible in the content. Links, footnotes, video, audio, graphics, etc. They may not flow into the container called “book,” but they’ll be available to other containers that can make use of them.
Wikification: Both John Maxwell and the folks at FLOSS Manuals are pushing the Wiki-first, book later model. It’s interesting and I’m keen to explore it, but I fear that our contributors will not use a Wiki (no matter now ‘user friendly’ it is). Writers like something that looks like a word processor, not like a small editing window in a page of distractions. I’ve heard good things about Press Books, so I’ll have to check that out. In the meantime, we’re going to give it a shot with structured Google Docs.
Incentives: What exactly are the incentives for the contributors these days? Jay Rosen talks about the potentially negative incentives in newsrooms: the rush to break a story, etc. Many young journalists I talk to still want that press clipping to show their parents. Contributors to a book probably expect a book. Are there new incentives that are being missed in the shadow of tradition? The jury is still out on this for me.
Constraints: We went into the Beautiful Trouble project with a mental constraint about the length of each piece, or module. But as we see the pieces coming in – some shorter, some longer, some much longer – we have to struggle with that question. Yesterday I asked: why are we putting constraints on length at all? I’m all for constraints on quality, and understand the concern about short attention spans that also imply constraints – but the constraints of one possible output container seem artificial when I start to think about a Web-first publication.
Your turn: What else should I be exploring, thinking about, or reading-up on the topic of ‘Context First’?
**We're at [Mozfest][mozfest] this weekend, and we have a plan.** Our aim: turn our [Getting down with GitHub session][session] into an ...… Continue reading