Another week (and a bit) has passed. Time is tight for me at the moment, and I’m not posting here as often as I’d like so, for now, here’s a quick roundup of everything that’s zipped past my inbox in the past week:
… advocates an assertion-evidence design, which serves presentations that have the purpose of informing and persuading audiences about technical content
Needless to say, with my first ever conference presentation looming, I’m fairly focussed on both topic relevant stuff and anything that will help make my presentation better.
Creating an XML-based Content Management System to single-source technical publications is as simple as 1 – 2 – 3. Rather than focusing on any single tool or solution (and thereby forcing users to change to match the tool), this article describes one possible three-step process for using XML to single source your content deliverables.
A rather simplistic view of things, but if you are a bit flummoxed by the raft of information available in this area, and you aren’t really sure where to start, have a quick look at this. Short, simple and easy as A-B-C.
… the acid test is looking at your information as your reader/user would see it, and asking yourself “can I find what’s important without reading the whole page”?
You can format your text in a variety of ways, but it pays to take a step back and view the format of your content from the point of view of your readers.
Getting to the web-first mentality
Interesting to read that other professions are struggling to embrace the internet. Ultimately I think it’s getting to the point where we just need to take the plunge.
Start putting the web content management system into the workflow at the front end. This could be as simple as using Google Docs as a word processor instead of the bloatware that we know as MS Word.
Collaborate or fail
Titled “Building a Collaborative Team Environment” the opening couple of paragraphs kept me reading:
Technical communicators work hard to meet deadlines and value the standards inherent in the profession. At the same time, they value their personal creativity and the responsibility for developing a complete publication on their own. They tend to enjoy doing everything from writing, editing and page layout, tographics, technical content, and more.
Working as part of a team to create a single set of deliverables, handing over responsibilities to fellow team members, and trusting the work produced by others does not come naturally.
It’s an excellent article, looking at a variety of ways in which we, as technical communicators, can adapt how we work. It will no doubt prompt some posts here as I digest it further.
And on that, somewhat culinary note, I’ll thank you once again for stopping by.