Development services for technical publications
Mekon’s development team continue to enhance and update the notus and Eclipse range of applications as standards and industry needs change. In addition, Mekon also produce custom applications for customers to address specific tasks.
These custom developments can take a variety of forms, including:
Mekon take care to define the customer requirements in detail before starting work to be sure that the result delivers what the customer needs. A written functional specification is included as part of any quotation for the work.
Mekon will use a variety of technologies, selecting the most appropriate for the task, and can support both SGML and XML content.
Mekon can also provide continued support for the custom development. This can be either long-term support or just for the initial implementation period. Although all developments are tested by Mekon it is expected that the customer will test for themselves with a greater range of content and situations to identify any issues at an early stage.
Further information
Please contact us using the form at the bottom of this page or via contact us page
Resources
Development in XML XSL stylesheets
Example development projects
Our client needed to be able to publish manuals that conformed to the AESP formatting requirements in Def Stan (Defence Standard) 00-601.
The source data was to come from S1000D data modules. There is an immediate problem in trying to take S1000D and present it as an AESP: the AESP has 2 separate hierarchies in the content but S1000D only has one. There is a hierarchy of heading levels and a separate and independent hierarchy of paragraph numbers for AESP, whereas S1000D’s heading an paragraph levels are tied together. The first thing we had to decide with the customer was how to create writing rules for the S1000D content to manage these hierarchies.
Other challenges for this project included some special handling of applicability. The customer wanted BookBuild to be able to analyse the applicability applied to the data, then decide automatically whether to build common chapters, or model-specific chapters. This special applicability handling is triggered by additional processing instructions in the Publication Module.
The project has been a great success. The end user is the UK MOD who have been very happy with the look and feel of the publication. It works and feels like an AESP, even though the underlying data is S1000D. Our client is also happy at the speed with which we did the initial creation of the build application, and how rapidly we have work through the finial stages from initial beta, testing with the client, changes and final delivery. By ensuring the client could keep their data in S1000D, benefiting from the modularised structure and applicability to manage the model variants, we were able to save them lots of rework and repetition of data, compared to if they had to rewrite everything in a traditional authoring tool to achieve the AESP layout requirements.
Our client was using Arbortext and our Eclipse ATA plug-ins, but needed customisation of the output. This initially entailed work to create new stylesheets developed using Arbortext FOSI (Formatting Output Specification Instance). FOSI is a stylesheet language written in SGML. After the initial customisation work, the project expanded to include new ATA document types such as the Fault manual and Wiring manual.
By bringing all of their manual production into one system, our client was able to simplify their technical documentation production environment. Authors only need to learn one product and workflow is simplified. Production to delivery can all be completed in Arbortext using the relevant authoring tools and stylesheets.
In the Aerospace and Defence team, we have had a long association producing applications for the UK MOD and in particular RAF Handling Squadron – now the Defence Aircrew Publications Squadron (DAPS). One of their specialist products is Flight Reference Cards. These are a set of cards, usually loose bound in a ‘flip’ format, that are small enough to be carried by aircrew in the cockpit. They are designed very carefully, with clear indexes, thumb tabs, and strict style guidelines to assist the finding and using of information quickly and accurately. Indeed, some of the drill and procedures in the FRCs may literally be the difference between life or death.
When approached by a major aircraft navigation system manufacturer, we were able to take those years of knowledge of the best practice for producing FRCs and help this client produce new stylesheets for FCCs for their navigation equipment. One important aspect of this project was having the source data in S1000D. ‘Crew’ was introduced to S1000D at Change 1.6 and has developed over the years with all the structures necessary to support FCCs. However, taking that information into a stylesheet to build a comprehensive set of cards is still a complex operation. Drill groups and tab designations drive the marking of the cards to highlight the information types (eg red tabs or card edges to denote emergency or warning drills). To be able to produce a full set of FCCs on an almost turn-key basis saves an incredible amount of time and effort in formatting and layout for even a very skill technical author.
As our Crew stylesheet has developed it is now being used by more clients, so we have made it available as an option in our notusBookBuild and notusCSDB Publishing Engine tools.
One of our long-term clients is a 5th-generation military aircraft project. When the project started S1000D was in its early days of being a public standard, still in SGML only and lacked several structures the project required. The project customised their DTDs to add these enhancements and Mekon provides the stylesheets and BookBuild capability to produce their FRCs and Aircrew manuals. The FRCs are loose bound and are updated by issuing replacement cards. On occasion, new material being inserted will be greater than the space available. Mekon’s solution allows the use of ‘point’ cards, eg 6.1, 6.2, so that new material can be inserted in logical sequence without having to reprint (at high cost) entire sets of cards.
Having maintained this long relationship with our client, we have been able to work with them in looking to the future and improving their documentation environment. We are currently looking at the viability of migrating to a modern version of S1000D, that now has the capabilities that were missing all those years ago. Key to the success of this study, alongside the feasibility of mapping the bespoke structures and current content to S1000D, is also being able to look at the potential benefits of moving to a ‘standard’ implementation of S1000D. Among these will be a move to industry standard tools removing the need to maintain bespoke systems. However, another potentially much bigger benefit would be data exchange with suppliers. Data cannot currently be automatically integrated from external sources as there is no compliant standard. Moving to S1000D would allow a much wider range of integration and prevent the need to either rework data, or embed PDF copy, losing the benefits of electronic delivery. We hope to be able to report back in the future with the outcomes of this study.
Contact us now
Fill in the form below with a brief message about your requirement and one of our team will be in touch to help.
