The Art of Content Engineering

Software engineering is important to virtually every part of Inkling’s business, not just for building our iPad software, but for creating powerful business intelligence tools, managing the engineering infrastructure itself, and helping us scale our content processes in clever ways. You can see it in the backgrounds of our people. Our Creative Director studied engineering at MIT, and even our CEO has a degree in computer engineering. Across the company, engineers and software engineering methods are important parts of Inkling’s culture.

That’s because what we’re doing is technically challenging. Inkling isn’t just an iPad app; it’s the world’s best platform for the design, creation and distribution of complex learning content. The processes used to create textbooks and creating software have traditionally been very different, but we believe that as content becomes more interactive, rich in media and available on multiple platforms, the application of software engineering practices to content creation makes a lot of sense.

Here are three reasons our unique software-oriented approach to interactive content creation makes sense.

First, content is source code. With Inkling, content has evolved beyond the flat InDesign or Word document. It looks much more like the source of a website: hyperlinked HTML and XML files mixed with images, videos, 3-D objects, and other media types. Content is stored in open formats that can be created and modified by any number of software tools.

Once you think of content as source code, then the natural way to manage it is through a source control management system, an indispensable tool in software engineering. Storing content in an SCM allows those who work with the content to think about the process in a whole new way. For example, multiple people can then seamlessly work on the same content simultaneously from different places in the world. (Well, almost seamlessly: see merge conflicts)

Second, whereas books have typos, software has bugs, so traditional methods of content proofing don’t work well in this new world of interactive content. It’s hard to take something like an Inkling textbook and flatten it into linear representation that can be marked up by hand. It’s like trying to flatten a massive website into a single document. How would you order the content? How would you represent links among documents? Plus, marking up a single document doesn’t scale to more than a few people working in serial, like a proofer and an author. In the new world, where multiple teams are working simultaneously, a more sophisticated tool is needed.

Shortly after the first line of code was written, the first bug was discovered. And shortly after that, bug trackers were born. Bug trackers sit at the center of any good engineering operation. Project memory, like the timeline of defects and features, are stored there. The open/close rate of bugs represents the pulse of a software project, and it’s the tool that manages the lifecycle of a task from inception to completion.

A defect discovered in Inkling content looks a lot more like a bug than a traditional typo, so software engineering practices for identifying, tracking and closing the “bug” apply much better than traditional methods.

Third, with software, you don’t do print runs, you run builds. Software’s inherent flexibility affords us luxuries unheard of in the traditional publishing world. For example, we can quickly view the actual finished product, modify it, and view it again, without involving a printing press. So what’s the modern day equivalent of printing a proof? We think its closest analog is the software build process.

In software engineering, the build is usually the output of a compiler. A compiler generates an executable binary from the source code, and targets a specific platform like Mac OS X, Linux or your iPad. The compiler and target are very important abstractions. They enable the same source code to run across different platforms. Inkling content has been structured in the same way. S9ML, Inkling’s native markup language, is built for a specific target, just like software. The target could be an iPad today and a browser-based client tomorrow. This lets us scale across multiple platforms without rewriting the S9ML over and over again.

Builds are another very important part of software engineering. Each one is unique, and they’re usually identified by a build number, which represents the software version. The build number is a critical piece of data when reporting defects as it exactly identifies the point in time of the project when the problem was discovered or introduced. Builds can be extended to include unit tests, which are automated verification tests that attempt to identify problems before humans do.

Inkling content is “built” directly from our SCM on demand by a given project team. Every time the project is saved to the SCM system, a battery of unit tests–or unit “proofs” as we call them–is run against the content, instantly identifying possible problems. This continuous integration methodology is also borrowed from software engineering, and it allows authors and editors to find and fix problems quickly.

Our approach to digital content publishing–treating it as a software engineering problem–will afford us the same benefits of software projects: collaboration across multiple functional teams, revision control, support for a plurality of platforms, and automated quality assurance. It will also allow us to scale as a platform that will eventually open up to a much larger audience of users. By thinking about content from a different perspective, we’ve opened up a whole new world of interactive possibilities, and made it scalable. Who says engineering isn’t an art?