Technical writers are not the only ones who create technical documentation.
Engineers, developers, managers, part-time content authors from outside, technical illustrators, IT teams – they all may participate in the content process in various roles. Their goals may vary from occasional contribution of various types of content to automation of content processing and publishing.
Here are some use cases that we are observing in many companies:
Occasional content contributors: an engineer creates technical specs and hands them over to a technical writer to integrate them into the documentation. Similarly, a technical illustrator may create a drawing that technical writers use in their documentation.
Script processing: the IT team writes a script that automatically retrieves the required files from the content repository and adds them to the software compilation process. In some cases, some kind of bulk processing needs to be run on the content stored in the repository.
Keeping non-structured content together with structured content: in big documentation teams, especially those of them that include teams received as a result of merges and acquisitions, technical writers have to deal with different types of content. While one part of the team is using DITA, other writers may still be using legacy formats. Keeping different formats of the content in different repositories create silos and disconnects teams from each other.
None of these use cases require the same component content management capabilities that technical writers enjoy. Occasional content contributors and IT teams rarely need that level of control. All they need is to be able to access the repository in a simple way that allows them to add, retrieve, or process content.
DITAToo Virtual Drive addresses this need by mounting the database-driven content repository on your computer as a local drive. You get an additional drive letter that behaves as if it were a regular drive.
On this screenshot, you can see drive Z: that represents the content repository. It appears alongside with the actual drives C: and D:. You can now access the DITAToo DITA CCMS repository and perform basic operations, such as check-in/check-out, viewing the version history, assigning a file to another user, and changing the workflow state directly from Windows Explorer. DITAToo Virtual Drive integrates some content management capabilities into the Windows context menu.
Because your computer “thinks” the DITAToo content repository is just another drive, you can also access it from any application in the same way as you would access a real drive. No application-specific plugins or add-ons are required because your application – whether it’s a DITA editor, FrameMaker, MS Word, Photoshop, Visio, Notepad, or a development environment – sees the repository as a regular drive.
This means that your occasional content contributors (for example, engineers or developers) can create documents in Word or Excel, save them to the Virtual Drive and thus, make them available to the technical writers accessing the content repository via the “full” DITAToo UI. Using the DITAToo menu integrated into the standard Windows context menu (see the screenshot above), they can also check-in/check-out their files, control their versions and workflow states, and assign them to other users.
Additionally, your IT team can write a script that accesses the content repository in the same way as it would access a regular drive, retrieves or adds content, and runs any kind of processing (for example, automated bulk publishing). DITAToo Virtual Drive provides a command line interface (CLI) that you can use to programmatically perform some basic operations, such as check-in/check-out, change the workflow state, compare versions, retrieve the translated version of a topic, and so on.
There is one more implication of using the Virtual Drive when it comes to keeping non-structured content in the DITAToo content repository.
Most DITA CCMSs can store non-DITA content. Uploading, for example, non-structured FrameMaker or Flare files usually isn’t a problem. However, because most of DITA CCMSs are designed to work with DITA files, they don’t recognize the dependencies between non-DITA files when you open these files for editing.
For example, a non-structured FrameMaker document will be opened likely without images because the references to the images won’t be resolved. Similarly, opening a non-structured FrameMaker book with all its chapters would require from you manually downloading the book file and all chapter files and then manually uploading them back to the CCMS.
This might be a challenge if you keep working on non-structured content while having other content in DITA (for example, because you are in the process of migrating your legacy documents to DITA). With the Virtual Drive, instead of maintaining different silos for structured and non-structured content, you keep everything in the same repository, under the unified version, metadata, and workflow management. Your non-DITA authoring tools consider the DITAToo repository as a regular drive and therefore, open files with all the dependencies.
Let us know if you recognize any of these use cases and see how DITAToo Virtual Drive can bring a value to you!
Our engineers don't write any thing, but I see how our translation supplier can use the virtual drive. Now I send them dita maps and topics via email. They can use the virtual drive to get to get to the content database, take the files, translate them and upload the translation. Can the virtual drive allow them to upload translation?
Tobias Horn