TechWhirl Sponsors

About TechWhirl

TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.

For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.

There's no need for the server to connect to the internet. The server can (probably does) include its own HTTP stack and serve up the docs within the intranet. That's how my product works... It's a VM appliance that runs inside the firewall. But since it's got a doc server, I get to do stupid pet tricks. So you could include PHP apps, serve your docs as a local WIKI, map into MySQL, or whatever. In my case, the law was set down to have minimal footprint on the server, so I do most of the processing in the browser (javascript). But that's not the main issue at this point. The main issue is that you can serve the docs from your product with all the capabilities that come with a doc server. Most groovy.

And... As this architecture for "products" becomes increasingly prevalent (thanks to VM and cloud infrastructures), users will come to expect that kind of capability in your docs.
Of course, I have a vision of distributed docs (4D Pubs -- see slides on
my LinkedIn profile), and would like everybody else to fit into that
framework. But again, that's beside the point.

Thanks, Chris. This is really useful. Although the product runs on a server, the server is not connected to the internet. But even so, your ideas are really great. Some are feasible from the first delivery (end of year) and some will be in future versions.
:)
Erika

You're in an awesome position -- the product is a server which means you can do anything you want with the docs. Here are a few things users are starting to consider... In the not too distant future they might become expectations:
* Social input -- Both in the private group (behind the firewall) and the outside world
* Responsive design -- Format according to device (tablet, phone)

This is on top of the usual suspects such as a TOC, search index, glossary, links, context-sensitive (well, context-specific) calls, media, etc.

My product is similar, and I'm lucky enough that the company let me invent my own system. I deliver raw DITA, and convert it to HTML on the fly. This gives me room to inject things dynamically at the last minute. At this time I can:
* Filter by user type
* Convert printable content into HTML forms -- I do this for the API docs
* Call the product API to inject real-time data

I'm working on other capabilities according to time and need. And yes, we still ship a PDF, so single-source turns out to be a requirement.