If, after examining and analyzing a problem, I find the best solution, I recommend and, at times, fight for that solution. This approach seems so self-evidently correct that I’m shocked to find myself even writing it.
Tag: tools
As technical writing consultants, our job is to advise and recommend. Of course, that advice and those recommendations cover lots of different aspects of the entire process. Obviously, we review the material and try to organize the information so we can present it in the most effective, most efficient way possible. Rarely, if ever, do we receive much push-back from our clients on this part of the process. After all, that’s why they hired us.
And while writing and organizing content remains one of the more important parts of our work, we also believe that we have some insight into what tools to use make that efficient presentation of material possible. Unfortunately, our clients don’t always agree.
Here are some examples.
A company approached us with a problem. It produced a piece of hardware that it sold with optional modules. The company wanted to ship a manual that covered only the modules that were purchased, not all of the modules offered. The problem the company was having was that it had created the manual in Word and either it had to manually manipulate the document each time it made a sale – delete the sections for the modules that weren’t purchased and renumber the chapters and pagination – or send a manual with all of the features and text for all of the modules. Which always creates problems – “Why can’t I get this machine to do what it shows in Chapter 8?” Answer: “Because you didn’t buy the module described in Chapter 8!”
We suggested we import the contents of their manual into FrameMaker and use FrameMaker’s conditional text feature to mark the text that belongs to each module. In this way, we could mark whole chapters that related to individual modules, as well as words and paragraphs – in feature lists, for example, in the introductory sections of the manual – so the resulting document would reflect only those modules that were purchased. A brilliant solution, we thought, and so did the client. Happy client; happy consultant.
A different company talked to us about documenting a large enterprise software package that also offered different, optional modules. After discussing the application with the SMEs and reviewing the existing documentation (our due diligence), we concluded that the final document would be very large – it was a VERY large enterprise software application that did many things – with lots of graphics and screen shots and would not do well in Word. Furthermore, the client admitted that its clients didn’t always buy all of the modules and so would want the ability to offer a manual that only included the modules purchased.
Fresh off the previous consulting engagement in which we were able to address the hardware manufacturer’s similar problem, we proposed using FrameMaker and marking the sections describing each module as conditional text. Then, the company could produce a “customized” document for each of its sales. Not only would we solve the “purchased module” problem, we argued, but we could assure the client that FrameMaker would handle the large size of the document much better than Word because that was what FrameMaker was designed to do and Word was not.
Our contact at the company agreed with us but found little support with her management. Why? Management wanted to be sure it could revise the document without having to hire a FrameMaker “expert” and so wanted it done in Word. What about the optional module problem? “We’ll deal with it internally,” they said. Since in our line of work, the customer is always right, we wrote the manual in Word and regretted every minute we spent on it, knowing the resulting material was inadequate. Alas.
I’ve yet to hear of someone instructing a plumber as to what kind of wrench to use to fix a leaking faucet or tell a carpenter what type of blade to use to cut a piece of wood, or, as I’ve said before, told a developer what language to use to code an application. We hire experts and rely on them to advise and recommend the best way to solve a problem. Technical writers are the experts. Listen to their recommendations.
Objectivity tends to be one of the core values of technical fields. The fundamental laws of physics dictate the properties of microprocessors, and chemistry defines the properties of the materials we use. These methods make up the API, determining how that application behaves and what it is capable of doing. The way that people interact with technology, however, is anything but objective. They bring a lifetime’s worth of experiences that guide their behavior and frame their expectations for both what the technology will do for them and how it will perform its duty.
The user interface of an application – even one with a convoluted design – gives users some sense about how to navigate the application. It may be painful, but users can usually muddle through if they have to. APIs, on the other hand, offer no natural affordances or signifiers allowing developers to learn how to use the API. Therefore, good documentation is crucial for any API project.
Eric Sedor is a senior software engineer at MongoLab, a cloud-based database provider located in San Francisco, and frequent contributor to The Technical Reader. Eric cut his technical writing teeth at Shoap Technical Services before returning to his true passion, software engineering.
For additional information regarding Waterfall/Agile development and how it impacts technical writing, please refer to previous blog posts written by Eric Sedor and Shaun Kelly.
Moving a product out the door to capitalize on market demand is a necessity – it’s simple economics! Consumers demand constant product improvements. This “out with the old, in with the new” mentality has led many successful companies to switch from Waterfall development to Agile. What does this mean exactly? For the uninitiated, use this simple analogy. Waterfall development can be compared to a marathon. All software features are built in one long process and then errors are fixed. Agile development is more like a series of sprints. Software is released in a series of small iterations. Each release includes a few added features, and errors are corrected along the way rather than at the end. As you can imagine, the switch to Agile development completely shatters the status quo and roles of people associated with the development teams. This led us to wonder: Specifically, how does the switch to Agile impact the role of technical writers?
When clients tell me that they can write their own user manuals because, after all, they say, they already know how to write, I’m reminded of a quip from an old friend, frustrated by his software developers’ inability to complete a payment application on time: “Why does it take so long? It’s just typing.” Sadly, I sometimes think, people think the same about technical writing: It’s just typing. Which got me thinking: What does a good technical writer have to know to be a good, dare I say, great technical writer?
Technical writers are a rare breed. To be successful in this profession, you have to be patient, know how to communicate, and, last but not least, understand technical concepts. These tough demands have been the inspiration for this article, the third and final, in what we like to call our technical writing “rant topics.” See the first two in the triptych, “What’s Wrong with the Passive Voice” and “Why is Consistency Important.”
So, what makes technical writing such a challenge?
In an earlier article (http://www.shoap.com/rfp-responses-go-technical), we discussed the importance of responding to RFPs with correct, easy to read and understand responses. Several of our readers wondered if there were any tools that could help them address the arduous task of responding to RFPs. This article is for them.
Unquestionably, there are more onerous tasks than responding to a big, fat request for proposal (RFP). Unfortunately, I just can’t think of anything. People who have to do this for a living spend countless (and thankless) hours, ensuring the response is correct and flawless. These responses can go for hundreds of pages, require inputs from various and sundry departments within the organization, and are under tremendous time constraints. It’s stressful just thinking about it. Many companies, however, are facing this nightmare head-on by investing in software that automates the process. Leave the copy/paste method behind.
You may have heard the term “gamification” floating around and wondered, “What is that?” The answer: Gamification is the new buzz word representing the idea of incorporating gaming concepts and techniques into non-game activities in order to drive a desired behavior. Marketing campaigns can use game mechanics to drive customers to their websites, sales agents can participate in games to drive competition and increase sales, and in our industry, documentation and training groups can build game-like training materials to fully engage the learner.