Bill's perception is quite correct, and I'm glad to see other agree. The best TWs I know are the ones who happily roll up their sleeves, dive into an unknown situation and get dirty. My mental image is of them parachuting from a plane far above the unknown, getting last minute shouted orders from a drill seargeant, then grabbing their laptops and parachutes and jumping.
It's a lot like journalism (the first love in writing of many of us). You have no idea what the situation is. Someone will hand you a press release that tells you what one fraction of the equation wants you to think. You must dig, find the truth of how the situation functions, and put that down in the kind of description you'd use for a complex design. Right now, there's a massive convergence in technology because it all uses the same basic interface elements. Web2.0 software is all server based, but Web3.0 may be cloud-based, and in both cases, the basics of the interface, networking and remote software interface are well known. The old TW job would have been to describe these. The new one is to give the users power over the application and show them how to become power users. In other words, people are now familiar with the basics of the task, so we have to show them a power user method that quickly gets them up and running and dominating their most likely tasks. What we're doing now is what aftermarket books did in the 1980s and 1990s. In my view, technical writers should recognize that unless we adapt, we're going to become specialized contractors called in when the real work is done to write the manual (WTFM) and then skedaddle. What we could be doing instead is throughout the life of the product, studying how it interfaces with the user and making that process more facile. In this new role, we'd be part journalist, part communicator, part trainer, part project manager, and part interaction designer and user advocate. This is to the benefit of writers, as we get to spend the entire product development cycle getting to know it and get a more justifiably necessary and lasting role, and companies, as they get several roles in one. --- Rene Stephenson <rinnie1 at yahoo.com> wrote: > HA! Quite true! TW's usually also bring an approach that is closer to > "green field" than the developers, engineers, etc., can provide. > Because they understand how THEY INTEND for it to function and be > used, they can be a bit myopic about how what they have CREATED > actually plays out. > > Rene > > Bill Swallow <techcommdood at gmail.com> wrote: I'd say that those are > additional skills. What I took Chris' remark to > mean is that writers should be there through the entire process, > involved with design, so not only do they influence the product > design > along with the other stakeholders, but also have a means of > thoroughly > planning the entire documentation effort as part of that product > development planning. Let's face it, most tech writers come at a > product from a different angle than an engineer or a tester. It may > not always be user focused, but it certainly is from a task-based > angle. "Is this thing going to be well thought out and therefore easy > to explain or is this going to be yet another 100 page install > procedure?" > > http://technical-writing.dionysius.com/ technical writing | consulting | development __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com