Explaining My CMS, XML, and Oxygen Experience for Technical Writing Jobs
Introduction
I’ve been asked to explain and clarify my experience working with DITA, XML, and working in a CMS. The
XML tools I’ve used are pretty straightforward to explain. On the topic of CMS, during our interview, I
may have interpreted the questions regarding CMS to refer to the broader use of the term, rather than
specifically technical authoring content management systems. The simple answer is I’ve used both
technical authoring content management systems, as well as engineering organization content
management systems. I’ll attempt to explain below.
CMS and XML at Cummins Power Generation
At Cummins Power Generation, we used the DocZone DITA CMS. It appears that DocZone may now
be defunct, but my former colleagues at Cummins verify that they are indeed, still using the system and
the tools. The DITA CMS was setup in a tree-type structure. There were maps dedicated to models of
generators, with branches extending to types of literature be it, Installation, Operator, Service, or Parts
Manuals. The writer needed a certain mastery of this authoring CMS in order to know how to build a
manual. I had to know which topics to include and which files to “turn-on/turn-off” when creating a new
bookmap.
For XML, we used Oxygen in combination with DocZone. We sometimes would author with the tags
viewable, and sometimes hidden. I could update a topic file in one manual and that would update that
topic in every manual where the file appeared in other bookmaps. I’d also create “project specific” topic
files where I’d make an update that I only wanted to happen in the manual that I was working on, rather
than updating every instance where a topic was used within the CMS.
The engineering/organizational CMS used at Cummins was called Matrix. After our documents were
created and approved in the authoring CMS, they could be introduced to the organizational CMS, and be
put through the benchmarks and checks there before being published to web and print. The author had
to create Engineering Change Orders (ECOs) to bring a document to publish. This was a heavy lift,
requiring knowledge of the system and a level of technical aptitude. Further, the author used the Matrix
system heavily in document creation as many engineering drawings or design specs were held in the
Matrix system. The intent was that technical information held in Matrix was the organization’s “single
source of truth.”
I cannot speak to my level of mastery of these tools, but can explain that I was promoted from Junior
Technical Writer to Technical Writer in record time for the department. I updated existing manuals as
part of the Value Product Change group, and then began leading my own authoring projects, and was
trusted to create new manuals when I became a part of the Value Product Introduction group. I also
mastered our desktop publishing tool, Interleaf/BroadVision QuickSilver.
CMS and XML at Boston Scientific
At Boston Scientific we used the ArborText XML and Content Management environment. I suppose if I
was not clear during my interview, it may stem from how I tend to think of these systems as singular
tools rather than a system or environment. They are content managers unto themselves, but I think of
using the environment as one piece that I need to create a manual. When I think of CMS in terms of my
time at Boston Scientific, my mind goes to Windchill, which I had to use heavily as part of the job.
I’ve actually used the ArborText CMS as far back as 2011/2012 as an Intern for Southwest Airlines. This
was my first exposure to DITA and XML authoring. I felt so lucky to get that experience early on in my
career. I took to the tech well and made many updates to FAA approved manuals. I still have portfolio
pieces from my work there showing the ArborText environment, including my master’s thesis where I
explain authoring using tags. I can provide portfolio pieces if needed.
At BSC we used the DITA CMS end of ArborText as the holder of the bookmaps, written content, images
and illustrations, symbols, equations, dosages, localization-related info, etc. It was a much, much more
complex environment than the DocZone environment I worked in at Cummins. We had a dedicated IT
professional to maintain the system. He was constantly debugging, instructing us on how to not break it,
and always looking for ways to improve it.
For XML authoring, I believe I had tags always on in my user interface. We had A LOT of conditional use
for maps, topics, and tagging. A pacemaker lead, for example, can have a lot of conditional componentry
be it the tip shape (some “grip” the heart while others “screw” into the surface), its MRI suitability (MRI
safe or NON-MRI), if the pacing is active or passive, etc. I had to use the authoring environment to tailor
manuals to the needs of the project.
We published our manuals to PDF, then again we prepped a submission package to introduce the
created manual to the organizational CMS, PTC Windchill. As writers, our Windchill skill had to be on the
same level as our ArborText skill. It was used not only in publishing, but was again one of the sources we
had to scour for engineering drawings, design specs, and other technical info. Bending the system to
your will was a constant endeavor of the BSC technical writer.
While at BSC I gained the skills to update existing manuals, and was then trusted to work on new
product manuals where I created documentation from scratch in the authoring environment. I don’t
consider myself a master of these tools, but I’ve used them extensively and I’ve been entrusted in
previous roles to be given more and more responsibility with regards to creating documentation. My
previous managers knew that I could be counted on to complete complex projects with a high degree of
quality.
