Formless Content

There is a lot of interesting stuff happening to the page right now. 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 in an article he wrote for Book: A Futurist’s Manifesto : formless content and definite content. (This was 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.  It’s a really well-argued position and one that is in tension to the current design methodologies of book designers today. Book designers are taught to design contained space – books are a very definite context in which they work. Desktop publishing applications are built to meet this methodology and are designed to enable pixel-perfect manipulation within a strictly contained space. If the designed digital article does not exactly match the printed artifact then something went wrong. A lot of energy has gone into this process.

Formless design principles are uneasy to consider for traditional book designers – how can you design for a page that does not yet know its container? It is literally like asking a book designer to design a book without telling them the page dimensions.

As it happens, web designers have been thinking about page design too. For a long time now web designers have made pages that embrace differing containers – they have been working, at least in part, with formless content.

What is missing, however, are good tools for taking the web designer’s aptitude for working with formless content to enable them to produce books. A good tool set for designing formless books should not work with constrained page dimensions. It is tempting, for example, to think of working with a design environment with constrained page-like artifacts – think of Google Docs as an example. Could something like Google Docs with its digital, scrollable, yet fixed page size be a good starting point for some kind of design tool? Place layout and typographical controls on top of Google Docs and do we have the next book design environment?

I don’t think so, because it is exactly the kind of idea that is blinded by the media of the past and cannot accept that things have changed. We must design tools that enable book design for formless content. What those tools look like is a very interesting question and one which Aleksandar Erkalovic (Booktype lead dev) and I have been working on with students (Hannes Bernard and Aiwen Yin) from the Sandberg Institute in Amsterdam.

Our argument is that the design of formless content is really a partially constrained environment, since elements within the page have some kind of relationship to each other. This is an argument web designers are familiar with when using design tools like position:relative – a rule which sets a relative position relationships between objects. Relationships can be constrained or shaped by rules which will be at least partially preserved when displayed in different contexts. The meaning is preserved by the relationship between the elements, more than by their relationship to the constraints of a page.

This is the reasoning behind Cascading Style Sheets – the design language of the web. It is rule-based design and even partly conditional. It is possible to express conditions in CSS even though it is not done that often. A CSS rule such as :

h2+p {page-break-inside:avoid;}

is a conditional CSS rule which will apply the style only when a paragraph follows heading 2 (h2) element.

Web designers know this kind of thinking, but book designers are going to have to let go of pixel-perfect design and enjoy thinking and designing this way. It seems like a simple idea but it takes a lot to overcome legacy. The legacy is so strong that designers are pretending the issue does not exist. There are tools now appearing and sold as design environments for iPad books. They give near 1:1 page relationship between the design environment and the final result. However, we all know what happens to digital hardware – it changes. What is true now will not be true 5 years from now, so the idea that an ebook is a contained space is very appealing to traditional book designers but it will be a short-lived myth. iPads might keep the same form for 5 years, they might not but they certainly will not keep it over the next 5-10 years. Better to learn how to design in the new way than be fooled into thinking you can bring all the old methods to a new medium and get away with it for long.

What we are working on now, is a way to meet the designers half way – a visual design environment which is used for rule and condition based design. Can book designers accept a tool like like this? Will web designers just step in and take the role of book designers? Its an interesting question and one we hope to have some more experience with soon.

Book Sprint Textbooks…anyone?

My role as ‘an educator’ revolves around group processes – namely, Book Sprints. Essentially I facilitate groups of 5-10 people working together in one room over an intensive 3-5 days to produce a book. Zero to book in 5 days (or less). This process is known as a Book Sprint and although it is an uncommon practice, most people who ask for and participate in a Sprint see it as a Book Production methodology. However, I would argue that, in all circumstances, the collaborators walk away having learned a great deal about the subject they have just created a book about.

I also believe that this process can be used by students to write their own textbooks, learning what they write and passing the free textbook onto the next year’s students to improve. I am eagerly awaiting the first enlightened institution that would take this on, and I am sure they would be positively surprised by the results – both in the quality of books produced and by what the students learn in terms of content and collaboration.

Book Sprints utilise collaborative environments. The only Book Sprint (1) I know of before we did them (2) used word processing documents – passing these around via email between collaborators – and a wiki for collecting the articles. Part way through the process, they gathered in person to develop the outline in a one week intensive ‘Outline Sprint’ and then proceeded to collaborate via email and a wiki over a period of 4-6 months. After the material was complete, the group passed the documents through several editing stages. The process cut the standard industry timeline down by about 30-50%. Zero to book in 4-6 months is still pretty good in the publishing industry.

However, for FLOSS Manuals, 4-6 months was too long. We wanted to do it in 5 days and so we needed a quicker methodology and a better tool set. Wikis might come to your mind immediately as they did to us. However, we had already realised that wikis were not built with the right paradigm. Books are very structured and wikis are not. That is the essence of it – I don’t want to get into ‘future of the book’ discussions. Books can be many things, so I am talking here about what ‘most’ people mean by a book. A one piece cover, several hundred pages, table of contents, structured readable and comprehensive content, self-contained with very few references to other parts of the document, and careful use of outside references instead of a welter of back-and-forth hyperlinks. We built a system that could produce this kind of book – paper books – in a Book Sprint environment. Zero to book in 5 days – that leaves about 3 minutes at the end to produce book-formatted PDF ready to upload to a PoD service or send to the local printer. That is what we needed, and wikis don’t enable you to do that. So we hand rolled our own. The first generation was built on TWiki and we pushed it to its outer limits with extensions built by Aleksandar Erkalovic and a PDF renderer built by Luka Frelih. Now we are onto the second generation – Booki (a BOOK-wikI if you will). It does the same job as the first tool set, but does it better – it’s easier to use, more flexible, and it supports a greater number of possible output formats and types.

While Booki does a lot, and it’s hard to imagine a Book Sprint without it, there are limits to working digitally in a Book Sprint. Certainly, we also experience the highs of surprising networked collaboration. One Sprint (‘Introduction to the Command Line’) was written almost entirely remotely and written in 2 days (Mako Hill, FSF Board member and renowned hacker said it was the best book on its topic). However, there are also limits to digital media and digital networks. I believe that there is less knowledge passed through digital media communication channels when collaborating. I firmly believe this – other wise we would have all of our Book Sprints remote – it would cut down on logistics and costs. However text-based chat does not convey enough information, VOIP is terrible for more than 2 people at a time and even then I wonder at its real usefulness in intensive collaboration, and email is just too slow and the ‘unthreaded’ nature of email will soon drive you crazy in this kind of environment. Microblogging is as good as IRC in this instance – ie. barely useful. Sneaker networks are not only faster but more fluid and they enable better-shared understandings, quicker.

In addition, I find it is often good to push people out of the screen and into the book. Since we work fast in Sprints we sometimes realise we need to clean up structural issues. This often occurs when 2 or more people are working on content that needs to fit together – and it doesn’t. Often we print out the necessary chapters, sit on the floor, and (gasp) cut-and-paste the chapters into each other until they work. Same process as a digital text editor, just with a physical tool set – the result is that it gets better results quicker.

The end result of a Book Sprint is a book. That’s a great thing to have. However there is also a mandate to take care of, and content to take care of. How do you enable this content to live? Books do not live by licenses alone – they need help. They need the original collaborators to find the avenues to keep the content alive. One strategy is to maintain this content themselves although, despite good will, this seldom continues beyond some initial edits immediately after the Sprint ends. The original collaborators need to pass on the mandate to others and this is critical for the life of the book. As such I discourage the use of terms like ‘authors’ as this denotes legacies of ownership and does not encourage new contributors to take the mandate to improve the book. Instead, the strategies revolve around keeping the participation threshold low (minimising social filters, using open language, making Booki simpler and simpler to use) and welcoming in new contributions. We also welcome forking books. Take a book – make it your own whichever way you feel is best.

However occasionally Sprinters, caught up in the fervor of intensive production, often get worried about misappropriation or unethical use and erect barriers that do nothing to help and a lot to hurt. They ask themselves questions like ‘What if someone takes the content and makes money? What if contributors spam the book? What if someone changes the tone of the book? Could contributions ruin it?’ This is the ethical quandry put at the foot of freedom largely by the fears and protective necessities of the proprietary publishing industry, We all carry this a little bit and my response is always ‘let it go’. Let the content be free and you will be happily surprised by the results. The irony is that once sprinters are convinced of this idea they are left ‘fighting’ the default – standard attitudes towards publishing and authorship means it’s hard work to get people to uptake the freedoms of free content. Book Sprint collaborators (and free content developers in general) often need to put a lot of energy into reaching out to others to get them to take ownership of the material and make changes, but it can be done with the right approach. I am hoping soon we see will the integration of Book Sprints into curriculum to create and improve textbooks as another way to explicitly pass on the mandate to change,and I’m very much looking forward to seeing this strategy develop…

Notes:

(1) The idea of a Book Sprint as outlined in the article by Marco Zennaro et al was the brainchild of Tomas Krag

(2) Marco Zennaro, Enrique Canessa, Carlo Fonda, Martin Belcher, Rob Flickenger, “Book Sprint” in The International Journal of the Book (Melbourne, Australia, Common Ground Publishing, 2006) Vol 2 Number 4.

written by Adam Hyde, founder of FLOSS Manuals.