I’ve been tracking the growing scope for “simpler DITA” editors for several years. I’m not surprised that the trend exists–I’ve helped encourage it, in fact. In her post on The devolution of DITA editors, Sarah O’Keefe asks, What is the case for what she calls babyDITA editors? Of course, I have an opinion.
Having watched DITA’s growth from the beginning, I’ve never believed that DITA was just for Tech Pubs, although that scenario certainly informed on DITA’s design. But given the current maturity and power of DITA editing tools for Tech Pubs (or Information Development–ID), I feel that now we can move DITA beyond the fringes of that community, where as a web-oriented standard, there are whole new markets for DITA’s use.
For full-on technical writing, the standard, best-of-class DITA editors are absolutely what is needed. Those are the only tools for that level of job. It’s just that the technical writing job requires more than average knowledge of XML, DITA elements, conditionality strategies, content reuse goals, build and publishing skills, and the procedural know-how to help steer effectively through the full life-cycle tasks that define the job, and these tools typically integrate your access to all those job functions.
For those domain specialists in your company who create content that you wish to bring into a smart corporate strategy, and whose job description does not include “DITA,” these power tools are just not a good fit, obviously. They’ll keep on using what they know and have access to unless you can give them something that they can agree makes sense for them as well as for the strategy. Not that they’ll have to love the new tool, but they shouldn’t have to hate it!
Content from across the enterprise is not only technical, it can come from marketing, business, site news, specifications, HR, company P&P, and more, very often NOT requiring information typing or technical domains. Much of that content has limited intersection with Tech Pubs. But when the directive comes to start implementing DITA across the company, or just anywhere beyond Tech Pubs, the need for simpler and seductive DITA editors becomes much more justifiable, in licensing cost, in training, in centralized IT provisioning (assuming the use of corporate collaboration tools), and more.
I can’t say that my experience using any of the heavy-hitting DITA editors has ever been particularly agreeable or in any way seduced me from other editors. But I’ll bet the business plan for the Codex team is based strongly on providing a compelling, low-barrier experience for these non-ID writers. Once you can get them into DITA, your existing DITA infrastructure can start providing more benefits: federated content sharing via common back ends, consistent appearance thanks to shared production tools and stylesheets, the option of reuse by reference for ID (in that generic DITA generally can be conreffed into any information type, which solves the typing problem), and more.
The full, easy end-to-end functionality for those users is still evolving, but I believe that the need for such tools for non-ID writers is greater than ever, and I look forward to more growth and better definition for the marketable uses for DITA beyond ID.
As the use of DITA grows for content across the enterprise, there are adjustments to make, of course. These tools are not for power tech writers. As many have observed, the features and functionality for working with standard DITA content is just not in these lower-cost tools. Therefore you must resist the thought of turning programmers and sales people into surrogate ID team members–they have their own jobs to do, and using DITA may never be in their job descriptions. But if you can give them a tool that just happens to ease the harvesting of their knowledge in a progressive way, you just might be working smarter rather than harder.
Editors in this category exist for several preferred content architectures:
- Browser based that you integrate into your own Cloud strategies, for which Xopus and DITA Storm are fairly full-featured examples. I’ve used the open source expeDITA Content Collaboration project as a demonstrator for what is possible using native, in-browser editing capabilities (at the Rich Text level).
- SaaS-based offerings, for which easyDITA is a good example. I don’t understand the role of Codex well enough to say that it fits here for certain, but I think it is poised to grow in this space.
- Desktop-based offerings, in which collaboration is through the back end. These are close to full-featured, although not often seen in the high-end lists. Among them are Syntext Serna and XMLMind XML Editor which support DITA collaboration via the WebDAV standard. DITALabs does so via the CMIS standard. And Quark XML Author and Simply DITA for Content Mapper are Word-based add-ons aimed at “seducing” users with deep Word experience (which number in legions, I’m told).
Conventional DITA and XML editors for ID-level use can provide interface customizations that can help simplify the experience somewhat as well. But there is a crossover point where the requirements for seductive user experience and non-expectation of deep DITA awareness drops into the realm of cost and function that the cheaper echelon of tools can provide.
And I have to mention as well my recent series on “Creating DITA” using the flotsam and jetsam of our connected lives–if you caught without your favorite DITA editor, you are not necessarily out of options for still getting your drafts into DITA for the longer haul.
Several years ago, we just didn’t have many lower-cost DITA options to press into beyond-ID usage. Now I’m looking forward to where this larger sea of DITA uptake can take us!