A good hockey player plays where the puck is. A great hockey player plays where the puck is going” — Wayne Gretzky
When it comes to technical communications are you a good player or a great player? Is your team simply reacting to the latest trends or is it anticipating what your customers will need six months or more down the line?
The past five years have seen companies rush to adopt component content management. The trend is driven by a desire to cut translation costs and increase efficiency—but more alert players recognize the potential of the technology to reinvent content delivery and dramatically improve the customer experience. If you understand your customers’ needs and expectations it’s a great opportunity to go mobile with your content.
The writing is on the LCD display—mobility is emerging as a major driver of future revenue opportunities. Tablets and smartphones are quickly becoming the primary means of consuming information. Consider these numbers: Apple has sold over 50 million iPads since introducing the tablet two years ago.
Ignore the trend at your peril. Global IT executives aren’t—84% of the 400 who responded to a recent Accenture survey say they're convinced that mobility will significantly improve customer interactions.
If you aren’t considering the mobile future, you’re already behind the curve. And the longer you wait, the wider the gap becomes between you and competitors who “get it.”
Do you know what your customer needs to succeed? Do you have a strategy in place for moving from conventional document delivery to a Content-as-a-Service (CaaS) model that gives your customers dynamic and instant access to information?
If you want to improve customer interactions you need to better understand what motivates consumers and how timely access to information helps them succeed.
The “win” is a formidable one—mobile devices make it possible to deliver information where it has the greatest benefit—the point of use,.
Instead of chasing the puck, you need to start anticipating where it's going. Adopt a heads-up approach that lets you capitalize on major trends shaping the future and creating opportunities to fundamentally change how customers access and use your content.
Those who are content with being good respond by making incremental adjustments to things they already do well. But those who aspire to greatness will seize the opportunity to transform themselves and win market share.
I've been involved in processing XML for about 10 years. Most of that time the tool of choice for taking XML from one format (DITA, DocBook, RSS, etc.) and transforming it into another format has been XSLT.
Most of the XML transformations I've worked on involve leveraging an existing library such as the DITA open toolkit, or the DocBook stylesheets. The DocBook stylesheets are a suite of XSLT files that make it quite easy to build nice output in multiple formats (PDF, HTML, Microsoft Help), and support translating the content into multiple languages.
Some really bright folks have created some very powerful libraries with XSLT, that do make it much easier to work with DITA or DocBook and get output in multiple formats.
Anyone with the challenge of selecting a technology direction and strategy needs to consider several factors when making a decision. Here are factors I consider when making strategic technology decisions:
- Does the technology fit the problem?
- What is the learning curve for adopting the technology?
- How maintainable is the solution going to be?
- How flexible will the solution be?
- Is there a community of experts to help and to hire?
- Is there an exit strategy if the initial approach doesn't work out?
- How much effort and money are needed to get started and to grow?
XML gets very high marks for resilience, flexibility, and supportability, and usually, suitability.
In the area of Documentation and Learning, DITA and DocBook both allow companies to enrich content by embedding semantic intelligence in the text. An XML can allow the same content to be used in different contexts. DITA, an XML vocabulary and information architecture for documentation, also scores very high on these criteria.
What are your criteria? What else do you look at when selecting a technology for specific problem?
Next time: Ruby vs. XSLT for XML processing