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.
This article is for real, all heckling aside. The cloud (or whatever you want to call it) is all about many service nodes providing many features. The word "product" is changing in meaning. More and more "products" are servers that interact with other servers that interact with other servers... All mashing up data and presenting that data to you in a client GUI. That client GUI is the so-called product a user interacts with. Everybody here uses products like this... Unless you never use Google or Yahoo.
As this domain matures, it gets interesting. The scale for deploying such a service node is shrinking down... No longer do you need a massive datacenter and billions in revenue. You can subscribe to space "on the cloud" that will grow according to your need. On the flip side of this, APIs are proliferating (look into articles on the "API economy"). Why? What do vendors hope to gain by publishing APIs for every "product" they put out there? Simple... There's a market for plugging disparate service nodes together to make unique "products" out of the processing that's out there. If you use my API you pay me a subscription fee, which of course you pass on to your customers.
So laugh if you like, but "...slinging portable, concise fragments of instruction into rich, scalable
user interfaces (while also mapping them to sequential help articles,
blogs, and examples) " is what it takes to support this environment. Because that's what this environment does with the concept of a "product".
This is precisely why I'm developing an open source framework that I call 4D Pubs (Distributed Dynamic Document Display). Distributed documentation is the key... A single, centralized doc server won't scale in this environment (or that's what I assert). Documentation stays with the service node, where it belongs.
I support a product that is in this environment, and enables this environment (see http://www.vmturbo.com/). I had better be ready for the product to succeed, and for this environment to take hold. I deliver our docs in an embryonic version of 4D Pubs. The system loads raw DITA from the server, and converts it to HTML in the browser, on the fly. And I can do cool things:
* Simple, agile doc delivery
* Skinning the "look"
* Dynamic filtering per user role or other criteria
* Modification of transforms on the fly
* Get and use state information from the server
* Execute server actions from the docs
When we add more products to the offering, we'll also offer a client that merges these multiple "products" in a single GUI. I'll then be able to merge the docs from these multiple "products" into a single delivery... Real time and on the fly.
That's what this article is getting at. As you can see, so am I.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Doc-To-Help 2014 v1 now available. SharePoint 2013 support, NetHelp enhancements, and more. Read all about it.
