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:Re: Oracle Help or Java Help -- how to choose? From:Bill Swallow <techcommdood -at- gmail -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Tue, 7 Jun 2005 13:44:43 -0400
> Fine, but that doesn't speak to the fact that XHTML is XML, thus can
> be single-sourced in a simple devel environment, and later parsed
> easily by Java for an alternate (though barely) presentation.
Very true. But XML isn't in itself a solution. You need to wrap some
display context around it. This is where it gets tricky because if the
goal is "pure Java" then you need to create a 100% Java browser for
this. And then you get into the old debate of whether to reinvent the
wheel or go with existing solutions, such as JavaHelp and OracleHelp.
> To me, it's a question of when you bridge the documentation content
> to the product. Doing so continuously through development is
> costly. If the hooks are there, they can be developed discretely
> and joined at the last moment. Or moments. Or unforeseen moments.
I don't understand why it's costly. I have help that's continually
updated with the product and is 100% context-sensitive. It's built
automatically every night. All I have to do is ensure the content's
good.
> Sorry, but this is one of my axes. For my money and professional
> sensibility, needing to see how the docs integrate with the product
> at all development stops is an obsessive waste. It's also quite
> standard, and keeps more than a few aftermarket help products and
> their adherents in work -- when they might be working on effective
> content and presentation instead. Call it writing. :^)
I don't understand what axe you're grinding here. Are you saying you
don't feel it necessary to learn the technology and methodology, but
would rather focus on content and let someone/something else worry
about the implementation? If so, then I have to whole-heartedly
disagree with you on that note. It's my position that this is vital
knowledge that each and every tech writer needs to have; if you don't
know how your work is being wrapped into the product, how do you know
it's being done correctly?
New from Quadralay Corporation: WebWorks ePublisher Pro! Easily create
14 online formats, including 6 Help systems, in a project-based
workflow. Live, online demo! http://www.webworks.com/techwr-l
Doc-To-Help 2005 now has RoboHelp Converter and HTML Source: Author
content and configure Help in MS Word or any HTML editor. No
proprietary editor! *August release. http://www.componentone.com/TECHWRL/DocToHelp2005
---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- techwr-l -dot- com
Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit http://www.techwr-l.com/techwhirl/ for more resources and info.
