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.
1) You seem to think programming and documentation are the same. They
are not.
2) You seem to think David and I and others are agreeing with the
original article in the STC magazine Intercom. We are not.
3) You seem to think single-sourcing applied only to XML-based
solutions, it does not. I would argue that the majority of single
sourcing currently being practiced does not use XML at all.
4) You seem to think current help-authoring practice as defined by your
perception of the methods used by members of techwr-l are the rule, and
a good rule at that. Moreover, you seem to think single-sourced help
files should be defined in terms of your perception of traditional
WinHelp design. I'm not sure anybody has raised these issues or is
arguing with you on these points, but I also am not sure that these
assumptions are true and I do see that viewing help in terms of WinHelp
only is a very traditional thought process.
>> I guess you haven't been to a real marketing presentation recently.
;-)
I think I'm at one now 8^)
When someone says there's a 90% overlap without specifying units, I grow
skeptical. It's easy to take up 100KB with a single screen shot, but
100KB of
text is more labor-intensive. Is the 90% overlap one of words, or simply
bytes?
My figure of 30% overlap was for a real project, and indeed there aren't
any
graphics in the Help. Extremely terse, text-only Help seems to be both
the
prevailing sentiment on TECHWR-L and the current practice in Windows
Help.
(This difference in presentation is one of the assumptions of the author
of
the original Intercom article that triggered this discussion.) However,
perhaps you misread my example as print/HTML Help, so I'll ignore these
points.
>> (Oh yes, and something about Fat Mac binaries
>> which is all about compiling code and has no bearing
>> whatever on single sourcing information.)
Are you saying you do not recognize the similarity between compiling
source
code and single-sourcing information using XML? (If your "solution"
doesn't
involve XML, I apologize; you haven't been specific.)
>> Simply disparaging the arguments of others without offering
substantive
replies
>> does not, it seems to me, advance your case.
I agree. Maybe a sample page in MIF would help?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Buy RoboHelp Deluxe starting at only $798: you'll get RoboDemo, the hot new
software demonstration tool that's taking the Help authoring world by storm,
together with RoboHelp Office. Learn more at http://www.ehelp.com/techwr-l
Your monthly sponsorship message here reaches more than
5000 technical writers, providing 2,500,000+ monthly impressions.
Contact Eric (ejray -at- raycomm -dot- com) for details and availability.
---
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.
