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.
Re: How to convince a coworker to NOT use Structured FrameMaker?
Subject:Re: How to convince a coworker to NOT use Structured FrameMaker? From:Bill Swallow <techcommdood -at- gmail -dot- com> To:David Castro <thejavaguy -at- gmail -dot- com> Date:Sun, 20 Dec 2009 20:48:08 -0500
> I have a couple of coworkers who are in love with Structured FrameMaker
> source files.
They really need to get out more. ;)
> The end-product document is delivered in PDF format to the
> customer, so there really is no benefit (that I know of) to the customer by
> using structured vs. non-structured Frame files.
The deliverable should show no trace of how the source was handled, so
there's really no argument to be made in this case.
> One problem with using
> structured source files is that it makes it more difficult for our
> more-junior technical writers to help out with a document (as they need to
> learn not only FrameMaker, but Structured Frame, too).
Yes and no. If the juniors need to modify the structure then I agree,
but otherwise it should be not much of a stretch at all, and would
help because it would prevent deviant style use.
> However, the more
> compelling problem is that our DTD (or, rather, the FM equivalent) is not
> complete. It was developed by a writer who left the company three years ago,
> and nobody here has the knowledge necessary to update the DTD.
Now THAT is the best argument for bailing on Structured FrameMaker you
can possibly make. Can't maintain it or complete what you have? Then
ditch it or learn it. And if it hasn't been learned in 3 years...
ditch it.
> The
> incomplete nature of the DTD causes problems such as having red elements in
> the structured view (indicating that the XML is not in a valid structure)
> and having paragraph styles that are changed from the default being switched
> back when you're not looking.
And all sorts of nasties, which is why you're having a hard time
training juniors on its use - because it's broken and you're training
them how to work around the debris.
> If I was working for a previous employer, I'd just jump in and learn how to
> update DTDs for Frame files to avoid the problem. However, in my current
> employ, all work is billed to the customer, and I therefore don't have an
> easy way to spend a week or two on something like this task.
Unless you validate the need to fix it. Someone had to spend
non-billable time to create the DTDs you have now, right? And are you
billing the customer for time spent futzing with the files? While good
for your coffers, not quite the customer-first approach there.
> So, my question is: How would you go about trying to convince your coworkers
> that there is no benefit to using Structured Frame for a given project?
Cost/benefit analysis. You know what it costs to do a project using
the current setup. Now make a SWAG at a working structure scenario and
a SWAG at a non-structured scenario.
> I've
> already tried to get them to explain why they are using it, and they bring
> up some (in my opinion) minor benefits, such as being able to quickly and
> easily restructure large blocks of text without having to click at the
> beginning of a block to be moved and scroll through pages of content
> (instead being able to select the elements in the structured view).
That's certainly a benefit if you do a lot of that in the scope of a project.
Are you looking for one documentation tool that does it all? Author,
build, test, and publish your Help files with just one easy-to-use tool.
Try the latest Doc-To-Help 2009 v3 risk-free for 30-days at: http://www.doctohelp.com/
Help & Manual 5: The all-in-one help authoring tool. True single- sourcing --
generate 8 different formats and as many different versions as you need
from just one project. Fast and intuitive. http://www.helpandmanual.com/
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-