Re: Samples vs. Portfolio

[Pirjo Tinat <ptinat -at- yahoo -dot- com>]

Thank you David Hailey for triggering more depth into my train of thought.
I want to add that the writing test has always been after a thorough interview, in which the past work experiences as well as understanding of, for example, structured and modular documentation has been evaluated.
My problem with samples or portfolio (and, to a lesser degree, also with writing tests) is that you see only the end result, not the thinking that has been put behind it. How has that sample been produced? How can you see whether styles or structure have been used consistently? 
Only an interview can assess the following (among others): Does the applicant understand the concepts of single sourcing and/or modular documentation? Is (s)he acquainted with XML and standards such as DocBook and DITA? Has the applicant used more than one editor (and thus can adapt in using practically any editor)? Has (s)he been involved in more than one part of the publishing life-cycle (and not only as a part of a machine, editing text but not seeing the bigger picture)? What understanding does the person have of usability issues?
All these depend also whether we are looking at an entry-level applicant or a more experienced communicator.
Unfortunately, in some projects, we are asked to be nothing but information manipulators. To some, this may not be a problem, however in my experience the majority of TWs would like to be more than that and as a result they feel frustrated in especially contracting works.
I have worked most of my career in contracting (agency) companies, so I have experienced the kind of work Joe Pairman described (Re: Building experience--quit after six months or tough it out?). Fortunately I have also been involved in more rewarding projects. In those projects I have been able to improve on the customer's existing workflow and tools. Also, there have been projects where I have been able to really think about the usability of the product. It really depends on how far the writer has been separated from the "behind-the-scenes" publication workflow as well as from the product program.
David Hailey said:

... As long as technical writers are seen as technicians (who posess one, narrow skillset), they will face the problem of having their jobs outsourced. As Pirjo Tinat has pointed out, many suggest that a technical test that shows us qualified to be "information manipulators" is enough to define the profession.

Much of the problem is in the name, but much more of the problem is in the behavior of the profession.  I think the key is to move beyond technical writing and editing to a broader understanding of what it means to communicate. The technical communicator who understands the entire collection of fields related to corporate communication and who stays abreast of innovations in the profession can become communications director.
...


-Pirjo


      __________________________________________________________
Sent from Yahoo! Mail.
A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Create HTML or Microsoft Word content and convert to Help file formats or 
printed documentation. Features include support for Windows Vista & 2007 
Microsoft Office, team authoring, plus more.
http://www.DocToHelp.com/TechwrlList

True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com

---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot- 

To unsubscribe send a blank email to 
techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit http://lists.techwr-l.com/mailman/options/techwr-l/archive%40web.techwr-l.com


To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com

Send administrative questions to admin -at- techwr-l -dot- com -dot-  Visit
http://www.techwr-l.com/ for more resources and info.