I attended STC UK’s Trends in Technical Communication this weekend. For once, I actually got to be a regular participant in the sessions. And I got to vote on chapter-related matters (as I joined it this year).
Shannon Milsom of Cambridge Silicon Radio delivered an excellent overview of their XML implementation and lessons learned.
When she joined the company eight years ago, she was employee number 69; CSR now employees
4,000 people and 1,000 in the UK1,000 people. They create chips for Bluetooth (market leader), wireless, GPS, and other radio technologies. Most of their customer base is in Asia.
Development is in the UK and UK; “fabless” manufacturing in East Asia. Sales everywhere.
Their original workflow used Word and had all the usual problems you might expect. Styles were corrupt and style guides were not followed. As the company grew, the problems became worse. Single sourcing was needed for shared content; the copy and paste approach led to a risk of missing changes. Content from SMEs needed heavy editing and fixes of bad Word usage — they created their own individual styles and made a huge mess — and that assumes that they actually used the official template.
They had a wide range of content, and they classified it by product status (which is interesting and I don’t think I’ve ever seen before):
- Advance information
- Pre-production information
- Production information
Side note: A slide with the various contributors and roles includes an excellent graphic of the software guy as a hippie California dude with a tie-dyed shirt. Sales and marketing on the beach under the umbrella with a laptop.
Their goal was to have:
- Content re-use
- Cost-effective translation
- Version control
In addition to The Usual, their reasons for moving to XML include the ability to substitute “common text,” such as the product name and number, document type, and document status.
Modular authoring results in a workflow where they build documents from common blocks. If a block has been “released” (I think this means reviewed and approved), it can be used as needed.
Benefits they see from XML:
- Shorter production cycle
- Do more with small staff
- Increase throughput
- Marketing can build documents from signed-off information modules
- Use data direct from source (SMEs)
- Ease checking and sign-off
- Has taken human confrontation out of review cycles…approved modules are set in stone and it’s easier to reject change requests on those modules
- educe composition and review time
- Version control
- Automated system reduces errors — nothing falls through the cracks
- Cost-effective language translation…partial localization to save money over localizing everything
They considered building their own CMS but eventually bought. After a few trials and a false start with a product that didn’t work, they ended up with Ovidius TCToolbox, which they are very happy with.
- Understanding XML technologies is much more interesting than working in Word and not that difficult
- Choosing freeware, shareware, purchase, or DIY is a big decision
- Be sure to choose a mature, well-supported system
- May have to re-invent corporate style to accommodate XML publishing [or face huge costs in replicating existing style]
- Glossary is generated based on terms actually used in the document and pulls content from a 700-entry master glossary
- Solution is still changing
- Beware of solutions that are not fully supported
- Evaluate service vendors by looking at real-world implementations that they have done.
Issues to consider
- New way of working
- Will your tech comm group work this way?
- Can you recruit people who can work this way?
- Keeping a single voice in a single-sourced system
- Learning how to write in XML for content re-use
- Writing for one voice helps translation
- Editor/GUI is important to success
- Getting content directly from SMEs
- Good training/support and actual solution
- Involve authors in the setup of data and design
- Designate information architect for CMS-based solution
- Identify the skills gap
- Test drive the software
- Focus on your needs and examine the existing process
- Do you need a CMS? What about a staged approach?
- Can you create output, symbols, graphics, equations, xrefs?
- Be prepared to make diversions from original corporate style
- Hidden/rising costs?
- Allow time
- Everyone on the journey
- Team for evaluation
- IT system support
- Info architect
- Tech communicators
Today’s language lesson: “trial” as a verb, as in “We trialled XYZ, but didn’t like it.”