Abstract

A multidisciplinary textbook faces the challenge of satisfying the need for breadth, to represent all the disciplines that contribute to it, without compromising the need for depth, to treat each contributing discipline in a substantive way. We met this challenge in a text called “The Discipline of Organizing” with several innovations in book design. The key idea was to write the book as a “core” text with hundreds of supplemental endnotes tagged by discipline, effectively creating a family of related texts suitable for different courses and perspectives. This book architecture lends itself to implementation in ebook formats, and it also implies a clear path for evolving the book and ebooks over time. In this session the lead author and editor of the book describes the processes and principles needed to create, deploy, and maintain it.

Download Slides (PPT)

Transcription

Thank you. I'm Bob Glushko. I'm a professor at the Information School at the University of California across the bridge. I've spent most of my career in industry, starting at Bell Labs about 30 years ago inventing online publishing and document management. I've spent a lot of time in Silicon Valley helping companies become online publishers, and I retired from all that. Then, I discovered about a year ago that none of the problems had been solved yet, so we have to solve them again, with collaborative authoring and maintenance of multi-disciplinary textbooks. This one.

So, my talk today, I'm going to talk about the challenges that emerged in this project to build a multi-disciplinary textbook. In particular, the way it caused us to re-think book design, e-book design, authoring, and the maintenance and evolution of the book over time. I'm struck by how many people are doing really nicely synergistic things. It's been a fabulous two days, and I hope I can contribute to that synergy.

Let me start here. What do libraries, zoos, supermarkets, vineyards, Amazon, Google, Wikipedia, stamp collections, your office drawer, iTunes, and your garage have in common? Obviously nothing, but if you look at it from a level of abstraction, it's the intersection of library science, computer science, informatics, MIS, Law, Business, and Human Resources Management, which is the discipline of organizing. So, I call all of these things "organizing systems", which are collections of resources that have been intentionally arranged to enable some set of interactions. That definition is sufficiently general to cover all of them, I think. I wrote this textbook to be the textbook for this emerging notion of information schools, which are forty or fifty schools around the world that come from those seventeen different traditions that are trying to be something the same. The book looks like this in print, but about a year before I finished the print book, I realized it wasn't going to be a very good print book because it's a multidisciplinary book that raises a bunch of design challenges for books. So, we decided to make it into an ebook at the same time, and in doing that, I began to understand what multidisciplinary really meant. I saw that it was going to make it hard to do because it was changing fundamentally what books were going to be like. In particular, the text is multidisciplinary because it's trying to explain the concept at the intersection of many disciplines, but it has to do that in a way that is disciplinary neutral. But, at the same time, it has to build on top of that neutrality at the core to explain the discipline specific aspects of this new discipline in a way that connects to the transdisciplinary concept at the core. It has to basically handle this thing in the middle, which is the new thing, and then yet explain it in ways that people in the old fields can still understand. That wasn't clear at first.

I mean I started off with a traditional academic publisher, and we were going to write a traditional academic book. About a year before we finished, I realized it was going to have to be very different, because I was running into this fundamental challenge of multidisciplinarity, which is what I've come to call the "Breadth vs. Depth Challenge", which is that how can a book be both broad enough to include all the disciplines that fit into this multidisciplinary thing while treating all of them with enough depth and respect to be credible to people in those disciplines. You don't want to write a book that is a comic book that misses all the depth and nuance of the field that presumably contributes to this new discipline.

So how do you make a book broad and deep at the same time? I did it wrong for the first year. For the first year, I said, “I'll just put everything in the book, and everyone can have what they need in the book to make it multidisciplinary.” And so as I would have the book... Actually, I should say something more fundamental, which is that I am actually the editor of this book with eighteen co-authors. I'm also the first author of eight of the ten chapters, but that's part of the story of how a book can actually evolve in this multidisciplinary way while still having a kind of intellectual core from somebody who is the primary author and editor. That was part of the issues we had to deal with in this authoring in a multidisciplinary collaborative work.

So, we're all working on this book, and by having a number of different schools using the drafts and coming from different perspectives, we're able to start purging some of the disciplinary bias that I started with, as a person trained in computer science and cognitive science. The more we did that the more people would say "Oh, here's some great comments for you to fix this chapter," so I'm getting comments from computer scientists and cognitive scientists, and library scientists, and lawyers and business people, and MIS people, and I want to put them all in the book to make the book work. But of course, that means the book is getting bigger and bigger and bigger, and it became so big that it was going to be unwieldy. So, we finally said, “Something is wrong here”, and I tried to think through the problem in a different way.

So, what we did was, we said, “Let's re-think the notion of a book, especially a multidisciplinary book, to see if we can solve this problem.” I think we solved it in a way which actually is a very old solution, but it adapts well to new technologies. The basic idea is that a textbook, especially multidisciplinary ones, will have lots of different kinds of content. It might have core text, but it will also have lots of supplemental materials from different disciplines. It might have simulations, examples, datasets, case studies, all kinds of things. You can treat some of that as the core of this discipline that you're trying to write about and some of it as the supplemental parts. Again, this is not a new idea. We've always had supplemental content in books. Some of it has traditionally been kind of inline, like tables and figures and sidebars and things, and some of it has been pointed at, like footnotes and endnotes and glossaries and citations. Some of it has been external and wrapped around it, that paratextual stuff: the appendicies, the commentaries, the case studies, and so on. It's not that none of this stuff can be core, but it's just that it tends to enhance the core by adding that stuff on the lower parts of this table.

So, the simplest way to handle this "Breadth vs. Depth Challenge" is to selectively include that stuff. So you say, "let me personalize or customize your textbook" having a point of view by having the kind of core content in the middle and then logically include some of these supplemental materials in the textstream. That's what you do with footnote or an endnote. You basically follow it through some voluntary act of the reader and say perhaps by following hypertext links to some other content. It's an optional act, and we've done this for two thousand years or something like that. So, in the print book, we have endnotes often in books, and you follow them by voluntarily deciding to get some supplemental content that you bring into the book. You follow those links by hand and eye, and that's how you create a kind of a different take on the book you were reading.

Well, as I realized, as a way to handle this challenge for an e-book environment, I said let me tag these supplemental content by discipline, target audience, contextual categories, and then use those tags to guide the reader to make decisions about whether to read the note. Again, this is something which we've done in print books for a long time, but in e-books it gives a radically different experience. One which is fundamentally better. So, what I did in my final editorial pass last summer, when I re-wrote 100,000 words of various contributions from seventeen co-authors, I said, “Let me factor out all the stuff which is purely disciplinary around this core of transdisciplinary content.” So, I converted about one-fourth of the book into paragraph-sized endnotes, and I tagged them by discipline. You can think of this as letting the disciplinarity be a choice of the reader on the core book, rather than a distraction that overwhelms them with stuff that you don't quite understand yet. This is where I started thinking about Hypothes.is. That it was kind of pre-emptive annotation. I'm saying, there is going to be disciplinary annotation on this book, but let me do them in advance, so it will be there where a reader wants to know more from that particular point of view in a discipline. So, in the print book, all of the endnotes have these little tags like "computing" or "cognitive science" or "library and information science". That means that when you look at a note you can say, "ah, this adding some supplementarity from that point of view", so maybe the same paragraph about the Google Books project will have a legal footnote, a library science footnote, and a computer science footnote on the same paragraph with different takes on the same content.

We did something stupid here, which is that I didn't realize that I could do this in the print book too. I could have my, and this is the print, but I could have also tagged the footnotes in the line of text. I fixed that in the e-books. In the e-books, as you read the text, you can see it says, "49 web". It might say "50 lis", "51 computer science", and then you pop-up the footnote, and it basically has that additional annotation from that point of view. In fact, there are now ten different categories of endnotes in this book, ranging from library science to museums to archives to philosophy, linguistics, computer science, web architecture, business, and law. Is that 10? Alright.

But, this is the wrong way to do it. I mean, I go back a long way in this field, and I know this guy named Ted Nelson from way back. Ted Nelson talked about transclusion, and he was right. It's a much more seamless experience. If I could somehow not have to follow a link, but somehow just say, "Give me the book that has computer science stuff in it." So, I have been imagining a book reader, probably son of epub.js, maybe grandson of epub.js, that will be the browser-based book reader that will transclude on demand, where you can configure your book and say I got this book with all this additional material, let me fly it toward computer science, let me fly it toward the humanities and have that content seamlessly be in the book because I configured it to get stuff of a certain tag type. Okay. So, I can imagine that you have some kind of indication that the material is there, maybe with these little sidebar markers, where in this case, I think the red note means a legal footnote, so I go "phew", and it's in the text in this sort of seamless down the middle way without having to follow the link. I think it's a much better experience.

But, something even more fundamental emerges at this point, which is that who am I to say there should be ten types of notes. I mean, transclusion is a completely extensible mechanism. Anybody using this book, any institution, and department should be able to add supplemental content and tag it according to its particular point of view. There could be a bioinformatics tag or a digital humanities tag or a University of Texas tag, and you could tag your content that way. What you've now built is a networked textbook. I can bundle the book, the pre-packaged book that has some set of content in it, but I can say let me discover, on my book in a browser, content from other repositories which has been basically made public. So I can say, "Turn to Chapter 6.2", and there's a note on law, digital humanities, or bioinformatics that I then discover, and I can bring it into my book if I want to do that. That's what I'm calling the networked textbook and probably the great-grandson of epub.js. But, that will happen in our lifetime with the students because they work fast.

So, let me switch to a different topic, which is how does this way of thinking about books affect the writing and maintenance processes. I'm going to caricature, and I really am going to caricature because two of them are going to be straw men, three authoring options for achieving multidisciplinarity. The first I'm going to call (oh, I guess I'll skip that slide), I'm going to call it "coincidence." Coincidence is a very common academic model. You announce a workshop or conference. You say, “Come let's come and talk about this topic.” People write papers about it, and it ends up in a Springer volume or something like. There's not a clear focus on what it's about, but they’re all roughly in some field, sort of. You basically get a blind man and the elephant book that doesn't have a clear vision about what this field really is. It is something that's very vague. There is no consensus about what it really is about, but people wrote chapters about something that is in that area.

Now, a better one is what I call "consensus", which is probably closer to what Adam Hyde called the BookSprint model yesterday, where you have a facilitated collaboration. In this case, you assemble experts from different disciplines. It might be that there’s going to be a more focused workshop, maybe by invitation only. You start by having a plan, a shared vision, and if you're lucky, you have a nice book. But, sometimes, because, well, you want to get along, and you have some nice resort for a week or two, a castle, you want to avoid the rough edges, and so you end up with a comic book where you don't have the nuance because you tried to make it easy to do and get along. You have a book that maybe is multidisciplinary, but multidisciplinary in a very shallow way.

I propose a third model, which I call the "evangelism model", which says that one person with a big idea proposes a vision for this new book and recruits extras to help him flesh out the disciplinary corners and become co-authors in that way. So, my vision of the elephant looks more like this, where there’s some wise man on the elephant leading them in a particular direction. And, if you're successful, you end up with a really nice crusade that you all get behind. If not, you end up with a kind of Quixotic crusade, but if you're lucky, you build this multidisciplinary book where people are behind the same vision because their following this sort of leader who has this vision.

Now, of course, that's the model I think I followed. If you look at my case study of the evangelical collaboration with the TDO book, I began with my lecture notes from my course at Berkeley. I've been teaching for five years, trying to develop the materials, so it had a pretty clear focus. I had 1200 slides from 45 hours of lectures. I recruited a number of people to work with me, many of them were former students. I had lead authors from every chapter that I had laid out, and we did a slide swap. Imagine cutting your 1200 slides, six to a page, and then sorting them and saying let's get the dependencies right. You talk about this and then I'll talk about this, and we'll have this very clear conceptual graph of the book that you have, the tight coverage that you want in a textbook as opposed to the redundant coverage that you have in this collection of papers from random people. So, that was the goal: to minimize redundancy that way.

It sort of worked, except we ran into two inevitable laws of collaboration, which you may or may not know about. The first is called "Conway's Law", which says that the structure of a system always reflects the structure of the organization that builds it, and so if I recruit eight co-authors, I'm going to have nine chapters. Whether that's not the right model of the book or not, I had eight people working with me, so I ended up with nine chapters in the first draft of the book because I had nine people working on this who thought we each should have a chapter to lead. Of course, that often happens in collaboration, where you sort of optimize the people parts of it at the expense of the intellectual parts of it. So, when some of the authors didn't work out, I was left with holes where there weren't chapters.

But, you can fix that by running into the second inevitable law of collaboration, which is "Brooks Law", which is that, well I have a partial chapter of a book after a year, but since some of the people had left Berkley, or no longer wanted to work on it, I had to recruit new people. But, new people always take time to bring up to speed, and you have to start over. So, the project ground to a halt. We had some trouble collaborating because you know, I wanted to have people comfortable with the technology, so I let them all use Word, which was sort of the minimal authoring common denominator, but it meant that while it was easy to solicit co-authors that way and reviewers, it's not a good environment for collaborating with eighteen co-authors. You have a lot of problems passing Word files around, so we tried to use some kind of not book-specific functionality like Dropbox and Google Docs and Skype.

It was really getting difficult, and then, a semi-miracle happened. I ran into the guys from O'Reilly who have this thing called Atlas, which is this wonderful collaborative authoring environment, single source publishing, built around DocBook XML. I was doing XML in 1980, so I could do it. It has all these good features and built-in transforms for all the source...thank you Adam. He's the man, right there. Alright. I was the first non-O'Reilly book done in Atlas. I was kind of the experiment on how to see what the customization issues are in Atlas. It's a wonderful piece of work. They were very helpful. So, my book was in Atlas in XML and had the big magic button you push that says "Build Everything".

Now, of course, the decision to use Atlas posed its own issues because of course, it's native XML. At that point, I said to my co-authors “thank you very much” because I know you can't do XML, and that meant I could finish the book myself with my markup editor. But, this is where you see the implications of authoring in evolution. Because I didn't do a bottom up and emerging consensus model, I could tell people they were done and thank you very much and finish the book myself. But when you do that, you're saying we're not all created equal here. We don't end up with a Wikipedia, we end up with a top-down model. So, in some sense, a top-down evangelical model implies annotation at the edges, rather than, everything goes in Wikipedia. So, you see how my model of collaboration implies a model of evolution.

Now, we just published, as you heard this morning from the Hypothes.is talk, a version of this book which is in a browser and has Hypothes.is annotation capability next to it. We hope to create a version that takes the 600 notes that are in the print book and the annotations that I wrote and factor them into Hypothes.is, so we wouldn't privilege them so much and maybe encourage additional annotation that way from people using the book. We're using the book now in my class, and other schools are using or will soon be using it that way. We've got to develop a process for migrating user-contributed notes into the authoritative parts of this book. There are all sorts of interesting questions about how to manage that visibility and how to have curation. I'm trying to recruit curators by document type, so like, museum curator, library science curator, computer science curator, and so on.

So, what is an e-book really at this point? One minute? An e-book really is not a book, but it is a family of related books that are kind of around a core where you have this ability to have selective inclusion of content, and that content depends on not just the book, but also the relation of the book to the software that reads it and the process by which it is being maintained. And, I think that means I'm done.

Thanks very much.