Not too long ago, I found myself stuck between a rock and a hard place. I work for a large organization (30k+ world wide workforce), and I’m just one tiny fish in a very large lake.
I was asked to provide help content in the form of a getting started guide for a piece of software that was going to be released world-wide.
I started working on the project using my tool of choice, a help authoring tool called MadCap Flare. This is a tool I really like, and have been using for several years. I’m something of an expert on Flare, so it is my first choice for pretty much any authoring project.
I started working within my group, however, and found that Flare wasn’t going to be the right solution for this project because of project constraints outside of my control. We have an in-house translation group that does all our content translation. They have their tools in place and are not interested in obtaining and learning to use a new tool (MadCap’s Lingo tool). There are certain strings in the project (specifically surrounding variables and master pages) that wouldn’t get sent to translation if they didn’t use Lingo. This project is going to go out in 24 languages, so simplifying the process is essential.
I ended up creating a site using JavaScript and HTML. Translation can handle HTML files, so this project is easy for them to manage on their side.
The moral of this story is that I ended up picking an inferior (in my opinion) tool, HTML and JavaScript because it was the right tool for this project. While I think Flare is a better tool overall, in this case, it wasn’t the right fit. Now I could have gone through a bunch of hoops to output HTML files and then re-import them into the Flare project, and then try to re-generate the project in the new language, but that was more work, with more room for error, even though it would have given me more options for designing and creating my output.
Sometimes you have to pick the right tool, even if it isn’t the best tool.
You may remember the old WordPerfect days. Those were the days of Reveal Codes (Alt F3) when changing the formatting of your document was easy. In fact, in the late 80s and early 90s, WordPerfect was the de facto standard word processor.
Now, twenty years later, Microsft Word has taken over as the market leader and standard word processor. Word Perfect is still out there, but you’re hard pressed to find any company (outside of Corel, the current owners and developers of WordPerfect) that uses WordPerfect.
Most former WordPerfect users have been forced to learn to use Microsoft Word, and many complain that they are lost without Reveal Codes, and are unable to format the document the way that they want. They believe that WordPerfect was a better word processor. However, just because WordPerfect may be the better tool, it doesn’t necessarily mean it is the right tool to use. It turns out that if you can’t share documents with other people who don’t use the same word processor then you have a harder time communicating with them. Or, if your organization doesn’t support WordPerfect, you can’t use it at work.
(Now, I will point out that current versions of WordPerfect are able to read and write MS Word files, so this isn’t a perfect comparison, yet there have been many people who, due to work requirements, have been forced to make the switch to Word, regardless of WordPerfect’s ability to read/write MS Word files.)
The trick, it seems, is knowing when the right tool IS the best tool, and knowing when the right tool is something else. As technical communicators, we need to be more focused on getting the project done the right way for our organization, while focusing less on whether or not we get to use our favorite tools.
I’d love to hear about your experiences with giving up on tools you loved for the sake of a project. Share your story in the comments, below.
3 Responses to When the "right" tool isn’t the "best" tool