Why Doc-To-Help and not a wiki?

Being avid followers of the sea change of social media, our first instinct was to turn to a wiki solution to support real-time, team-wide, distributed authoring. We studied the field, narrowed it to the three most promising candidates for further research, but found no solutions among them.

1. Confluence - Being the one wiki designed expressly for technical documentation, we had to consider Confluence. However, its licensing costs and its relative complexity were real barriers. It also conflicted with our technology: ours is a Windows (ASPX) product, yet Confluence hails from the Java world and does not love Internet Explorer, which is our primary browser. I’d also heard from an adopter that Confluence would choke on the size of our builds to hardcopy formats, as it was only designed to export small subsets of wiki content. 
2. Mediawiki - Being the open-source wiki powering Wikipedia, Mediawiki made it onto our short list. While many aspects of it proved friendlier and attractive, we soon ruled it out because we couldn’t publish out of the wiki format into our other needed outputs, and (more importantly) we could not secure content and access with anything like the granularity we’d need for production work. 
3. Drupal - Drupal was a finalist not only because of its immense capability (as optional modules) but also because we were long-time users: we’d used Drupal for our product’s community site for years, offering blogging and forums as well as wikis of reference information. We could secure it, extend it, completely customize its theme, and probably publish (export) outputs from it, even use complex taxonomies to create a myriad of dynamic content experiences. However, we were on version 4 and would need to migrate to 6 or 7, which would be a serious project. Worse, we knew it’d take significant expertise to program Drupal for our complex documentation requirements — expertise we lacked in-house and probably couldn’t afford to contract for.

Why Doc-To-Help?

In truth, I played with Doc-To-Help 2010 (D2H) before considering it for our solution. Some tweet having pricked my curiosity, I downloaded the eval version and tossed together a project that included the Word outputs that comprised all of our flagship product content. Instead of choking on the tonnage, D2H handily built me a NetHelp site in minutes, not hours. That got my attention: this was not the Doc-To-Help I'd used a decade ago. Its acquisition by a company that made developer tools had resulted in a serious makeover under the hood! My economy car seemed lovingly rebuilt into a racer.

These are the features that merited a proof-of-concept with Doc-To-Help:

• Single-sourcing across build targets: compiled Help, HTML, manuals, training
• Single-sourcing across source types: HTML, XHTML, Word (DOCX)
• Merging generated API and developer conceptual docs into blended deliverables
• Unifying documentation strategy across user and developer docs (one system serves all)
• Support for team authoring in Team Foundation Server (and SharePoint repositories)
• Command-line builds, for automation and continuous integration
• Familiar and available editors for source files (crucial for non-writer participation): Microsoft Office, Notepad++, etc.
• Able to handle the scale of our builds (similar build time to AuthorIT v4)
• Affordability: new licenses for the cost of our AuthorIT maintenance

In posts to come, I'll explain how we managed to migrate out of a CCMS, how our current build system is organized, and where we're going next.

Comments

[Confluence]

Thanks for sharing your decision. I'm glad you found a tool that meets your needs :)

I'm curious to understand how Confluence's licensing costs were a barrier for your team?

[Mary Connor]

The barrier was lack of budget for ANY new solution. Our migrating to Doc-to-Help didn't cost us any _new_ money, in that we had budget for maintenance on our prior tool, and that was enough (thankfully). Perhaps I could have argued my way to new money if the wiki solved integrating API docs and those isolated HTML content files, but I couldn't see a happy path to that.

[Confluence]

Thanks Mary – makes total sense :)