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.
> First off, I have to disagree strongly with Andrew Plato that OS
> homogeneity is the key to productivity. I have worked for years as the
> sole Mac user in a variety of Windows/UNIX/Linux environments, with no
> compatibility issues to speak of. That's because the *tools* we use are
> cross-platform compatible, as mature tools should be. In the rare cases
> they aren't, I find workarounds that do not cut into my productive
> time. My manager doesn't care if I write a manual on a CP/M computer or
> an Amiga as long as he gets the deliverable he wants on time.
Any environment where multiple operating systems and tools are used
requires some administrative overhead. There are different file formats,
different network protocols, different support needs...the list of issues
is long.
A heterogeneous environment offers a higher rate of reusability. What
works on one machine, will work on all of them. This reduces support and
training costs. Its why large corporations like to standardize on certain
platforms or at least limit platform diversity.
Yes, it is POSSIBLE to support multiple platforms. But this is rarely the
most cost-effective way to run a company. This is why many firms use
Windows technologies. They are easy to integrate (reduces support) and
they are the most widely known (reduced training and support).
Its why good documentation uses standard styles, wording, and punctuation.
Furthermore,cross-platform tools are often inherently less capable than
their "uni-platform" cousins. This is because each variant cannot take
complete advantage of many of the advanced features of each operating
environment. This is what plagues many UNIX programs ported to Windows or
vice-versa.
The only thing that seems to have any weight are cross platform standards
- like HTML. Many different technologies interpreting the same basic
standard. However, there are compelling reasons to use a standard
technology to interpret each standard. That ensures consistency across all
generated work. If one person uses Notepad while everybody else uses
FrontPage, that person is adding unnecessary overhead to the project. They
should be required to use the same tool as everybody else.
As for productivity: productivity is not a tool, technology or
methodology. It is the ability to get work done. On an individual scale,
it is easy to see how Tool X and Technology Y make you more productive.
However, that is merely because you are comfortable using those tools.
On a corporate scale, productivity is a little more complex. You have to
think of many people, global needs, and overall cost to achieve
productivity goals.
Again, this is why firms standardize tools and platforms. It increases
productivity as a whole across the entire organization. Yes, it may cause
you and a few others to experience a brief loss in productivity. But, if
you are professionals and take your job seriously, you'll come up to speed
quickly and produce quality results using the standard toolset. If you
resist, you should be fired.
The needs of the many outweigh the needs of the few, or the one.
> Secondly, I think the attitude that everyone on the writing team should
> be using the same tool to produce code with is dangerous; proprietary
> WYSIWYG editors almost always impose idiosyncratic code that can render
> your finished product accessible only to a specialized audience. If that
> is not your intention, you are going to find yourself tweaking code by
> hand at some point, or attempting to explain to senior management why
> customer X can't see your very expensive website.
Most WYSIWYG editors produce perfectly fine HTML. Remember, you're
dealing with market factors here. If 90% of the market uses a particular
browser, and tool X codes HTML to work well with said browser - why waste
time and energy filling the needs of the remaining 10%, especially if that
10% is not your typical customer. Why spend additional money to satisfy a
small part of the market.
This is why firms phase out support for older technologies. It becomes
prohibitively too expensive to support and maintain those products for a
rapidly decreasing market share. The same concept applies to web site: why
spend an additional $50,000 in overhead to code for a site to handle the 4
people a year that hit it with a BeOS browser, when you can focus on the 4
million IE users that hit your site and save that $50,000.
Part of any decent documentation project is to know thy audience. This
concept extends to HTML work as well. Know thy web hits.
> Moreover, by allowing the manufacturer of
> your proprietary WYSIWYG editor to set the guidelines you produce under,
> you are handing over control of your project to outsiders, who may or
> may not be supporting their own product next week.
All the more reason to stick with tools from established companies, like
Microsoft. This is one of the problems with many freeware products. They
may be great tools - but will they be around tomorrow.
> And what if your project manager
> gets replaced by someone who doesn't like that editor and moves the
> project to another?
All the more reason to hire PMs that make intelligent, logical, business
decisions and reject the emotional attachments they or their staff has to
tools and technologies.
> Your only hope is to FIRST establish coding standards (I suggest
> HTML 4.0) and then outline very carefully the non-standard deviations
> from it, in writing, so that later workers can pick up the pieces.
Again - more overhead. The reason many companies standardize with certain
tools and technologies is to avoid the wasteful bickering of people who
have emotional attachments to software. By mandating tools, they head off
such wars.
I get resumes every so often from writers that refuse to use particular
tools, usually Word. We throw these resumes away. We use Word for many
projects and will not tolerate incessant tool bickering among writers. Our
clients pay for results, not holy wars and bickering. And we are all
perfectly productive with the tools chosen. Why should my firm spend money
to accommodate one writer because they have a personal obsession with a
non-standard tool?
I don't care how educated, intelligent, or trend-setting a person is - if
they refuse to follow the ground rules, they get cut from the team.
Andrew Plato
__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com
A landmark hotel, one of America's most beautiful cities, and
three and a half days of immersion in the state of the art:
IPCC 01, Oct. 24-27 in Santa Fe. http://ieeepcs.org/2001/
+++ Miramo -- Database/XML publishing automation. See us at +++
+++ Seybold SFO, Sept. 25-27, in the Adobe Partners Pavilion +++
+++ More info: http://www.axialinfo.comhttp://www.miramo.com +++
---
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.
