New Program Co-ordinator

After four years as co-ordinator of the Technical Communication program, Beth Agnew is handing over this responsibility to Anna Parker-Richards.

“It’s a great opportunity to get someone new involved in the Program,” says Professor Agnew. “Anna has been a strong leader in the Toronto chapter of the STC and her drive will be an asset to Seneca College and to our technical communication students.”

Having grown the program from a low of 18 students when she took over as co-ordinator in 2008 to a recent high of 42 students, Professor Agnew is still going to be active in getting the word out about this top post-graduate educational program for those seeking to enter the profession.

“I’ll still be teaching technical communication subjects and working with Anna and our co-op co-ordinator Charmaine Johnson to find appropriate work placements for our students,” says Agnew. Due to the program’s excellent reputation, there are more applicants than ever — prompting a second intake that will begin in May 2013.

Agnew thinks the program provides great return on investment. “The technical communication program is ideal for career changers because they can leverage their existing skills, background and experience into a new profession. Nothing is wasted. For new university graduates, the Tech Comm program offers a way to add to their skills while the students are still in “study mode”. It helps them differentiate themselves from all the others graduating with similar degrees.”

Tech Comm grads have proven technology and communication skills — high value currency in today’s workplace. “Plus, they’re trained to be problem-solvers,” says Agnew. “Providing solutions to customer problems always improves a company’s bottom line. That makes us very valuable commodities in any company.”

Agnew is excited about the new directions the Tech Comm program will be taking with Anna Parker-Richards as co-ordinator. “Anna is a positive leader,” she says. “She’s a master at networking and has the vision to ensure our program is meeting the needs of employers and students.”

For more information on the Technical Communication program, and to apply, see http://senecacollege.ca/fulltime/TECC.html

 

Facebooktwittergoogle_plusredditpinterestlinkedinmail

The Website Triad

Who is the first person you call when you need a website? It should be a technical communicator. Often described as a web content developer or web writer, a technical communicator with knowledge of the important disciplines of web usability and user advocacy will save you thousands of dollars when building or enhancing your web presence.

Most people contact a web development firm that may or may not include a technical communicator on the team. Web developers are necessary for building a website. Their job is to make the website work. They code the HTML, XML, Javascript, or Flash, they build the links, they ensure the page loads quickly and that the meta information is correct.

A web designer might be the first call you make when thinking about your new site. Their job is to make the website look pretty. You want an up to date look and feel for your site, you want the colours to be attractive, and the overall design to be inviting. Designers create or modify CSS and page templates, create the visual images needed for the site, and give the entire site a pleasant, uniform look.

The efforts of those two professionals give you a site that looks nice and works well. There are no broken links. Images don’t overlap. The site is attractive and functional.

But does it do the job you need it to do? Can customers or potential clients find the information they need? Does the user interface (UI) support the user in achieving their goals? Is it usable?

If you had called a technical communicator first, that individual would not only project manage the site’s development and co-ordinate the activities of the web developer and web designer, but they would ensure your content is well written and makes sense. They would ensure any user of the site is able to navigate to what they want easily, and is prompted to take the right action. They would ensure your website meets the objectives you have for your web presence. They would review and improve the work of the designer and developer, pointing out any potential bugs before the user sees them. And they would keep you from spending money on bells and whistles that may make the website cool but contribute nothing to the value the site offers visitors.

Getting a good website requires having each member of the website triad — the technical communicator, the web developer, and the web designer — work together to make a site that does what you need it to do. Whether you want your site visitor to buy something, pick up the phone for an appointment, or just get necessary information quickly and effectively, the way your site merges functionality with design in a way that leads the visitor to take that action is largely the result of the technical communicator’s skill in unifying the development and design efforts.

Web content also needs to be optimized for search engine results (SEO), something a good web writer or content developer can accomplish as well.

Usability for a website means that the visitor can accomplish the goals they had when they came to the site. If customers leave without buying because they couldn’t figure out how to navigate to the product they want, or they get frustrated because they cannot read the faint gray type on the web page, your site has failed, no matter how much money you spent on it. If you are hiring a creative agency, make sure they have someone with technical communication skills assigned to your project.

Technical communicators save companies money, time and headaches no matter what jobs they are asked to do. Helping make websites that work is just one of them.

Bad Websites — poor usability, interfaces, navigation or content
Good Websites — great usability, pleasing interfaces, efficient navigation, and purposeful content.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

FSOSS 2009 & Documentation

Concluding Open Source week in Toronto, Seneca held its annual Free Software and Open Source Symposium (FSOSS) yesterday. I was privileged to have the opportunity to speak about documentation for open source projects.

What is truly exciting about open source development is the collaborative and community aspect of it. I love the synergy of keen minds working on a collective project. Documentation too benefits from having multiple people contribute to and review it. While there is the danger of it sounding a bit like “authorship by committee” I think that problem is easily avoided by having an editor who is responsible for smoothing out the voice.

As we drift more toward topic-based writing that addresses user tasks rather than features, we can accommodate multiple writers because the style guidelines for topic writing are very straightforward. Publishing in an open source environment often involves Wikis, which are an excellent collaboration tool. Marry the idea of topics with a wiki that allows anyone on the team to contribute to the project and you have some excellent documentation that can be developed quickly.

I still encourage documentation plans, and reviews/approvals as part of the process, but generating content is much simpler.

I also still emphasize authorship, meaning document ownership. I don’t mean that someone gets to “own” the documentation in a proprietary way. Open Source is all about moving away from that idea of singular intellectual property toward a collaborative work package that represents the best a group of people can produce. Document ownership is simply taking responsibility for your contribution. Even though other people will look at it and edit it, each author does the best they can to make the documentation excellent.

Another point I brought up in my presentation was that documentation really includes all of the information, communication and knowledge around any particular product. Documentation is a way to add intelligence to the product during development to create a superb user experience. This can be as simple as putting informative labels of data fields that are to be filled in. The example I gave was of a web form that provided for a 10-digit telephone number, without hypens. The user doesn’t know that, however, until they start filling in a phone number 800-555-12 and run out of space. It takes very little effort to indicate how the user should input things like phone numbers, dates, postal codes, and so on.

Of course I recommended that technical communicators be involved in producing the documentation for Open Source projects. I know where you can get some if you want them.

The recorded version of my presentation will be available on the FSOSS web site shortly.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

No Gender Bias

Technical Communication is a profession that is practiced equally well by women and men. For many women working as technical writers in the ’60s and ’70s, our entrée into some male-dominated high tech fields came through the door of technical communication. We were accepted on teams in aerospace, engineering, automotive, and manufacturing because our skills were needed to communicate vital information about these subject areas.

In the 21st century, any barriers have fallen even further. Technology is no longer the province of only one gender, though some industries remain more heavily weighted toward males. For technical communicators, it has never really mattered whether you are male, female, or unsure. Our work has always been independent of its creator, and it will continue to be so.

There is no better profession for writers who love technology, no matter what your sex.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Dependencies: The Bane of Efficiency

Students in the Technical Communication program learn how to manage their documentation projects. I’m fond of drawing the parallel between the Software (or Product) Development Life Cycle and the Document Development Life Cycle. They both have the same phases.

The keys to project management of course are to control scope, supervise resources, and manage dependencies. It is this last item, dependencies, that often gives project managers their biggest headaches.

A dependency occurs when one part of the project cannot go ahead without another part providing input or a trigger for it. For example, technical communicators cannot complete documentation on a product unless they have a stable and complete version of the product to work with. Their work is dependent upon something produced by someone else. No matter how efficient they might be, they are brought to a halt quickly when some dependency is not ready.

Because so much of what we do as technical communicators depends upon actions taken by others, we develop skills to ensure others do what we need them to. You might think of us as professional gadflies. We coax, prod, chivvy, encourage, and even annoy those upon whom we are dependent. We relentlessly follow-up; we continually pursue loose ends. We check and double-check. We ask, “Is this ready yet? When will it be ready?” — questions others often don’t want to hear.

Our tactics are not enjoyable but they are vitally necessary. And too frequently, it is the technical communicator who ends up driving the project forward simply by virtue of needing certain things done by specific dates.

If your projects are sluggish, and efficiency is hampered by too many dependencies, get a technical communicator on your team and watch things start to happen.

Facebooktwittergoogle_plusredditpinterestlinkedinmail