The decline of the gerund in technical documentation?

Louise Downe, who works at the UK’s Government Digital Service, wrote a blog post (Good services are verbs, bad services are nouns), where she stated:

“After several rounds of user testing, the Home Office changed the name of ‘Immigration Health Surcharge’ to ‘check if you need to pay towards your health care in the UK’ – a service that allows visitors to the UK to pay for the cost of healthcare.”

Screenshot of Home office page, where  Heading uses "create"

Continue reading

What capabilities do Technical Authors want in an authoring tool?

We were contacted last week by a SaaS developer who wanted to know if their solution might be of interest to companies needing to write and host their product’s user manual or online Help content. So what capabilities do Technical Authors look for in an authoring tool?

There were a few features that sprung to mind:

  • Multi-channel publishing (for example: publishing to the Web, Microsoft Word and PDF). PDFs are still important as a publishing option, as people still like to read good quality printed content.
  • Separation of look and feel from content.
  • Content re-use (write once, re-use many times). This is different from simple cut-and-paste.
  • Variables (so it’s easy to change product names).
  • Conditional text (content that can vary depending on the type of user or type of product).
  • Link management (being able to find content in the project quickly, as well as being able to manage the dependencies among links and topics).
  • The ability to handle larger documents (200+ page documents with screenshots on most pages)
  • Expanding/collapsing table(s) of contents (and even different tables of contents for different types of users).
  • A user-friendly authoring environment.
  • Version management of the content.

Ideally, there would also be:

  • A way for occasional users to add and edit content without breaking formatting styles, using a User Interface that didn’t overwhelm them.
  • Access to and shared management of the content. This is so that writers could collaborate with each other, working on different topics for publications at the same time.

Are there any other features you would expect?

Issues for developers moving from on-premises software to Software as a Service.

On Monday, I spoke at the Visma Developer Days conference in Riga, Latvia, about some issues software companies have to address when migrating from developing on-premises software to Software as a Service.

One of the of the biggest changes is that the revenues are spread over the lifetime of customer – they pay on a monthly basis rather than an initial up-front payment. It becomes vital customers don’t give up on using the software after only a short while, because you won’t have earnt much income from that customer. If the software is difficult to use, and if users cannot find the answers to questions when they need them, there’s a good chance they will stop using the software, and stop paying their subscription fees.

We’re seeing a number of software companies changing their approach to providing user assistance (user documentation). More companies are thinking about it at the start of the project, so they can do a better job of delivering user documentation than they’ve done for on-premises software. They’re seeing documentation as part of the customer journey, and part of the design process.

This is welcome news, although it requires development teams to combine product design with information design. I wonder if there’ll be similar trends emerging at the next conference I’ll be attending – MadWorld 2014.

Technical writing in the Cloud

One of the most popular developments in computing in recent years has been the emergence of cloud-based computing and Software as a Service (SaaS). Examples of cloud-based computing include Google’s GMail: Instead of an application being installed locally on a user’s computer, it runs on a remote server, accessed via the user’s Web browser.

So is technical writing likely to move to the Cloud? Let’s look at the different approaches.

Why would you want to write using a cloud-based application?

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.

There are other reasons, why you might also consider moving to a cloud-based solution:

  • If you have staff, a technical writing partner (such as Cherryleaf) or contractors working remotely, cloud computing means you can quickly and easily add them into your authoring environment.
  • If you want to work in a collaborative authoring environment, cloud-based applications typically enable you to do that.
  • If you use a third party company (such as Cherryleaf), you have the opportunity, at a later date, to log into the system and make any minor updates (following updated releases of your product) yourself.

Check in/out

You don’t necessarily need to move to a cloud-based environment, if you want to have remote workers and/or collaborative authoring. The most popular authoring tools, such as RoboHelp, FrameMaker and Flare, use a check in/out model instead of a cloud-based approach. Writers can “check out” a topic from a project and work on it remotely. They can then “check in” the completed topic back into the project, via email or SharePoint.

Your authors will all need to have the Help Authoring Tool on their computers, and you cannot watch them as they write, but it’s worth considering.


If you’re looking for a SaaS authoring tool, then there are a number to consider:

  • DITA-based authoring applications and services, such as Doczone, DITAweb and Stilo Migrate
  • Help Authoring Tools, such as HelpConsole and Author-it Live
  • Wiki-based technical authoring applications, such as Mindtouch Cloud and Atlassian OnDemand
  • Word processors, such as Google Docs

You’re usually unable to add any additional plugins, which you’d be able to do if the software was installed on your computers or servers.

You may also need to consider where your data is actually being stored. Data privacy rules differ in the USA and the European Union –  the USA’s Patriot Act, for example.

Your own private cloud (VPN)

Some organisations simply add remote workers to their existing network. The organisation has its own private cloud, a Virtual Private Network (VPN). Typically, it’s up to the IT department as to whether a remote user will be given access to a system. You may need to acquire licences, and you may need to wait for IT to set this all up for you.

An alternative approach is to create a private cloud for your own department. You can create a server in the Cloud, using Amazon’s EC2 service, or using alternatives from companies such as RackSpace or Microsoft (Azure). On this server, you could install for example, a customised version of the Authoring application (containing all the plugins and macros you require), and provide remote workers with a web address, user name and password for them to log in. With VPN server prices starting at $20/month, it’s an affordable option.

If you decide to do this “under the radar” (i.e. don’t tell the IT department you’re setting up your own VPN), you need to make sure you’re conforming to your organisation’s IT security policy. Otherwise, you could be in trouble.

Are you writing in the Cloud?

The reasons for using cloud-based applications seem to be as valid in the Technical Publications department as in other departments. So it’s likely we’ll see a growth in the uptake of this type of service.

  • Are you writing in the Cloud? How have you tackled this problem?
  • Is writing in the Cloud a good idea?

We welcome your comments.

How the curse of the jilted Technical Author hit Google

Beware the software developer who releases software without adequate user assistance (in plain English: user guides and online Help) for “The curse of the jilted Technical Author” may strike your product.

This curse has just hit Google, who last week announced the demise of Google Wave.

Google released Google Wave without any online Help or a guide for users – just a 45 minute video and two shorter “getting started” video guides.

We blogged at the time of its launch that this could hamper the uptake of the software, saying:

While the application clearly works (although there is some uncertainty as to whether some behaviours are “features” or bugs), this unfamiliarity means that users could give up and reject the application.

(See Google Wave – A case study in 21st Century User Assistance and Google seeks to increase uptake of Google Wave by introducing witty user documentation)

As more complex software is released as “Software as a Service” and delivered as “in the Cloud” software, it’s likely more users will struggle and stop using the product – that is, unless adequate Help is provided as well.