When Paper Fails

When all the activities and practices that we now call “publishing” exist in a networked environment, something radical changes – affecting creators, content, ownership, and trust. That might sound like the end of publishing as it is now, but it also sounds like the beginning of something exciting. And of course, it is argued that this future is already here, but, to paraphrase William Gibson, perhaps a little unevenly distributed.
Responses to these new challenges are already partly in motion inside the industry (e.g., the work Safari Books is doing with bibliographies connected to their ‘cloud library’) and outside (too many to mention but one example is the very interesting Open Oil book project) and as we move forward I firmly believe these futures will become increasingly present and their economics more mature.
Where does that leave the publishing business? Well, it might be better to ask yourself, ‘where does that leave business?’ Forget capital P, ‘Publishing’, for a moment. What are the skills necessary to survive here, what will you be doing, and what is the economy?
People are going to continue to require services that deliver and produce information. Finding ways to create information and finding someone to pay for it is the heart of the matter. That is not going to change anytime soon. The need for information won’t change, but how information is produced and delivered will change. In fact, I believe the demand for content is going to rise (it is already rising rapidly), and the demand will increasingly be for more individualised, customised content and it will need to be delivered faster, much faster than today.
So, what would the world look like when the walls that contain the publishing industry fail and spill their innards onto the web? Or to see the same question through the lens of Eric Raymond, what is the essential difference between the cathedral and the bazaar?
Let’s quickly look at the environment of this particular kind of “bazaar” – the web – for a few clues. The most important issue at play is that the web always appears to find a way to route around arbitrary constraints. People, processes, and information route their way around unnecessary blockages looking for and finding the most efficient and least resistant paths. So what would happen if publishing was immersed in that environment? What are the containers, the constructs of the publishing industry, that would be routed around and may break down and fail? Here, I want to explore four main issues pertinent to this discussion – Books, Ownership, Authors and Authority.
Books: In this environment content containers, like books, lose the definitiveness of their boundaries. What is separating an EPUB, which is made of HTML, from the web? As Hugh McGuire has said many times, this differentiation is arbitrary.  Arbitrary containers like zip files (EPUBs, which we might call portable websites) might assist in the transport of curated content, but, in the long run, they will be under a lot of pressure to remain contained and will increasingly become unbound.
Ownership: Another “container” that will come under increased pressure from these forces. If the mere fact of copyright ownership protected their content then publishers wouldn’t be looking to DRM (digital rights management). We know that the way in which book content is owned and licensed will change dramatically. Protecting ownership will increasingly become an impediment to business as it decreases the utility of information (something that O’Reilly was smart to recognise early on and perhaps reflects Samuel Johnsons’ famous quip regarding his writings that “I have been paid for them, and have no right to enquire about them”).
Authors: Also an arbitrary construct, in as much as both the realities of book authorship, and its production, are more collaborative and iterative than commonly perceived. This is another dimension that will be radically transformed by the new collaborative possibilities opened up by digital technologies. Indeed, perhaps the cultural construct of isolated genius will remain only as a brand. In reality, people are less and less isolated on the web and there is more genius out there than you can imagine. I would argue here that the concept of the author will also become more “porous”. We will be looking at a world of “networked genius” rather than the traditional standalone kind. This has been discussed in fascinating detail by Martha Woodmansee and Jack Stillinger.
Authority: The web doesn’t seem to allow anyone to merely assert ‘authority’ – such notions are subject to the ebb and flow of public web “opinion”. Publishing as an authority will certainly come under immense pressure and one possibility is the move to “distributed opinion networks” built and mediated by technologists. We have already seen this on the web, and the question of authority in these networks is well articulated in commentary surrounding Wikipedia vs Encyclopedia Britannica, for example.
When paper fails, it affects creators, content, ownership, and trust in radically transformative ways. Production processes change, content is both harvested and produced, contributors are corralled and facilitated, books become individualised ‘outcomes’. We might say the engine this “new” publishing economy revolves around includes two critical factors:
(1) content production, harvesting and curation for increasingly individualised contexts; and (2) speed of delivery.

Helping people to get what they want, their outcome, is going to be the bread and butter of this economy. This is a move from selling the artifact, to developing and selling a service, or towards providing services to help others produce and distribute content. The faster you can deliver it the more competitive you will become. People, businesses, governments, schools, etc., are all going to be very happy to pay for that.

*Please note the Open Oil project is a small project and not provided here to illustrate this kind of model at scale but to point at a very interesting and important emerging model.

Many thanks to David Berry for improving this post. This post and all others by Adam Hyde are CC-BY-SA

Originally posted on 13 Feb 2013 on O’Reillys Tools of Change site: http://toc.oreilly.com/2013/02/when-paper-fails.html

Visualising Book Production

Data visualisation is one of the hot topics of the last year or two. So what does this offer publishing and book production?

Open data activists, in particular, have been lobbying governments for access to databases which they use to create infographics and visualisations for campaigns. It’s not a new science, of course, it was here long before the internet (for some background on contemporary practice see the wonderful books by Edward Tufte), but the net is made of data and is a good mechanism for transporting it. The internet is a good medium for scraping and re-presenting data in more palatable forms.
Prior to the net, visualising book production was tricky since the information either wasn’t recorded or was embedded in ungainly ‘record changes’ data in word processing files. So the few examples were preceded with some forensic historical research. One wonderful pre-Word example is The Preservation of Favoured Traces by processing inventor Ben Fry. He visualises the production of The Origin of Species over time to illustrate Darwin’s evolving thesis. Rather appropriately, his is a nice visualisation of the evolution of a book.

This is where the web steps in and changes the game. Online book production platforms enable you to store and retrieve historical data and use it as you like. You can record and access information quite easily. Information such as who is actively working on a book and when, how much they changed, what they changed, who else was online, word counts over time, is all available. If we could access and process this information in chunks, it could perhaps help us to make books better.

Just to show you where this might go, the following are simple prototypes Juan Barquero and I put together using real data from the online book production platform Booktype. The nice thing about Booktype is that it already has all this data recorded in the history for each book, so we could write a visualisation application and then look back over the history of many books. So we made a simple API (Application Programming Interface) and Juan put together a few demos using the JavaScript visualisation library D3JS. The following are some images taken from these trials:

channel1 Contributions to chapters (x) over time (y)

circles5Proportional contributions per contributor

These are just a few simple and raw examples that are of course very far away from being production-ready. However, they serve as interesting prototypes for thinking about how this might look and what we might learn from such techniques in a production environment.

Originally published on O’Reilly, 4 Feb 2013 http://toc.oreilly.com/2013/02/visualizing-book-production.html

Zero to Book in 3 Days

One of the burdens of book creation is the enormous time periods involved. Ask any publisher for a timeline for producing a book and you will be surprised if you get back an answer this side of 12 months. In this day however that timeline is looking increasingly glacial. How can we accelerate book production? How fast could it get? How does three days sound? Enter Book Sprints.sprint_booksThese three books were created in a three-day Book Sprint and output to paper, MOBI and EPUB on the third day.

Book Sprints bring together 4-12 people to work in an intensely collaborative way, going from zero to book in 3-5 days. There is no pre-production and the group is guided by a facilitator from zero-to-published book in the time available. The books produced are made available immediately at the end of the sprint in print (using print-on-demand services) and ebook formats. Books Sprints produce great books and they are a great learning environment and team-building process.

This kind of spectacular efficiency can only occur because of intense collaboration, facilitation and synchronous shared production environments. Forget mailing MS Word files around and recording changes. This is a different process entirely. Think contributors and facilitators, not authors and editors.

There are five main parts of a Book Sprint (thanks to Dr D. Berry and M. Dieter for articulating the following so succinctly):

  • Concept Mapping: development of themes, concepts, ideas, developing ownership, and so on.
  • Structuring: creating chapter headings, dividing the work, scoping the book (in Booktype, for example).
  • Writing: distributing sections/chapters, writing and discussion, but mostly writing (into Booktype, for example).
  • Composition: iterative process of re-structure, checking, discussing, copy editing, and proofing.
  • Publication

The emphasis is on ‘here and now’ production and the facilitator’s role is to manage interpersonal dynamics and production requirements through these phases (illustration and creation of other content types can take place along this timeline and following similar phases).

Since founding the Book Sprints method four years ago, I have refined the methodology greatly and facilitated more than 50 Book Sprints – each wildly different from the other. There have been sprints about software, activism, oil contract transparency, collaboration, workspaces, marketing, training materials, open spending data, notation systems, Internet security, making fonts, OER, art theory and many other topics.

People love participating in Book Sprints, partly because at the end of a fixed time they have been part of something special – making a book – but they are also amazed at the quality of the books made and proud of their achievement. The Book Sprints process releases them from the extended timelines (and burdens of guilt) required to produce single-authored works.

Here are some interestingwrite-upss that provide more detail on the process:

http://techblog.safaribooksonline.com/2012/12/13/0-to-book-in-3-days/

http://google-opensource.blogspot.com/2013/01/google-document-sprint-2012-3-more.html

http://www.booksprints.net/2012/09/everything-you-wanted-to-know/

Originally published on O’Reilly, 28 Jan 2013 http://toc.oreilly.com/2013/01/zero-to-book-in-three-days.html

Fork the Book

As one of the first mass-produced industrial artifacts, the book remains a solid signifier of stability. That aura is pretty strong and makes it difficult to think about books as being anything other than static. It appears to be part of their DNA.

While we continue to refer to ebooks as ‘books,’ this genetic legacy seems to be inherited along with the name. Books are stable. Websites are not. That’s the lore.

However, this distinction is more than a little arbitrary and it’s interesting to consider what advantage there might to destabilising books. What would we gain and lose if books became unstable and staticness was viewed as a property of a particular era intimately linked to the days of the printing press and paper books?

The technology is right here to make books unstable. EPUBs, for example, are easy to re-edit and ‘re-publish’. In early 2012, I made a demo with Juan Barquero to demonstrate this reality (the ebook itself is no longer online but Phil Schatz took up the idea and you can see something similar here.

The demo uses EPUB as a storage mechanism and the editor enables you to edit the ebook directly. You can edit the pages in the ebook itself. While this is in itself interesting, it doesn’t offer much more than what you can do with word processing now. It is true that the book can be generated as an EPUB on the fly, but this is optimisation of current processes, it in itself doesn’t offer anything new. You could do the same with MS Word files, it would just take a little longer.

What is more interesting is that the demo uses GIT as a back end (Adam Witwer and the O’Reilly crew have also been working on using GIT with Atlas). GIT is a technology programmers use to collaborate on code. It allows programmers to copy (fork) code, work on it and then re-combine (merge) the changes with the work of others. The git demo opened the door to cloning, editing, forking and merging the book into infinite versions. Clicking the download button gives you a new version of the book in its current state, immediately, but there could be 5 different versions of the same book in production. Or 50, or 100. Creating a new version is simply a matter of clicking a button and the book will be forked to its own repository. Further, it is possible that each fork can inherit the improvements in other forks by merging the content of several versions into one.

What does this point to? It points towards a particular kind of book instability. However, while it is technically feasible, the question really is – does this kind of book instability have any value? I believe it does. I would go as far to say that this kind of book, which I would prefer to call a ‘forkable’ book, is more valuable in many situations than stable books.

As a very small case in point, let’s have a quick peak at the life of a forkable book. The Cryptoparty Handbook.

The CryptoParty Handbook was created in Berlin during a 3 day Book Sprint last October. It consists of over 440 pages of information for those wanting to be safe online. The speed with  which the book was created was as fast because it reused content from two existing books (licensed under Creative Commons): How to Bypass Internet Censorship and Basic Internet Security. Both of these publications were also created with Book Sprints the previous year.

Creating The CryptoParty Handbook was simply a matter of forking (copying) each of the other books and merging them into a new container. Easily done. The team, under my facilitation, then structured a new table of contents, removed chapters that were not necessary, identified content that needed to be created, and then started writing and illustrating. It didn’t take them much time to produce a book which was immensely useful for their audience and which could also be easily remixed and translated.

The handbook has now been forked quite a bit. The first version hit 30,000 downloads in the first few weeks. There have also been some interesting forks, including one by the Liberation Tech list hosted by Stanford University from where it has been forked again another 50 or 60 times. The book is now being used by CryptoParties all over the world to train people in small informal workshops. As if this isn’t enough forking, the foundation books, from which the Crytoparty handbook was based, have also been forked into many many other books.

This is just one example highlighting what can happen when we allow books to be forkable. They become extremely powerful bodies of content that can be re-purposed infinitely for whatever context is necessary. That’s pretty valuable.

As a final note. This is not some kind of hippie content love-in. There are economies in action here. It takes skill to curate and corral content, shape it, get it to meet the needs of a specific audience, and find experts to fill in the gaps. It takes experts in facilitation and curation — and that points towards new sets of skills required in the emerging publishing practice.

Originally posted on 22 Jan 2013 on O’Reillys Tools of Change site: http://toc.oreilly.com/2013/01/forking-the-book.html

Paying for Books that don’t Exist (yet)

Kickstarter.com has taken up the concept of crowdfunding with significant success. The premise is simple: an individual defines a project that needs funding, defines rewards for different levels of contribution, and sets a funding goal. If pledges meet the funding goal, the money is collected from pledgers and distributed to the project creator, who uses the funding to make the project. If the project does not reach the funding goal by the deadline, no money is transferred. Most projects aim for between $2,000 and $10,000.

Kickstarter approaches have their issues, but they raise an interesting point – people are prepared to fund a book before it is produced. Or to put it another way and one which covers a wider spectrum of emerging book economics – people are willing to pay for books that don’t yet exist.

A while ago I worked with a Dutch organisation by the name of greenhost.nl. They are a small hosting provider based in Amsterdam with a staff list of about 8. The boss wanted to bring their team to Berlin to make a book about basic internet security so they hired me to facilitate a Book Sprint. We invited some locals to help and organised a venue for four days. In total, about 6 people were in attendance (including myself as facilitator) and we started one Thursday and finished the following Sunday – one day earlier than expected. The book is a great guide to the topic and quite comprehensive – 45,000 words or so written in 4 days with lots of nice illustrations.

The following morning the book went to the printers and then was presented  in print form two days later at the International Press Freedom Day in Amsterdam.

The presentation at International Press Freedom Day was complemented by a PR campaign driven by Greenhost. The attention worked very well as the online version of the book received thousands of visits on the manual within a few hours (slowing our server down considerably at one point) and there was also a lot of very nice international and national (Dutch) press attention. This worked very well for Greenhost as this is the kind of promotional coverage that is otherwise very hard to generate. That makes sponsoring of Book Sprints a very good marketing opportunity for organisations.

Many of the organisations I work with approach Book Sprints with similar ideas in mind. They think about what kind of book their organisation would want to bring into the world, then design a PR strategy around the book. The book is often given away free in electronic form to their target market, maximising the reach and goodwill created.

Of course, this approach does not come without its issues. Organisations that pay to have something produced generally do not like it if the product disagrees with them. Worse is the mindset that this possibility can produce in the producers. Anticipating and avoiding disagreement is in effect a kind of self-policing that can stifle creativity, especially when you are working collaboratively. However, this can be mitigated by hiring a good facilitator.

Lastly, The Long Tale. The long tail was popularised in the age of the net by Chris Anderson. It’s the familiar strategy of selling a large number of books to small niche markets, the idea being that a lot of sales of niche items adds up to a good profit, or as he put it in the title, Why the Future of Business Is Selling Less of More.

However, there is another possible ‘long tale’ market here – instead of seeing a total inventory as having a ‘long tail,’ each book in itself can be customised for resale over a number of smaller markets – one book distributed over several markets, each with its very own version of the book. We have experimented with this a little in FLOSS Manuals – customising the same book for specific markets. Remixing books can be considered to be exactly this strategy but on a very small scale. Many workshop leaders use the remix feature of FLOSS Manuals to generate workbooks with content taken from several existing books. We have also encouraged consultants to take books from FLOSS Manuals, clone them, and customise the book to speak directly to their potential and existing customers. It is a powerful pre- and post- sales device. The long tale here has a market of 1 – the client. This is the very end of the long tale but the return can be lucrative for the consultant that secures a sale or return sale because of their valued-added services powered by customised documentation.

I believe there is a business here – either creating or customising content as a service or providing the tools for people to customise their own content. In either case, we are seeing a broad willingness for organisations and individuals to pay to get the content they want before it is available ‘off-the-shelf’.

In-Browser Design

The page is changing in so many ways – time-based media is making its way into book pages, reactive content, scrollable space, and a multitude of differing display devices make designing pages pretty hard work these days. How to design for so many possibilities? How to understand so many possibilities?

Craig Mod of flipboard makes a very compelling argument for two forms of page : formless and definite content in an article he wrote for Book: A Futurists Manifesto – the first book to be produced by PressBooks. Craig’s argument, in a nutshell and in his own words is:

the key difference between Formless and Definite Content is the interaction between the content and the page. Formless Content doesn’t see the page or its boundaries; Definite Content is not only aware of the page, but embraces it. It edits, shifts, and resizes itself to fit the page [...] Put very simply, Formless Content is unaware of the container. Definite Content embraces the container as a canvas.

Craig argues that most book content we know is formless – the text can reflow into other containers without affecting the meaning. This position is in tension to the thinking of most book designers today. Designers of paper books design contained space and desktop publishing applications are built to manage pixel-perfect manipulation within a strictly defined and known container. If the finished digital article does not exactly co-relate to the printed artefact then something went wrong; it is assumed that either the designer, or the tool, has done a bad job.

Those familiar with this kind of process are uneasy with designing formless content – how can you design a page when you do not know its container? It is literally like asking a book designer to design a book without telling them the page dimensions. Web designers, on the other hand, have been thinking about page design too, and they have for a long time, at least in part, been designing for formless content.

The design of formless content is really a partially-formless, partially-constrained design process since elements within the page have some kind of relationship to each other, and they can have relationships to characteristics of a page, such as top or top left, for example. These relationships are defined by rules, the same rules I have discussed previously – CSS aka Cascading Style Sheets. Relationships can be articulated with CSS which will be preserved when displayed in different contexts. The meaning is preserved by the relationship between the elements and page features more than by their relationship to the the exact x,y position of a page with a specific dimension, although strict placement is possible. This is the job of Cascading Style Sheets – the design language of the web. It is rule-based design with some conditional arguments and it is the method for designing electronic books; it will become, increasingly, the technology for describing the layout and design of paper-based print.

All of this can be manipulated in the browser. In fact, the browser is the best place to design flowable text since it is the flowable type environment of our time and, as mentioned before, the browser (Webkit) is the background technology for many e-readers. We have not yet seen the development of very good flowable design environments in the browser, but that is changing. The closest we have seen so far are the ‘in-browser’ design environments that some internet service providers make available for their customers to ‘design their own website online!’ While actually quite powerful, these environments are generally horrible to use, but this practice is applicable to the design of ebooks.

The desktop publishing world is not taking this lying down, and Adobe, in particular, has been pursuing what they call “Adaptive Design Tools” for the production of ‘liquid content’. Liquid content is flowable content, content that can rescale and position itself to fit the container. Adobe’s tools are intended for content targeted for mobile devices and tablets, although they also identify a role for it in print production. Adobe’s yet-to-be-released Adobe Edge is the product targeted at this flowable design process and their background technology for this design environment is – Webkit, the same browser mentioned earlier. Webkit is the ‘design surface’ for the new generation of desktop design tools coming from established publishing technology providers.

Coming back to the paper book. Until recently it has been extremely difficult to generate a PDF that exactly co-relates to what you see in a browser. Until now the browser accessed the PDF-creation features of the operating system. Hence a PDF from the same browser would look different if that browser were running in Windows, Mac or Linux. Just recently this has changed and the browser itself is now making the PDF. Chrome has been pioneering this ‘Native PDF’ output from the browser and the output looks exactly as you see it in the browser. One to one co-relation of content in the browser to the content in the PDF is a breaking point which points the way to designing your paper book in a browser. We are getting to the point where you can use a browser just as you would a desktop publishing application to design paper books.

The browser can now play every part of the book production process except the actual printing (although from the browser you can upload PDF to print-on-demand services such as Lulu.com).

What this means is that you can write a book in the browser, while at the same time it is being proofed and edited, and designed. Each part of this formerly-linear production cycle can now become synchronous. You can now write, edit, proof, design the book ‘in the book’.

Collaboration and Book Production

Collaboration on a book is the ultimate unnatural act. —Tom Clancy

The emergence of online book production tools is, of course, bringing writers online. Authoring books online seems to bring two apparently opposing dynamics into play – the social web and the author. The production in the context of the increasingly noisy, social web seems at odds with the typical conception of solitary writer and the juxtaposition simultaneously brings into focus the potential for collaboration or ‘social production’ together with questions of authorship.

The modern discourse around book authorship began in 1969 when Michel Foucault asked, What is an Author? he  drew attention to a shift in the definition of an “author’s” role that represented a “privileged moment of individualisation in the history of ideas, knowledge, literature, philosophy, and the sciences” ([Foucault 2002]). Scholars and theorists of various academic disciplines have spent the last thirty years responding to Foucault in what has grown into a vibrant intellectual discourse on authorship. We need to enter this debate to discover what might lie ahead for online book production.

One of the foremost participants in this discussion is Martha Woodmansee, who notes [Woodmansee 1992] that the modern concept of author is rooted in the Romantic notion that significant writers, “break altogether with tradition to create something utterly new, unique—in a word, ‘original.’” As Benjamin Mako further discusses [Mako, 1995], this popular belief in an author’s primary, even exclusive, role in the creation of a text, is referred to as Romantic authorship and before the rise, and eventual dominance of this notion, writing gained value from its creative affiliation with existing works, or what Martha Woodmansee describes as “its derivation, rather than its deviation from prior texts” [Woodmansee 1994]. Before this important shift, the authorial role was often compared to that of a commentator, compiler, or transcriber. Woodmansee references a definition by the thirteenth century St. Bonaventure who describes an author as one who “wrote both with his own work and others’ but with his own work in the principle place adding others’ for purposes of confirmation” [Woodmansee 1994] . This thirteenth-century definition of authorship places literary creation squarely within the context of collaboration.

In this time, through the support of author honoraria, the constant production of new work was insured without the need for system of intellectual property or ownership. This arrangement was essential as the dominant models of literary creation were fundamentally intertwined with borrowing and collaboration.

Prompted by the rise of copyright in Britain in 1709, the eighteenth century introduced a new concept of individualised authorship based on the idea of a creative genius working alone. This idea—one at odds with collaborative, collective, or corporate creation—has remained widely influential despite powerful arguments made by theorists like Foucault and Woodmansee and a growing body of evidence that collaborative and collective creation is more effective than individual work.

At its birth, copyright was lobbied for and designed to benefit publishers alone. For at least the first century of its institution, authors continued to write in the ways they had before. They borrowed as they had before; they collaborated as they had before; they plagiarised as they had before. Collaboration in the forms popularised before the institution of copyright remained popular. However, by selling the rights to their ideas, authors were presented with a new system of compensation for their work: a way to “live by their pen.” They realised that by solidifying their access to these rights, they might insure their ability to make a living. This coincided, and was intimately connected, with the explosive growth of the publishing industry in Europe. Authors felt they needed to insure compensation for their intellectual productions and saw their copyright, described in the Statute of Anne and similar acts in other countries, as an available method for achieving this goal.

This is not to imply that collective authorship is not possible today, however, joint authorship operates in an environment hostile to collaborative work, and, as a result, is difficult at best. Under current systems of literary production defined by copyright and Romantic conceptions of authorship, writers have few other options. By emphasizing ownership and control as the primary, and in most cases the only, method of compensation for literary work, meaningful collaboration becomes difficult in all cases and impossible in most. Rather than borrow and work together, authors will work alone. Rather than borrow an idea, passage or theme from another novel and risk a copyright suit, authors are more likely to not include the theme or passage at all. The fact that joint-authorship and collaboration can function at all in this hostile environment, is testament to the power and of collaboration. Without a strong system of control shaping the landscape of literary creation, it is very likely our idea of how books are made would be very different and collaboration would play a central, valued, role.

However there have recently been some changes that affect these issues deeply and there is reason to be optimistic about the future of collaborative book production. Creative Commons is often heralded as a free content license movement. A ‘free content license’ is one which gives more nuanced control over the rights afforded by copyright. Instead of using the standard ‘all rights reserved’ copyright license, more and more people are subscribing to this idea of ‘free licenses’ or ‘free culture’ and producing work under more liberal copyright licenses. This article, for example, uses a Creative Commons Share-Alike Attribution license which means that anyone can do anything with it, commercially or otherwise, without needing to get any authorial permission as long as they attribute the source.

Licences such as these are important as legal mechanisms for opening up the opportunities for the reuse of content, however they are also an essential environment for collaborative production. The whole process just becomes more fluid. There is no need to sign ‘work for hire’ or other legal agreements to enable collaborative relationships, one can simply get on with the job. Free licenses provide a legal framework which is not, in itself, hostile to collaboration and from that position we can look at single authorship as a choice, not a given.

However, we must recognise that 300 years of copyright and a long era of Romantic authorship has left us with inadequate tools for engaging in the collaborative process. It is difficult to get beyond our deeply internalised ideas of book production, and we find ourselves unwilling to leave behind the romantic notion of authorship, as it is, well, romantic and very enticing. Collaboration, on the other hand, is difficult to imagine and, we should not forget, it has an army of derisionists like Tom Clancy, not to mention the academic and commercial publishing worlds, that are invested in devaluing it. Can books really be produced collaboratively and what does the process offer? It is difficult for many of us to answer these basic questions whereas we feel we understand the value and the offer of sole authorship.

In order to ease into the question, it is perhaps worth avoiding the word ‘author’ to describe the book production process. Instead of talking about the author, or even multiple authorship, let’s forget the word all together and reframe it in another way. I propose we instead think about strong and weak collaboration.

It is evident that the books you see in the book stores in your town are not produced by one person alone. Let’s imagine that someone did, in fact, write the entire book and it was untouched by an editor’s hand – we can at least accept that the sole writer did not design the book or the cover or take the entire bundle to the printer to be produced. There may be some cases where this has happened, certainly in the self-publising world this is not uncommon, but thinking for now about the established publishing industry. That book by Tom Clancy had at least some one, or more, involved in the process unless Tom is hiding his desktop publishing talents from us.

However, let’s just limit our focus to possible collaborative relationships which effect the actual text. There is practically no book that goes through the publishing process entirely intact. At some point, someone put in their hand to make an improvement, even if small. Did Tom do a thorough grammar check? Any proofreading or editorial comments before printing?

I would characterise this kind of interaction with the text as minimal or weak collaboration. More than one hand was at play to make that exact text which appears in the book: this was a collaborative effort, albeit an extremely weak one.

Moving up the scale. Where a writer and an editor might interact often regarding the text as it is being produced, the editor offering suggestions for improvement, or editing the text directly, this could be characterised as having a stronger collaborative nature than the previous example.

Stronger still is a relationship of two or more writers working very closely together to produce a text. This is evident in any number of ‘single author’ classics such as Frankenstein, which is attributed to Mary Shelley although we know now that Percy Shelly had a strong hand in some of the text, or The Wasteland, which has been discussed by many as a case in point where T.S Eliot collaborated closely with both Vivienne Elliot and Ezra Pound in its production.

Lastly, at the far end of the scale, we have intense collaboration where the delineation between ‘who wrote what’ disappears even to the collaborators themselves as they are producing the text.

As it happens, most books feature not just collaboration but intense collaboration between writer and editor.

As Valerie Peterson warns, “Once you sign a contract with a book publisher, you’re essentially in partnership to create “the book,” and you both have a say in the end-product. From trimming the fat of your language (akin to “killing your babies”) to altering the logical flow of the chapters, your book editor will have much to say about how your text will look in print. While your editor is there to make the book (and you!) sound better–and a thoughtful, skilled editor absolutely will do that–you two may not always agree on what’s best for the finished book. If you’re going to publish, it’s good to be prepared for some “creative differences.”

An  editor may be so esteemed by writers wanting to be published that they choose publishers, where possible, by the esteem they have for the editor involved. A wonderful example of this is found in How a Book is Born: The Making of The Art of Fielding by Graydon Carter and Keith Gessen. Choosing a publisher is to choose an editor, which in turn is really choosing a collaborative partner.

If we allow ourselves to do away with the notion of authorship and instead characterise the interactions on a collaborative spectrum we can see that collaboration already plays an important role in a ‘typical’ process, and it has more value than we may have first thought. Book production is actually a collaborative process and quite an intense one. The publishing world has hidden this from view because of the reasons discussed above but we should not be fooled into believing that creating a book involves Romantic authorship. Collaboration is a technique we use to improve all books, and we should bring it into focus and explore it.

The advantage of producing books online is that we have an enormous scope of collaborative activity available to us. Until now, exploration of the possibilities has largely been limited because of our investment in myths of authorship but if we discard this notion we can explore the opportunities the web offers. The good thing about the net is that ‘the door’ can be regulated depending on the production needs. We may wish to fling the door wide and invite anyone to come in and work on a text, or we may shut the door completely and work in isolation. We may need to, for example, remain in a weak collaborative position for quite some time as we flesh out a work. Later, when we ask for feedback we move slightly up the scale, and later still when the first manuscript is in the hands of an editor we move up the scale to quite strong collaboration. The point is, we have the choice, and much more choice than we had before.

With thanks to Benjamin Mako Hill for asynchronous inspiration and collaboration on this text. Many thanks also to Rachel O’Reilly for improving this post.

This version expanded from  http://toc.oreilly.com/2012/12/changing-the-culture-of-production.html  (11 December 2012)

WYSIWYG vs WYSI

HTML is the new paper and the new path to paper online editing environments are becoming much more important for publishing. Dominant until now has been the WYSIWYG editor we all know and…err…love? However, the current WYSIWYG paradigm has been inadequate for a long time and we need to update and replace it. Producing text with a WYSIWYG editor feels like trying to write a letter while it’s still in the envelope. Let’s face it…these kinds of online text editors are not an extension of yourself, they are a cumbersome hindrance to getting a job done.

Apart from huge user experience issues the WYSIWYG editor has some big technical issues. Starting with the fact that the WYSIWYG editor is not ‘part of the page’ it is instead its own internally nested world. In essence, it is an emulator that, through Javascript, ‘reproduces’ HTML. As a walled/emulated garden, it is hard to operate on the objects in the garden using standard Javascript libraries and CSS. All interactions must be mediated by the editor. The ‘walled garden’ has little to do with the rest of the page – it offers a window through which you can edit text, but it does not offer you the ability to act on other objects on the page or have other objects act on it.

Thankfully a new era of editors is here and maturing fast. Still in search of a clearly embraced category name they are sometimes called ‘inline editors’ or HTML5 editors. This new generation takes a large step forward because they enable the user to act on the elements in the page directly through the HTML5 ‘contenteditable’ attribute. That allows ‘the page’ to be the editing environment which in turn opens up the possibility for the content to be represented in a variety of forms/views. By changing the CSS of the page, for example, we can have the same editable content shown as multi-column (useful for newspaper layout), as a ‘Google docs type’ clean editing interface, in a semantic view for highlighting paragraphs and other structural elements (important for academics), as well as other possibilities….

Additionally, it is possible to apply other javascript libraries to the page including annotation software such as AnnotateIt or typographical libraries such as kern.js. This opens up an enormous amount of possibilities for any use case to be extended by custom or existing third-party JavaScript libraries.

It is also possible to consider creating CSS snippets and apply them dynamically using the editor. This in effect turns the editor into a design interface which will open the path for in-browser design of various media including, importantly, ebooks and paper books.

There are various attempts at the HTML5 editor, which might also be called a ‘WYSI’ (‘What you see is‘) editor. The most successful are Mercury, Aloha and the recent fork of Aloha called ‘WYSIWHAT‘.

Each of these is treading their own path but things are really opening up. As an example, and with reference to the last post I made about math in browsers, the WYSIWHAT group is making some giant strides in equation editing. Their equation plugin which was first built by Mihai Billy Balaceanu at the September WYSIWHAT hack meet in Berlin has since been improved and extended by the Connexions team and the good people at OERPUB (including the talented trio of Phil Schatz, Kathi Fletcher and Marvin Reimer). The plugin was made by including MathJax in the page and allowing the editor to interact with that. This was not easily possible with previous WYSIWYG editors.

The progress on the equation front is looking very good but what this shows more than anything is that by using WYSI editors the entire page is available for interaction by the user or JavaScript. Anything you can think of that JavaScript can do you can bring to the editing environment, and that is quite a lot…

Published on O’Reilly, 3 December 2012 http://toc.oreilly.com/2012/12/wysiwyg-vs-wysi.html

Math Typesetting

Typesetting math in HTML was for a long time one of those ‘I can’t believe this hasn’t been solved by now!’ issues. It seemed a bit wrong – wasn’t the Internet more or less invented by math geeks? Did they give up using the web back in 1996 because it didn’t support math? (That would explain the aesthetic of many ‘home pages’ for math professors.)

MathML is the W3C-recommended standard markup for equations – it’s like ‘HTML tags for math.’ While MathML has a long history and has been established in XML workflows for quite some time, it was only with HTML5 that mathematics finally entered the web as a first-class citizen. This will hopefully lead to some interesting developments as more users explore MathML and actually use it as creatively as they’ve used ‘plain’ text.

However, the support in browsers has been sketchy. Internet Explorer does not support MathML natively, Opera only supports a subset, and Konqueror does not support it. Webkit’s partial support only recently made it into Chrome 24 and was held back on Safari due to a font bug. Firefox wins the math geek trophy hands down with early (since FF 3) and best (though not yet complete) support for MathML.

What’s the hold-up?

It seems that equation support is underwhelmingly resourced in the browser development world. Webkit’s great improvements this year (including a complete re-write + the effort to get it through Chrome’s code review) have been due to a single volunteer, Dave Barton. Frédéric Wang plays the same heroic (and unpaid) role for Firefox. The question is: why is this critical feature being left to part-time voluntary developers? aren’t there enough people and organisations out there that would need math support in the browser (think of all the university math departments just for starters…) to pay for development?

As a result, we have no browser that fully supports MathML. While you cannot overstate the accomplishments of the volunteer work, it’s important to tell the full story. Recent cries that Chrome and Safari support MathML can give the wrong impression of the potential for MathML when users encounter bad rendering of basic constructs. The combination of native MathML support, font support, and authoring tools, [ see this more recent post for more detail] makes mathematical content one of the most complex situations for web typesetting.

There have been some valiant attempts to fix this lack of equation support with third-party math typesetting code (JavaScript), notably Asciimath by Peter Jipsen with its human-readable syntax and image fallbacks, jqmath by Dave Barton (same as above), and MathQuill.

However, by far the most comprehensive solution is the MathJax libraries (JavaScript) released as Open Source. While MathJax is developed by a small team (including Frédéric Wang above) they are bigger than most projects, with a growing community and sponsors. MathJax renders beautiful equations as HTML-CSS (using web fonts) or as SVG. The markup used can be either MathML, Asciimath or TeX. That means authors can write (ugly) markup like this:

J\alpha(x) = \sum\limits{m=0}^\infty \frac{(-1)^m}{m! , \Gamma(m + \alpha + 1)}{\left({\frac{x}{2}}\right)}^{2 m + \alpha}

into an HTML page and it will be rendered into a lovely looking scalable, copy-and-paste-able equation. You can see it in action here. 

So why is this really interesting to publishing?

Well… while EPUB3 specifications support MathML, this has not made it very far into e-reader devices. However, MathJax is being utilised in e-reader software that has JavaScript support. Since many ebook readers are built upon Webkit (notably Android and iOS apps, including iBooks) this strategy can work reasonably effectively. Image rendering of equations in ebook format is another strategy, and possibly the only guaranteed strategy at present, however, you can’t copy, edit, annotate or scale the equations and you cannot expect proper accessibility with images.

The only real solution is full equation support in all browsers and e-readers either through native MathML support or through the inclusion of libraries like MathJax. We can’t do anything to help the proprietary reader developments get this functionality other than by lobbying them to support EPUB3 (a worthwhile effort) but since more and more reading devices are using the Open Source WebKit, we can influence that directly.

The publishing industry should really be asking itself why it is leaving such an important issue to under-resourced volunteers and small organisations like MathJax to solve. Are there no large publishers who need equation support in their electronic books that could step forward and put some money on the table to assist WebKit support of equations? Couldn’t more publishers be as enlightened as Springer and support the development of MathJax? You don’t even have to be a large publisher to help – any coding or financial support would be extremely useful.

It does seem that this is a case of an important technological issue central to the development of the publishing industry ‘being left to others.’ I have the impression that it is because the industry as a whole doesn’t actually understand what technologies are at the centre of their business. Bold statement as it is, I just don’t see how such important developments could go otherwise untouched by publishers. It could all be helped enormously with relatively small amounts of cash. Hire a coder and dedicate them to assist these developments. Contact Dave Barton or MathJax and ask them how your publishing company can help move this along and back that offer up with cash or coding time. It’s actually that simple.

Many thanks to Peter Krautzberger for fact checking and technical clarifications.

Published on O’Reilly, 26 November 2012 http://toc.oreilly.com/2012/11/math-typesetting.html

 

InDesign vs. CSS

The explosion in web typesetting has been largely unnoticed by everyone except the typography geeks. One of the first posts that raised my awareness of this phenomenon was From Print to Web: Creating Print-Quality Typography in the Browser by Joshua Gross. It is a great article which is almost a year old yet still needs to be read by those that haven’t come across it. Apart from pointing to some very good JavaScript typesetting libraries, Joshua does a quick comparison of InDesign features vs. what is available in CSS and JS libs (at the time of writing).

It’s a very quick run down and shows just how close things are getting. In addition, Joshua points to strategies for working with baselines using grids formulated by JavaScript and CSS. Joshua focuses on Hugrid but also worth mentioning is the JMetronome library and BaselineCSS. These approaches are getting increasingly sophisticated and, of course, they are all Open Source.

It brings to our attention that rendering engines utilising HTML as a base file format are ready to cash in on some pretty interesting developments. However, it also highlights how rendering engines that support only CSS (such as the proprietary PrinceXML) are going to lose out in the medium and long term since they lack JavaScript support. JavaScript, as I mentioned before, is the lingua franca of typesetting. JS libs enable us to augment, improve, and innovate on top of what is available directly through the browser. Any typesetting engine without JavaScript support is simply going to lose out in the long run. Any engine that ignores JavaScript and/or is proprietary, loses out doubly so since it is essentially existing on a technical island and cannot take advantage of the huge innovations happening in this field which are available to everyone else.

Once again, this points the way for the browser as typesetting engine; HTML as the base file format for web, print, and ebook production; and CSS and Javascript as the dynamic duo lingua franca of typesetting. All that means Open Source and Open Standards are gravitating further and faster towards the core of the print and publishing industries. If you didn’t think Open Source is a serious proposition it might be a good idea to call time-out, get some JS and CSS wizards in, and have a heart-to-heart talk about the direction the industry is heading in.

Correction: The latest release of PrinceXML has limited beta Javascript support. Thanks to Michael Day for pointing this out.

Originally published on O’Reilly, 19 Nov 2012 http://toc.oreilly.com/2012/11/indesign-vs-css.html