Below are the slides and notes for the presentation on FLOSS Manuals that Scott gave at FSOSS 2010. You can also find them on our page at Slideshare.
Monthly Archives: October 2010
Slides and notes from Scott’s FSOSS presentation
Weekly links roundup

- Anne Gentle looks at Web analytics for documentation sites
- Some good examples of bad technical writing
- Tom Johnson ponders why tech comm is the career path of last resort for students
- Some usability advice for those times you’re working with a Web-based CMS
- Yes, we really need to speak the customer’s language
Dealing with acronyms and jargon

Jargon. Acronyms. They’re everywhere. Yes, even in technical communication.
Jargon and acronyms have helped bloat the English language and contributed to a level of obfuscation and confusion that’s deeper than an unknown foreign language. In fact, people who overuse jargon and acronyms often sound like they’re speaking a foreign tongue. Or just speaking in tongues …
As technical writers, we regularly run into this. I sure do. Worse, we can’t seem to escape jargon or acronyms.
But that doesn’t mean we have to put up with either. We can do a lot to minimize the amount of jargon and the number of acronyms in what we write. By doing so, we can make what they’re trying to convey clearer for any reader.
Content strategy for technical communicators: what happens to my doc plan?

by: Larry Kunz
The buzz about content strategy has never been louder. During the past few weeks we’ve been treated to a whole gamut of views about content strategy.
There was Tom Johnson’s characteristically thoughtful analysis of what content strategy is and is not. Rahel Bailie showed that content strategy isn’t just about web content. The staff at Johnny Holland gave us a week-long series on common issues surrounding content strategy. We even had a great conversation that started with an editorial error.
There’s no doubt that, as Tom said, content strategy is gaining momentum.
While there’s still discussion about how best to define content strategy, I think that most everyone agrees on a couple of key points:
- A content strategy is, well, a strategy. A strategy, by definition, provides an overarching framework within which specific actions can be planned and executed. A strategy gives purpose to every action, but a strategy is more than just the sum of the actions. It’s not tactical: for example, it doesn’t dictate things like how a style sheet should be coded (although it might contain broad guidelines for how the styles should look).
- A content strategy should be broad enough to encompass all kinds of content: content from all over the organization, as well as (increasingly) from the user community; and content that can be distributed in a variety of formats.
New guest blog post coming tomorrow

Tomorrow’s post comes from the keyboard of Larry Kunz. It’s an interesting complement to a recent guest post in this space.
Wondering what Larry has to say on this subject? Then drop by tomorrow to find out.
Weekly links roundup

- A look at authoring in DITA using the Serna XML Editor
- Speaking of DITA, here’s a brief look at what it is and why you should care
- Sarah Maddox on blur testing to assess page design in technical documentation
- Three strategic ways to reduce the number of support calls
- Some thoughts on how to get started in technical communication
- Six ways to improve your help authoring workflow