You Got Your Technology in My Typography!!!
It is fairly well known that content authors, graphic designers, and technical data developers often wind up at odds. XML stylesheet technology often jokingly referred to as “rocket science.” These disparate groups of individuals have a lot to learn from each other, however. Especially when it comes to the topic of single source, multiple outputs content publishing with XML. How can we cross the understanding divide between these three groups of individuals?
Scott Abel, The Content Wrangler, himself, recently posted the following question to a message board: “‘XML, like movable type, is primarily an economic innovation… we can extrapolate from 15th-century reactions to movable type to guess about how the shift to XML will go.’ What do you think?” Scott came up with the question after reading Sarah O’Keefe’s “What Do Movable Type and XML Have in Common?” (PDF) article published in the December 2008 issue of Intercom, the magazine of the Society for Technical Communication.
At the time I read Scott’s question I was, coincidentally, in the midst of reading Ellen Lupton’s excellent typography guide, Thinking With Type: A Critical Guide for Designers, Writers, Editors, & Students (New York, 2004). I asked myself: just what is it about XML, and the technical publishing solutions that storing content in XML enables, that makes non-technical, design-oriented people in publishing want to run for the hills while screaming “You just don’t get it!”, leaving the technical people in publishing in the dust, wondering why no one understands all the wonderful benefits that can be reaped through publishing automated by XML-enabled technologies.
Clearly (and ironically), we have a communication issue to deal with. But where to start?
I learned typography and page layout before I formally learned anything about design, content development, and most importantly, anything technical or related to programming. Way back in 1992, I learned to layout pages to a specification by route. My employer literally handed me a pica stick (typographic ruler) and a calculator, provided a demonstration for entering computer codes based on my measurements and calculations, and put me to work cranking out pages. Luckily, I had an inclination and an eye for detail, so I took to learning the methodology of my new “craft” quite nicely.
© nebari – Fotolia.com
Eventually, I left my role at the compositor to go do SGML things (mainly, write batch print stylesheets). This was my introduction to computer science, desktop publishing (we had only just started to do Quark jobs at the compositor), and thinking about things in a logical, and technical way. Somewhere along the way, I learned basic programming skills, took an introduction to programming class, and my professional identity eventually morphed from “but you just write stylesheets! You’re not a REAL programmer…”, to someone known for being able to apply programming concepts to the craft of typography. Technology was cool, and I was more than happy to play with it. I was sold from the very first time I saw a demonstration of an actual table editor. Prior to this demonstration, tables had always been a mysterious bit of strings and codes along with some information that took forever to set, and that never came out of the typesetter quite right.
Along the way, technical programmers I knew, who could write rings of code around me off the top of their heads, often jokingly referred to my stylesheets as “rocket science.” You see, they understood the programming end of things, but didn’t necessarily understand the concept that while all data is text, not all text is data. Text is irregular. Text doesn’t necessarily follow a planned hierarchy. Text often veers left when you expect it to go right. This means that in working with text processing systems, you have to account for the “unknown,” which you can’t predict.
Further, technical programmers are not usually trained up in the specifics of the actual craft or art of typography. Technical people often comment that designers are being too persnickety and all OCD about the number of points a particular piece of content is out of line—they don’t understand that this level of detail is important for a very big reason: over 500 years of philosophy, methodology, and design concepts paralleling art and architectural history. (And yes, we really CAN see things that are off by one or two points. We’re trained to!) As a result, modern designers and typographers often frown at less than perfect typography, and send off a report to the techies telling them “almost, but not quite.”
The techies would respond: “OK… So your columns don’t balance, and the hyphenation rules aren’t quite what you expected, but you turned out 250 pages in less than 2 minutes…” And the designers would shake their heads and think “they just don’t get it…”
“Why don’t they get it,” you ask? Attention to typographic detail at what the rest of the world may consider the minute level is part of any typographer’s or designer’s heritage as a professional. We are trained to see detail. The nuances of geometry whether applied to the architectural grid of a book’s page, or the fit, fixture, and texture details of a cool building.
This is not to say that all technical people have no sense for detail. But it is the case, more often than not, that people don’t pay attention to something that isn’t brought to their attention either through education, personal, or professional interest. If people aren’t paying attention to these details, it’s as if they don’t exist. And this is point where communications between authors, designers, and technical data developers break down.
All of that said, there was a period of time where even I was blinded by the “Look what this software can do automatically, and in less than 5 minutes” nature of my stylesheets… Technology really is that cool, but I had to learn this. Someone had to point it out to me.
Here’s a scenario: I traveled to a customer site to demonstrate the journal article stylesheet functionality that I had worked on day and night for six weeks. I was expecting “oohs” and “ahhs” from my audience, but was confronted with the reality of exactly the kind of response that Sarah O’Keefe imagined when Illuminators and Copyists were told about the invention of the Gutenberg Press some 500 years ago… Unhappy people who weren’t capable of thinking past the immediate impact on their craft and trade. Further, they were unhappy people who saw my whiz bang stylesheet as a black cloud over their future employment. You see, the editors I demonstrated to were responsible for more than just editing journal content; they were also responsible for all of the content source tweaks necessary to produce pristinely perfect typography. Clearly, if my stylesheet could handle the minute details of their typographic requirements, then what would they do on a day to day basis?
Here’s another scenario: I once attended a round table meeting where the executive in charge explained his division’s grand plan for automating typographic production AND enabling the creation of additional digital products, such as ancillary texts and accessible eBooks. When the floor was opened for questions, a quiet woman from editorial asked if these changes meant that the company would no longer be publishing books. She went on to explain that she wasn’t technical, wasn’t interested in technology, and was really disappointed to know that she would no longer be exclusively designing for bound paper.
I mention these experiences because the one thing that really stands out for me personally while reading Sarah O’Keefe’s article, was the impact of the Gutenberg Press on the trade of copying and illuminating bound texts; a painstakingly detailed and time consuming art. Monks could work on a single manuscript to the point of artistic perfection for months at a time.
And in the ~500 years since the invention of the Gutenberg Press, typography has become more than just a means to an end when it comes to publishing content, whether technical schematic, or philosophical treatise. In fact, typography, often described as the user interface to content, became a part of communicating information. A good user interface in software is one that user doesn’t have to pay attention to—it just works. Design methodology, and the concept of the printed page as geometrical grid, resulted from hundreds of years of different schools of thought, first moving away from anything that looked like a handwritten manuscript toward the extremes of geometric type in the post-modernist age, and back.
Skipping to the point… consider the humble table. When you read a table, do you think about the table itself? The rows and columns? Rules? Column Heads? Spanned cells? Most likely, no, you do not. You pay attention to the content in the table, and the relationships between the separate pieces of content in each cell. But wait… How did you know there are relationships between cells? How did you know there are relationships between columns and rows? That’s right: the table is designed to communicate content. If the designer didn’t get the details of the table right, such that relationships are immediately apparent to the reader, the result is often a very confusing pile of seemingly disparate pieces of information from which the user must derive any sense with no effective visual aid.
So typography is part art, part trade, part communication tool, part of culture, and imbued with meaning unto itself. Entire typographic schools of thought intentionally paralleled schools of thought in art and philosophy throughout the years. According to Ellen Lupton, “In Switzerland after World War II, graphic designers built a total design methodology around the typographic grid, hoping to construct with it a new and rational social order.” (Lupton, 2004)
…and now we’ve arrived at a point where the next big leap, a leap in publishing enabled by XML technologies, is positioned to reinvent this art, trade, communication tool, and culture in the age of the Internet and constant communication.
It’s going to be a bumpy road until we can get the technically oriented individuals to understand that designers aren’t just dismissing the cool technology without valid concerns, and designers to understand the capabilities of XML-enabled publishing beyond the printed and bound book. And why they should care.
Yes, it’s true – better economics result from automating processes like typography. I’ve seen this in project after project. But personally, I still care about the extra white space, the unbalanced pages, and the other details that sometimes result from automating typography. It’s steeped in almost 500 years of “how things were done.” At the same time, I also understand that what is true for publishing one kind of content – say, humanities content, and what is true for publishing technical content – say, schematics and wiring diagrams, can be quite divergent due to the context in which the content will be consumed. Pristine typography takes a back seat to accuracy of knowing which wire goes where. Either way, I’ve learned to follow my customer’s lead; if they want really detailed typography, I’ll do everything I can think of to provide that level of quality before I admit defeat. If the customer is less concerned with really detailed typography and just wants their single source output, I can do that too.
Typography is driven by the needs of the reader. Different needs of the reader include large-type, bound books, screen displays (in a multitude of sizes), content purpose, and audience specificity. The beauty of these requirements is that XML-enabled technologies are extremely well-suited to supporting all of it (and probably some stuff we haven’t thought of yet, too).
My customers care about their content and what it means to the context of their business and their customers. XML technology can enable automatic processing of content in ways people previously never thought of. Each company has to make a decision – automation over artisan or vice versa accordingly.
I know this much, though: Automation through XML, no matter what the output, is definitely not going away. And creative design that is part art, trade, communication, and culture imbued with meaning unto itself? It’s not going away, either.
Which means we (that would be all of us: authors, designers, and technical gurus) need to come up with a way to continually remind ourselves of the pesky understanding divide between the creatively right brained design community, and the logically left brained technology community, who, whether they like it or not, will be working together with single sources of information that can be processed in different ways, for different audiences, different languages, and with different contexts.
What are the best approaches to communicating across the understanding divide? How do we get the technology crowd to really understand the context of over 500 years of something as embedded in our culture, language, and communications as typography? How do we get the design crowd to shift from their current historical context (this is how it’s always been done…) to understand a different context of what is now possible for the future of publishing using XML-enabled solutions, and why this future is important?
If 500 years of typographic history reveals anything, however, we can definitely figure out the answers to these questions in less than the next 500 years, due to our many technological advances, and the exponentially, increasing quantity of available information, in as many different formats as we can dream up a reason to create.
About the Author
Jean Kaplansky is a Senior Global Services Consultant at PTC. She is also a member of Content Management Professionals, and has been responsible for a myriad of XML-related activities at various companies including Arbortext print FOSI development, W3C Schema writing, applied XML and application development in Microsoft Office 2003 and 2007 (specifically in Microsoft Word and InfoPath), XML in Adobe InDesign exploration, and general XML standards research. Occasional XML-related observations can sometimes be caught on her blog. Contact Jean via email.
Author’s Note: Special thanks to Suzanne Napoleon and Archie Anderson for repurposing themselves as content sounding boards!
Similar Posts:
Great topic! I gotta jump in.
Re: “Text is irregular.” This means that a few sample documents may not show all the possibilities. There are a lot of”What If” questions to be asked, such as: What if a chapter title is long and requires two lines? Will it still fit in the page header? What should it look like in the table of contents? The sample documents may contain fewer than 99 pages, but what if there are more than 99 pages? Is there space in the table of contents for three-digit page numbers? The issue here is domain knowledge. IT developers working with XML formatting need to acquire it, otherwise they can make mistakes equivalent to rounding off entries in a bookkeeping application to the nearest dollar.
Re: Different types of documents. What if you received a document with information about your 401K account and you noticed formatting glitches? Your trust in the company that has your money could be affected. On the other hand, a mechanic reading a thousand-page technical manual could probably care less about formatting problems—as long as the essential information is accurate.
Re: Automation. Working with text has always been a laborious process. When manuscripts were copied by hand, the change to hand-set movable type was a huge improvement. But after a few hundred years of composing type by picking up each tiny letter and setting it next to the previous tiny letter, some folks thought there had to be a better way. Of course, not everyone felt that way, and it’s no different today. However, when a new technology saves time and money, it generally replaces the old technology, whether we like it or not.
Re: The aesthetics of formatting. Formatting is not just about aesthetics.
Formatting specs affect the reader’s desire and ability to read the document. This is very important because if readers do not want to read the document or cannot read it, the time and cost of writing and publishing the document is wasted. Ideally, formatting makes readers want to read the document and make it easy to read the document. Choices for font, leading, and margins have a lot to do with the desire and ability to read a document, but there are other factors that are not so obvious. Tables are an excellent example. It may seem best to include all cell and table borders in order to organize tabular material for the reader. In fact, the lines, and especially the corners, add to the reader’s effort. For tables, it is actually better to use white space instead of lines when possible in order to separate table rows and columns—white space does not increase what the reader must process.
In addition, formatting helps guide the reader through the document. For example, a two-column layout with Z-paging presents an ambiguous reading order when a table or graphic spans both columns in the middle of the page. After reading the content in the upper left corner and encountering the page-wide object, does the reader go to the upper right corner or continue reading down the first column? In some documents, reading instructions out of order can injure or kill the reader! L- paging solves the problem by eliminating text from the upper right corner. However, L-paging creates a new problem by increasing the page count of the document.
Formatting specs are also about economics. One point is 1/72 of an inch, so an extra point or two in formatting specs may seem insignificant. However, extra space may result in an extra line, and an extra line may result in an extra page, and an extra page may result in an extra signature or an even extra volume! All of which add up to extra, unnecessary, cost.
Consider a two-page document printed on both sides of one sheet of paper. If the number of pages increases to three, twice as many sheets of paper are needed. If only a few copies of the document are needed, that’s not a big deal. But if a million copies are printed—you do the math. And added expense goes far beyond the cost of the paper. The cost of ink, press time, and shipping are also increased.
Consider a 160-page document printed with a 16-page signature (16-up). One extra page adds another signature, and results in a printed document with 161 printed pages followed by 15 blank pages. This increases the cost of paper, printing, binding, and shipping.
Consequently, formatting specs for printed documents are generally designed to fit as much on each page as possible without sacrificing the ability to read the material or the reader’s desire to read it.
Does XML help? Yes! A stylesheet for batch formatting of XML content ensures the desired formatting specs are utilized; incorporates style guidelines and corporate identity strictures; and produces formatting that is truly standardized. In addition, multiple outputs from a single source widens the formatting possibilities. For example, a fancy four-color version can be produced for customers and a plain black-and-white version can be output for employees, just by changing stylesheets. But so much more is possible. For example, different color versions designed for readers with different kinds of color impairment. So, a change to XML is a good time to re-evaluate the readership and their needs.