Month: September 2016

For the last month and a half or so, I’ve been a staff writer and editor for a major K-12 textbook company. And let me tell you, this process is horrific. It consists of passing around MS Word documents that cannot deviate in the slightest from a particular format, and commenters that give such helpful suggestions as, “You need to rewrite the chapter. We don’t feel that you are properly targeting the intended audience.” Please, can you be any more vague?

As a science and engineering consultant, I work on large projects for a living. And I’m talking “space shuttle” large. Textbooks are microscopic by comparison. And so here’s what I think the textbook industry needs to do.

1) Adopt a version control system. You have multiple people editing a thousand single-page Word documents. This is horribly inefficient. Everyone should always have access to all of the pages, at least for reading. And then they should be able to check-out for editing, with merging at the end. The software industry solved this problem a long time ago, and it’s about time that publishers adopted it.

2) Adopt a CSS-style system for templates. You want the book to have a consistent look and feel — I get that. But insisting that everyone conform to writing with the same (very messy) template in the same version of Word is stupid. Content should not care about look and feel, and the textbook artists should be able to change that without having to go back and edit every single page. Again, this is a solved-problem in the software development community. Maybe look in to that.

3) Adopt a requirements management system. Engineering projects have tens of thousands of requirements. This keeps everyone on the “same page” with respect to things like module inputs and outputs, screw sizes, and the like. It ensures that all of the pieces fit together at the end. A textbook has a lot of requirements too. Common core dictates that these things be taught in this order, and a finished text can have over a hundred sections. But again, this is a much smaller number of requirements than even a medium-sized engineering project. And again, this is a solved problem, whose solution should be adopted.

These three pieces can (and often are) integrated in to a single package in the engineering world. ClearCase/Doors is a good example of just such a package. If publishers were to adopt such systems, they’d get all of these benefits:

Authors and artists could use whatever tools they like to edit pages.

If an editor wants to change the look and feel, they can just do so without having to change every page.

It’s easy to see what previous people did to a page, and a page can be reverted if need be.

Multiple people can edit the same page at the same time without stepping on each other.

It can be seen at a glance, which requirements have been fulfilled and which need work.

A single “builder” can be used to “compile” the textbook in to a single file for printing, or ebook publishing, or web delivery, without changing any of the content or editing any page.

Since it’s easy to see who worked on what and did how much, individual authors and artists could easily get the credit (and payment) that they deserve.

So come on publishers — get with the 21st century and start using the tools that are already out there!