Digital Adaptation in Action

Previously, I made the case that the world was broken, or more specifically the way rules are delivered to players is becoming increasingly frustrating and outdated. However, unlike most problems that I encounter in the world, I have the power and skills to fix this. The two seeds of knowledge I have are that (a) the industry-standard program used to make rulebooks has a function that exports HTML and CSS and (b) it is possible using automated systems to process this output into a web page that meets contemporary web standards. I have planted these ideas and from them grown a mighty concept that I am currently calling a living digital adaptation (defined in the previous post) of a board game rulebook. In this post, I describe my process of creation, and in my next post, I use the knowledge gained through the process to make some recommendations and predictions about how this innovation could and should change our industry.

Living links the digital file to the source file of the print rulebook. The adaptation would be updated by the process of updating the original, making it possible for a publisher to maintain both a physical and digital rulebook through a single process.

Digital establishes that this exists in the digital space, either easily accessible through the open internet, or via an application.

Adaptation describes what the product or service is. It is a physical rulebook that is adapted (changed) to better serve players in this digital space.

Before you go any further, dear reader, you should be advised that this article may be of little interest, but should interest to some people in the industry. Primarily this article is actionable by, and therefore useful to:

• Publishers that want to deliver rules to their customers in accessible formats, and have the power to do so (having the budget and access to the expertise to do so)
• Workers in the rulebook workflow, being graphic designers, writers, editors, game design and developers, and - now, for the first time ever - web designers and developers (to build or run the machine, you’ll need to go a few steps further than HTML and CSS).

If you’re just curious and would like to view the final product, you’ll need to skip to the end of this post (skipping to the end is one of the few things that is easier with printed pages).

The Game

The document that I’ve used as a pilot project is the rulebook for Hand of Fate: Ordeals. I was involved with the rules in the early processes, doing a development pass for terms and structure, but not in the actual layout or editing process. I chose it as a good candidate for a case study as it was a reasonably complex document that would have a wide release, and it was an easy project to start work on as I was already familiar with the document and I could get easy access to through my established relationship with the publisher.

Goals

Before starting the project, I wanted to establish what I actually wanted to achieve with the process. I established a Primary Goal, by which I could define the success or failure of the project, and some Secondary Goals, which would be nice to achieve, but not totally necessary to announcing the successful birth of the living digital adaption.

Primary Goal

Through the Export function of InDesign, export a web document that can serve as a rules reference for the game and conforms to contemporary web standards (which ensures that it is a friendly and usable document).

Breaking that down a little:

• The document’s intended use is a rules reference, not a rules replacement. Any person, or group, that uses the document should also have access to a physical rulebook.
• The document must be responsive. That is, it must be easily accessible and readable on a range of devices, especially devices that live in people’s pocketses.
• As a general rule, text should not be delivered as image. This is important for a rulebook that must be searchable, and it is respectful of the reader’s bandwidth.

Secondary Goals

• The Export process should be a single process without any additional manual post-processing, but can involve some automated processes. The original designer of the rulebook, or any sufficiently skilled human, should be able to press a not-necessarily-proverbial button and output the web document.
• The original InDesign document must be intact. The original designer, or any subsequent designer / editor / human, must be able to update and use the document as before, with functionality added, not taken away.
• The process should be as un-intrusive as possible. It would be best to design a system that would work for most InDesign files, without intervention in the file, but I don’t believe that goal is achievable.
• The process should respect the original layout of the document. This is a considered decision with this as a case study, since the layout is more than just linear text with in-line images
• The document should track changes to show players if any content has been clarified, changed or errata’d to hell.

Scoping the content

After establishing my goals, I assessed the rulebook to scope out the project and decide if there was anything I could eliminate from the process.

• The setup pages were too heavily-designed to be adapted, very designed and took up a full spread (two pages). Setup is not an essential part of the document as a rules reference, so this neatly fit into both the unnecessary and the too-hard basket.
• The sidebar was a big design element that needed to be considered. Elements in the sidebar were visually separated out from the main text and implied that the content therein was supplementary, and not part of the standard reading order. I needed to represent this visual hierarchy in my adaptation.
• Co-operative content was supplementary. As a self-directed and self-funded project, there wasn’t a good reason to include the cooperative content, and since the campaign was narrative-based, there was a danger of players accidentally reading ahead (spoilers!).

The Process

The process itself took many months, as I was only working on this in my spare time between other projects, and went through several stages. The first stage was exploratory, as I started using the basic export function and analysing the output. After the analysis, I had a good idea of what should work and started building a system, through iterative stages, honing the exported web document until it had the basic structure I wanted. In the final stage, I came back and did the web design of the document itself, and implemented a few extra features, after consultation with the publisher.

Structuring and Exporting the Document

There are a few different options when exporting HTML from InDesign, and the important first step was deciding how to export the document. The options are presented as Content Order, but the different options also affect how the content is grouped, which is very important for a web document.

The three options available are:

• Based on Page Layout
• Same as XML
• Same as Articles Panel

The default option Based on Page Layout was not satisfactory, as it didn’t provide enough grouping of the content, which was important for how I needed to construct and style the web version. After a little bit of experimenting, it seemed that exporting using the Same as Articles Panel option would provide me with the structure I needed to deliver a sidebar with main text area, by giving me the ability to include placeholders that I could replace with opening and closing tags, as well as the ability to use pasteboard content without altering the original layout (not ideal, but it would turn out quite necessary). The big downside was that it was very intrusive. I needed to cut and rebuild many of the text frames and then manually drag them into the correct order in the articles panel.

The third option, Same as XML Structure, I only briefly explored, before deciding it was not the best fit for this project since the Article panel provided a clear early path. The Article panel is much more approachable for those not comfortable with coding, and even though InDesign provides a graphic interface for XML tagging, I know through experience that the XML can be quite unforgiving of errors and often needs somebody fluent in the language (or a similar tag-based language such as HTML) to fix small errors. Using the XML-based option would likely add a barrier for others to use the system, but could be further explored.

Columns

The original document had a dynamic 3-column layout, which sometimes included sidebar content with a distinct red ribbon background. As I went through the adaptation process, I used a column layout to maintain and reinforce the information hierarchy of the original document, respecting the original column layout, but breaking out to better convey the intent. I believe multiple columns are a good design solution for rules reference, as it allows high information density that makes scanning and scrolling easier compared to single column text. Of course, being a responsive document, I needed the columns to adapt to the viewport, reducing to single

Failing Forward

Much of the adaptation process was discovering what wouldn’t work. Throughout the process, I discovered that there were solutions to most problems, and while the implementation of those changes was time-consuming, this was mainly because the document wasn’t set up with knowledge of what works well for an adaptive process such as this.

Drawings

One of the original stumbling blocks I encountered was how InDesign exported graphical elements that were drawn in InDesign. It really wanted to export them as single drawings that ignored the layout from the document, so something that looked like this in the program and as an exported PDF:

transformed into a weird deconstructed and discombobulated mess like this when exported for HTML:

Initial experimentations to get the export function to respect the original document proved frustrating so I circumvented the process by using linked images, taking the drawings from InDesign and copy and pasting them into Illustrator.

The copy-paste process was not a good solution for an adaptation since it was fairly invasive and destructive. Moving the images between design programs destroyed the links to placed images and reduced editability. To preserve the integrity of the original document, I used the pasteboard as an additional canvas, using it to deliver web-only content. The end result was acceptable but not perfect, as elements that shouldn’t scale with the image did, making text and strokes thinner and thicker depending on the size of the window. It should be possible to create a more responsive system, eliminating drawn elements that could be replaced with CSS, but I decided that this was out of scope for this adaptation.

Once I established this process, I started exporting images from Illustrator to override the InDesign exports (of the placed Illustrator images), which gave me more control over file-size and image quality. This revealed another less-destructive option, as long as the images were linked and only the images were exported, I could leave images as is in InDesign and replace them by overwriting the files after export.

The lesson learned here, and throughout the process, was that adaptation was a time-consuming and inefficient process. The knowledge gained, however, was valuable, and if used as part of the rulebook design workflow could deliver a document that needed less intervention. Adhering to the simple maxim of “All graphic content should be placed from an external file, not constructed in InDesign” would save much post-work in the adaptation process,

I should note that using linked images in Illustrator wasn’t a big leap for me, as it’s possibly how I would have set up the document anyway. I personally don’t like drawing and composing images in InDesign, as I find it awkward compared to Illustrator, which has a better interface for non-layout work, especially when aiming to deliver consistent styles and images. However, designers can be creatures of comfort and habit, and I know many designers who prefer to do all their work in InDesign.

Blending Modes

The appearance of the images with a lino-cut style was mostly delivered using the Multiply blend mode in InDesign. While it is possible to deliver a similar blend mode using CSS, it appears to be limited as it doesn’t respect multiple levels. The solution to this was simple and just required some additional image processing, and it was another thing that once identified could be used as a consistent rule going forward: process the image to produce the desired result, don’t rely on in-program effects.

Inline symbols

Most inline symbols just needed a little CSS attention after the initial export, but images that deviated too much from square caused problems. I created a Character Style to deal with this, but it is still too fiddly a fix for me to be happy about. Targeting the images themselves was difficult since they were all copied-and-pasted, not-linked images, so InDesign exported them as chronological numbered files. The larger lesson learned about images - use linked images, not native drawings - could be applied here for different effect. A consistent file name would allow targeting in post-processing to apply a class for images that deviate from a regular ratio. An even simpler solution would be to just make all inline symbols the same height to width ratio, adding negative space to produce a consistent output.

Text Wrap and Column Span and other very InDesign things

The document was initially constructed using some of the more advanced the tools that InDesign provides, allowing the layout design to create quick and fluid layouts, but I found that the advanced layout features weren’t respected in the export process. The solution to this was fairly straight-forward, but once again, time-consuming. I deconstructed the text boxes and then reconstructed them manually to match the more automatic layout. As a layout method, this makes the construction of the document a little more time-consuming, but I don’t think is overly cumbersome, since it also strongly integrates into the Article process needed for export. Creating a consistent layout this way requires eye-balling positioning, or inputting exact measurement to ensure consistency, but using a strong grid system as part of the layout design could easily eliminate this issue.

Classes

The true hope coming into this was that a well-constructed HTML documented styled with CSS and a well-constructed InDesign document actually share a lot in common. Character, Paragraph and Object Styles in InDesign work similarly to CSS classes, as both have a hierarchy of shared characteristics, so it made sense that the two systems would be easy to integrate. Unfortunately, I discovered that the export process removes the based-on system of InDesign and just exports the styles as a single class, which meant that I needed to target a lot of classes to make changes. Additionally, any minor tweaks that are made to suit the physical layout of objects on pages can get carried into the web document as individual classes or IDs (like classes but more unique and powerful). Altering the styling of text in the initial export meant targeting a vast number of classes, even if those classes all had the same base style in InDesign, and often the targeting wouldn’t work because there were lots of tiny overrides.

The solution for this was to bring CSS-style class-based thinking and name construction into InDesign, and it was this solution that ended up being the cornerstone of the project. By naming styles in InDesign as I would in a web document, I was able to post-process the HTML document to separate the single class names from InDesign into multiple classes for more control. Once I discovered this solution, I was able to integrate layout concepts into my Object Styles, creating direction in my InDesign document that would flow into the web document to be used as CSS. This process was fairly lengthy, but the core of the system constructed would be applicable to any living digital adaptation, providing a solid foundation for future projects.

Web Design and Styling

The final step was the actual web design. As a new system with a bunch of information pushed through from the InDesign export there was lots of small issues and conflicts to resolve. As the duration of this project was quite lengthy, I came back to the project every month or so, with fresh eyes, and explored multiple layout solutions. In the end, I deviated further from the aesthetics of the rulebook to deliver a more clear and visually consistent document. One of the final changes I made was to change the visual delivery of the sidebar content. I felt that the ribbon graphic was too strong of a visual element, as it separated the side content from the main content too much, and became even more obtrusive on small screens. By removing the background graphic and adding some less obtrusive style indicators, I was able to respect the design intention and deliver a visually cohesive page.

Version History

Adding version history to track changes was a reasonably simple implementation at the end of the project, that was easily integrated into the constructed system on the web design side, but to track the changes it was necessary to add extra content to the InDesign file, which I didn’t want to print or export to PDF. There was already an in-built solution to this, with the Conditional text feature of InDesign, which allowed me to both display my cake and print it.

Navigatibly / Shareability

When I showed an early version of the page to Allen Chang, the Creative Director of Rule and Make, he suggested that it would be helpful for players to have a way they could easily link to and share content. At this point, I had constructed the system, and adding on a few extra functions was simple, but still time and resource intensive. I was able to generate a linked Table of Contents through InDesign, and use those links as shareable anchors for the page.

The Final Product

To evaluate the final product, you can explore the finished page, and compare it to the up-to-date PDF here. In my next post, I will evaluate the project according to my initial goals, and explore some ideas about how this system could fit into the industry, and evaluate some potential candidates for adaptation.