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: