What do we want?

At TCUK12 this year, I chatted with several people about authoring tools. Vendors, other technical writers, managers, I asked the same two questions, again and again.

What authoring application do you use, and why do you use it?

The answers were illuminating, interesting and always useful. There are many, many options out there, catering to many different needs, and all of them have a different set of strengths and weaknesses. Alas, no matter how hard I tried, regardless of how many ways I tried to bend our requirements, all of those conversations led me to the same conclusion.

No-one out there builds what we want so we may have to build it ourselves.

As part of improvements to our content, one of my team has led the charge to restructure our information. She has a passion for information architecture and devised a three pronged approach to our content. You can either navigate in by role, by product area or… by something else we haven’t yet decided upon.

We’ve audited the topics we have and applied some simple structuring decisions and it is looking good so far. The problem we will soon have is that we will need to build this new structure and make it usable by our customers.

What we would like is to be able to tag our topics, and use those tags to present a default structure to our information. The tags would also allow users to filter the topics they see and, either by addition or subtraction, create a unique set of information for their needs. Ultimately this would lead to personalisation of content in a basic form, but that could easily be enhanced to provide a smarter take on content for each user.

Alas it seems that, without doing a lot of customising of an XML (most likely DITA) based system we won’t get near that and even the products that get close require a compromise somewhere. Most of the time it would be, for the team of writers, a step back to a less friendly interface, and more exposure to the underlying technology of the tool they are using. At present Author-it provides a simple authoring environment that allows the writers to concentrate on writing content.

But perhaps that is the point. Maybe it’s time to try a different set of tools, adopt new working practices, take on a the bigger challenge.

Written By

Long time blogger, Father of Jack, geek of many things, random photographer and writer of nonsense.

Doing my best to find a balance.

More From Author

You May Also Like

Reasons to work

Hotel Life

Everything changes


Hi Gordon,

It seems to me you were asking the wrong question. Until half way through this post I was going to suggest “Why no customise rather than build”, but by the end it seems clear you’re not asking for an “authoring tool” at all, you’re looking for a client-side filtering and personalisation tool. That’s not authoring, it’s assembly.

One of the major objectives of component content methodologies is to allow the kind of dynamic delivery you’re talking about, but it’s delivery, not authoring. They’re not creating the content, they’re filtering and personalise it into new deliverables according to their needs.

The XML paradigm is that content is separate from the publishing and delivery later. That’s (somewhat) contrary to the HAT, DTP and (older) FrameMaker model at a fundamental level so tools are either designed to be “one stop shops” and you accept that no tool will be all things to all men, or you separate authoring and publishing as you do in XML/DITA.

I agree, there are not a lot “off the shelf” dynamic publishing options at the moment for anything. We usually have a requirements and design phase for each client and we implement something based on our codebase with some variations each time.

*”Why not customise rather than build”
*the publishing and delivery layer

Noz, I agree and that is where my thinking is definitely headed.

Alas if we can’t build it ourselves, or get a reasonably priced solution (less than Β£10k to implement) then it’s a no-go.

I understand it’s complex and needs a good design phase but I think many people would rather save costs and adapt their working practices and outputs upfront, get an “off the shelf” product, and worry about changes later. Just my opinion, but it’s much easier to ‘creep’ purchases than get a lot of upfront spend.

But maybe, with the value of information being realised more and more in organisations, that is changing?

Comments are closed.