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:Keith Hood <klhra -at- yahoo -dot- com> To:TECHWR-L <techwr-l -at- lists -dot- techwr-l -dot- com>, David Castro <thejavaguy -at- gmail -dot- com> Date:Mon, 21 Dec 2009 08:54:26 -0800 (PST)
> 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. 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.
Arguments to use here:
The situation will get worse because of this lack of knowledge. All such current problems will continue, and you can't add anything new without running the risk of causing more and new, different problems. Without the expertise to change the DTD, your documents must necessarily be stuck in their current forms, at their current level of functionality in use of the structured elements. The situation can't be changed unless you abandon structured FM or get someone who can rework the DTD as needed.
No system planner would get into vendor lock on buying components if he can avoid it, but here you have a document version of vendor lock - you're straightjacketed in what you can and can't do. Because of this, if a future customer wants something significantly different from what you're doing now, you won't be able to satisfy their needs. That could cause CRM problems later.
The lack of personnel who know FM DTDs causes problems in the hiring process. If you do try to find such a person, who would be able to determine if he really knew enough? Adding that requirement to personnel acquisition would make a hiring search longer (translation: more expensive).
> 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.
No offense intended, but I don't understand why this is a problem. In every job I've ever had I've spent time studying on my own - taking tutorials and running experiments to learn more about the tools and/or the subject matter. I've taken night school courses in Java so I could do my work better. I can understand why you don't want to spend your own money on learning about DTDs, but if you have any spare time, even after work hours, I don't see why you wouldn't go ahead and crack a book on this subject.
> 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? 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).
Time/motion comparisons. So by this they save how many key strokes? How many seconds? How much time is really saved on the front end, and how much time is lost on the back end having to correct problems because the malformed DTD causes errors? Try to make them look at that difference.
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-
