Balancing Automation and Innovation Within an Automated Workflow
I am not a programmer. At the best of times I am a failed literary scholar turned publishing student, which by way of pandemic has led me here writing about technology within the field of publishing. Strange how things work out.
The kind of automation I am interested in is rooted in language and communication. It is a lesser known or explored concept in conversations around automation in tech, but I feel it can enrich our ways of thinking about automated publishing systems.
In Hederis founder Nellie McKesson’s recent medium post “Automated Publishing Workflows, Explained,” she discusses the “black box” nature of many automated publishing systems and how they can create a negative experience for users.
In this post, I want to expand on this idea of “black box” systems, hopefully giving you a clear image of what they are and how they can be frustrating to work with when creating books, and how they relate to the poetic concepts of innovation and “automatization.”
The Black Box Metaphor
I grew up, like many, with a large gray box in my living room. My father told me if I stood too close to it, this majestic object would fall on me like a boulder over Wile E. Coyote.
As the years progressed, this great big boulder lost its majesty. The buttons on the bottom right had permanent fingerprints where the plastic was worn down by an increasingly forceful press. My brother developed a habit of banging on the TV whenever snowstorms blew over his regularly scheduled programming. While it temporarily set the image right, it also hastened the TV’s demise, and soon the great big boulder met the great big trash heap.
Unbeknownst to us, our TV had loose electrical connections, and hitting the box temporarily reconnected them but also broke them down quicker. The solution employed by the user, in frustration, becomes a permanent unfixable problem.
Although my box was gray it still helps to illustrate how users operate a tool or software when they have no knowledge of it’s inner workings and are unable to communicate with it; in other words, a black box.
When users have no way to know what a program is doing and no options for manipulating it to their liking, they will bang on the box until the problem resolves itself.
If you think that in the 15 years since our TV met the trash heap of history we have somehow resolved this brute-force-as-resolution problem in tech, may I refer you to this Twitter thread inspired by Nellie’s article and the source of inspiration for mine.
The evolution of black boxes in publishing
In addition to not being a programmer, I am also not a publishing historian, but I’ve heard tales of the “time before computers,” of the era of paste-up and photostat and rapidograph. Desktop publishing software made it comparatively easy for book designers to handle all the little tasks of laying out a book, to change page margins and typefaces with a few clicks, saving multiple people hours or even days of work.
Where the process was once entirely manual, and yet difficult to manipulate once set in (literal) metal or glue, desktop publishing software made manual layout manipulation a relative breeze. For example, in the days of paste-up, fixing a bad break in a justified text meant cutting out individual words and manipulating the spacing by hand. Desktop publishing made it possible for these changes to be made by highlighting a paragraph and toggling some tracking settings. For reasons like this, desktop publishing was a massive paradigm shift for book production.
But then along came another paradigm shift, brought on by the rise of digital media. And then print was no longer king, and software that had been designed specifically for print was suddenly found lacking. Ebooks became a mandate for publishers, and some segments of the industry even found themselves required to distribute to purely Web-based platforms. On top of that, Web economies added new demands for the publisher: publish faster, publish more books, publish books on the latest trends, compete with self-publishers, stay relevant alongside publishing or Web giants who have huge budgets to invest in their processes.
Automated workflows began to seem like a magic bullet for publisher woes.
The promise and opacity of automation
In many ways, automated workflows were a major step forward. Publishers could create clean, valid ebooks on the first try, at the same time as creating their laid-out print files. A book could get to first-pass pages in a matter of seconds or minutes, and could be updated with the latest changes and re-converted at will. (If you’re feeling like you need a clearer picture of what this kind of automation entails, I encourage you to pause here and read Nellie’s article, if you haven’t already.)
But the manual manipulation that desktop publishing software had revolutionized is difficult to replicate in an automated workflow, where the book exists entirely as code and you don’t see the final product until the typesetting process has completed. The book is basically a reflowable text with chapter breaks or paragraphs and heading tags as its only anchor. To pin down a bad break in this type of program is like trying to catch multiple goldfish with your hands. You think you finally got the last one, only to find out it was a diversion and his friend has escaped (I think you can guess how I spent my weekend. I’ll give you a hint: I lost my net).
These lines from Nellie’s article illustrate some of the issues with this sort of black box system in the context of automated publishing:
Most automated workflows exist as a “black box,” meaning that there isn’t a window into how the pages are being laid out. Design instructions are created via code, then you feed those design instructions into the tool, and then cross your fingers that the pages come out looking ok, without too many widows or orphans or terrible line breaks.
Nellie points to a major flaw in automated workflows: the laborious process of “guess and check.” Design instructions must be predetermined before the text can exist within its container format (e.g., page), yet most print design instructions are determined by how the text exists in its container format. It’s almost like going back to the days of paste-up, where a designer had to choose their fonts before ever getting to see the layout. This issue is compounded by historical book design conventions and the way book production has functioned to create a product standard that is hard to replicate in an automated workflow, leading publishers to stick with more labor-intensive processes.
Much like the gray TV of my childhood, book designers using automated publishing systems struggle to get the image clear and have no way of opening up the box to see what is causing static in their text. They are left to determine the problem by its output and rework the input as many times as it takes to get it right. Essentially, they are attempting to replicate the standards of print book interiors on a program designed for reflowable text.
Automation vs. innovation
The late German semiotician Roland Posner’s book on “Rational Discourse and Poetic Communication” talks about automation within the context of language. If you are plugging your nose and mentally preparing yourself for a deep dive into linguistics and semiotic analysis in order to better understand computer programing, think again. I am a shallow swimmer, and we will really only be skimming over a few passages.
When defining poetic communication, Posner points to two elements of poetics: innovation (he uses the word de-automatization), or “an action carried out for the first time”; and automatization, or “actions which one is accustomed to.” Roland explores how automation exists in language, specifically the way in which specialized situations played out like a script again and again can automatize your relationships with others as well as your perception of reality, while innovation does the opposite. The reason why I like his explanation and have held onto it for six or so years is because it presents innovation and automation together as two actions that propel the language forward. The way I see it, too much innovation leaves a text incomprehensible, but too little creates a rigid language system incapable of processing novel experiences.
Now compare print-standard formats and the tools built to create them; we can call the tools InDesign on the one hand, because we all know that’s what most of us are working in, and automated publishing systems on the other. A peek inside a typical book interior designer’s InDesign file reveals a world of innovation in the custom tracking, kerning, and styles unique to the text — all for the purpose of creating a beautifully set print text (and a nightmare for the ebook production team). The automated system, by contrast, seems like an obvious exemplar of Posner’s “automatization,” built to render a text in more of a one-size-fits-all format, with some even utilizing layout templates to speed up the process even further and create the kinds of standardized files preferred by platforms like Kindle. As I mentioned before, this can limit a publisher’s ability to problem-solve, and ill-fitting sections of text and ugly breaks can reveal the limitations of the predetermined design instructions for addressing the unique needs of a particular text.
Automation that fosters innovation
With the typical framing of desktop publishing vs. automated systems, the difference is presented as a choice between high quality print layouts on the one hand and faster production on the other, but this framing minimizes what automated workflows — especially an innovative automation platform like Hederis — are able to accomplish. Publishers still need to create clean, valid ebooks. Publishers are still under pressure to publish more, and to publish faster, and to compete with new players. And of course, publishers still need to create beautiful print layouts that maintain the invisible standards that readers are accustomed to.
That said, web-based technology has already introduced changes to various aspects of the publishing value chain that are becoming the norm. Publishers are growing more and more used to user-friendly SaaS solutions that give them access to powerful software applications right in the browser, easily customizable templates for creating marketing collateral and slick email campaigns are already the standard for publishing marketing teams, and everyone is used to seeing what they will get before settling on a final product. The Web has changed what people expect from the tools they use, and has changed the types of files that publishers are expected to create.
What we are developing with the Hederis app addresses all of these expectations, offering the efficiency of automation with lots of opportunities to tweak the design specs of your project and preview how it will look before (simultaneously) building your final print and ebook files. You might say that our cloud-based platform offers a “window” into the black box of automation. It’s automation with a side of de-automatization — and the opportunities for creativity and innovative thinking that go with it. Drag-and-drop a Microsoft Word file into the browser, and see a high fidelity live preview of print and ebook outputs in a matter of minutes; get a valid, accessible EPUB file at the same time as a print-ready PDF; upload custom fonts, adjust line breaks, tweak hyphenation settings, and invite your colleagues to preview the book right in the browser. Our goal is to combine all the opportunities offered by the Web with the established benefits of desktop publishing software and the promise of automation, and we encourage you to give our app a try and let us know how you’d like to see it grow.
