David Farbey tweeted recently on how he had noticed how everyone had started summarising the years 2000 to 2009. As the end of a decade is such a momentous event (?) it is probably inevitable that editors struggling for a story during what is called “the silly season” turn to an easy fix. Not to be outdone, and honoring the fact that I have, officially at least, been a Technical Writer since 1999, I offer my own completely unscientific review of how the technical communication world has changed in the last ten years.

Note: I have split the review up into parts. Part One covers the migration from static offline help to user generated on line help.

Help….WinHelp!

In the good ol’ days when I had loads of money (pre-marriage) a full head of hair (also pre-marriage and pre-work) and technical communicators were easily pleased, I produced my first piece of documentation in WinHelp format. The sleek, familiar user interface made my first foray in technical writing a relative breeze. Oh how the mighty has fallen. One look at a WinHelp project these days makes me wince. OK there were some good things about it (e.g. non-scrolling regions) but on the whole it just doesn’t cut it in today’s feature rich, customer interaction environment. They just didn’t provide enough functionality for the discerning user and we Technical Writers just had to go. Whilst they are still used to this day, despite Microsoft’s best efforts, they are few and far between having largely been relegated to legacy help files for old and tired applications that have yet to be sunset or assigned a budget to upgrade.

The step to Microsoft HTML Help brought with it a rich stream of possibilities to improve user content. Like anything new it required a certain amount of getting used to, not least the fact that it was coded using HTML, but on the whole it was a huge step forward. Just the fact that you weren’t using MS Word as your editor was surely reason enough to change. However rather ironically a number of Help Authoring Tools surfaced that allowed you to generate the required HTML from a MS Word like interface. Now you could produce HTML in from a familiar interface without the vagaries of the familiar application! All of a sudden you could produce your HTML code without ever coding anything. Whilst it is possible to create your HTML topics in Notepad (I know someone who does even now) tools like Adobe RoboHelp provided an MS Word like user interface with which to produce your works of art. Microsoft HTML Help also brought with it a range of new gadgets and tools that allowed you to enrich your content (e.g. DHTML, browse sequences, forms, etc.).

However arguably even Microsoft HTML Help has its day. Whilst CHM files are still widely used and probably will be for sometime to come, the arrival of the Internet brought with it the need for online content. With the concept of a CHM being that they are designed to run on a local PC, we often used to see if we could bend the rules by placing them online. This worked to a degree but the incessant need for 100% security soon drove a dagger into any CHM file located online. They were deemed to be a risk and after Microsoft released Security Update 896358 in June 2005 they could no longer be effective unless located on a local drive.

Online help became the buzzword of the day. Outputs like WebHelp and FlashHelp gave Technical Writers the ability to change from being purely content providers to someone who could start to change the look and feel of the documentation we provided. The advent of skins allowed us to design the interface to the documentation as well as the documentation itself. What is more these outputs were more flexible allowing us to place them on internal intranets or an external site. Now our users could access the very latest documentation without having to install or upgrade an application. What is more, they could do so from anywhere provided they had an internet connection. All of a sudden staff in the field became enabled to find information quickly and easily.

Now I can’t let a review of output formats of the last ten years go by without mentioning my nemesis. For a short period after taking on my current position I was tasked with producing JavaHelp. The misguided decision made before I joined that this was the required output type because our application was written in Java was soon reversed! As soon as I pointed out the long list of its limitations and more importantly the negative feedback we were getting from users, particularly around searching, we managed to get agreement to change. If anything, it was this decision that highlights the changes that have occurred throughout my career. Namely that the documentation function has gone from something that costs, to something that can add real value to the product. The powers to be can see that it eases pressure points and can be a real difference to the overall user experience.