As I mentioned previously, the opening presentation at TICAD was by Adobe and featured their vision of the future of Technical Communications and information development. Apparently that future includes video.

Video has been available to many for a few years now, yet it is never really the main focus of a documentation team. Tom has questioned this as well:

“For too long I’ve minimized the importance of the audiovisual. Captivate — the industry standard tool for creating screen demos — is actually a relatively simple application. Mastering it and integrating audiovisual into user help will take it to the next level.”

This echoes what Adobe suggest, no big surprise there, but I have to admit that I don’t fully agree.

As a quick learning tool, I’m sure videos (screen demos) are useful, but I wouldn’t really know as I’ve never used one as a primary source for learning about a product and I’m not sure I know anyone who has. Of course that’s not to say they don’t have value and with some research into the intended audience I’m sure it can be proven that they have a valid place in the product documentation set.

However my initial thoughts on the matter are hard to shake.

It may be one of the unwritten rules of documentation, the rules that few people question and may well be inaccurately applied, but I’ve always operated under the assumption that people only use the documentation when they are stuck.

Of course this is a broad sweeping statement but I believe that it is true for the majority of software users. So, if that is the case, what is their mindset when they finally give in (having asked a co-worker and searched Google to no avail) and fire up the online help or open the user guide? Typically they will be annoyed and want an answer or fix pretty damn sharpish.

Why, in that case, would they even consider sitting through a 2 minute video that explains how to use the functionality with which they are currently battling?

To be fair, Tom isn’t suggesting this approach but I think it’s wise to counsel against this trend lest it be used too heavily. A few short demos of how to complete core tasks, accompanied by a comprehensive help system or user guide is the best balance.

My fear is that the “cool” effect will override sensibilities and we’ll be plagued by popup videos and worse in the future.

The written word certainly isn’t the only way to effectively communicate information, and as technology progresses we will all need to carefully match the available delivery mechanisms with the information we need to deliver. The key word here is “carefully”.

I’d love to hear from anyone who is already doing something like this, I’ve not used Captivate, nor offered any form of video as part of a documentation set before as they didn’t match the audience profile but I’d be interested in hearing how successful they were.

A big hello to anyone visiting from the TICAD conference. I’m writing this post in advance of the conference itself (the joys of scheduled publishing), so hopefully my presentation went well and you found it useful. I hope the page of links I mentioned is of some use to you and anyone else who pondering whether or not a Wiki lies in the future of their organisation (yes, it does!).

The very act of pulling the presentation together has been both fun and educational for me, it has helped me fully understand some things I took for granted and hopefully that is reflected in my words. My thoughts on the experience, and the rest of the conference sessions, will be posted here soon.

If you are visiting from the TICAD conference, please leave a comment, any and all thoughts, feedback and criticisms are encouraged.

Having recently upgraded my MacBook to run the latest version of OSX, I’ve been using the built-in Help to figure out how to configure things to the way I like them. It’s an excellent example of well designed and integrated help. Of particular note is the effect shown in the screenshot below.

An excellent example of integrating user assistance with an in-built online help system. Don’t you think?

Typing in your question to the text box, top-right of the window, dims the contents and ‘spotlights’ the items which possibly match what you are looking for. Smart, huh. There are many more examples of this kind of thing but this one caught my eye.

Over the past year or so, as I’ve started to struggle to keep up-to-date with the multitude of websites that interest me, I’ve increasingly turned to RSS feeds to help me manage the load.

With that in mind, I’ve been compiling a list of Technical Communications feeds that I find interesting. Some are by Technical Writers, some are not, but I generally skim through the new items daily and I’ve yet to have a day when I didn’t read or find something interesting and useful.

If you have an RSS newsreader, then feel free to grab a copy of my subscriptions. If you right-click that link you should be able to download the file, and then just import it into your newsreader of choice (I prefer Google Reader).

And, of course, I’d love to know if I’m missing any. Hope you find this useful.

Just about finished at this years conference and, as ever, I feel fired up to get back to the office and get things moving. Overall the main theme of the conference was preparation, preparation, preparation, mainly focussed around gathering requirements before kicking off a project. Nothing special there but if you are considering moving towards a single source environment, there is a LOT of preparatory work you’ll need to consider.

I’ll amend this post tomorrow with some notes and thoughts from some of the sessions, but overall I’d highly recommend you visit X-Pubs next year. What follows is largely compiled from scribbled notes and random thoughts, but hopefully may be of interest. I’m not sure if copies of all the slides will be available on the X-Pubs website at any point, I certainly hope so.

Like most people, I ‘fell’ into the world of Technical Communications. I didn’t choose this career, and like many I didn’t study anything that remotely involved writing. But then, who really knows what they want to be when they are choosing what to study at university.

So, after spending a few years learning about Electronic and Electrical Engineering, and largely finding the entire experience boring, I packed that in and somehow found myself working as a Technical Administrator for a small local software firm. My Mother had spotted the job advert in the local paper and the rest, as they say, has passed under the bridge…

Having spent some time helping out at a local community centre, creating flyers and brochures for local charities and organisations, starting work as a Technical Author was a departure into a new ‘technical’ world. I learned a lot of things in that first job but the most important things can be easily summarised and stated that as “how NOT to be a good Technical Author”. Still, no-one can say I don’t learn from my mistakes.

Fast forward many years and I find myself in the position of knowing enough about my profession to understand how it can best help the company for which I’m currently working, and being comfortable enough about the processes involved with being a Technical Author that I don’t need to worry about them on a daily basis. I can quite happily paddle along, with nary a ripple cast in my wake. Of course I strive keep up-to-date with the latest fads and fashions in the world of information access and creation, technologies and methods which are constantly on the move, but the changes to the prevalent methodologies within the Technical Communications industry (the draft and review process for example) evolve rather slowly, and I have to admit that the lack of speed of progress in these areas is a concern.

Anyone involved with the software industry will have felt the varying effects of the internet, good and bad, as it has ripped across many different areas of technology, massively changing how people think about information. We, as Technical Authors/Writers/Communicators now work with a commodity which continues to rise in value as more and more people create and manipulate, publish and expose it for everyone to use. It’s no revelation to state that the internet has brought about an ‘information boom’ and this boom means that, for those of us working in the software industry, we need to rise and meet one simple expectation.

I want it now. No, I don’t want to look it up. No, I don’t want to have to read anything. No, I’m not that interested in anything else other than solving my current problem. Now. Please. Thank You.

Not even 10 years ago the expectation was different. The expectation had some built-in tolerance, an acceptance that information may need to be found, or at least filtered, from at least one source. Maybe that expectation was taken advantage of, maybe that expectation gave us an excuse to produce a level of product documentation that was ‘good enough’, as opposed to ‘better than expected’. Maybe not.

The field of Technical Communications prides itself on making information usable. Yes, there is a focus on making sure that information is complete, and accurate, but after that there is little point in having information if what the reader wants to find is hidden away behind some weird structure or methodology with which they are unfamiliar. There are a number of ways to presenting information to the user, and some consistent methods such as a Table of Contents, or an Index being the most common. However these all require some effort and in the age of instant access I’d humbly suggest that there is one growing universal truth by which all information must abide: If I can’t Google for it, why would I bother?

Of course it’s not all bad, one technological advantage of the “Google-age” is the relative lack of work required to make your information available to the mighty search engine. Put your PDFs, web pages, or even Word documents on a website and Google will find it. Simple enough.

However, to fully leverage the advantage and properly embrace the webcentric view so many people now have of the information world, we, as a profession, need to add another string to our bow, we need to master the skill of search engine optimisation (SEO). This is no small task but, naturally, the internet is brimming with information that can help, with plenty of hints and tips to get you started.

The world of information, both creation and usage, continues to change, I wonder what other skills we will need to develop?

Next week I’m heading down to Reading to attend the X-Pubs conference, where I’m hoping to learn more about both how a solid XML publishing solution is implemented and, ultimately, why I need to bother. OK, I know why I need to bother so I guess I should re-phrase that to “how I justify all the effort involved”.

I’ve done my fair share of research in the past, and have previously implemented an AuthorIT based solution. That worked reasonably well for our needs back then, but I’m with a different company now and the needs have, naturally, changed. I know all about the benefits of single sourcing content (re-use), and why XML is the best choice for storing that content (re-factorability, if that’s a word!) but as yet I’ve still not seen the killer product/solution that makes things:

1. easy to implement – I’ll accept some pain but most of the solutions I’ve seen have a fairly large knowledge mountain to climb
2. easy to adapt – I have, currently, very specific needs dictated both by the company and our product, and by my the needs of my team.

Of course no such solution exists, or we’d all be using it, right?

And that’s why I’m attending the X-Pubs conference.

I do believe that single sourcing is THE way to go about things in technical communications, almost (implementation costs aside) without reservation for any size of team and almost without regard for what they are producing. Like here in the UK, which is trapped between imperial and metric measurements, the technical communications industry seems to be a mix of differing output requirements. Some audiences demand printed manuals, some want websites full of searchable content, whilst others are happy with PDFs or online help. And that’s before we start worrying about localisation (localization).

I’m not entirely sure what I’ll discover at the conference, and I’m doing my best to keep an open mind, but I truly believe that the power of single sourcing will remain the refuge of the few until someone comes up with a workable, affordable solution that everyone can use.

I’ll be posting from the conference (possible even “live blogging”), so come back on the 4th June to find out what’s going on.

Do you single source? Or have you consider it in the past but never pursued it, and if so, why not?