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.
Julie says the following:
===========
Our product requires access to the Internet (that is, there is a "cloud"
aspect to it), So until that changes, we should be fine with hosted help.
And I've already got a plan for when we finally get a customer that demands
being able to work off-line (and I'm sure that's coming at some point).
===========
It sounds to me as though your product is a client/server sort of thing, and the server is fundamental. So if the server is already there serving up data to your customers, why not have it serve up the docs as well? It only makes sense. And I presume ththat for customers who need to be "sequestered" you will deliver some sort of appliance that includes the server -- probably on a VM.
This is exactly the sort of product that should be serving up the docs from the brains, and not from the individual clients that access the brains. But I would also say, don't go to an external provider for this service. Both points, for so many reasons:
* Keep the docs where they belong -- with the product's brains.
* Re-use... Different clients to the same server might need different docs.
If the server can discern the client role, then it can filter the docs
appropriately.
* Distributed delivery... If you do deliver appliances on VMs, then the docs
should be with the delivered appliance, not with some centralized server.
In addition, if you implement distributed servers that put together supersets of
features, this approach can adjust to that as well.
* Product Intelligence -- If the docs are on the server, then your dynamic processing
can query the server state and modify the docs on the fly.
I actually do this for our product. Our product is a VM appliance that many people access from the enterprise intranet. I deliver raw DITA on the appliance, and use AJAX + XSLT to transform it into HTML on the fly. We have different user roles, and I can adjust the docs accordingly. I also have implemented some API access from the docs to the product -- currently to show examples in the API documentation, but we're looking at using this for self-paced training modules. And I have to say, the work flow is awesome. All I do is edit a DITA topic and commit it to the source repository. End of story. No generating a project and all that. I use FrameMaker, so generating the PDF is also a snap.
If you want to see the docs in action, you can download a free version of VMTurbo and install it in a VM environment. And if you're into VM management you get to see our groovy product as well!
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
New! Doc-to-Help 2013 features the industry's first HTML5 editor for authoring.
