Some Thoughts on Technical Writing in the Cloud

Cherryleaf -- Thoughts on Technical Writing in the CloudCherryleaf has an informative article about technical writing in the cloud. Ellis Pratt writes,

There are a number of reasons why a Technical Author might want to use a cloud-based application. The first reason is cost. Instead of purchasing an application, cloud-based applications are typically offered on a monthly fee basis. If you’re looking to move to a DITA authoring environment, this spreading of costs could prove an attractive alternative to the upfront costs associated with buying a DITA solution. (See Technical writing in the Cloud.)

Cherryleaf lists some other compelling reasons for moving to the cloud as well: it allows new authors to get integrated quickly, it facilitates collaborative authoring, and allows for third-party groups to log in and make minor edits.

I agree that technical writing in the cloud has major appeal. Some help authoring solutions that you install yourself require extensive implementation. It may seem like a cost savings to install and run the software yourself, but if you have to hire an expert to come on-site and install the system, and then periodically maintain it, that expense can add up.

I know that WordPress has offered a choice between the cloud or a local install. WordPress.com is a cloud-based host; in contrast, WordPress.org allows you to download the same software and install it on your own server.

The cloud solution allows you to focus on the content rather than getting wrapped up in technical problems. There’s a strong appeal in that. However, the WordPress.com solution places various limitations on what you can and can’t do. That restriction can often be a dealbreaker. For example, WordPress.com prohibits ads and restricts you to about 150 pre-selected themes. But mostly you have the same potential to write and publish content.

With technical writing, I’d like to see help authoring companies move towards similar models: offer a freely hosted solution in the cloud, but also offer a self-installation solution. Let users choose.

Now here’s the problem. Most help authoring companies charge per license and will place the entry bar at a high financial level. For example, when we looked at easyDITA, the hosted solution cost something like 60k a year. The incentive for the cloud isn’t that strong because help authoring tool vendors don’t have any other revenue model besides the fee assessed on the customer.

But what if the cloud model could function more like Gmail or WordPress.com, offering free or inexpensive solutions? The company could earn money from side benefits such as advertising and add-ons. Even if each webpage had the vendor’s company logo in the footer, that might be tolerable. After all, every Youtube video imprints itself on videos users upload. It’s the price for using their service. Instead of despising this third-party branding, most people have become immune to it. Actually, during a previous usability research session here, when a user saw the Youtube logo on a video tutorial for our software, she immediately said, “Cool!”

The company that makes this cloud model work might be a major player in the help authoring space.

Related Posts

13 thoughts on “Some Thoughts on Technical Writing in the Cloud”

  1. Mark Baker

    Interesting post, Tom.

    In a sense, any CMS is a cloud based system — in cloud terminology, a private cloud. It takes some of the functionality off the desktop and puts it in a central, shared location. Any cloud-based technical writing offering is in some way an extension of that model.

    One of the keys to such a system is getting the division of functionality right between the desktop and the cloud. It is vital to get the issue of when and how data moves between the desktop and the cloud right. One of the big issues with CMS, especially early on, was that the client performance was terrible because of the number of times the client had to fetch data from the server, and when that occurred in the writing process.

    Depending on how your data was structured and how your authoring environment was set up, just opening a document could require dozens of back and forth data exchanges that could leave the author fuming. Dropped network connections could mean lost data, and doing a build, creating a link, inserting a graphic, or opening another document could take agonizing minutes as client and server swapped data.

    When the transfer takes place is really important. Using a version control system like SVN allows you to do all your work on a local working copy of the data and then commit data to the repository periodically. Even if the pulling updates from the repo and committing changes takes several seconds or minutes, each operation only takes place once a day, or when you take a break. Thus there are no network data exchanges while you are working.

    The other extreme is for almost everything to take place in the cloud, with the desktop serving only as a thin client that sends commands to the cloud. In this model, the command the client sends can be small, and therefore quick, or can be handled asynchronously (such as when Google Docs saves a file without you having to stop typing). This allows authoring to be smooth and efficient without having to cache data locally.

    Another approach is to balance what functionality takes place on the desktop and in the cloud so as to optimize the exchange of data across the network. (For example, when you print in Google Docs, Google Docs generates a PDF on the cloud and then sends the PDF to the desktop for printing locally — an elegant distribution of responsibilities.)

    I have not used any of the cloud-based DITA tools, so I have no idea how good a job they have done of getting this right. But DITA, with its constant need for the author to navigate the repository, and its maps with links to hundreds of resources, is full of interesting problems for an efficient cloud-based implementation.

    Such problems are pretty easy to mask in a demo, by using small data sets and choosing examples and approaches with low bandwidth demands, so it is definitely something people should be aware of when considering a cloud-based solution. Bandwidth continues to increase, of course, but then so does traffic and data, so these issues can still have a material impact on your productivity in the cloud.

    One thing to consider is that a system that was designed to run in the cloud is likely to run much better in the cloud than one that was designed to run on the desktop and then ported to the cloud. (The whole debate between RPC and REST architectures for Web apps is instructive here.) In tech pubs, this could mean, for instance, designing your system so that topic files do not make directly hard connections to other resources — which then have to be fetched.

    My expectation is that for tech pubs to really move successfully to the cloud, we will need to see the development of tech pubs systems designed from the ground up to run in the cloud, rather than ports of systems that were designed before the cloud.

    1. Tom Johnson Post author

      Mark, thanks for your comments and explanation about difficulties of cloud authoring. I definitely agree that some formats are much more suited to desktop authoring (and then committing to a cloud repository). Any image formatting or illustrations or video, for example, are much better done on the desktop. But if it’s just writing, pure cloud authoring is probably fine. But you’re right about the intricacies of links and other connecting parts to coordinate. I agree that designing a system to run in the cloud from the start is probably key to its success.

  2. Nancy Thompson

    Our technical publications department uses the DocZone CMS, including a cloud-based repository, local editing with XMetal, and a small “bridge” software program that lets the two communicate. We can add conrefs, resolve them, and link to images in the repository very quickly and efficiently.

    Maybe it works so well because it was designed for the cloud at the outset, as Mark mentioned. And it frees our technical writers from maintaining a server, troubleshooting the transforms, and a whole host of other duties we are not able to perform without a programmer on staff.

  3. Myron

    We did initially consider moving to the Author-it cloud because of Author-it reviewer. Also, from time to time, we get our China office to translate our literature. The option to make the Author-it interface available to our reviewers and translators with authentication tokens from a license pool was very inciting. In the end however, the price and cumulative licencing model did not justify the benefits.
    I believe that cloud-based cms’s offer a lot of flexibility for access and possibilities for collaboration, but costs are unreasonably high to make them viable right now.

    1. Tom Johnson Post author

      Myron, thanks for commenting. I agree that Author-it is fairly expensive. I’m curious to learn more about their newly released cloud product.

  4. DiSc

    Thank you for the interesting article. Maybe an interesting tool is booki (http://www.booki.cc/) developed by the FLOSS Manuals community. I have only read about it and never used it myself. From the outside it looks kind of bare-bone, but maybe it is a decent tool for, say, API references.

    1. Tom Johnson Post author

      Diego, thanks for the note. Yes, the FLOSS manuals community is good example of cloud authoring. Ironically, though, the end product is a downloadable PDF.

  5. branded items

    One of my technical writers asked me how they can leverage cloud computing. Interesting thought!!!. From a developers perspective, we have been talking about cloud as a development and testing resource. For eg. I can easily scale up my resources using the cloud environment if I need to run a scalability test. In the past, I used to raise a request and wait for the resources to arrive before I can even start my test; and I used to call this time as the planning phase. How do you leverage cloud for technical writing?

  6. logo items

    The immediate benefit came to my mind is online collaboration. Desktop publishing is going to be a thing of past. Google Docs (I’ve been using google docs over 4 years now) revolutionized online shared editing though there were other players in the market at that time. Adobe, Zoho, Whiteboard and a number of others came in, but none of them could attract us as much as Google. The latest addition to this list is Microsoft with its office live and SkyDrive. BTW, I just noticed that Office Live doesn’t use a secure connection. Online documents and collaborative editing will help me to update documents the way we add notes or review comments in Acrobat, Word and OpenOfffice documents. It will be faster for developers and testers to update the documents as and when they find some changes required and a team member from the technical writers group can merge the changes easily.

    1. Tom Johnson Post author

      Rick, thanks for the comment. However, why are you adding the addvalue.com.au link as your website? This makes me dismiss your comments as “nice spam.” Are you a real person?

  8. Luigi Fulk

    There are several factors that determine the value of a backlink. Backlinks from authoritative sites on a given topic are highly valuable.[3] If both websites have backlinks geared toward the keyword topic, the backlink is considered relevant and believed to have strong influence on the google rankings of the webpage granted the backlink. A backlink represents a favorable ‘editorial vote’ for the receiving webpage from another granting webpage. Another important factor is the anchor text of the backlink. Anchor text is the descriptive labeling of the hyperlink as it appears on a webpage. Search engine bots (i.e., spiders, crawlers, etc.) examine the anchor text to evaluate how relevant it is to the content on a webpage. Anchor text and webpage content congruency are highly weighted in search engine results page (SERP) rankings of a webpage with respect to any given keyword query by a google user.

Comments are closed.