bookmark_borderLooking forward

2011 looms larger and larger in my view and as we start to plan out our goals and aims for the coming year, so I find myself increasingly struggle to make time to write some blog posts, add to that a couple of weeks of food poisoning, and I’m a little behind with things.

That said, it is looking like we are well placed to enter the new year with all the foundations in place to make measureable improvements to the information we offer. We have routes into customer projects via support call outcome codes (if it was an information related issue, I’m contacting the project to see how it arose and what we can do to fix it), stats on what areas of our knowledge centre are being accessed down to the topic level, via our recent upgrade of Author-it, which will allow us to target the areas of the documentation that are being most heavily used, and we will soon be launching a Q&A style forum within our developer community website, allowing a level of user-generated content to be available to all of our customers.

Personally I’ve started to get to grips with the ISTC website and hope to use some of the time available over the holidays to crack on with moving it to a CMS. There is some restructuring required as well and I’m hoping to start adding some new sections in the early part of the year, more on that nearer the time!

To everyone who has visited this blog, I wish you all the very best for the coming festive period, and in to the coming year!

bookmark_borderBack to DITA?

I’ve mentioned DITA a few times on this blog, and my DITA is not the answer post is still attracting attention. As I’ve said, I think the DITA standard is an excellent one for software documentation and the DITA movement is slowly catching up to the hype. I’ve never given up on DITA and had always planned to use it as the basis for the next stage of our content development, and as it happens the switch to a full DITA/CMS based solution may be closer than I had anticipated.

We have been considering how best to publish up to date information in keeping with patches and minor releases, and if we can tidy up and publish useful information from our internal Wikis and support system. The nature of the product we work with means there are a lot of different usage patterns, not all of which we would document as they fall outwith typical (common) usage.

So, how to publish formal product documentation, in-line with three versions of the product, in PDF for ‘printed’ manuals, JavaHelp to be added to our product, and HTML to be published to a live website alongside other technical content (ideally maintained in the same system as the product documentation). Storing the content as XML chunks also allows us to further re-use the content programmatically (which can be tied into our product in a smarter, dynamic, fashion).

The obvious answer is single source using DITA to structure the content, storing the content as XML to give us the greatest potential avenues for re-use. Nothing particularly startling there I know, but it’s a switch from the direction we had been considering. So I’ve been catching up on what’s new in DITA-land and have to admit I’m a little disappointed.

We already have FrameMaker and Webworks in-house, although both are a couple of versions old, and thinking we might keep using those applications I’ve been hunting about to see if I can find a solution that offers a coherent, end-to-end, story. There are several CMS solutions which require an editor, editing solutions which require a CMS, and a few products that straddle both CMS and editing but then require publishing engines.

I understand that it would take a collaboration between vendors to be able to offer a simple, seamless solution

In addition to that there does seem to be a tendency for any DITA focused solution to remain the remit of the overly technical. Don’t get me wrong, I’m quite happy delving into XML code, hacking elements, or running command line scripts to get things done. But surely I shouldn’t have to resort such things? Now, I’m sure there are many vendors who will tell me that I don’t need to worry, but I’ve seen several demos and all of them miss a part of the FULL story.

Come on then vendors, stick your necks out. If you are a CMS provider, then recommend an editor. If you sell editing software then talk nice to a CMS vendor and start promoting each other (yeah Adobe, I’m looking at you!).

And yes, I’ll happily admit that maybe I’m just not looking closely enough. If only there was some sort of technical community website that I could join, perhaps with a group or two on DITA? That’d be great.

Ohhh wait. There is! (not the most subtle plug in the world, was it? I think the new Content Wrangler communities could be a big hit, do check them out).

Have a got the wrong end of the stick, are there really gaps in the market in this area at present or is it just my imagination? I guess I’ll be running a fair few evaluations over the coming few weeks and, of course, I’ll post my thoughts and findings here.

bookmark_borderAgile Source

If you are working in an Agile environment, and don’t have “single source” in mind when you write then you are slowing yourself down.

Working in an Extreme Programming environment (an Agile methodology that our Development Group follows) brings a unique set of challenges. During the early stages of a release, we spend a couple of days thinking about what we will be building, writing out the requirements as customer-focussed stories and breaking down those stories into discrete, small, chunks of work each of which has an estimated time for completion.

We don’t have a project plan, and as we work in tight iterations with functionality being released on a regular basis, there is always the chance that the scope will change at some point, generally with little warning. The system is built to deal with this so it’s not as bad as it sounds but it does throw up some challenges for the technical writer.

However with a little thought and awareness it’s a very easy system to work within, but does mean we need to push into other areas a little more.

First up you need to get involved when the developers are writing up the stories. Sit in the customer meetings and any planning meetings. Be the user advocate. Ask questions now. Stories are written from the perspective of the customer (with that customer being the person who requested the functionality) and you can (should!) help to craft these properly, making sure each story remains customer and real-world focussed. Every story, regardless of the functionality that will eventually support it, is a high-level requirement and should be stated as such. The actual work might be to make an object persistent, but the story will only say “The customer wants to be able to view previous transactions for each account”.

You should also be present during the break down of the work. At this point, with each story being broken down into small chunks of work for the development team, you can gain a better understanding of the functionality, including any presumptions and dependencies that may be added. Each piece of work should be no longer than a few days, less is better, and you can start to build an idea of the scope of work during these discussions. As yet I’ve not found any direct corrolation between X days of development work to Y days of documentation work.

So, from the stories, you should have a good idea of the high-level functionality that is being produced, and you can create an outline of the documentation that is required. You should also, having sat in on the discussions, understand the requirements of the customer and the reasoning as to why a certain piece of functionality is, or isn’t, being developed.

The chunks of work can help to feed into each section in your outline, and working to the same principles as the development group, you can estimate each section. Even if the figures are never published, it’s a good idea to take a stab at guess-timating the work based on what you know, allowing scope for research and playing with the software. These guess-timates also re-enforce the fact that you will be working on discrete chunks of work at a time, which should help you cope for descoping of functionality by the development team.

The speed of change is what makes Agile development so popular. If Agile development is the speedboat, the more traditional development approaches are most definitely the oil tanker. Slow to get moving, and hard to stop if a change of direction is needed. Understanding how the work breaks down, and writing in a style that helps encourage and support that, you should be writing discrete chunks of information that can be used anywhere.

In other words, you should be writing as if you are in a single source environment, even you don’t have a database or CMS in place, even if all that content is being held in one document. The principles and structure that single source systems promote will allow you to keep pace with development.

Be the speedboat!

bookmark_borderRecently Read

Another week (and a bit) has passed. Time is tight for me at the moment, and I’m not posting here as often as I’d like so, for now, here’s a quick roundup of everything that’s zipped past my inbox in the past week:

Resources on presentation design

… advocates an assertion-evidence design, which serves presentations that have the purpose of informing and persuading audiences about technical content

Needless to say, with my first ever conference presentation looming, I’m fairly focussed on both topic relevant stuff and anything that will help make my presentation better.

An XML CMS is simple as 1-2-3

Creating an XML-based Content Management System to single-source technical publications is as simple as 1 – 2 – 3. Rather than focusing on any single tool or solution (and thereby forcing users to change to match the tool), this article describes one possible three-step process for using XML to single source your content deliverables.

A rather simplistic view of things, but if you are a bit flummoxed by the raft of information available in this area, and you aren’t really sure where to start, have a quick look at this. Short, simple and easy as A-B-C.

Make your writing east to scan

… the acid test is looking at your information as your reader/user would see it, and asking yourself “can I find what’s important without reading the whole page”?

You can format your text in a variety of ways, but it pays to take a step back and view the format of your content from the point of view of your readers.

Getting to the web-first mentality
Interesting to read that other professions are struggling to embrace the internet. Ultimately I think it’s getting to the point where we just need to take the plunge.

Start putting the web content management system into the workflow at the front end. This could be as simple as using Google Docs as a word processor instead of the bloatware that we know as MS Word.

Collaborate or fail
Titled “Building a Collaborative Team Environment” the opening couple of paragraphs kept me reading:

Technical communicators work hard to meet deadlines and value the standards inherent in the profession. At the same time, they value their personal creativity and the responsibility for developing a complete publication on their own. They tend to enjoy doing everything from writing, editing and page layout, tographics, technical content, and more.

Working as part of a team to create a single set of deliverables, handing over responsibilities to fellow team members, and trusting the work produced by others does not come naturally.

It’s an excellent article, looking at a variety of ways in which we, as technical communicators, can adapt how we work. It will no doubt prompt some posts here as I digest it further.

And on that, somewhat culinary note, I’ll thank you once again for stopping by.

bookmark_borderExplosions: keeping ahead of the blast

Is it just me, or are we seeing a notable growth in the tools and voices linked to our profession? Are we, the technical communicators (writers, authors, designers, whatever..) finally clued in to the internet and making the best use of the global space? Are the tools we use starting to touch other areas of our organisations, thus raising our profile, which raises the bar for the tools, which expands the reach, which raises the profile…

It’s just me, isn’t it?

I’ll happily admit that, a couple of years ago, I was growing apathetic with this industry. I dreamt of working in a zoo, tending to cute fluffy animals and having nary a worry in the world (and likely not enough money to pay the bills). Since starting a new job in January this year I’ve rediscovered my vigour and enthusiasm, and that seems to have been matched by the tool vendors. I would also try and lay claim to the growth in technical communications focussed blogs and websites but that’s a little generous of me I fear.

FrameMaker has launched a new version and a new suite, AuthorIT has launched a new version, MadCap blazed onto the scene (geddit) and ruffled some feathers, and the XML focussed single source arena seems far more active than it was. Now, I’m happy to admit that it may just be that I happen to be more aware of what is going on, but the coincidences are a little too high to ignore.*

Of course what this really means is that, at some point in the near(ish) future, people are going to start to select a tool. The XML guys are reasonably future proofed in that respect for, as they all share a common file format/standard, the choice of tool isn’t the locked in choice it once was. In a way, AuthorIT is in the same boat as they can roundtrip through XML, even though they store their information natively in a database.

But our dear old FrameMaker, despite the new version and a seemingly re-invigorated development team, now sits as the odd one out. When I heard that Adobe had launched a Technical Communications Suite I presumed, instantly, that it would mean “instant single sourcing”. Possibly a simple CMS backend, from which you could pluck topics and edit them in FrameMaker or RoboHelp. At the very least a proper roundtrip between those two tools and, as we now know, we don’t get any of that. In fact Adobe have introduced even tighter coupling between their two applications and I’m still trying to figure out if that is a genius move, or a final throw of the dice.

Regardless of which tool you choose, or which blogs you read, this profession is growing. Links are being established between other groups, and as software continues to increase in complexity the understanding of the need for good documentation is continuing to rise. I’m certainly spending less time explaining both what I do, and why it is needed and that can’t be anything but a good thing.

The ability to self-publish has created millions of “writers”, and an astonishing change to the way people view the written word, in a very short time. Some of those people write about technical issues, indulging themselves by sharing their hobbyist knowledge and, as such, they are both the subject matter experts and the technical writer of their niche.

As a profession, our ability to collate, filter, sort, and organise information, tailoring it for the right audience, providing that information at the right time, in the right place, will be the key differentiator. The playing field is levelling out, but we have some tricks up our sleeve yet.

* I’m deliberately ignoring the HATT arena, if you have any insights there I’d love to hear them.

bookmark_borderX-Pubs Conference

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.
Continue reading “X-Pubs Conference”