Guest post by Julia Malkin. This originally appeared on the dita-users mailing list as a response to a query from a list member about whether it was worthwhile for them to implement DITA.
Julia Malkin is a Principal Technical Writer at Endeca. Since 2006, she has pioneered Endeca’s DITA adoption as the DITA project lead and a member of the Information Architecture team. Julia has been following standards and best practices in the DITA arena as well as related authoring, content management, and documentation production tools since 2005, and applied this knowledge when overseeing the implementation of a new XML authoring and production environment for the Endeca Documentation team.
We have implemented DITA at my company during the 2007-2009 years, going from Frame 7 to XMetaL and SVN. The conversion was manual and took so long because we did it gradually, starting from those guides that were the highest priority and/or were new, and then moving all other guides to DITA-based on their priority. I was the project lead and, initially, along with my manager and our editor, we were the team that was both interested in DITA and knew enough to get started. From what you describe, your doc set will definitely benefit from being more modular. It is incredibly useful not having to write content twice or to maintain duplicate content. However, whether getting these benefits is worth the effort in implementing DITA depends on the following factors:
- The willingness of the team to learn and change their ways. Your team’s success largely depends on whether everyone on the team is willing to commit their time and learn. In addition, there are many tasks in the project that could be shared along the way, and it helps tremendously if your team is willing to pick any of these tasks and drive them to completion.
- The willingness and ability of one or two members of the team to serve as project managers. This includes creating wiki pages with information that must be shared along the way, continuous project tracking efforts through some project management software (zen, scrumworks, jira), creating and conducting learning demos/presentations to the team.
- The willingness and ability for one or two team members to serve as information architects. This person would create the new organizational model, decide which units of information you are going to have, and how you will organize them in content sets (maps). This role also includes development of metadata, creation of XML templates for your topics and maps, naming conventions, creation of SVN directory structure, deciding which output types you are going to need and implementing them (PDF and some sort of online output that suits your needs, either Eclipse Help or other), troubleshooting and customizing the production of outputs (online and PDF).
- Finally, there is conversion of the legacy content. At each of these stages, there are consultants and software you could use to help leverage existing accumulated knowledge, simplify and/or speed up the process. It helps, of course, if you have management support, not just at the doc team level but at the larger departmental level.
Looking back, I am happy that we are now a DITA/XML group and that we made the leap. I am also grateful for the learning and professional growth that occurred along the way. Personally, I would also switch from Frame to a native XML editor, because I believe the transition to typed XML-based content is significant enough that it warrants having a truly XML-based authoring tool. It also helps to use an XML-based editor when you must stop relying on an unstructured writing environment of FrameMaker. However, I recognize that switching editors is debatable, and that many writing groups appreciate the numerous benefits of FM, and value them more over other features, such as native XML support.