Monday, July 27, 2009
#
The one thing that has remained constant for a writer is the role of providing information content. However, providing a context for information is changing, again and again. Technological advances and consumer demands have created an explosion of contexts in which content can be consumed; and they want it all.
The high-level contexts for information content can be described as follows:
- Content - Consumable (raw) data
- Delivery - Presentation of data
- Availability - Completeness of data
- Accessibility - Navigating large collections of data
- Structural coherence - Understanding large collections of data
Finer granularity of these contexts include such things as, book-like information, GUI help, packaged software demonstration (online quick tours, primers, tutorials, and animations), online seminars, FAQs, special interest communities, and more; (the list is hardly exhaustive).
The exponential scope and scale of the present-day Internet-enabled challenges will require several evolutionary paths for writers, all addressing the issues of providing processed information in a useful manner. I see at least three roles evolving for writers in an Internet-enabled world:
- Content developers
- Information miners
- Infrastructure architects
Content developers are writers whose task it is to document the use and function of a product or process. These writers have contacts closest to the development of a product. This role most closely identifies with today’s writer. The evolutionary path from writer to content developer will be relatively smooth for any writer who has already experienced using a new tool or process to deliver content.
Information miners fulfill a purpose of finding information that is related to the use and function of a product or process. These writers are once-removed from the development aspects of the product, and closer to customer feedback forums, such as customer support databases and special interest communities. These writers gather related information and repackage both the content and context for better consumption.
Infrastructure architects focus mainly on the contexts in which information is presented, ensuring that consumers are able to understand and navigate large virtual collections of data with relative ease. These writers will have to possess knowledge to design a scalable infrastructure and to document the infrastructure (with meta-information). (A good analogy may be that these people are like architects of a city, planning major civic centers and roads that provide sufficient flow access to efficiently get from one part of the city to another.)
The following specific elements make up a world-class strategy for content development:
- Information types are consistently presented in appropriate locations.
- Expectations of how and where to find different types of information are consistent and easily learned.
- “Help” anticipates a consumer’s need or desire, based on prior interactions or natural language queries. (Sometimes referred to as active help.)
- Embedded help for all software products. (More traditional online help offerings)
- A browser-independent interactive information system for each product.
- Internet-based interactive (not passive) tutorials that are tightly integrated with software products.
- Frequent and timely product information updates supplied to consumers over the web.
There are many organizational “owners” of information, (such as Customer Support providing data for FAQs, or Technical Marketing providing net seminars on new product features). All information will need to be channeled into a collaborative web-based architecture to make information useful.
Mark Metcalfe
www.linkedin.com/in/MarkMetcalfe
Wednesday, July 15, 2009
#
Your technical writer has completed a 20-page draft of a feature that your team has been working on and sends the team a notice for review, allowing for a week to review it and make comments. You put it on a pile somewhere with a vague intention to skim through it before the next project team meeting. When the meeting arrives, you approve the documentation by your silence, relying on the expertise of the writer because the document never left your growing In box.
This is not uncommon. Reviews of documentation are very hard to come by, and when they come they are usually done by a very few conscientious persons; usually the primary developer and a technical editor, if your company is lucky enough to still employ them. They are often missed by people with specialized perspectives such as those in customer support, pre-sales, training, and quality assurance.
As a writer, I know all the reasons and excuses (some of them very legitimate), and I have accommodated many reviewers by extending review deadlines (often with meager results). I will observe here that there is an inverse ratio of the cost of the software product and how accurate and complete the documentation needs to be at release time. If you sell a product inexpensively, then your razor-thin profit margins cannot afford the expenses of customer calls or inadequate documentation. Conversely, if you sell a very high-end product, you can send a product expert to hold the hand of the bleeding edge customer that is willing to pay for the advanced versions of the software (while the documentation depart continues to create content in preparation for mass adoption of the product).
It is true that if you have a more experienced writer on your staff, the more you can risk not reviewing the documentation – but in these economically difficult times, companies are more likely looking at costs rather than value, so weigh your risks before passing on that review. In any case, getting it right the first time saves money in the long run.
If the Ghost of Past Reviews visits you in the middle of the night, telling you that every customer call against faulty documentation is a new link in a ponderous chain, and you’ve said to yourself that the documentation is the business of the technical writer, permit me to shriek and moan and rattle some chains to remark that “Documentation is YOUR Business!” Just as the technical writer reviews and comments on software, offering usability suggestions to make the software better, other cross-functional members of the team have a stake in the documentation because it is part of the perception of the quality of the product. Every member of the team is responsible for the output of every other member of the team, or it is simply a collection of talented individuals.
Mark Metcalfe
www.linkedin.com/in/MarkMetcalfe
Monday, July 06, 2009
#
Topic-based information is the way to convey information because answers to issues need to be concise, portable, and relevant. The trouble is that many companies have a lot of information already stored in old documentation formats. User guides are becoming rare, as they should because the effort and cost involved in creating a user guide is too great as a ratio to the number of users who need comprehensive information. Quick Start guides are replacing the user guides and the comprehensive information is being moved into less sizable chunks of information.
It is a relatively easier job to create a DITA-based, XML-powered topical information system from scratch than it is to retrofit existing documentation into a new model. However, if your company is contemplating just such a move, there are several phases you need to consider before making the switch.
First, make sure your content is well-typed, meaning that the manuals need to have a consistent organization, making sure that your sections are organized into types of concept, task, or reference, (or some derivative of these types). Doing this will improve the usefulness of the documentation, even if it is never converted into XML to meta-tag the content.
Second, choose the XML solution that works best for your situation and roll out the changes. Remember that customers do not care about the source of the information; they only care about the output, so the company needs to consider costs, longevity (will the solution grow with you?), and ease of use among the users who are outside of technical publications (so that content also can be developed by other domain experts).
If Phase 1 is done properly, and the documentation is laid out consistently, automation can convert much of the content. However, even a manual conversion should take less time if the content is typed, so spending time on Phase 1 is very important.
Once the content is properly tagged, then it becomes a matter of how the content will be distributed and displayed, which can take several forms. This should be determined and worked on while others are engaged in Phase 1 activity.
Mark Metcalfe
http://www.linkedin.com/in/markmetcalfe
Friday, June 26, 2009
#
To make a pun about an “elephant in the room,” one cannot discuss technical writing these days without involving India. It is a particularly touchy subject, especially to American writers, but I will hazard a few observations.
The quality of writing coming from India in the early days showed that it was in the early stages of development. A good technical editor could smooth out much of the (somewhat stilted) British language, but the English-language-speakers in India created the market. When companies first started hiring technical writers in India, it cost between 20-25% of the cost of a writer in the US. The last I heard, the ratio was about 33-50% which is applying pressures on companies to look elsewhere. This is particularly true of other functions where use of the English language is not as critical, and India is now feeling the pressure of less expensive costs elsewhere, but I want to focus this blog entry on India.
Most assignments to Indian writers were mature projects that needed documentation maintenance; cutting-edge and new writing projects were trusted to the more experience writers in US-based offices. However, as the technical writing industry in India has matured, companies have found the economics involved too difficult to ignore.
So what is happening to the technical writing profession in the US? The good news is that it is not disappearing, but the bad news is obvious: fewer technical writing jobs will be available for technical writers in the US.
What I hope American corporations will begin to recognize is that globalization need not equate to off-shoring, nor is off-shoring the best way to create value. While it does cost more to distribute a global workforce, there are definite benefits and value from having culturally diverse and geographically local employees.
When I became director of a global staff of writers, I obtained funding to bring the writing team together for a summit. I understand that sometimes these meetings are considered boondoggles, but there was a palpable change between the before and after dynamics of the team. Before, we had several centers of writing activity; after, we had a cohesive organization that collaborated on matters that concerned our craft and business. The writers from India were apprehensive about meeting their American counterparts, knowing that corporate economies applied pressure in their favor because of their lower costs. Coming eyeball-to-eyeball helped each to recognize colleagues - in a personal way - as talented professionals and not disconnected persons halfway around the world.
I have developed close friendships with several of my colleagues from India – highly motivated and talented folks who are earning a living at what they love to do – and I love working with them!
A global company needs a culturally diverse workforce to more effectively respond to the needs of their local customers. Further, the “cross-pollination” of culture and talent creates and broadens value that is greater than the sum of its individual parts.
Mark Metcalfe
www.linkedin.com/in/MarkMetcalfe
Wednesday, June 24, 2009
#
When I left Wang Laboratories and joined Digital Equipment Corporation (DEC to the DECCIES), I was hired to write about how to define tags to be used in the Standard Digital Markup Language (SDML), a proprietary version for developing DEC documentation. My background in programming languages made me a good fit for the job. After I had ramped up on the project for several weeks, I called my supervisor one day and asked him if I could have another project. He immediately scheduled a meeting between us in a conference room.
In a serious tone, he said to me, "Um, Mark, we usually finish a project around here before asking for another project." I laughed and said, "No, no, you misunderstood! I meant that I was looking for an additional project." I felt that I could handle more than what put on my plate (and during the heyday of DEC, I could). I volunteered to do more.
I did not get a new project right away, but it was not long before I was tapped for projects that needed urgent attention. Tackling hot projects is sometimes called "fire fighting" and I was developing a reputation for it. I built a good track record of it and carried this reputation throughout my writing career.
Mark Metcalfe
www.linkedin.com/in/MarkMetcalfe
Tuesday, June 23, 2009
#
Some years ago, I developed an acrostic to help guide me as a Technical Publications manager. They have become my CORE values, standing for Clarity, Opportunity, Relevance, and Essentials. These concepts cover many of the issues any worker or manager deals with on a day-to-day basis.
Clarity
Eighty percent of job anxiety is caused by not being sure what to do. Getting or providing clarity is a large part of getting things done. When things are unclear, productivity suffers. When things are clear, then you can make adjustments if things are not quite right. Having the objective in mind enables a person to start on the journey and make adjustments along the way.
As a writer, I sought clarity in my assignment and an understanding of how customers intended to use the product (and not necessarily how the engineer intended it to be used).
As a manager, I talked through assignments with writers until I knew they understood what the success parameters were. The more experience a writer had, the less we needed to talk through it, but clarity was very important to ensure that the project objectives were understood.
Opportunity
Opportunity is often an intersection between being prepared and recognizing a need. Clear objectives open possibilities of new or better solutions, and a good writer looks for ways to convey information in new and better ways.
There is a time element to opportunity, too. Opportunity needs to be seized while it is available.
Relevance
Relevance is perhaps the most important theme because it defines the difference between best and optimum. The best may have a cost-prohibitive price tag associated with it, whereas optimum engages the law of diminishing returns to find the best return on the investment of time, energy, and resources. For example, a person can be the best chef in the world and take more than an hour to provide a sumptuous meal, but if a person at a sporting event is looking for a quick hot dog, the chef is wasting time making a soufflé. Similarly, you wouldn’t want a hot dog vendor barking at a fancy restaurant.
Knowing what the customer wants, needs, and can afford are critical to being successful. As it regards technical writing in particular, I have experience with projects that required very minimal documentation and was delivered outside of the corporate standard for documentation; it was a targeted need (a special order) by an important customer and time was critical. On the other side of the spectrum, I have experience with a comprehensive information set that must be carefully scrutinized before it is released. This is where company mission and vision statements are useful because they center an employee on activity that is relevant to the business.
Essentials
Truthfully, I have often considered Excellence to be the final theme in my CORE values because I strive for excellence in my work. However, Essentials reminds me that first things should always come first. I had a writer on my team who was always thinking of new ideas. I put him in charge of an important initiative for multimedia in technical documentation. I knew he was up to the task but reminded him that if he failed to deliver on his assigned project, his work on the initiative would count for very little; our customers needed his documentation. (He did a great job with both!)
In the day-to-day decisions that have to be made, I think about these themes. Do we have clarity? What are the opportunities? How relevant is it to the objective? Are first things first?
So far, so good!
Mark Metcalfe
www.linkedin.com/in/MarkMetcalfe
Monday, June 22, 2009
#
As more deliverables were added to the work load of technical writers, I started to hear some of the other writing managers say that we needed to learn how to say “No” to additional work that simply could not be supported by the existing staff. I disagreed, offering what I think is a better approach to the very real problem of understaffing. I came up with an acrostic “SCAN” to communicate a better way to deal with a growing workload and still meet the demands of the business.
Say “Yes.”
When approached by upper management with additional work, recognize that managers have identified a way to further the business. Saying “yes” recognizes that we are partners in ensuring business success.
Communicate the Costs.
Saying “yes” is not free if you have scarce resources; something often has to give and managers should understand this. “Yes, we can do this, but it will take two weeks of attention and Project X may have to be delayed. There may be other options; let's discuss them.”
Ask about the priorities.
Return the power of decision to the decision-maker. “Is it more important to postpone Project X so that Project Y can be done in the time frame the company needs? If both are equal priorities, can we get additional resources to accomplish our goals?”
Negotiate the workload.
After you have partnered with colleagues and let them know what it would cost to assent to the new business requirement, help them to understand and come to agreement on the shifted priorities. “A delay of two weeks on Project X is acceptable so that we can accomplish Project Y now.”
“No” should be rarely used (if ever) in successful business. It stops the conversation and sets up a battle. “Yes” is the beginning of the conversation by collaborating with colleagues on a company priority while also dealing with scarce resources. If you are really "on the same team" then "Yes" is the only real way to make things happen.
Mark Metcalfe
www.linkedin.com/in/MarkMetcalfe
Saturday, June 20, 2009
#
It's Saturday, so I feel like writing about how I got started in technical writing.
I took a computer class in high school and really liked it. I then took all the computer classes in college that I could. I was a business major at the time, but the computer classes were more appealing to me. When the school created a bachelor's program for computer science, I jumped in.
I became one of the computer lab assistants, and my professor noticed that I also had a knack for describing to other people how to do things. He asked me to put together a document to help Freshman get started with their own computer accounts, and performing the necessary tasks to use the computer. I was happy to do so, and they used the document for quite a few semesters. This was at a transitional period of time where some students were still bringing Smith Corona typewriters to college to do their papers.
I wrote about using a text editor to write college papers, and students began to submit dot matrix papers. At the time, some of the professors did not approve of the perforated paper and strange font. Also at the time, my dad was a pastor at the college and he had developed his sermons on the typewriter, too. I got a school account for him and introduced him to the ability to move an entire paragraph from one part of the body to another, and the backspace/delete keys; great innovations that some believed actually hurt compositional writing because it was too easy to amend on the fly.
I was one of the first three people at Eastern Nazarene College to obtain a bachelor's degree in computer science. I had little idea of the number of functional areas available to me in the computer industry. I thought I had to program code somewhere. (I was pretty good at COBOL and Pascal.) I landed four interviews out of college: two were for writing code, one for corporate training, and one for technical writing at Wang Laboratories in Lowell, Massachusetts. Thanks to my professor who saw potential in my helping abilities, I wanted to get into the technical writing field.
I was hired at Wang and really enjoyed my work. I still remember my first assignment, which was a 20-page document about a utility. I also remember the engineer's name with whom I met to gather information. I liked my job because I could play with computer software, point out the bugs (and not have to fix them), advise on how to make a program more intuitive, and write about it to help others use it. In many ways, I looked at my writing craft as programming in the English language.
My computer science degree helped me to pick up the more technically challenging products with ease and translate engineer-ese into common parlance for the user audience. It also helped me to develop macros for my colleagues and I to use to insert screen shots (back then, little more than a large text box) and to develop editing shortcuts.
I really appreciate my start in technical writing at Wang and still have friends from that time to this day. It has been a great career.
Mark Metcalfe
www.linkedin.com/in/MarkMetcalfe
Friday, June 19, 2009
#
"Don't go around the block in Boston," my dad advised. He gave me this sage advice long ago because the streets in Boston are not laid out logically. Boston is an old city that grew organically. In fact, many of the winding roads in Massachusetts are paved-over cow paths of old.
Think instead of Manhattan. If you are on West 42nd street, you can easily figure out how to get to East 23rd Street. That is because the streets are laid out in a logical progression and you can expect that 41st Street precedes 42nd Street and that the next street will be 43rd Street.
Along the lines of expectations, think about what you expect when you walk into a McDonalds or Burger King. You know that you can go almost anywhere in the world and get the same experience. (McDonalds in India serves chicken sandwiches; no hamburgers.)
When a company has an ocean of information, the key concepts to getting the information you need are access and navigation. If information is laid out consistently, on a web site or in the documentation set, customers can navigate easily through the system. For example, it means that Overview sections have the same kind of information and always appear in the same place. The regimentation gives users the confidence of knowing where to find the information for which they are looking.
Mark Metcalfe
www.linkedin.com/in/MarkMetcalfe
Thursday, June 18, 2009
#
The goal of an information professional is to communicate ideas to another person that will enable that person to apply the ideas to their own goals. Communication is a three-part process, as follows:
1. Form an idea or concept.
2. Transmit the idea.
3. Receive the idea.
Despite the fact that forming and transmitting ideas come from a single person, people can have trouble articulating exactly what they conceive in their minds; that creates a (sometimes significant) change in the message before it gets transmitted to the receiver.
The receiver poses yet another challenge to the communication process because the message is interpreted through the filters of personal experiences and biases, and the receiver’s ability to comprehend the message.
The better technical communicators understand how to express information in ways that carry the message from conception through reception. An axiom along these lines is "say what you mean, and mean what you say."
Mark Metcalfe
www.linkedin.com/in/MarkMetcalfe
Wednesday, June 17, 2009
#
I was a technical writer for 16 years before moving into managing technical writers. We are a peculiar bunch of folks; kind of like the high school band: talented, but a little quirky. Most of us are introverted and get our kicks from composing information that people find useful. (I am one of the extroverted ones.)
While writers focus on their products, the writing manager has a broader focus on the corporate brand. A manager that merely maintains the status quo by updating operational information does not create good documentation. After nine years of managing people who are cut from the same professional cloth as I am, I reflect on the following qualities of a good documentation manager:
Innovation and leading-edge technology use employs new techniques to transfer knowledge better. Multimedia content allows a customer to watch a 3-minute demonstration rather than having to read several pages of documentation. (It has the added benefit of keeping writer skills current in a competitive market.)
A long-term vision develops a well-architected information system, plans a phased evolutionary path, and steadily executes on the plan.
Customer focus, which involves finding out what customers think that they want, but also markets the value of documentation to the customer; a proactive approach that communicates to customers that we understand their wants and needs, and respond to them, and include innovations that they should like.
Initiatives drive internal process improvement, such as defining best practice content, developing short-term and long-term strategies, working with internal and external customers for value-added documentation, helping to produce marketing brochures, just to name a few.
A proven track record of quality shows up in awards and other forms of recognition, indicating a pattern of excellence.
I am certain that other successful managers could add to my list. I will only add that I believe it is imperative that a technical writing manager understands technical writers and the value of content development to the company, even when others in the company cannot quite understand how good documentation affects the bottom line. (I have already blogged about how poor documentation definitely impacts the bottom line.)
Mark Metcalfe
www.linkedin.com/in/MarkMetcalfe
P.S. I played first trombone in the school band.
Tuesday, June 16, 2009
#
Thanks for the comments. Here is a more complete listing of information types that is extensive but not exhaustive. (By the way, I am hard-coding this page in HTML because I don't know how to easily create a table in this blog interface. Perhaps real geeks don't need Help, but I would benefit from it!)
Disposable information: Installation information such as wizard text, liner notes in a CD Jacket, and temporary information (passwords). Product Notes to tell the customer what is new in a version of the software. Getting Started, which is information in a small document (~20 pages) to familiarize someone with the product (in-depth information available elsewhere), or a high-level tool tour (which can be text or multimedia).
Reference and Quick Help: Road map that provides all-points access to the information set (that is, an index of sorts); information accessed from the Help menu and Help buttons. Web Information such as frequently asked questions (FAQs), knowledge database (user communities), known problems and workarounds; in addition to the rest of the information set available online. Reference Help such as procedures, command information, examples, descriptions, summaries, and glossaries.
Competence training: Tutorials that show an example use of the product from start to finish, or provide an online, interactive way to learn how to use the tool. User guides provide in-depth information about using the tool including complex reference information. Methodology guides provide tool-neutral introductions to new technologies. Flow documents describe "zero-to-goal" paths for using the software. They can also provide tool-to-tool migration of data for projects that require more than one tool to generate a product. Best Practices describe recommended uses of a tool. Expert papers also can describe specific successful uses of a tool.
Mark Metcalfe
www.linkedin.com/in/MarkMetcalfe
Monday, June 15, 2009
#
There are two fundamental reasons why people learn about something:
People learn to accomplish a specific task.
For example, a recipe for baking a chocolate cake contains specific instructions.
People learn to acquire knowledge, which can be applied in more than one way.
For example, a reference for baking techniques (perhaps at different altitudes) will contain concepts related to baking (the textures of certain breads, the right way to use yeast, and so on).
When the information professional understands ways that people learn, a number of methods are available to accommodate the various ways of learning. The following examples describe two ways to teach a person:
Progressive disclosure teaches a person by building concepts on the foundation of other concepts. For example, learning to count comes before learning adding numbers, which comes before learning to multiply numbers. Calculus cannot be taught without first laying the foundations of fundamental mathematics.
Rote reinforcement teaches a person through repetitive action. For example, an assembly line worker becomes more productive as repetitive action improves the skill.
Note: Both methods of learning may teach a person that 7x7=49. One person may add 7 seven times while the other looks up the answer on the multiplication table. If 7x7 is referenced with sufficient frequency, a person can “learn” that 7x7=49; the answer is available without needing the fundamentals of mathematics. But this kind of learning does no good if the equation changes to 17x8 or needs to be related to higher mathematical functions.
Mark Metcalfe
www.linkedin.com/in/MarkMetcalfe
Friday, June 12, 2009
#
The information professional determines ways to transfer information based on how, where, when, and why people learn. Because people learn in different ways, so we must take more than one approach to communicating ideas. Additional considerations include human factors and behavioral preferences of the consumer and the technical depth, volume, and complexity of the information may have impact on how the information should be presented.
In the broadest of terms, information has three main distinctions: disposable, point-of-need reference, and competence training.
There are times when we don’t need to learn, but we do need to acquire temporary knowledge to accomplish an immediate goal. For example, a person is given a temporary password for a single login session. The password must be transmitted and received, but it does not need to be retained after use. We provide some necessary types of disposable information such as installation guides and helps, which become unnecessary after installation is complete.
Reference information is important for the experienced user who needs specific point-of-need information to continue working. Usually, reference material is uncomplicated and should assist the experienced user with accomplishing a task.
Training can take a number of forms, including once-use quick starts, comprehensive user guides, focused tutorials, and abstract methodologies; all designed to develop proficiency. In contrast, proficiency is not the goal for disposable or reference material.
Mark Metcalfe
www.linkedin.com/in/MarkMetcalfe
Thursday, June 11, 2009
#
"Nobody reads the documentation," is something I hear a lot. There is another adage in software development that says, "if software was developed properly, then we wouldn't need documentation." This may be true, I do not know, but since I've been in this profession for so long, it may be true that precious few software products were developed properly.
However, (even as a documentation professional), I readily confess that I too tinker with software before I resort to reading about its features. There is much to be said about intuitive interfaces reducing the need for information about a product.
Sparse documentation may be fine for simple products with targeted functionality, but complex software that is "feature rich" is more likely to need information about how a user can go from dabbling to dazzling. This is where RTFM ("read the fine manual") comes in.
If documentation is good (and useful), people access it more often because they want to and because the information communicates and relates information in ways that people want to learn. Good documentation performs its function well (and occasionally gets praise).
If documentation is so-so, people access it only when they need to, because most so-so documentation is operational, focused primarily on describing the features of a product. So-so documentation can perform only somewhat adequately; it never receives praise, but it will be criticized when it does not meet minimum requirements or expectations, and it is the product (and company) brand that suffers as a result.
Mark Metcalfe
www.linkedin.com/in/MarkMetcalfe
Wednesday, June 10, 2009
#
Hello. My name is Mark Metcalfe and I have been a technical writer and technical writing manager since 1984 when cut and paste meant scissors and tape. A lot has happened in and to the world of technical writing since then. In 1984, most technical writers came from backgrounds like education, biology, English majors. I have a bachelors degree in computer science and there were precious few of us then. It seems that anyone who could show writing prowess and acumen could do it. It did not take long for colleges and universities to offer certificates in technical writing. Experience began to build, groups formed, and conferences convened.
The value of technical writing was difficult for some companies to see (even to this day) because anyone can slap together a description of software. Some people in other functions were very good writers, and some technical writers did little more than warm over specifications. However, the product documentation always reflected part of its overall quality and value to the customer, so if the documentation was well-written and organized, then it performed its job (and most customers took no notice; that is what good documentation does). If the documentation was bad, it reflected poorly on the product and cost the company real money in customer service calls. Most people do not know good documentation when they see it, but almost everyone knows bad documentation.
Today's documentation is being globalized. Due to the high cost of labor and the economic backdraft that led companies to cut its US writing staffs, we opened offices in India more than a dozen years ago, and now those offices are becoming primary generators of documentation. India is feeling the pinch from China, Russia, and other places, even in Technical Writing where English is still the primary language for product information.
Technologies have advanced and so have release cycles for documentation. In 1984, manuals had to be closed for weeks before the software release to be able to manufacture, print, and store the manuals. Today, companies are striving to convert their legacy documentation into rapid-access topics. What is ready at release time is quick starts and reference material - necessary for early adopters of the software - but writing continues following the release to get ready for the mass adoption of the software. The mass audience needs the more in-depth training and easier to consume and digest information. Text only is also becoming passe in a YouTube consumer environment.
The Technical Writer (a good one) possesses the skills to organize, prioritize, and convey information but that person also needs to adapt to new technologies for better, rapid access to just-what-I-need, or just-what-I-want information about a product or service.
I intend to use this blog to document things related to the technical writing field to generate an appreciation for content development in our current time.
Mark Metcalfe
www.linkedin.com/in/MarkMetcalfe