For tech comm, blogs are a great medium to develop our profession, but also to archive knowledge and discussions.
I started Kai’s Tech Writing Blog 4 years ago, with a little fanfare:
Welcome to my new blog, yay! You’ll find my insights and experiences about software documentation here, what I’ve found to work and what didn’t. And some occasional wackiness.
Since 2010, the tech comm blogosphere (and blogs in general it seems) have been on a steadily declining slope. I think there are different reasons why tech comm blogs fade away:
- Some writers move on into other fields.
- Some find they have nothing more to say.
- Some stay in tech comm, but shift their priorities when the demands and responsibilities of their jobs increase.
- Some change their social media habits as they find twitter, Google+, LinkedIn or other services useful.
But the content in tech comm blogs is often still very useful, valuable and worth considering:
- When a question on methods or strategy pops up at the office or at conferences or webinars, I refer to “old” posts and often find them applicable, maybe after a little brushing up
- Old and recent posts on my own blog get a steady stream of readers as my stats indicate. There’s definitely a “long tail” over time to blog posts which proves their lasting value, if to niche audience. (There’s actually a short section on networks and crowds in the long tail on Wikipedia.)
See for yourself. Whether you’ve been reading my blog for a while or just found it a few weeks or months ago, here are 10 posts from the past which I still find useful:
Because a help system is like a library or a department store in a lot of ways.
Because moving from unstructured to structured documentation and topic-based authoring needn’t be difficult.
Because topic-based authoring imposes a structure that doesn’t always sem to work.
Because quality metrics for technical communication are difficult, but necessary and effective.
Because most of us rely on subject-matter experts who don’t always have reviewing our content as their top priority.
Because most of us are not done after creating content and getting it reviewed, we often need to edit language and provide index key terms for print output. Here’s how, along with links to resources I’ve found useful.
Because it can be rough being the only tech comm’er in your organisation. My presentation slides link back to some posts to show you how you can improve documentation and raise your profile by adopting a few general management skills.
Because research is a better argument for your “alignment decision” than personal taste.
This is the one that started it all, my first post over at DMN Communications. It does show its age a bit, but it’s still the best piece if you want to know “where I’m coming from” and what makes me tick as a technical communicator.