Tag: <span>STC</span>

Quite a lot going on at the moment, but don’t worry dear blog reader I’ve not forgotten about you, I’ve still got plenty of things to post here just not really finding the time (or requisite brain power) to focus on them and think them through properly.

Here are some of the things I’ve started to write about but not yet posted.

In other words, “here are the posts languishing in DRAFT”.

  • Content from the ISTC and STC publications, why isn’t it all free?
  • Social Media Models, where I try and outline what I think are the models that we, as technical communicators can get the most value from adopting
  • The evils of presumption
  • Embracing user-generated content
  • Small social media. If your ‘community’ is very small, what will work for you?
  • How to stop thinking about documents

I will hopefully revisit some (all?) of these in the future, but before all that I have an eSeminar to prepare for, more details on that soon.

Work

Before I say anything on this topic I’ll confess that I am not fully versed in the history of the organisation. I am not a member, this is merely my take on some of the blog posts I’ve read on this matter.

And there in is the my main point.

I’ve read a lot about the issues the STC are currently facing but have yet to read anything from the STC itself. No doubt there is an STC mailing list ablaze with such news but given the amount of negative press currently floating about on blogs and on Twitter I’ve yet to spy any sort of formal, or informal, word from the STC.

I’ll let you read into that what you will.

Elsewhere there are plenty of suggestions to solve the initial woes, and many ideas of how to help the STC modernise and become the organisation the members want and, as I’m not a member, I can allow myself to suggest that perhaps the time has come to wrapup the STC and let a new organisation grow from the ashes.

Those who are interested, and who believe our profession needs such an organisation will rally round and rebuild something. If there is not enough interest then perhaps that is a further indication that the STC has had its time.

I’m not suggesting that technical writers do not need an organisation like the STC, there are many many good benefits, and I’m fully aware there is a lot of history and hard work that has gone into creating and building the STC. But sometimes it’s better to cut your losses.

Of course, a large part of me hopes that it won’t come to that.

But I must admit, part of me is intrigued to see what would happen if it did.

Work

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:

Blogging

Comments closed