TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:"Meta".......(Was "Passing the Flame") From:Doug Grossman <Doug -dot- Grossman -at- sas -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Wed, 6 Dec 2000 10:51:53 -0500
This actually has nothing to do with "passing the flame." However, John's use of the pseudoword "metawork" brought a question to the forefront of my mind concerning the use of the word (or words) "meta data." Whether it actually is one or two words is the crux of the question, as many of you have figured out by reading this far. We wanted to use "metadata," but word got out that this would be a bad thing, because supposedly, that word was trademarked by a corporation going by that very name. Whether or not this is true, we decided to play it safe when we heard that, and we use "meta data" instead. Can anyone shed some light on this?
---Doug (Doug -dot- Grossman -at- SAS -dot- com)
-----Original Message-----
From: John Cornellier [mailto:tw -at- cornellier -dot- com]
> I'm leaving my current job, and have been asked to write a document
> which provides information on the documentation set (PDF & online help)
> that I'm leaving behind. This document is intended for the technical
> writer who will replace me (I won't get to meet him/her before I leave).
Having been through the legacy-handover-grinder more than once recently, I now document what I do, as I do it. (Sorry Manjeet, I know this isn't helpful to you now, it's just a comment). The idea is, when you do go you don't have to spend your last few weeks doing this sort of thing. It's also a useful exercise for getting an objective view of what you do.
Set up a documentation home page on your corporate intranet.
* If you have files you use, put 'em in a public space and put links to them, rather than on your local disk.
* Document the evolution of your templates and documents with links to your EDMS system, if any.
* Publish your planning and your bugfix lists.
* Any reports/memos about the state of the doc or your plans, put 'em on the web (tip: don't just use the web as a document interface linking to a load of PPTs, DOCs, and PDFs, convert to HTML where poss, out of consideration for future generations).
* If you have URLs you use in your work, put them there, rather than in your browser bookmarks.
The above is not actually much extra work, usually you can reuse stuff from your planning, monthly reports, etc. On the other hand, it shouldn't become an end in itself. Keep it quick and dirty. Don't get obsessed with it being representative of your work. Your work is producing docs. This is metawork.
Having moved around a bit recently, I've been at both the sending and receiving end of this. Something I find quite useful where there is a lot of legacy doc is some historical perspective of how things got the way they were, as in the following scenario.
1. In Ye Golden Age, everything was written in Ventura 1.0 for DOS by a team of experienced TWs in the Engineering Dept. in Fargo, North Dakota. The documents were backed up on 295 5 1/4in floppies.
2. There was an R&D initiative to move everything to SGML in 199x. The budget was spent, the files were converted, but the implementation never went through as there was no user demand, no business case, no added value....
3. After the collapse of pork futures in 199x all the TWs were sacked.
4. A few years later clients started to complain about the outdated doc so cowboys were brought in by the marketing department. Cowgirls too. The 295 5 1/4in floppies having been used to shingle an outhouse in Monango, they salvaged the SGML into HTML 1.0, thence to Word 2.0. Except for the stuff they got OCR'd by some interns.
5. R&D got fed up with all this and hired new TWs, who moved everything to Adobe products on Mac OS.
5b. And so on.
The point is, sometimes things are done which "seemed like a good idea at the time" but are hard to fathom later.
John
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Develop HTML-based Help with Macromedia Dreamweaver! (STC Discount.)
**NEW DATE/LOCATION!** January 16-17, 2001, New York, NY. http://www.weisner.com/training/dreamweaver_help.htm or 800-646-9989.
Take XML and Tech Writing courses online! Our instructor-led courses
(4-6 hrs/wk) give you "hands on" experience at your convenience. STC members
get 20% off! http://www.online-learning.com/index.html.
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.