If you’re in the Toronto area and you’re looking for something to do tomorrow night, come out to the STC Toronto Social Jester Pub and Grill at Yonge & St. Clair. I’ll be there and Scott may be as well (if he finishes his basement renovations in time). I’m looking forward to catching up with fellow STC members, meeting some new people, and
bitching about politics and the economy discussing what’s going on in technical communications over some wings and beer.
OpenOffice 3.0 was released yesterday to the masses, resulting in their website crashing. As of this post, their website is still down. I was able to download a copy of the Windows version (insert punchline here) and I’ll be evaluating the release over the next few weeks. The company I’m currently working for uses OpenOffice to develop technical documentation and there is some interest in migrating.
Initial reviews suggest that although the UI is still a bit clunky, the performance has significantly improved from the previous version. So, given the state of the economy, will companies increasingly choose open source applications such as OpenOffice as a way of trimming the balance sheet?
Something that Aaron and I continually stress is that people in our line of can can do more than just technical writing. One area in which I think a good, knowlegeable, and flexible writer can really make a difference is writing case studies.
For the last couple of years, one of the hottest topics among technical communicators has been modular, content-based authoring. There’s been a lot written about this topic, but two of the best pieces I’ve read on it come from the blog Cool Stuff. The first post discusses why you’d want to go modular. The second compares DITA and DocBook for modular authoring.
Both are definitely worth reading, as is Cool Stuff itself. The blog isn’t updated all that regularly, but when a new post appears it’s usually a must read.
It’s a necessary evil of being a contractor or freelancer: you need to keep an accurate account of the time you’ve spent on a project. Otherwise, the folks who are using your services might be more than just a little reluctant to pay you. It makes sense from the employer’s perspective: they want to know what they’re spending their money on, and simply saying “I worked 78 hours on project X” doesn’t always cut it.
So, what can you do to accurately account for your hours? Some firms use one time-tracking tool or another. If you can, use that. Or, if you prefer to use something under your control there are a lot of options out there. Just remember to keep it simple, and keep everything transparent.
Here are a few options.
I was poking around on Slideshare the other day and stumbled across this one pager titled “The ten tenets of effective communication”. (Actually, this is part one of the article, which covers half the tenets) Thanks to Scott Abel for making this available.
The article is focused on marketing and customer communications. But it definitely does relate to technical communication. How? Here are a couple excerpts:
your message, whether written, verbal, or visual, must be audience-centered – focused around the needs of your audience.
Instructions especially benefit from clarity. Who among us hasn’t struggled through frustrating assembly instructions, or the less-than-accurate steps for using software features? And yet it’s this lack of clarity that increases traffic to a company’s technical support lines with the corresponding increase in costs.
Obviously, nothing groundbreaking or earth shattering here but it’s nice to see that some of the struggles we face are common across many forms of communication.