## 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.
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.

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

## The New New Typography

In the 1920s and 1930s in Europe, there was a movement known as the New Typography. It was a movement that rejected traditional type set in symmetrical columns and instead treated the printer’s block as a blank canvas to be explored in its entirety. The calling card of the movement was type arranged in harmonious and beautiful asymmetric compositions. In the past two years, there has been another slow-breaking wave of typographical exploration. The printer’s block is now HTML, and CSS and JavaScript are fast becoming the new tools of the typographer – not just for the web but for ebooks and for print, and not just for printed books, but for all printed material.

### Browser as typesetting machine

The change of the book’s basic carrier medium from paper to HTML (the stuff web pages are made of) has meant many changes to what we might still call typesetting. Kindle and other e-ink devices actually move ink on a display screen to form words, sentences and paragraphs. The moveable type of Gutenberg’s time has become real time – 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 to aid readability. Moving type in ‘read time’ marks a significant paradigm shift from moveable type systems, including digital moveable type manipulated by desktop publishing software, to flowable typesetting. We are leaving behind moveable type for flowable type.

The engine for reflowing a page in real time is something we have seen before. It is the job of the browser. And, since ebooks are webpages, browsers have come to play a central role in digital e-readers. In the case of the iPad, the iBook reader is actually a fully featured browser engine, Webkit, the very same technology behind the Chrome and Safari browsers. Browsers are the typesetting machines for ebooks.

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 becoming the typesetting engine for print. CSS and Javascript are the print design tools of our immediate future and the vast majority of innovations in this area are based on Open Source and Open Standards.

### The power of CSS and JavaScript

CSS is the set of rules followed by the browser in placing type, images and other elements on a webpage and styling those elements. Typical rules define where an image is placed in relationship to text, the font used, the font size, background colour of the page, and the maximum width of an image, and so on. While designed originally for the exclusive application to webpages, the CSS Working Group responsible for overseeing the development and direction of CSS, anticipated the intersection of the book and the web some time ago. In the latest drafts of the CSS standards, new additions are almost entirely focused on typography and page control. As a consequence, this area is starting to blossom. In particular, the CSS Generated Content for Paged Media Module specification is astonishing for its reframing of flowable text into a fixed page. Cross reference and footnote controls, not needed on the web, are among many book-like structure controls being addressed by CSS. Table of contents creation, figure annotations, page references, page numbers, margin controls, page size, and more, are all included. The definition of these rules precedes their adoption in browsers, however they are being included in browser engines, notably Webkit, at a very fast pace.

Coincidently, there has recently been an explosion in interest in improving browser typography primarily for the better design of websites. Although these advances have not been made with book production in mind, these advances can be inherited by the browser for typesetting both electronic and paper books. Of interest is the sharp rise in the websites offering tips on CSS typography, an associated explosion of the available web fonts, and some very interesting JavaScript libraries.

JavaScript is the programming language of the web and it can be used to create dynamic content or manipulate objects on a webpage in ways CSS cannot, or cannot yet. Of particular interest is kerning.js, inspired by the previously available lettering.js library. These code libraries allow you to change each letter individually in a paragraph or heading and control the spacing between letters (called ‘kerning’). Kerning is essential for printed books, and ebooks, but missing from browsers for a very long time. colorfont.js is another JavaScript library which enables dual toned glyphs, and the amazing typeset.js emulates the sophisticated TeX line spacing algorithms developed by Donald Knuth.

Even the layout of musical notation and guitar tablature (which were never effectively mechanised with Gutenberg’s moveable type and were handwritten into books for many decades after the printing press came into the world) have come into focus with another JavaScript library, VexFlow. With libraries like these, it is apparent that JavaScript, the programming language of the browser, has a future with typography, and that JavaScript is fast becoming the lingua franca for all typesetting.

There is a lot of fuel in these developments and, interestingly, most of it is coming from outside the traditional print and publishing industry. It could be said that these industries, built upon the printing press, have lost sight of their very foundation. Instead, the IT industry is taking hold on a very deep level.

Apple and Google are behind the development of Webkit – the rendering engine behind iBooks, Safari and Chrome – which makes a lot of these typesetting innovations possible. Apple utilises these typographical features not just in its browser, but in the development of its iBook reader – the ebook reader on iPad which is itself based on Webkit. Google also fuels these innovations for many reasons other than the browser – better typography in Google Docs being one of them. We can expect the momentum to build and it is possible to say with some confidence that the browser, together with CSS and JavaScript, is to become the most important typesetting engine of our time as it is fast becoming the typesetting mechanism for digital and paper books and the web.

### Ease and efficiencies

The implications of this succession by the browser are enormous and possibly not yet fully realised. At publishing industry conferences and other book-focused forums, the attention has largely been on the ebook’s affect on distribution, and on e-readers and the demise of the so-called bricks-and-mortar book stores. The biggest effects, however, are elsewhere, ‘bubbling under’ in the recasting of the browser as a typesetting engine, and with it the slow realisation that the technical ecosystem surrounding book production can be replaced by tools for producing webpages.

We are beginning to turn our attention to the tools for making webpages, to make books, and this, it turns out, is much easier than with desktop word processing and publishing software. Additionally due to recent developments, all of this, as it turns out, can also be used to design print (more on in-browser print production in a future post). Book production once again is becoming faster and cheaper and is on its way to achieving another leap of magical efficiency.

The future of book production right now is exploding all around us. These pieces of the puzzle are coming together and coming together fast. We can almost watch in real time as the necessary mechanics get filled in by new release candidates of major browsers and searching online for ‘out of the blue’ small innovations such as JavaScript typography controls. It is getting easier and easier to make books in the browser and consequently there has never been a time when it has been this easy to make books of all kinds.

Ease of production is where it all started for Gutenberg and it is starting again for us. If you believe Gutenberg’s efficiencies changed society forever, then what affect will the new-new typesetting engines have? It’s a giddy question. Making books in the browser will have an enormous impact on society as a whole, and just like the printing press, it will not revolutionise the old order, but create a new one.

Originally published on O’Reilly website, 18 Oct 2012 http://toc.oreilly.com/2012/10/the-new-new-typography.html

## What’s wrong with WYSIWYG

The current WYSIWYG paradigm has been inadequate for a long time and we need to update and replace it. Using a WYSIWYG editor is pokey and horrible. Producing text this way feels like trying to write a letter while it’s still in the envelope. These kinds of editors are not an extension of yourself, they are cumbersome hindrances 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 the rendering of HTML. However, 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.

The new generation of HTML5 editors have taken a large step forward, not because they integrate HTML5, as such, but because they act on the elements in the page directly. 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, we can have the same content represented as a multi-column editing environment (useful for newspaper layout), as a ‘google docs type’ clean editing interface (see demo below), a semantic layout 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 Annotate It or typographical libraries such as lettering.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 applying them dynamically using the editor. This is in effect turns the editor into a design interface, which will open the path for in-browser design of various media.

Lastly, WYSIWYG editors, while marvellous in their day, have had their day. They feel too pokey and ‘old school’. Largely due to the success of Google Docs users no longer want to poke around in a tiny WYSIWYG editor. They want large clean interfaces for content production.

The above screen shot is taken from the semi-functional demo at http://data.flossmanuals.net/mercury/index.html (all demos work only in Chrome for now).

In brief summary, essential problems of the current WYSIWYG world are:

1. it is not easily possible to enable JavaScript libraries to act upon the objects in the editor
2. representing the content in context is difficult
3. the content is not part of a page so additional functionality like (non- intrusive) annotations cannot be added to content
4. dynamic rendering of content retrieved from the server is hard to achieve
5. dynamic creation of content is hard to achieve
6. inclusion of nested JavaScripts is hard to achieve
7. they look ‘pokey’ and old school
8. synchronous editing is possible but hard to achieve
9. users want to see the content they are making in a much cleaner and clearer ‘fullpage’ way
10. some users want semantic views
11. some users want design views
12. all users must be able to edit the content (designers, editors, content creators, etc) and do what they need from the same view

Online book production has special needs such as the ability to display the content as it might appear in the output, annotations, draft view etc.

## The Ideal Editor

A short list of starting list of features for a new editor might look something like this:

1. harmonise edit, draft, proof, design features into one view
2. live chat
3. short messages which also support ostatus API (which is built on Twitter spec)
4. send to renderers from within the editor
5. ability to switch on and off third party JS libs
6. apply CSS templates to content
7. create CSS snippets
9. share snippets and templates
10. dynamic snippet rendering
11. live template swapping including semantic layout and ‘output’ view
12. synchronous editing
13. per ‘chunk’ notes

Many of these features are relatively easy to achieve, others will take some careful thought and planning.

## The Dream features

1. backend hook up to git
2. versioning of content especially for different outputs (A4 vs A5 pages, html, epub etc)

## Where to start

We need to develop with an editor in the hand. The current batch of html editors does pretty well but we need to choose one which has a good support community and a good feature set. Currently, there is just one option – Mercury editor. It currently has a new home page (less than 2 weeks old), and a thriving community.

Some demos if what could be done with Mercury in a book production environment:

http://data.flossmanuals.net/mercury/index_semantics.html

http://data.flossmanuals.net/mercury/index.html

http://data.flossmanuals.net/mercury/index_hyphen.html

http://data.flossmanuals.net/mercury/index_prettify.html

If you want some more convincing,  try this math editor using Mercury and MathJax…  http://data.flossmanuals.net/mercury/index_math.html
Try typing $f(x)$ into the window to see how it works

Or try this to see how AnnotateIt works in this environment.

## Annotate Me

Annotation is an interesting world. It has survived the many changes in book technologies until, interestingly enough, the net. It’s not that we have never needed it, it’s that we haven’t been able to do a good job of it. There have been some good attempts – CommentPress was one by Bob Stein and the Future of the Book Institute. Comment Press was useful, I installed it myself and used it – it was built on top of WordPress. But Bob and crew learned their lessons and improved the idea with the yet-to-be released Social Book.

On top of that has been Purple Numbers (by Douglas Engelbart – you know! the guy that invented the mouse!) , and the code known as Marginalia, and there have been three of four attempts using Jquery to get this right. While Marginalia did get included into Moodle, which is pretty cool, it didn’t really take off and none of the other attempts got anywhere.

I think that might be about to change with a very nice relatively new project called AnnotateIt. It is built on top of Jquery and is built by the crew behind the Open Knowledge Foundation, which in turn has been supported extensively by the Shuttleworth Foundation.

It’s good stuff. Very simple to use as either a free and centralised service, or you can establish your own annotation server. I am trialling it at the moment wíth FLOSS Manuals. You can create an account at http://annotateit.org/

And then try it on FLOSS Manuals. For example:

http://booki.flossmanuals.net/a-webpage-is-a-book/_draft/

Looking forward to trying it out. Any feedback on both the book and the annotation tool is very much welcomed.

## Re-use

Xerography—every man’s brainpicker—heralds the times of instant publishing. Anybody can now become both author and publisher. Take any books on any subject and custom-make your own book by simply xeroxing a chapter from this one, a chapter from that one—instant steal!"   —Marshall McLuhan, The Medium is the MESSAGE

This vision from McLuhan is of an analogue future. A future of analogue media and analogue networks. It would take digital media to realize his vision. Webpages being the networked document of our time enable the kind of instant steal that McLuhan foresaw. With free content licenses and simple tools for importing content from other books or other libraries, we can borrow enormous amounts of rich information to help us build the books we want.

In a recent Book Sprint on Basic Internet Security, 9 chapters from 3 existing manuals were reused – that was 15,000 words that we did not have to create afresh. Of course the material needed some work to fit the new context, but it was still a substantial time saver and extended the scope of the book well beyond what we could have produced in the time we had.

This was really quite amazing for me to see. The idea of reusing content was envisioned from the moment FLOSS Manuals was built, but, 3 years later, this was the first real case of substantial re-use. It takes time to build up the materials to make sense of re-use in this way, however, after waiting 3 years, I took a great deal of pleasure in seeing it happen for the first time.

Re-use is not just a time saver, however, there are many other exciting possibilities enabled by re-use. Re-use is also about translation and recontextualisation. Re-use is about updating books and improving them. Re-use is about taking content and making it work in your language. Re-use is about enabling anyone to get your content to their audience and in the form they need it. Re-use is also about allowing you to re-use your own work, since often publishers hold the copyright and do not permit authors to update, re-use, or improve their own work.

Re-use helps you make the books you want to make faster and get them to the people you want to have them in a form that suits them best.

Re-use, despite its attractive opportunities, is an issue that existing publishing models are going to find very hard to work with. This is because full engagement with re-use leads to the federation of content and the inevitable possibility that anyone can publish any book you have made. Taking a book, not changing a word, marketing it and selling it, is re-use. It is going to be difficult for publishers to agree to this consequence while tapping into the many opportunities for new business models around this idea. But that is not our problem. We want books to be freely re-used and we should find the most open channels to do that.

The core of re-use is primarily about extending the usefulness and life of a book.

One of the differences between a book and a newspaper, is that we expect longevity from a book1. We expect a book to have value beyond the date printed at the top of the page.

The web offers enormous opportunity for the life of a book to be increased further than it is now. The Open Educational Resources (OER) movement is alive to this idea. They imagine you could take a mathematics text book and update it for the following year’s curriculum, or combine it with another book to better suit your students’ needs. Or correct it if you found a mistake, or translate it. Major advantages in all sectors, not just education, can be attained by keeping books alive.

Books currently have too long a life as a static object. They have become too static as a result of Gutenberg’s invention. ‘Static-ness’ is now a part of a book’s genetics. ‘Readers’ find it even hard to pick up a pen and write notes in the margin of books. Margin notes are frowned upon by libraries. We have forgotten that notes like this (‘marginalia’) were once very common. When paper was hard to come by, the margin notes were often where books were written.

So books did not always have a static genetic code. They once were places for lively discourse and for book production itself.

Interestingly, there is a kind of slow historical regression taking place because of digitally-networked media. There are a few projects (notably commentpress2and the yet to be released Social Book by Bob Stein, and some ebook readers) that enable types of margin notes in digital books. In the case of Commentpress these notes are the point of the book – a place to start discourse (almost literally) around the book.

However, we still cannot seem to embrace changing the book itself.  It is one thing to allow ourselves to leave margin notes in this new era of digital documents, since we know the source will not be affected. We can easily spray comments around the book as the book itself stays intact. Can’t we allow ourselves to change the book too?

Books have always been changed over time. Ben Fry did a very nice visualisation3 of the changes Darwin made to his Origin of the Species over 6 editions. It is a nice work showing substantial changes, including the addition of an entire new section in the last edition. The Origin of Species was an evolving thesis and the book was kept alive over the period of Darwin’s life. The book’s ’life’ ended with Darwin’s.

But why must a book die with the author? Why can’t anyone contribute to a book to keep it alive, even during the life of its author? We feel somehow that this is breaking some kind of moral law (as well as copyright law). Forgetting copyright for now – why not improve the original? Why can’t we take a book, any book, and improve it, perhaps even while the author is still alive? Why is that idea so difficult for us to engage with?

Leaving copyright licensing aside for the moment  – one part of the puzzle involves the overly rarefied respect for the authoritative version. The version born from the author. We (you or I) are not that author and so we cannot know the author’s intent with all its nuances. We should not meddle with a work because we would be breaking our unspoken contract to preserve the author’s intent. It would not be considered an appropriate thing to do. We do not have the authority to do it. The authority is inherent in the author alone – so much so, that the role of the author to the book is analogue to the role of ‘god’ to its creation. The author is the creator.

Sound like I am overstating the cultural value of the author? In William Golding’s Lord of the Flies, the children use Piggy’s glasses as a magnifying glass to start a fire. However Piggy was short-sighted and hence starting fires with his glasses would be impossible as they are concave, and concave lenses disperse light4 . You cannot start a fire with concave lenses. Would we allow anyone to alter the book to correct this rather trivial fact? No. No, because the book is Golding’s world and in Golding’s world concave lenses start fires. Golding is the creator. He has the authority to change his creation and we do not.

I think that is a very deeply ingrained principle.

For this reason, many recoil in horror with the prospect of changing great works of art. We are in some way tampering with the mind of the creator – a kind of god. However, we must remember that if we change a book, we change nothing in the original. Books, unlike paintings, are not one-of-a-kind pieces. That is precisely why the age of Gutenberg has such an impact – books could be duplicated. So when we change a book (I’m not talking about historical paper artifacts, just the abstracted contents) we don’t destroy anything, and this is particularly true in the digital age. In fact, the digital age gives us more tools to take care of the provenance of a work. Hence we can easily have Pride and Prejudice by Jane Austen and Pride and Prejudice and Zombies by Jane Austin and Sethe Grahame-Smith5 .

How to we develop a culture where it is OK to change a book? Free Licenses are meant to change that but in my experience it is still difficult to get people to take hold of explicit free license clauses that enable derivative works and improve a work. They feel they lack the mandate to change. Many people still ask if they can improve a free/open book work even though the mandate to change a work is loudly passed on and articulated by ‘the creators’ to anyone.

In fact, it is difficult to pass on the mandate to change. It doesn’t help that large projects like Wikipedia are working against this mandate. Wikis and Wikipedia have managed to introduce ideas of participative knowledge creation, but as Lawerence Liang6  has argued, Wikipedia is possibly trying to establish itself as an authoritative knowledge base which also has the effect of revoking the mandate to chang,e as has been experienced by many new contributors that find their edits reversed.

I think we will leave this all behind in time, but it’s going to be a long time.

All books can be improved – even the most sacrosanct literary works. However we live with the notion of the authority of the creator. The only thing that can change that, is to take the rights afforded to us by free licenses and experience and value the possibilities open to us if we act differently.

We need living books, and under copyright we have to fight very hard to keep them alive. The first step it to take someone else’s book and improve it.

1. Daniel James^
2. http://www.futureofthebook.org/commentpress/ ^
3. http://benfry.com/traces/^
4. http://homepage.mac.com/cbakken/obookshelf/vision.html^
5. http://www.quirkbooks.com/book/pride-and-prejudice-and-zombies^
6. http://vimeo.com/10750350^

Booki provides an RSS feed for every book. This means you can follow a book and see the edits made. Each RSS feed is linked from the info page. For example, the book about OpenMRS has an info page here  and the RSS is linked from the bottom.

A few weeks ago, we asked for some help creating a visualisation using this source. Pierre Commenge responded and started developing a Processing visualisation of the RSS feed. Processing is a free software used a lot for creating visualisations.

Pierre has a prototype available that runs in a java applet. So this look pretty cool. The live version enables you to play a timeline and see the development of the book over the period of 1 day.

This not only looks cool but it enables you to see how a book is being made. This is extremely interesting – imagine if we had all the data about how every book has been made up until now… it would tell us a lot of things about the book production process and the differences between different models etc… It’s a very exciting idea and we hope to be able to explode this idea in the following weeks and months in our experiments. Many thanks to Pierre for getting this underway.

## Remix vs Shuffle

One of the key memes in free culture has been the remix, freely licensed content combined to make something new. Remixing of books is of obvious interest and there have been many explorations of this in various forms including the Rice University project Connexions. FLOSS Manuals has had the ability to take existing manuals about free software and remix it since 2008. Remixing of books is of obvious interest and there have been many explorations of this in various forms including the Rice University project Connexions.

FLOSS Manuals has had the ability to take existing manuals about free software and remix it since 2008. It’s easy to use this mechanism to add a chapter or chapters of a manual with other chapters from other manuals. The output is templated HTML or customised PDF. Although the remix feature (very easy to use with a nice drag and drop process) always gets very positive responses when demonstrated, however, it does not get used very much.

After some years thinking about this lack of use, I have come to the understanding the ‘remix’ as such has only a limited use when it comes to constructing books from multiple sources. A remix of a book in this fashion is not a good remix as we might understand it. DJs make good mixes out of several tracks but they have various tempo, tone, and volume controls to integrate the sources. A book remixed by the (outmoded) remixing tool we built for FLOSS Manuals is not like a music remix but more like playing back selected tracks using shuffle. The chapters are not integrated to flow well into each other, they are instead compiled into some kind of anthology.

The difference is not subtle and it’s easy to understand the problem when you look at the obvious popular example of remixes in DJ culture. A DJ takes multiple sources – some complete – some snippets – and works them into a continuous whole. For the DJ, remixing is part-curatorial process and part-production. The curatorial process is the choosing of the works and considering where and when the selected pieces will fit into the whole. The production process is changing the tone, speed, and colour of the sound and making it all work together. Without the production component, it’s not a remix at all – it’s just a shuffle of sound snippets.

Text requires the same kind of shaping. If you take a chapter from one book and then put it next to another chapter from another book, you do not have a book – you have two adjacent chapters. You need to work to make them fit together. Working material like this is not just a matter of cross-fading from one to the other by smoothing out the requisite intros and outros (although this makes a big difference in itself), but there are other aspects to consider – tone, tempo, texture, language used, point of view, voice etc as well as some more mundane mechanical issues. What, for example, do you do with a chapter that makes reference to other chapters in the book it originated from? You need to change these references and other mechanics as well as take care of the more tonal components of the text.

This is why remixing in itself is not that interesting and also another argument why some free licenses should be banned for free book production. An ND license (non-derivative) renders a ’free’ work useless for combining with other works. You can separate it from its original corpus but you cannot make it fit easily within a new one. You have no licensed right even to change the mechanical components. You cannot create chapters that will smoothly exit one book and enter another. You actually have to produce the mixed material to make it all work together – there is not really much point to trying to avoid this issue.

As a consequence of these experiences, at FLOSS Manuals we designed Bookspark to enable importing of chapters from one book to the editable environment of another book and we ditched the old remix approach. This means you can import chapters from other books and then edit the chapters to make them fit the context. That is the only sensible way we can work with this kind of re-use/remix.

See http://cnx.org/ to view and share free educational material in small modules that can be organised as courses, books, reports or other academic assignments.

## 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.

## Federated Publishing

Federated publishing takes all of the concepts I have dealt with so far – ease of online book production, collaboration, reuse – and applies them to a new networked model of publishing.

In the social software circles, there is a movement that advocates a Federated Social Web. The main advocates are ostatus and the free software micro-blogging platform status.net. The Federated Social Web is a vision of inter-operable social network platforms enabling “people on different social networks connect with each other as friends and colleagues,” says Evan Prodromou.

Federation of this kind is not new to the web, and there are many online services which work like this. Email is a federated system – it doesn’t matter where you have your email account, you can still communicate with other people who have email accounts elsewhere. However, federation of this kind is not the architecture of choice for monopolistic social network enterprises like Facebook. Facebook will not enable you to install your own copy of Facebook for your business or school, nor does it enable communication between users on Facebook and users on other social networks.

What we need is a federated architecture for online book production and publishing. Anyone should be able to set up their own online book production/publishing service and share books with other book production/publishing networks, enabling anyone to reuse any book, anywhere.

Federated publishing supports traditional, established book production techniques while fueling radically different approaches. To achieve healthy federated publishing on the web, four key elements need to be built up:

• Fee content
• Federated book production platforms
• People participating
• Suitable economic models

There is currently no prolific exploration of this model. Federated publishing is currently only illustrated, I believe, by FLOSS Manuals. In FLOSS Manuals, anyone can clone or migrate a book to another platform, reuse and change the book without permission, and publish it wherever they like. That is federated publishing.

Federated publishing was anticipated by this astonishing passage from Marshall McLuhan in Predicting Communication via the Internet (1966), in an interview with Robert Fulford, 8 May 1966, on CBC’s This Hour Has Seven Days):

“Instead of going out and buying a packaged book of which there have been five thousand copies printed, you will go to the telephone, describe your interests, your needs, your problems, and they at once xerox with the help of computers from libraries all over the world, all the latest material for you personally, not as something to be put out on a bookshelf. They send you the package as a direct personal service. This is where we’re heading under electronic conditions. Products increasingly are becoming services.”

This passage is usually quoted as a prophecy of the Internet to come. However it is not a vision of the Internet, rather a vision of the book-as-service through federated publishing – an open network of book production platforms connecting people and books.

In contrast, proprietary publishing dominates the search for new distribution formats and economic models, reward systems for authors and others, and fuels an unwillingness to make content interoperable on a technical, legal, or social cultural level. It was this context McLuhan imagined we were escaping.

Through collaborative publishing projects, we have found that not only is federated publishing highly productive, exciting, and fun but there are also economies evolving around it – organisations and ‘crowds’ pay to have books produced this way, and they pay you to help them to do it.

## 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
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:

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.