bookmark_borderThoughts on HATT Survey thoughts

Tom Johnson has had a look at the survey recently published by the HATT matrix website on help authoring and, by pulling in the results of some other surveys in the same area, has extrapolated some good conclusions from them.

He rightly points out that surveys need to be taken with a pinch of salt (he goes into the detail of why this is so), and that whilst the numbers involved would seem to be high enough it’s likely that the questions themselves need further consideration in future.

That said, there are two things I took from his post.

1. Know the problem before picking the tool
You may not be in the position to switch authoring tools, but if you are and you have investigated the market then please make sure that you are buying a tool that addresses the problems you have.

The presumption here is that if you have a legacy tool (like we currently do, FrameMaker 7.1) and it still works and meets your requirements then there is no good reason to upgrade. I’ve been victim of buying into the ‘keeping up’ frenzy that software manufacturers like to generate but once a product is reasonably mature it is likely it has most of the features you need already.

I’d offer Microsoft Word as an example here, I could probably still use Word 2.0 for the few documents I maintain in that format as the newer versions add functionality I don’t need (and which has ended up intruding on my workflow at times!).

The X-Pubs conference a couple of years ago had a common, if not publicised theme. Almost all of the presentations included the advice to figure out what problems you had, before deciding IF single sourcing (using XML as the base format) will help and that’s even before you consider the tools themselves.

2. DITA is still a theory
Whilst it is true that the number of people leveraging DITA for their content is rising, the numbers remain low.

Partly that will be due to the fact that few organisations/teams/people are in a position to quickly switch just because a new technology has come along, but and I’ve said this before (in fact I’ve said that I’ve said this before!) rollout of DITA remains harder than rolling out a bespoke authoring tool.

When costing an implementation of a new tool there are various factors and it’s very easy to see that you can get MadCap Flare up and running quickly, where as a DITA based solution takes investment in developing the environment. This is beginning to change but, as yet, the phrase ‘DITA support’ really only means that you can output to a DITA formatted XML file. The tools aren’t constructed around the DITA concepts, so you immediately lose a lot of the benefits that DITA can bring.

Until there is a tool that fully leverages DITA, building it into the workflow of using the tool, and helping the concepts become part of your daily working practice then it will continue to be a marginal player.

Which, in a way, is how it should be. DITA is not a tool, it is a technology and methodology. It is there to support the toolset and the writer. It’s just a shame that tool vendors continue to believe that THEIR format is best, refusing to budge from that position and shoe-horning ‘DITA-esque’ features into their software.

Anyway, the rest of the survey write up is interesting and worth a read but, as Tom says:

“I do love these surveys, though; if for no other reason than they give us something to talk about”

bookmark_borderUA Conference Notes – Day 1

Notes and thoughts from Day 1 of the User Assistance Conference

Session 1 – Tony Self – Emerging Help Delivery Technologies
It’s been quite a while since I heard Tony speak but as ever he provided an entertaining, if somewhat limited, presentation. Covering the various types of help viewing technologies he nicely summarised some of the available choices including the features to look out for, including the ability to wrap up an online help system in its own application (using technology like Adobe AIR). It was interesting to hear some Web 2.0 features making their way into online help technologies, including voting and commenting facilities which would give you direct feedback from the people using your help system.

Session 2 – Joe Welinske – Write Mote, Write Less
Embracing the Value of Crafted Words and Images
Another regular speaker and Joe was certainly fired up, challenging us all from the outset of his presentation to consider how we work in far more detail than we currently do. First up he suggests that we should be writing fewer words whilst making sure those words are correct and so lessen the impact on the reader, providing just the information they need and nothing more.

And then he hit on something that I’ve previously mentioned here (although Joe nailed it much better than I did), namely allocating writing resource to the highest priority pieces of documentation work, rather than the traditional approach of documenting everything. It’s a simple approach that, when combined with better writing, leads the craft of technical communications to provide much higher value to the business which is good news for all of us.

Session 3 – Sonia Fuga – DITA & WordPress Solution for Flexible User Assistance
A showcase style presentation of a stunningly simple concept. With a little bit of coding work (building a DITA importer to get XML content into the WordPress database), the team at Northgate offer a web-based help system which allows users to add their own notes and to vote for useful information, and which is can receive updates with new content with each release.

How? By using WordPress features. Notes are left as comments, votes are left using a WordPress plugin, and the updateable content is controlled by only allowing the customer (who has access to the WordPress admin screen) to create Pages, leaving the Posts controlled by Northgate. I use WordPress for this website, and spoke to Sonia in the evening to confirm some of the finer details. It’s a very clever use of WordPress, and I hope Northgate release their DITA importer to the open source community!

Session 4 – Question and Rants
A short session with four speakers each giving a two minute ‘rant’ and then taking questions. Nothing particularly noteworthy came of this but it’s a good addition to the usual style of presentations and made for a little bit of light relief.

Session 5 – Dave Gash – True Separation of Content, Format, Structure and Behaviour
Another familiar name, Dave is always entertaining and a very dynamic speaker and in this session he even managed to make the somewhat mundane topics of HTML, CSS, and JavaScript interesting!

Outlining some basic principles he showed how you could take an HTML file, full of embedded behaviours (javascript), style rules (CSS), and content and strip out all four parts into a more manageable set of files. This way, holding the style and behaviours in referenced files, you can make changes to either and have them ‘ripple’ through all of your deliverable.

Admittedly this was all done by hand but the basic principles are something that you should be following if you have that kind of output.

Session 6 – Matthew Ellison – User-centred Design of Context-sensitive Help
Interesting presentation by Matthew which started a little slowly, covering the history of context-sensitive help before taking us onto the idea of task support clusters. Originally presented by Michael Hughes at the WritersUA conference, the premise is to offer the user a smarter landing page, referred to as Keystone Concept topics here.

The key to a successful Keystone Concept topic is not to limit what is presented, and to consider that it should be different depending on the context from which it was launched, with the ultimate aim of getting the user back on task as quickly as possible. This includes any form of tips and hints, and crucially suggests NOT to include the obvious stuff (don’t answer questions that users will never have!). This mirrors part of the theme from Joe’s talk early in the day, and certainly seems to be a sensible goal given the business (time and resource) pressures we are all under.

After that, I had a few beers and a chat with some other delegates, and as ever it was great to hear that most of us have similar issues, problems and solutions.

I’ll post my notes from Day 2 of the conference tomorrow.

bookmark_borderPromoting DITA without promoting DITA

Recently Scott Abel posted a heartfelt plea to get people all psyched up about how to better promote DITA to the rest of the world. He backs the idea of the DITA Adoption Technical Committee, stating that:

“we need excellent communicators with the gumption, know-how, and network to get the word out about the many ways DITA impacts the world and those who live in it.”

I’m a fan of DITA and as I read his post I could feel myself getting quite excited, he makes some excellent points about finding real world examples of the benefit DITA can bring but something just doesn’t quite fit. It’s taken me a while to get my head around this but, isn’t a standard supposed to be a technical implementation detail, not the main focus of life changing events? Ahhh but wait, Scott agrees:

“DITA cannot be the focus of DITA adoption and publicity efforts.”

OK, so we can’t focus on DITA itself and, as Scott rightly points out, the software vendors will soon turn discussions away from DITA and towards their own feature set, so we can’t look there for an example either. In fact it’s not until the latter half of the post that Scott really hits on what he would like us to do, and in my opinion the following sentence is the key to his entire argument:

“Let’s strip away all the noise that prevents normal humans from understanding what we technology addicts find so wonderful about DITA, XML, content reuse, content management, dynamic content, personalization, and so on. … The focus has to be on the human impact. How does DITA help make the world a better place? How does it make it possible for humans to interact with one another? How will it help everyday humans in their everyday lives? How can it help governments better serve their citizens?”

Big questions.

Whilst Scott is aiming at a top-down view of the world, there are lessons there for those of us who are trying to push these things upwards. Selling DITA as the fundamental part of a single source solution now seems a little odd, particularly when most business cases are focussed on ROI and the whys and wherefores surrounding the choice of tooling, so if you can detach the tool from the business case, and focus thinking on the benefits of DITA (rendering the tooling generic rather than specialised) you can start to really crack the story behind how adopting DITA as a content standard will benefit the customers of your company, THEN you have a much more powerful argument.

So, if anyone has any answers to those big questions, do let me know…

bookmark_borderHi there

A quick welcome to anyone visiting from the ISTC Communicator magazine. I feel a little spoiled getting two mentions in subsequent pages (10 & 12 if you are wondering) but I’m not really complaining.

Over the past year or so I’ve definitely got the feeling that the ISTC is changing, and it certainly feels like a more modern and dynamic organisation than it has seemed to be in the past. Perhaps that’s natural, but it’s amazing how little things like a redesign magazine and newsletter, and hopefully a new design for the website, can refocus the energies of those involved.

Anyway, thanks for dropping by, there are plenty of links and opinions to be found in the archives (scroll down a bit, they are on the right), and here are a few of the more popular posts:

Or perhaps you just want to download the RSS feeds.

bookmark_borderRecently Read

I’m utterly failing in my attempt to make this a weekly feature on this site. Maybe I should cut it down a little, thoughts and comments are appreciated.

Writing an Interface Style Guide
Some handy tips for what to include in any user interface guidelines document:

Interface style guides are extremely useful to define best practices for design and development. However, keeping that information updated and functional is imperative. A glossary, an index, references, acknowledgments, etc., are among some of the supplementary details you can add to make the style guide as helpful as possible.

A Climate of Fear among Technical Communicators?
Prompted by a panel in the recent STC Summit, Ben Minson outlines some basic tenets of employment which, whilst we all know them, bear being repeated:

I think protection lies in being inventive. If management and your peers see that you go beyond the bare minimum and the mediocre because you’re interested in what you’re doing, they’ll see value. If you invent in order to solve problems and to benefit your team and the organization, they’ll see value.

Interestingly, this aspect of professional life raises some issues, some of which were encountered by Anne Gentle at the STC 2008 Summit.

STC2008 – Wrap up STC Summit trip report
Anne heard a couple of similar issues during the summit (as well as a lot of other great stuff), but she noted that:

proving that [an] idea needs to be implemented in the first place means understanding how to convince management of the value.

It seems to be something we all struggle with, providing ROI to back up our reasoning behind choices of tool and technology. Which brings me neatly to the next post…

What is the Best Metric to Measure the Success of Your Reuse of DITA Topics?
Of course you’ll have to have provided enough evidence to at least get a pilot project or proof of concept off the ground, but if you have, how do you get the most from the data you are capturing. Bill Hackos suggests you should measure the percentage of repository words that are reused in context:

The ratio of the repository content to the produced content metric works at the content level rather than at the topic level. This metric is proportional to actual costs because translation is charged by the word, and maintenance costs are proportional to the volume of content rather than to the number of topics.

I’m not a huge fan of such quantitative measures but sometimes needs must. The article mentions some other possible metrics, and if you are considering a single source rollout give it a look as it will spark some thoughts I’m sure.

Finally a couple of quick links that do exactly what they say on the tin:

bookmark_borderRecently Read

A quick note this week: If you know of any blogs out there that focus on hardware documentation writing I’d love to hear about them. I’m keen to see if there are other topics being covered out there as I’m aware that my scope is defined by my current interests. Right, let’s press on.

Can online help show “read wear?”
Anne Gentle ponders on how best to show the online help topics which have the most traffic, and comes up with some interesting ideas:

“You could … show the most searched-for terms when the user searches. Concepts may be more easily connected when you understand what others were searching for.”

To my mind anything that helps people find what they are looking for is a good thing, and these more subtle, dynamic, pathways are a tangible advantage to delivering content online.

Do We Really Need Structured Document Formats? (Is Real Reuse Possible?)
Eric Armstrong investigates the many and varied aspects of structured authoring, and offers a balanced view of the pros and cons from his own point of view:

“I know from personal experience that it is possible to be “seduced by the capacity for reuse”, to the point that you over-engineer your docs like crazy, and take forever to deliver something “perfect” that would have much better received had it been much more imperfect, and much more rapidly produced!”

Can better technical documentation give your business a competitive advantage?

…technical documents – the user guides and help systems used regularly by customers – at the centre of the corporation-customer relationship, and calls such documents “value generators” as they help build trust and confidence.

Striving for Success in DITA Conversion – A Quick Reference
From Noz Urbina, some sage advice that I’m filing away under “Obvious but worth being reminded of”:

A lot of people see ‘project scoping’ as overhead that delays ‘production’, but it’s a classic example of ‘measure twice, cut once’.

A bit short and sweet this week, such is the price for a four day week though.