Building Book Production Platforms p1.

There are a number of web-based book production platforms out there at the moment. Booktype was the first. Its birth was around 2006-2007 and it started as a series of extensions (written in Perl) to the TWiki platform. TWiki was, and is, an old school wiki with a very pluggable architecture.

Booktype is now a stand-alone book production platform built with Python (Django). I founded the project and kept it going for many years, and I’m very proud of it. It is free software and now has a permanent new home at the Open Source, Berlin-based, development house Sourcefabric. I’ve since moved on to think about similar issues for the Public Library of Science.

Since Booktype, many platforms have come out of the woodwork including Atlas (closed source), PressBooks (semi open), gitbook, Inkling, PubSweet, Lexicon, Penflip (closed), Gitbook.io, FastPencil (closed), and many many others.

Seeing these evolve has been interesting. Most interesting is that I see a lot of mistakes still being made which we made in the early days of Booktype. I’m not saying Booktype is perfect, it is far from it, but I wanted to document what I consider to be a few high-level gotchas for those wanting to build this kind of platform. We need more book production platforms that improve the game. We need to avoid making the same mistakes over and over, so I hope the following will give those building tools from scratch at least something to think about.

This article is first in a series. It should be noted that I am targeting my comments at those that wish to build Open Source book production platforms. I’m not terribly interested (actively disinterested), in closed source platforms. Hence the narrative encourages you, the Open Source development team, to consider book production platforms as a distinct category of software – don’t use existing software such as MediaWiki, or WordPress etc to do the job.

Stand-alone platforms

I firmly believe that book production platforms should be built as stand-alone applications dedicated to the work at hand – building books. Book production platforms should be specialised software that ‘thinks like a book’. Your users want to make books, not blog posts or wiki articles, and they deserve a platform that is built with their goal as the central premise.

Don’t learn this the hard way as I did. Booktype started with a wiki and it did a pretty good job. At the time TWiki could be considered as a kind of rapid prototyping framework for Perl, much like Django or Rails is for Python and Ruby respectively. It provided essential login features and user management, plus a host of plugins to extend functionality with diffs, reports, permission management etc. It did pretty well for a while. However, the wiki-like paradigm soon started to grow old. Initially, I had pulled the guts out of the wiki and replaced wiki markup editors with HTML editors (more on that later) and did a whole lot of crazy URL redirects using .htaccess to get nice book-like book/chapter URLs and attending structure. That was OK, but when it came to other functionality that books needed, then the wiki paradigm was sagging pretty noticeably. It also took increasing amounts of time and effort to build an interface that was clearly intended for making books instead of wiki pages, not to mention the issues with updating a core application framework for security or performance improvements when the internals had been hacked so extensively it no longer really worked the same way as the original application.

A bit of template paint helped with some of these issues, and I commissioned some programmers to extend TWiki to fill in these book-wiki gaps, but, after a while, it became obvious it would be better to build a dedicated standalone book production platform from scratch. Given all my experience since then, I am convinced that if you want to make books you should have a software built specifically to do that.

Paradigm differences

Book production platforms are a specific category of software as the functional needs are quite different from those for producing wikis, blogs, or other types of CMS. When building book production software there are essential paradigmatic differences that just force you out of the existing categories and into the new…

The following are some examples, and I will document one or more at a time as this series continues. First of all, the Table of Contents.

Table Of Contents

Any book production software needs a way to create and manage a Table of Contents (ToC). Neither wikis, CMS, nor blogs have the need to structure content in this way: they are designed for non-linear, contextual navigation (you click on a link from within a paragraph to be taken to somewhere else). The closest these other software paradigms get to a Table of Contents is through navigation bars and breadcrumbs and hacking together ‘lists’ of associated content.

However, books have a very linear structure so one thing follows another in a vertical narrative. That’s not to say you can’t break the structure. However, if you intend to create paper books or electronic books, then it is very difficult to escape this very strict linearity. An easy and fluid way to manage this vertical linearity is a must for any book production platform.

There have been attempts at making this work with other types of software. Mediawiki makes an attempt to do this with the concept of ‘collections’. A user can save references to articles in a list then jockey them into order. Other software, such as PressBooks, has attempted the same with blogs – organising blog posts into a list. But the solutions are never satisfactory. It always feels like a compromise – the poor user is asked to work with something that feels like it’s actually built for another job, and it is.

A Table of Contents interface should be the heart of a book production platform, and the platform should own that space. There needs to be a fluid and fast interface for creating new chapters, moving items around, quickly seeing the structure of the book, and if you like the idea of concurrent production, then it needs also to be able to show at a glance who is working on what. The user needs to be able to add and remove chapters at a click, move chapters outside of the ToC while keeping them available for possible later use, or rename them – right from the ToC without the need to dig down into individual chapter settings. Additionally, the changes in structure need to be dynamic: updating immediately for every user without the need to refresh. The status of individual chapters needs to be ascertained from a single glance at the ToC.  The interface for book production should be fast, clean (separate from additional blog or wiki cruft), and feel like it is an interface built specifically for the job it is attending to.

The ToC is how people get an overview of a book, and book production software necessarily gives  them the tools to manage that overview. So start with the Table of Contents as a central UI element, and let the user go from there. The user will then feel that the platform is all about managing their book. The UI will communicate ‘book! book! book!’…not ‘wiki!…err…book!…errr…wiki!’. A ToC as a central motif communicates the purpose of the platform and gives the user a tool that gives an immediate overview of the work at hand, and the output feels like a book from the very beginning.

Book production platforms need to have a Table of Contents interface as a central part of the paradigm, and this should be reflected in the UI – it should not just be something that has been tacked on as a ‘workable solution’. Start building something to manage a ToC beautifully and work out from there.

Why Attribution is not Sustainable

It’s easy to understand the problems with attribution. In the one book = one author days, it was easy – put the author’s name on the cover. 50 years later, same book, same solution.

However, this does not work for collaboratively-produced works and it is one of the most difficult issues for free culture going forward. Already in FLOSS Manuals, we have books that have 8 pages of credits – each chapter individually referenced with the copyright and attribution data. Some books have 40-50 chapters and some chapters have 20+ collaborators, all of which need to be listed. For FLOSS Manuals, we solved the problem by generating these lists – when edits are done in Booktype, there is a digital record of who did what, so we just automatically generate this list. However, this is just the beginning and we are already asking ourselves – are 8 pages of credits really necessary?

The answer is no, it is not necessary. Attribution is not as important with collaboratively-produced works as one might have suspected. Those involved in the process are not too worried about it – there is some kind of excitement generated by pushing your name forward as a protagonist at some key moment in the life of a book but this can happen in the text, as part of the book’s story, or in press releases, blog posts and so on. We don’t actually need attribution – the prominent foregrounding of all the names of the individuals involved in the book’s production. What we need is backgrounding of this information and the ability to know the history and lineage of a book.

We need standards to maintain history records for a book’s development and we also need this to be stored in publicly- accessible repositories so we can check this information for interest’s sake or more meaningful uses such as historical records, or research.

These records of book history could be also very necessary for verification of content. If, for example, we use open licenses or (one day) no copyright then how do we verify quotes, for example? (In reality, provenance is orthogonal to copyright restrictions, and indeed such restrictions are an obstacle to maintaining provenance, but still. people often ask this question.)  How do I know that this book, which purports to be the thoughts of the author, actually does present the thoughts of the author and not some maliciously invented text masquerading as such ?

Currently, in free software circles, there are at least three major strategies for dealing with this kind of issue:

  • Use a publicly-trusted source for the distribution of content so people know that if the book comes from a trusted source it is what it says it is.
  • Use a ‘checksum’ – a method for verifying of any errors have been introduced in the text during the transmission (delivery) of the content.
  • Digitally-sign content so that it can be verified as coming from the purported source.
  • Libraries or public archives could play a very strong role here. Records of history would become very important in a federated or prolific free-content environment, not just for research but for providing public mechanisms and standards for the ongoing verification of sources.

Attribution is the star system of the single author = single book publishing system. With the breakdown of these models, or at least with the diversification of these models, author attribution will, out-of-necessity, become a more transient commodity. Collating version and contribution history, however, might become a business in itself.

Which is all to say that lowercase attribution (a useful bit of provenance info) is sustainable. By contrast, Attribution to Authors as creator-gods is suspect and superfluous.

book.js

I mentioned in an earlier post that the movable type of Gutenberg’s time has become realtime, in a very real sense each book is typeset as we read it. Content is dynamically re-flowed for each device depending on display dimensions and individualised settings. Since ebooks are web pages, browsers have come to play a central role in digital e-readers.
bookjs
Three books produced by the book.js in-browser typesetting library. Photo by Kristin Tretheway.
What is interesting here, is that the browser can also reflow content into fixed page formats such as PDF which means that the browser is on its way to becoming the typesetting engine for print. book.js demonstrates nicely the role of the browser as print typesetting engine.book.js is a JavaScript library that you can use to turn a web page into a PDF formatted for printing as a book. Take a web page, add the Javascript, and you will see the page transformed into a paginated book complete with page breaks, margins, page numbers, table of contents, front matter, headers and so on. When you print that page, you have a book-formatted PDF ready to print. It’s that simple.
1_plainhtml3
Plain HTML file with book content
2_bookjs
Same file with book.js applied
3_illustration
A page with an illustration
4_toc
Illustration of Table of Contents automatically generated by book.js

It brings us closer to in-browser print design and a step closer to the demise of desktop publishing. Although book.js is in an alpha form, it is a clear demonstration that the browser is fast becoming the new environment for print design.

That is an enormous leap, one that not only means print design environments can be developed using browser-based technology, which will surely lead to enormous innovation, but it radically changes the process of design. The design of books and paper products enters a networked environment. This will enable more possibilities for collaborative design and bring print production into the workflow of online content production. There will be no need to exit browser-based environments to take content from source to final output. This means there is no need to juggle multiple sources for different stages of production, there can be efficiency gains through integrated workflow, and, most interestingly, content production and design can occur simultaneously…

It is also important to realise that these same technologies, book.js and others that will follow it, can make the same things possible for ebook production. Flowing text into PDF for a paper book, or into e-reader screen display dimensions, is the same thing. This enables synchronous in-browser design and production on a single source for multiple output formats.

book.js is Open Source, developed originally by and for Booktype, but the team is looking to collaborate with whoever would like to push this code base further. It is at the alpha stage and a lot of work still needs to be done, so please consider jumping in, improving the code and contributing back into the public repository.

book.js demo and information can be found here .  Note: This is strictly for the geeks to try as it requires the latest version of Chrome; see the demo information.

Originally posted on O’Reilly, 29 October 2012
http://toc.oreilly.com/2012/10/bookjs-turns-your-browser-into-a-print-typesetting-engine.html

Books as Learning Environments

Books are of course learning environments. However, this is usually understood from the perspective of the reader. What is often forgotten is that book production itself is a tremendous learning process. As people work together to write/illustrate/create a book together they are learning a tremendous amount about the subject.

Kieran Nolan, a teacher at DkIT1 in Ireland, asked students to create a book together using Booktype. The project was for a module called “User Theories” for fourth-year students in the BA (Honors) program in Communications and Creative Multimedia. The course looks at different interactive media types, different user groups and the creative ways in which people repurpose and reuse all the digital creation and distribution. In Kieran’s words:

“The topic we had last week in class was ‘Emotive Design’ and trying to reduce user frustration with interactive media. In other words, looking at ideas of giving interactive products personality (for instance, avatars) so that users feel some sort of connection and less alienated to the product. So the students are being asked to reflect on the readings and come up with their own idea for an ‘emotive interface.’”

Rather than creating the content individually, Kieran’s students are creating a book collaboratively. Kieran liked producing a book collaboratively online because the class could share their ideas, learn from each other, and learn about collaborative production by doing it. The fact that students can produce a book from the result adds another dimension for Kieran: “It bridges the gap between digital and print media and produces a tangible product.”

Kieran utilised the history feature of the production software to track a student’s contribution to the project. The work counted for 15% of the final mark.

Over the space of two weeks, the class collaborated online both in the lab and individually at home to create a compendium book of 21 original design concepts.

The students I teach are well accustomed to using the online space as a learning environment. While a lot of material can be covered in the space of a single lecture, extra time is often needed to help students absorb and reach a deeper understanding of their source material. Online discussion of in class topics helps facilitate this. So too experiential learning is essential for reaching a deep understanding of a subject.

We can, of course, imagine a perfect perpetual production book machine – students write textbooks together and learn the subject and get evaluated on their contributions- the next year’s students improve the textbooks and hand onto the next year’s students and get evaluated on their contributions etc. Students produce their own textbooks for their school and to fulfil their own learning needs.

There are some experiments going on in this area but not nearly enough. The Open Educational Resources (OER) movement is largely stuck in traditional publishing work processes. With time, hopefully, the value of learning within the book production processes will be understood and utilised to produce more open textbooks which students need.

 

Ease of Production

Around 1460, the entrepreneur Johann Fust (commonly confused with Johann Faust) took some of the Gutenberg bibles to Paris to sell. Paris did not know of the printing press and rumours started. How could someone produce so many books so cheaply? How could they possibly be made so quickly and with the exact same rendering of all characters on all pages? The apparent ease and speed by which these books were produced had the feeling of witchcraft.

It’s a good story and a popular one, although it might actually be apocryphal. It seems, according to Elizabeth Eisenstein [see The Printing Press as Agent of Change, Cambridge University Press 1979, p50] that at that time, the “increase in output did strike contemporary observers as sufficiently remarkable to suggest supernatural intervention.” This story helps us imagine how Gutenberg’s Press changed the world forever, simply by making the production of books easier and faster. Before this, books were created by scribes copying the content by hand – a process which took tremendous time was prone to error and was very expensive. The newly invented printing press meant books could be made quick and cheaply. As a result intellectuals and artists were starting to work closely with printers, print shops became places where these people would meet and where knowledge started to cross disciplines, publishers eventually evolved, the economics surrounding knowledge changed, book production was made accessible to a vastly larger section of society, literacy increased, and knowledge was transmitted across societies and boundaries in ways previously unimaginable. Making books easier and faster to produce changed everything.

Because books are now web pages, book production again becomes easier. All the tools required to produce beautiful books can be accessed through a browser. ‘Web-based workflows’ for book production begin with an empty book and take you through the entire book production process without needing to leave the browser. Easy-to-use tools take you through this workflow and in so doing they change every part of book production. The book becomes something you can make, not something that publishers make for you.

This ease of production is assisted greatly by the development of online print-on-demand services and ebook distribution channels which integrate APIs. An API is an ‘Application Programming Interface’ – jargon for a technical process that enables websites and online services to integrate and work together. Using APIs, you can utilise the services from another website in your own webpage. For example Lulu.com – one of the world’s largest online print-on-demand services – allows you to upload books directly to their service from your own website. That makes web-to-new book production models and print workflows a whole lot easier and faster. Ebook distribution services are also offering APIs so platforms can push ebooks directly into their channel.

Book production coming online means new book production models can evolve and new kinds of publishing can emerge. Book production can become faster, publishing becomes something anyone can do, people from all over the world can share distributed workflows and work on the same content simultaneously. Book production is open to more people, and anyone can produce an array of books from best sellers to niche texts. Peer production markets of skills and knowledge can ben generated to enable the production of the books we want – faster, cheaper, and better than the current state of publishing.

Book production platforms to enable these advantages are just starting to appear. Wikis were, and still are for many, the default knowledge production platform and have been used many times to make books. But Wikis are not designed for making books. Not only do they do this badly but they do not foster a ‘book writing’ mindset. Wikis tend to be used for short form texts and often as a kind of textual mind map. Wikis do not deliver the ease of production we are looking for.

The same is true of blogging software. Blogs do seem to build a culture of slightly longer and more structured narrative forms which does help but blog software is not intended for producing books either. It is intended for producing another kind of text. It’s true that blogs like WordPress can be bent into many shapes and WordPress is often considered by many to be a Content Management Tool rather than a blog, but at the end of the day, building a non-blog becomes more work using WordPress than if you had chosen a tool built for that purpose.

Essentially Wikis, Blogs, and CMS all have very specific roles.  Bending them to fit book production may work for a while, but they lack the possibility to richly explore online book production because they were not built to do this. They might be a useful shortcut for rapid prototyping but their inherent paradigm will soon get in the way. If you want to do something, then it’s usually more effective to use a tool built for that purpose. Additionally, it’s not just the tool’s purpose that counts: the culture surrounding how the tool is used is also important.

Having used a wiki to build a publishing system, I can say from experience that we soon ran up against core design principles of the tool that made it hard to make it do what we wanted. We could do all the basics but when we really started working in an immersive way with online book production, we found that there were many issues that a wiki could not handle without significant re-development of its architecture.

When building a software for book production there are some features and issues that need to be considered as part of the core paradigm. First – any platform operating in the world of open or federated publishing MUST be open source. Open content on a closed platform is a hypocritical position. You deserve to be skeptical of any platform like this and its relationship to you, your privacy, the ownership and control of content, the distribution paths open to you etc. Beyond the primary necessity that the platform must be open source there are 4 key features that should be easy to manage :

  1. it’s easy to create a new book
  2. it’s easy to add and edit content
  3. it’s easy to manage the table of contents
  4. it’s easy to export to a book format

These are the basic 4 necessary ingredients.

Beyond this, there are some very important issues that need to be managed, either in a second tier of interface or done ‘automagically’ using default settings or presets:

  1. copyright license management
  2. attribution
  3. well designed output

That gets you to a basic ‘plain vanilla’ online book production environment. Of course it looks easy but it’s not. Realizing this simple vision is pretty easy if you wish to produce EPUBs. However, if you wish to support multiple output formats, it gets trickier. Paper books are especially tricky because you have to deal with the page – a real paper page. Paper pages need left and right margin control, page numbering, accurate linking of the page numbers to the table of contents, and not to forget bi-directional text rendering and widow and orphans control. Not only are these not very simple issues to resolve technically they are also offer very many questions about usability. How many of these options/parameters do you manage ‘by magic’ and how many (and how) do you expose to the user to control? This is when the going gets tough.

We are seeing a few online platforms evolve that are embracing some or all of these notions. The variety of feature sets and strategies is large but the following three online book production platforms are the ones I believe have the highest claim to having a stake in the game to date :

  1. PressBooks – a service started by Canadian Hugh McGuire who had previously experimented with a book platform called the Book Oven  (which is now closed). PressBooks is based on WordPress and has a good workflow if you are familiar with the popular blogging tool. Unfortunately the platform, while built on top of an open source software, is not open source software. It is a free (gratis) service but closed source. PressBooks does not currently hold high collaborative potential but it is very useful for writers who wish to work with an editor or editorial teams to compile anthologies. PressBooks is focused on extending the traditional publishing cycle online. The development team is spending a lot of time working on good formatting for book-formatted PDF. PressBooks also targets the web as a book output.
  2. Inkling – a service which is free to use but all content must be sold through the Inkling sales channel. Inkling derives a royalty for each sale through this channel. It is closed source and targets the iPad and the web as output formats. Inkling is targeted at textbook publishers and sells content in the form of books and chapters. Inkling is not open source and is targeted at traditional (but distributed) online publishing workflows for traditional publishers.
  3. Booktype –  of the three listed here, Booktype has been around the longest – formerly known as Booki and originally developed by FLOSS Manuals, it has been around for almost 6 years in various functional prototypes. Booktype is now developed by Sourcefabric and is open source. Booktype has a very flexible workflow which is ‘native to the web’ and is designed for non-publishers and publishers alike. Booktype can be a highly collaborative environment and is the platform of choice for rapid development processes such as Book Sprints. Booktype outputs to web, iPad, Kindle, print-on-demand, text document formats, PDF and many other formats. (Disclaimer : I am the project lead for Booktype).

These three are the 3 best platforms on the radar for easy online book production right now. The web being what it is, means there will be more to enter the market and this will probably happen quickly. The iPad iBook Author is not mentioned here because although easy to use it is not an online tool and I believe this is a critical missing feature for reasons that will become clearer later.

I believe these three outlined above change the game and interestingly have their own distinct primary use cases and strategies. There will be more to come. If you believe Gutenberg’s efficiencies changed society forever then what effect will tools like these have? It’s a giddy question and from working with book production like this for 5 years now, I firmly believe making books in the browser is not just a matter of having an easy way of making books – it will have an enormous impact on society as a whole.

  1.  

CSS is the new typography

The new layout language for the book is HTML. It has never been easier to make web content using HTML, hence it has never been easier to make a book.

Generally speaking, HTML is frowned upon as a source file format for books because it is seen as worst practice. Best practices require complicated file formats like “docbook” or, worse, Latex. These file formats have been designed to contain and describe content so that beautiful books can be made. Unfortunately, the process of creating docbook and Latex is extremely complicated. Getting a new user to work with either of these formats is quite a process. On the other hand, WYSWYG editors which produce HTML work very much like simple text editors. It is trivial to create HTML with a WYSIWYG editor or similar tool and it can be done online.

HTML is a very established, very well used, and very well distributed format. There are already an enormous number of people using HTML, and an enormous amount of content already stored in HTML. That content and those people are networked, and HTML has a rich legacy of tools that enable transformations into other formats. HTML is the new source format for books.

CSS (Cascading Style Sheets) is the syntax that controls the look and feel of HTML. E-readers and web-browsers can read this syntax and present the content accordingly. Book production platforms such as Booktype enable the customisation of CSS for ebook output, but, more interestingly Booktype also enables CSS to control the look and feel of paper books. Designing in this way takes some thought since it is usually disorientating for book designers to ‘design in code’ and it is equally disorientating for web designers to use code to design material products.

The W3C CSS Working Group1 (responsible for overseeing the standard) anticipated the intersection of the book and the web some time ago. In the latest drafts of the CSS standard, new additions are almost entirely focused on typography2 . As a consequence of this emphasis, this area is starting to blossom. There has also recently been a sharp rise in the websites offering tips on CSS typography3 and an explosion of web fonts. (If you are interested in a very good insight about how fonts get to the web please watch the Unbound Book video presentation by Otmar Hoefer, the Director of Font Marketing at Linotype Library4 ).

There are also some very interesting JavaScript libraries available that are trying to make up for what is lacking in CSS typographical controls. Most are based on the well-used and prolifically distributed JQuery JavaScript libraries.

Of particular interest is the kerning.js library which combines the previously available lettering.js library. What these libraries do is to make each glyph (letter/number) into its own element, each of which can then be transformed by CSS-like rules. In plain speak, these code libraries allow you to change each letter individually in a paragraph or heading etc.

There are some nice demonstrations online about why this is interesting, of which the most interesting demo can be found at kern.js. Try visiting that page, double click the big blue circle, then click on and drag the letters individually.

If you then click ‘Finish Editing,’ you will get the CSS controls necessary to implement this effect (if you had kerning.js linked from your page).

There is also another interesting typographical library called colorfont which enables dual toned glyphs.

It is a pretty good trick they used to achieve this. Essentially they created two fonts from the same master font, each displaying just partial glyphs. When overlayed, they display the full glyph. Hence each ‘layer’ can be targeted with a different color.

With libraries like this, it is apparent that JavaScript has a future with web typography but maybe it doesn’t stop at that. These kind of tricks can also be implemented with ebooks and with more and more book designers entering the world of ebook design, I am sure we will see a growing need for more of these libraries.

Good nuanced control over font rendering is good enough at the moment and getting better quickly. However, many e-readers and all web-browsers do not support all of the CSS controls and most ebook readers do not currently support JavaScript. This will change in time, especially since ebooks are becoming a revenue stream for Apple, and Apple (together with Google) is behind the development of webkit – the rendering engine behind iBooks, Safari and Chrome. Good support of CSS typographical controls is on its way and we can expect more web designers to start designing books, and to see more book designers learning code.

What is dismaying, however, is the current trend of vendors like Apple to use non-standard CSS controls to layout the books. Baldur Bjarnasons has written some very good blog posts about this. The strategy by Apple is to make any book authored by the iBook Author software only work (or work well) when viewed with the iPad. I do not really understand this strategy – yes it is the typical platform / sales channel lock-in that Apple is known to perpetuate. However, it means that content creator content has limited distribution because of this. Apple might wave this away by saying that it is ‘innovating,’ but innovation like this cannot be seen without a degree of skepticism about the intended goals.

Nevertheless, it is possible to say with some confidence that CSS and JavaScript will come to be seen as an important development in the history of typography. Just as Gutenberg “was concerned only to imitate the book of his day – which was handwritten”5 but unintentionally gave birth to new aesthetics, we can imagine the new CSS typography to have similar consequences.

  1. http://www.w3.org/Style/CSS/members.en.php3^
  2. http://dev.w3.org/csswg/css3-text/^
  3. http://www.1stwebdesigner.com/css/advanced-css-text-effects-web-typography-tips/^
  4. http://vimeo.com/24415178^
  5. Jan Tschichold, The New Typography, University of California Press, 2006, pg 15^

Collaborative workflows in online book production – some case studies

“Collaboration on a book is the ultimate unnatural act.” 
—Tom Clancy
One of the most obvious opportunities open to online  book production is collaboration. Of course, collaborative writing actually has a somewhat (unfairly) tainted name. During the first wave of wiki-mania, Penguin books conducted an experiment called A Million Penguins1, a collaborative writing project using a wiki. By all accounts, it was more successful as a social experiment than a literary experiment. I think most people think of this kind of thing when they think about collaborative writing. It's an interesting experiment, the thinking goes, but possibly it is not able to produce the same quality as a single-authored work.

However, let’s not forget that ALL books are produced collaboratively. Books generally carry the name of a single author but this is because the publishing industry trades on this. Publishing is a star system and its bottom line relies on it. It is better for a publisher to build up one star than distribute the glory over the 2,5, or 10 who were actually involved in producing the book. As a general rule acknowledging collaborative production is not good for business.

Rather than deny collaboration occurs, it is better to consider whether the character of the collaboration is weak or strong.  Borrowing from a list of continuum sets outlined for collaboration in the book Collaborative Futures2  we could characterise it something like this:

  1. Weak – A single writer completes a work and secondary collaborators discuss or change elements with little or no interaction. For example, a friend reads and discusses elements or a proofreader is commissioned to clean the work up. In the case of the proofreader, little or no interaction occurs between the original creator and the proofreader although they are both aware of the proof reader’s role and changes in the text. The text is monolithic and attribution is solely to ‘the author’. An example would be any Tom Clancy work.
  2. Stronger – A single writer works with an editor, colleague, family member or friend to shape the text throughout the writing process. It is in part a form of mentor – writer relationship with the boundaries negotiated in a fluent and ongoing nature. The collaborator will make direct changes as challenges and suggestions. The text is monolithic but possibly with shared notes, and attribution is to ‘the author’ with thanks  in an additional credit note to those that helped. This is a very typical methodology for publishers but also many works embrace this process informally. Mary Shelley’s Frankenstein is an example where many have argued that Mary Shelley formed a collaboration like this with her husband Percy Shelly.
  3. Strong – A multi-authored work where multiple collaborators share various levels of authority to act on the text in a highly modular and seemingly autonomous fashion. Although there is something of an over-reliance on the Wikipedia as an example, its unusually evolved structure makes it a salient case. Collaboration is remote but a coordinating and shared goal is clear: construction of an encyclopedia capable of superseding one of the classical reference books of history. The highly modular format affords endless scope for self-selected involvement on subjects of a user’s choice. Ease of amendment combined with preservation of previous versions (the key qualities of wikis in general) enable both highly granular levels of participation and an effective self-defense mechanism against destructive users who defect from the goal. Attribution is shared.
  4. Intense – A multi-authored work where the collaborators decide on the scope and character of the book in close and intense discourse throughout the production process. It is generally a very egalitarian environment and permission is not sought or needed to change a colleague’s work. FLOSS Manuals, originally established to produce documentation for free software projects, is a good example. Their method usually involves the assembly of a core group of collaborators who meet face- to-face for a number of days and produce a book during their time together. Composition generally takes place on an online collective writing platform, integrating wiki-like version history and a chat channel. In addition to those physically present, remote participation is solicited. It is necessary to come to an agreed basic understanding between collaborators through discussion of the scope and purpose of the book. Once underway both content and structure are continually edited, discussed and revised. The text is modular with granularity on the chapter level. Attribution is shared and often not as important as other forms of collaboration.

Producing books online obviously opens up some very interesting possibilities for collaboration. First, unlike a typical writer’s room, the net is a public space. That multiplies the possibility of making connections and working with people you may not know. It also means that you could box yourself in and open the door just to those you want to let in. The point is that you have the choice.

In addition to this continuum, there are open and closed collaborations. Open collaboration is an open door policy where anyone can come in and participate. A closed collaboration is where the boundaries of participation are set by social or technical means. Open and closed is a continuum characterised by the strong or weak porous nature of the boundaries. Closed collaboration is the default for the production of almost all books at the moment but some of the most amazing results can come from opening yourself up to open collaboration. My experiences working 5 years like this with a repository of 300 books and 4000 collaborators can recount many stories regarding this as the repository is completely open. Anyone can register and edit any book. As a result of these experiences, I find the case for ‘open collaboration’ extremely compelling. Interestingly, however, the more intensive the collaboration is the more difficult it is to sustain openness. New contributors may have missed formative discussions regarding the book and struggle to find a ‘way in’ to the content, additionally, new contributors may find it hard to enter the close-knit social fabric that is created as people work intensely together over time.

The following are two examples of collaborative workflows enabled by online book production. They investigate different points along the collaborative continuum. The first example is from James Simmons. James wrote several books online in a manner he calls a ‘Book Slog’ or ‘collaborating without co-authors’ – you might think of it as ‘the normal way’ to make books. The second example is of accelerated book production using a collaborative process known as a Book Sprint.

The normal way…

From the words of James Simmons:

A “Book Slog” is pretty much the normal way of writing a book. It is what most publishers would nail (attribute) to a single author. The long road to producing a book.  For example: The book will, of necessity, take more than a week to write.  More than likely it will take months, and will involve much research.  The main author will end up knowing much more after finishing the book than he did when he began it. The book will have one main author, who will do most of the actual writing. The book may or may not have other contributors.The contributions of others may be informal. Other contributors will not be as highly motivated as the main author, or may have their own motivations that are not the same as the main author.The contributors will likely never meet face to face.

The question is, does online production have anything to offer the Slogger? Based on my own experiences, I would have to say it does. I used Booki (now Booktype) for my books. The main reason to use Booki rather than a word processor to write a book is to effectively collaborate with other authors.  I have completed two books this way (and the Spanish translation of my first FLOSS Manual would definitely qualify as a third), so my opinions on this might be worth something.

Some might not think of these books as a collaborative effort, since I wrote every word, but in a very real sense they are collaborative works. I got lots of feedback from other developers, help in debugging my examples, help resolving problems with the test environments, and many useful suggestions. Writing the book on the web made that kind of collaboration much easier.

There were a couple of people who offered to write chapters, but this did not come to pass. In the end, this didn’t matter; the books ended up doing what they needed to do.

After the first book was published, there was interest in creating a Spanish version. Some of the most successful OLPC projects have been in South America, so I definitely wanted there to be a Spanish version.  Unfortunately, I don’t speak any Spanish, so I didn’t feel qualified to do it. After the translation project got set up, a couple of people got accounts and looked over the book, and one of them translated a few paragraphs. Several of the people who had offered to help were concerned that they did not have the technical knowledge to translate the book, and for several days it looked like nobody was going to work on it.

A friend suggested using Google translate to create a base translation that native speakers could correct. I ended up using Babel Fish instead because the HTML generated by Google Translate had a lot of extra stuff in it like JavaScript and the original English text being translated. After I started doing this, a retired teacher who was fluent in Spanish started to correct the text, and I went through it and untranslated things that should not be translated, like code examples. It really needed native speakers to get it into shape.  The retired teacher sent out an email on some lists explaining that we had a translation going that needed to be corrected. After that, several native speakers got accounts on the site and started to correct the text.

What I learned from this, is that starting a book from nothing is intimidating. However, once the book reaches a critical mass and there is no doubt that there will be a finished book, you’ll find that getting help and feedback is easier, almost inevitable.

The best motivation to collaborate on writing a book is a desire for the book to exist. To quote Antoine de Saint-Exupery:

“If you want to build a ship, don't drum up people together to collect wood and don't assign them tasks and work, but rather teach them to long for the endless immensity of the sea”

If you can sell people on the idea of the book, you’ll get collaborators. That’s another reason you may have to write a substantial chunk of the book before collaborators show up. A partial book is easier to sell than an idea for a book.

With the book “E-book Enlightenment,” I collaborated with some people from an organization in Oregon called the Rural Design Collective. This is a group that has done work for both the Internet Archive and the One Laptop Per Child project. They have a summer mentoring program where talented students get involved with an Internet project and learn skills that may lead to a future career.

When I announced that Make Your Own Sugar Activities! was finished, I got an email from Rebecca Malamud of the RDC congratulating me. I told her about my plans for a new book and asked if she’d like to contribute.

At that point, the RDC was contemplating what to do for their summer mentoring program and they decided that working on my book might be just what they were looking for.

We all wanted the book to exist, but for different reasons. The RDC is focused on training young people to create websites, and so they chose to focus on the graphic design of the book more than the content.

The RDC found a talented young artist who did some terrific cover and interior illustrations (the small ones at the top of each chapter). The cover illustration that everyone liked didn’t really go with the title I had proposed, so I ended up changing the title.  (The same artist also did new cover art for the printed Make Your Own Sugar Activities!) Another of their mentees created stylesheets which they used to create a really beautiful bound and printed edition of the book.

In addition to the RDC’s work, I also got much help and encouragement from the forums of DIY Book Scanning and Distributed Proofreaders. Again, this is not collaboration in the way the word is normally used, but it was a vital contribution to the book. I would post a link to the book on the FLOSS Manuals website and ask for comments. The comments I got often contained valuable information and suggestions.

So, in summary, I’d say that online production is a good way to collaborate on writing a book!

Book Sprints

A more radical action for online book production is the Book Sprint3.

A Book Sprint is a facilitated process that brings together a group of people to produce a book in 3-5 days (although it has been done in shorter time). While the group meet in person, the books are produced collaboratively using networked (online) end-to-end book production tools. Often remote participants also join in. Usually, there is no pre-production and the group is guided by a facilitator from zero to published book. The books produced are high-quality content and are made available immediately at the end of the sprint in printed (using print-on-demand services) and e-book formats. Book Sprints produce great books and they are a great community and team building process.

The quality of these books is exceptional, for example, Free Software Foundation Board Member Benjamin Mako Hill said of the 280 page Introduction to the Command Line manual produced in a two-day Book Sprint:

“I have written basic introductions to the command line in three different technical books on GNU/Linux and read dozens of others. FLOSS Manual’s Introduction to the Command Line is at least as clear, complete, and accurate as any I’ve read or written. But while there are countless correct reference works on the subject, FLOSS’s book speaks to an audience of absolute beginners more effectively, and is ultimately more useful, than any other I have seen.”

Book Sprints offer an exciting and fun process to work with others to make that book you always felt the world needed. It is a fast process – zero to book in 5 days. Seem impossible? It’s not, its very possible, fun, and extremely rewarding in terms of output (a book!) and the team building that occurs during the process.

There are three common reasons to do Book Sprints:

  1. Producing a book that will be ready at the end of the Sprint drives the process and helps to justify the effort.
  2. Producing knowledge in a short period of time forces the participants to master the issues related to their subject. They will work intensely on content together, share and reshape their understanding of a collective question.
  3. Reinforcing or creating social links. Mobilizing a community to produce a book or text forges and solidifies a sense of belonging among participants.

As a result, I have experimented a lot with this format. To understand the many facets of collaboration in this process let’s look at the second case study – Collaborative Futures.

This book was first written over 5 days (Jan 18-22, 2010) during a Book Sprint in Berlin. 7 people (5 writers, 1 programmer and 1 facilitator) gathered to collaborate and produce a book in 5 days with no prior preparation and with the only guiding light being the title ‘Collaborative Futures’. These collaborators were: Mushon Zer-Aviv, Michael Mandiberg, Mike Linksvayer, Marta Peirano, Alan Toner, Aleksandar Erkalovic (programmer) and Adam Hyde (facilitator).

The event was part of the 2010 Transmediale Festival . 200 copies were printed the same week through a local print on demand service and distributed at the festival in Berlin. 100 copies were printed in New York later that month.

The book was revised, partially rewritten, and added to over three days in June 2010 during a second book sprint in New York, NY, at the Eyebeam Center for Art & Technology as part of the show Re:Group Beyond Models of Consensus and presented in conjunction with Not An Alternative and Upgrade NYC.

developed_collabfutures

Collaborative Futures – Second Edition cover by Galia Offri

Day one of the first sprint consisted of presentations and discussions.

During this first day we relied heavily on traditional ‘unconference’ technologies—namely colored sticky notes. With reference to unconferences we always need to tip the hat to Allen Gunn and Aspiration for their inspirational execution of this format. We took many ideas from Aspiration’s Unconferences during the process of this sprint and we also brought much of what had been learned from previous Book Sprints to the table.

First, before the introductions, we each wrote as many notes as we could about what we thought this book was going to be about. The list consists of the following:

  • When Collaboration Breaks.
  • Collaboration (super) Models.
  • Plausible near- and long-term development of collaboration tech, methods, etc. Social impact of the same. How social impact can be made positive. Dangers to look out for.
  • Licenses cannot go two ways.
  • Incriminating Collaborations.
  • In the future, much of what is valuable will be made by communities. What type of thing will they be? What rules will they have for participation? What can the social political consequences be?
  • Sharing vs Collaboration.
  • How to reconstruct and reassemble publishing?
  • Collaboration and its relationship to FLOSS and GIT communities.
  • What is collaboration? How does it differ from cooperation?
  • What is the role of ego in collaboration?
  • Attribution can kill collaboration as attribution = ownership.
  • Sublimation of authorship and ego.
  • Models of collaboration. Historical framework of collaboration. Influence of technology enabling collaboration.
  • Successful free culture economic models.

Then each participant presented who they were and their ideas and projects as they are related to free culture, free software, and collaboration. The process was open to discussion and everyone was encouraged to write as many points, questions, statements, on sticky notes and put them on the wall. During this first day we wrote about 100 sticky notes with short statements like:

  • “Art vs Collaboration”
  • “Free Culture does not require maintenance”
  • “Transparent premises”
  • “Autonomy: better term than free/open?”
  • “Centralized silos vs community”
  • “Free Culture posturing”

…and other cryptic references to the thoughts of the day. We stuck these notes on a wall and after all of the presentations (and dinner) we grouped them under titles that seemed to act as appropriate meta tags. We then drew from these groups the 6 major themes. We finished at midnight.

Day two—10.00 kick off and we simply each chose a sticky note from one of the major themes and started writing. It was important for us to just ‘get in the flow’ and hence we wrote for the rest of the day until dinner. Then we went to the Turkish markets for burek, coffee and fresh pomegranates.

The rest of the evening we re-aligned the index, smoothed it out, and identified a more linear structure. We finished up at about 23.00.

Day three—At 10.00 we started with a brief recap of the new index structure and then we also welcomed two new collaborators in the real-space: Mirko Lindner and Michelle Thorne. Later in the day, when Booki had been debugged a lot by Aco, we welcomed our first remote collaborator, Sophie Kampfrath. Then we wrote, and wrote a bit more. At the end of the day we restructured the first two sections, did a word count (17,000 words) and made sushi.

After sushi, we argued about attribution and almost finished the first two sections. Closing time around midnight.

Day four—A late start (11.00) and we are also joined by Ela Kagel, one of the curators from Transmediale. Ela presented about herself and Transmediale and then we discussed possible ways Ela could contribute and we also discussed the larger structure of the book. Later Sophie joined us in real space to help edit and also Jon Cohrs came at dinner time to see how he could contribute. Word count at sleep time (22.00): 27,000.

Day five—The last day. We arrived at 10.00 and discussed the structure. Andrea Goetzke and Jon Cohrs joined us. We identified areas to be addressed, slightly altered the order of chapters, addressed the (now non-existent) processes section, and forged ahead. We finished at 2200 on the button. Objavi, the publishing engine for Booktype, generated a book-formatted PDF in 2 minutes. Done. Word count ~33,000.

Some months later the book was ‘re-sprinted’ in New York with another group of people. The following contains excerpts from the experiences and voices of those involved:

Over the course of the second Book Sprint, we often paused to reflect on the fact that editing and altering an existing book (one originally written five months prior by a mostly different group of people) is a completely different challenge than the one tackled by the original sprinters. While the first author group began with nothing but two words -Collaborative Futures- words that could not be changed but were chosen to inspire. This second time we started with 33,000 words that we needed to read, understand, interpret, position ourselves in relationship to, edit, transform, replace, expand upon, and refine.

Coming to a book that was already written, the second group’s ability to intervene in the text was clearly constrained. The book had a logic of its own, one relatively foreign to the new authors. We grappled with it, argued with it, chipped at it, and then began to add bits of ourselves. On the first day, the new authors spent hours conversing with some of the original team. This continued on the second day, with collaborators challenging the original text and arguing with the new contributions

If this book is a conversation, then reading it could be described as entering a particular state of this exchange of thoughts and ideas. Audience might be a word, a possibility and potential to describe this readership; an audience as in a performance setting where the script is rather loose and does not aim for a clear and definite ending. (It is open-ended by nature); an audience that shares a certain moment in the process from a variable distance. The actual book certainly indicates a precise moment, thereby it IS also a document, manifesting some kind of history in/of open source and counter-movements, media environments, active sites, less active sites, interpassivity (Robert Pfaller), residues of thought, semi-public space; history of knowledge assemblages (writers talked about an endless stitching over…) and formations of conversations.

The book as it is processed in a Sprint, is a statement about and of time. The reader or audience will probably encounter the book not as a “speedy material”. Imaginary Readers, Imaginary Audience. We came to recognize, however, that the point was not to change the book so that it reflected our personal perspectives (whoever we are), but to collaborate with people who each have their own site of practice, ideology, speech, tools, agency. In service of a larger aim, none of us deleted the original text and replaced it to reflect our distinct point of view. Instead, we came to conceive of Collaborative Futures as a conversation. Since the text is designed to be malleable and modifiable, it aims to be an ongoing one. That said, at some point this iteration of the conversation has to stop if a book is to be generated and printed. A book can contain a documented conversation, but can it be a dynamic conversation? Or does the form we have chosen demand it become static and monolithic?

In the end, despite our differences, we agreed to contribute to the common cause, to become part of the multi-headed author. Whether that is a challenge to the book or a surrendering to it, remains unclear.

  1. http://thepenguinblog.typepad.com/the_penguin_blog/2007/03/a_million_pengu.html^
  2. http://www.booki.cc/collaborativefutures/continuum/^
  3. http://www.booksprints.net^