The starting point of any publication is the Publication Module. This special type of data module provides a catalogue of the DMs that will make up the publication. However, it is much more useful than just a simple list – it provides the structure for the output including section names and structure. The ‘book’ can be broken down into sections (or chapters – name them as you wish) and sub-sections. Also, multiple DMs can be concatenated together into each section or sub-section, providing a more logical flow to the output.

There are several reasons you may need a BookBuild tool:

Data Modules are normally built as standalone items and there is no automatic way of ‘sticking’ them together
Although the Publication Module provides a catalogue of the DMs required to make up your book or manual, there is no automatic mechanism in S1000D to then ‘stick’ them together. It requires an external engine, whether building an IETP or, like notusBookBuild, making a printable publication, to do the ‘gluing’. That engine must be able to read all the DMs, rationalise all the cross-references (including handling duplicate IDs), and do the many other tasks required to join together and logically present the DMs.

That’s all fine, but I’m delivering my DMs as an IETP

There are many stages to getting to the point of delivering finished DMs. Even if your final deliverable is a set of data modules that your customer will load into their CSDB or IETP viewer, that technology may not support the lifecycle of development. How will the publication be verified and validated? Do you need to make a PDF so that the content can be handed over for assessment prior to electronic delivery of the final output? Do you need to print draft copies to support the development of the content in a logical fashion? There are many reasons why we, as technical publication authors, reviewers and managers still like a paper product. Quality Assurance, or proof reading, is a particular skill that is much, much easier on paper than on a screen. While the holy grail of tech pubs is the truly paperless office, sometimes the practicality demands a proof copy.

Although we are delivering S1000D, my customer still wants a traditional book

This is true in so many industries, and especially the aerospace and defence world. Reading an all electronic publication is very difficult. It is great if you are dipping in and out – for example, doing some just-in-time training on a particular process, or working through a standard maintenance procedure step-by-step. However, when you are trying to learn a topic, particularly for crew that need to learn and understand the whole platform, not just a single system, then books still work best.

The readability of DMs is poor

On physical paper you understand the amount you need to read by the thickness of the book in front of you. Electronically this is difficult to comprehend; with data modules in an IETP this is impossible. Furthermore, DMs may often be tiny snippets of information relating to a very discrete item or information type. A data module can be just a few words or sentences. That makes the flow of reading very difficult.

To be able to have a familiar section and chapter layout helps the user understand the content better – the amount they need to read, what logically comes next, how information fits together. Furthermore by using a tool like BookBuild to put together those little snippets, in to well-structured flowing text on a page, avoids all the difficulties found when reading an IETP, rather than just using it to ‘data mine’.

The biggest complaint we hear about electronic publications is poor navigation and being able to find the required information easily. While searching for key words can yield results, it can be very hit and miss. Proper menus and navigation trees are critical.

Because the notusBookBuild engine reads and digests all of the data modules in the publication, before building the book, then every cross-reference and link can be passed through to the build engine. Whether it is internal references like figures, paragraphs or tables, or references to (or even within) other data modules, these are all managed and converted to hyperlinks. notusBookBuild also generates PDF book marks for overall navigation, and within the document pages, the tables of contents, figures and tables. Even the index, if you choose to include the <indexFlag> element to tag items, is auto-generated and hyperlinked to the content.

While all of this takes some effort as an author (for example, you need to think how many ways the users may look up items and then provide that many versions of indexFlag entries), it pays dividends for the user in having a manual where they can find and assimilate the information with ease. notusBookBuild provides the engine to automate as much of that generation as possible.

Contiem have years of experience, supporting customers to manage their S1000D content in an efficient way. Time and time again, one of the key issues is not the content, but the delivery. Ever since we began providing tools to produce S1000D content, we have also been building solutions to deliver that content. Building on the heritage of our FrameMaker Eclipse BookBuild, our new notusBookBuild focuses on those requirements that customer old and new keep coming back to us for – generating books, with options to control the layout and elements. The new notus engine, in partnership with the AH Formatter, is fast. Gone are the days of going for a lunch-break while all the complicated processing happens – notusBookBuild is done in moments, allowing you to review, adjust and build again.