Eric Sedor has a piece on tech writing for the cloud

Subject: Eric Sedor has a piece on tech writing for the cloud
From: Chris Despopoulos <despopoulos_chriss -at- yahoo -dot- com>
To: "techwr-l -at- lists -dot- techwr-l -dot- com" <techwr-l -at- lists -dot- techwr-l -dot- com>
Date: Fri, 14 Mar 2014 03:52:58 -0700 (PDT)

Craig said:
Is anyone here already working in the cloud?

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  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.

Learn more:


You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-

To unsubscribe send a blank email to
techwr-l-leave -at- lists -dot- techwr-l -dot- com

Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit for more resources and info.

Looking for articles on Technical Communications? Head over to our online magazine at

Looking for the archived Techwr-l email discussions? Search our public email archives @


Previous by Author: Re: blinking, flashing, pulsating, fading
Next by Author: Re: Eric Sedor has a piece on tech writing for the cloud
Previous by Thread: RE: Eric Sedor has a piece on tech writing for the cloud
Next by Thread: Re: Eric Sedor has a piece on tech writing for the cloud

What this post helpful? Share it with friends and colleagues:

Sponsored Ads