Adobe Technical Communication Enterprise Summit: Structured Authoring

This month, I was fortunate to attend the Adobe Tech Comm Enterprise Summit, a free conference on the latest trends in technical communication, held at the Adobe facility, in Boston, MA. It was a full and lively day, complete with informative presentations on trends in technical communication, from various thought leaders on structured authoring, including Scott Abel, CEO, from The Content Wrangler,  Inc., and Max Hoffman, from Globalization Partners International, Inc. Others presenters included Adobe’s own Kapil Verma, Ankur Jain, and Tom Aldous, followed by a detailed case-study on how to leverage Adobe’s Technical Communication Suite 3.5 , from Accenture’s Rick Thompson.

Technical Communicators, as Content Management Consultants

As described in my earlier post, Scott Abel’s keynote suggested that technical communicators are now more management consultants for content, as opposed to creators of content. Working alongside product management, Abel called upon technical communicators to continue breaking down the cylos within their respective organizations, with the objective of optimizing every part of the content delivery process. The end result, according to Abel, is re-usable content, developed for multiple delivery channels, audiences, formats, and languages.

Key Trends in Technical Communication Today

Adobe’s Kapil Verma described key trends in technical communication
today, driving the evolution of Adobe’s Technical Communication Suite 3.5:

  • Globalization, opening up new markets, in
    emerging economies
  • Multiple devices, requiring multi-screen, multi-channel
    publishing options
  • User-generated content & democratization of
    content creation
  • Increasing demand for rich media
  • Increasing demand for highly personalized content

Later that day, Thomas Aldous made a strong case that the
Adobe Tech Comm Suite, which includes both unstructured and structured
authoring versions of FrameMaker 10.0, sets technical communicators up for long-term success, as market requirements continue to evolve.

Structured Authoring: Reasons for Making the Change

Verma provided helpful guidelines, for when making the
change to structured authoring may make the most sense. Structured authoring
may be suitable for your organization, Verma advised, when you’ll be…

  • Translating doc into multiple languages
  • Transfering documentation, between systems
  • Managing dispersed content production
  • Creating and maintaining a large volume of
  • Making frequent documentation updates
  • Supporting multiple production variants
  • Publishing multiple formats
  • Following a standard documentation structure

Verma followed up these recommendation, with a meaty analysis, on how to derive the highest ROI from your migration to structured authoring.

More Information

In my next post, be on the lookout for highlights, from Ankur Jain’s presentation, on developing an enterprise social collaboration strategy.

I haven’t used the structured version of FrameMaker, or Robohelp in a few help authoring assignments, so in the comments, please feel free to add your experiences with these tools, or comparisons with other authoring tools. Past versions of FrameMaker (up thru version 9.0) have spoiled me for all other desktop publishing tools. How has making the transition to version 10.0 been for you?

And oh, before I sign off, a very Happy 25th Birthday, FrameMaker. Thanks to Adobe and all the presenters for their time and for the generous knowledge share. 

About This Blog: Copyright Information

Contacting the Author: Content for a Convergent World – Peg Mulligan’s Blog

Adobe Tech Comm Enterprise Summit, Keynote: Technical Communicators as Management Consultants, for Content

Technical communicators are now “management consultants for content,” Content Wrangler Scott Abel recently observed, at the Adobe Tech Comm Enterprise Summit, in Boston, MA. In his keynote, “Understanding the Role of Technical Communication in Enterprise Efficiency,” Abel  noted that technical communicators are now in the business of creating content (not books), which can be repurposed for multiple devices, audiences, formats, and languages.

Abel further explained how “automating enforcement of writing rules is one easy way to gain efficiency,” and how software can now encode rules to prevent authors from making the most common and costly writing mistakes.”

In Abel’s view, content creation is science, not art. For the technical communicator, Abel suggests, the art lies not in creating content, which can now be manufactured, but rather in deciding how to make content fit, in different scenarios, and in optimizing every part of the content creation process, eliminating redundancy and other waste, through the
application of structure and consistent terminology.

Abel pointed to Autodesk’s WikiHelp, which embeds videos, as an example of socially-enabled support content, and the efficiency gains of directly connecting and listening to customers, in this way.  He also pointed to the iFixit community, which provides repair information, not documents, which community members can directly edit. He further stated that every piece of generated content in these examples can be tracked and directly tied back to sales.

To advance similar initiatives, Abel recommended evangelizing efficiency gains and marketing achievements, within your company. He further advised partnering with
product management, with the objective of breaking down silos.

Resources on Structured Authoring

For more information, Abel pointed to Managing Enterprise Content: A Unified Content Strategy by Ann Rockley.

At the Enterprise Summit, Adobe’s Thomas Aldous offered a compelling value proposition for Adobe Technical Communication Suite, 3.5, suggesting that it makes a lot of sense for technical communicators, even those who are currently using the unstructured FrameMaker version, to set themselves up from the start, on a multi-channel publishing platform, which offers both unstructured and structured authoring options, and which can evolve with changing and inevitable market requirements.

Your Turn:

Do you agree with Abel’s keynote, that technical communication today represents more science than art? What might be the possible exceptions? Can you recommend additional resources or tools, for structured authoring?

About This Blog: Copyright Information

Contacting the Author: Content for a Convergent World – Peg Mulligan’s Blog

Heroic Narrative: Motivating Readers in Technical Communication

In the blogosphere this week, “Persuasion Ruled,” especially during the recent edition of “Kitchen Table Talks.”

There, Chris Brogan and Joe Sorge, of Kitchen Table Companies, kicked off the theme, by interviewing Sally Hogshead. Author of Fascinate: Your 7 Triggers to Persuasion and Captivation, Hogshead described seven ways to help small businesses grow, by identifying and honing their best persuasive triggers.

The next day, in a livestream interview at his blog, Brogan hosted Nancy Duarte—author of several books on making powerful presentations.

Presenters as Mentors

Touching on themes from her book (Resonate: Present Visual Stories That Transform Audiences), Duarte referred to the Hero/Mentor Archetype. Instead of the presenter as hero—dispensing information—Duarte explained how today’s best presenters act as mentors, helping the hero (the audience) overcome obstacles and accomplish goals.

Technical Writers as Facilitators

As applies to technical writing, Brogan’s webcasts made me recall Anne Gentle’s Conversation and Community, which predicts two roles for technical communicators, on the Social Web:

  • Sage on the Stage – instigator of conversation
  • Stagehand– enabler of conversation

In either role, the technical communicator isn’t leading the conversation, so much as helping to facilitate customer conversations.

Audience-Centered Learning Models

In his review of Gentle’s book, Stewart Mader ties in the related audience-centered focus from instructional design, where the metaphor for instructors is now “guide on the side,” as opposed to traditional information authority.

In this kind of mentor role, technical writers can support community managers or move into community manager roles themselves, Gentle’s book suggests.

“Emplotting” the Reader

In “Motivation and Technical Documentation,” David Goodwin observes how the age-old “heroic narrative” (Goodwin 99), “emplots the reader.” “What better way of motivating readers or users though a site than by providing them with a [heroic] journey, one rich with agreements, opposition, and problems,” Goodwin asks.

According to Goodwin, “not only does this “action-oriented role” apply to manuals, but it also can be built into content and navigation.”

Who’s Your Hero?

What ways do you know, of emplotting the reader, in the product documentation? How does your documentation place the customer, at the center of your product’s story? Is the customer the hero of your story?

About This Blog: Copyright Information

Contacting the Author: Content for a Convergent World – Peg Mulligan’s Blog

Trends in Technical Communication: Mobile-Accessible Documentation

In a recent post at TheSearchAgents blog, Mary Hayes highlights the growing importance of mobile devices, which according to AdAge Global are “poised to become the most ubiquitous media device in history.” AdAge Global reports that worldwide, mobile usage far outweighs that of the PC:

PC vs. mobile penetration rates for China are (20% vs. 57%); India (4% vs. 41%); Brazil (32% vs. 86%); and Indonesia (5% vs. 66%).

By Christmas 2011, Nielsen has estimated 1 in 2 Americans will have a smartphone.

Despite these trends, blogger Chris Brogan aptly observes in his Future of Media series that “the way we create media right now is still primarily as if we’re imagining a laptop.”

Understanding Mobile Users

In the Difference Between Mobile Search and Desktop Search, Dhrub Raag explains that “users accessing the Internet via desktop PCs or laptops are in a totally different mindset from their mobile counterparts,” with PC users “spending large chunks of time in a fixed location,” possibly spending hours searching and researching.”

Mobile users, on the other hand, are on the go, with a specific task to accomplish, usually in transit.

Mobile users “snack” on the Internet in small browsing sessions, and generally access the web, when they need a quick answer.

Implications for Technical Communicators

In his recent alertbox, Mobile Content Is Twice as Difficult, Jakob Nielsen recommends that for optimal usability, “websites (and intranets) must design a separate mobile version.” (Mitch Joel explores similar themes in Do You Need a Mobile Version of Your Website?)

Extending Nielsen’s findings about mobile content to technical communication, it would make sense that we must similarly repurpose our desktop user assistance for mobile users.

QR Codes: The Future of Technical Communication?

As part of a single-sourcing solution with multiple outputs (including PDF, WebHelp, and WebHelp Mobile), help-authoring tool MadCap Flare 7.0 already offers a Mobile format.

What’s more, Madcap Flare has expanded its leadership in mobile-accessible documentation, with support for creating and publishing Quick Response (QR) codes in printed documents.

Mobile devices can scan the QR Codes to access searchable, interactive content on the Web, including product usage information (see 10 Ways to Use QR Codes).

Repurposing User Assistance for Mobile Delivery

Most importantly, repurposing desktop content means keeping in mind what Mary Hayes calls the 15 Second Rule:

Mobile users want to find, not search. Determine what you want the user to do, then ask, “Can they do it in 15 seconds?” “Chances are, if they can’t, you’ve lost them for good.”

Streamlining content for the mobile platform will not only accommodate mobile users’ most immediate task requirements, it will also mean faster page load speeds.

…but Jakob Nielsen’s findings suggest to me that repurposing content for mobile users, involves a lot more than simply developing quick reference versions of our user assistance, in a mobile format.

Instead, repurposing desktop content for the mobile web will require technical writers to think even more than we currently do today about information types (Concept, Task, and Reference),  delivering the right type of information, via the media that best support that kind of content. Level of detail and scope, as well as how our efforts complement other content disciplines will take on increasing importance.

We’ll also need to start developing mobile-accessible documentation in a high-context communication style, which contrasts to the more low-context style, which has traditionally defined technical writing deliverables, especially in the US.

Another important consideration will be incorporating links back to the web versions of our user assistance or corporate web sites, for additionl context, as well as where to embed QR codes in the user assistance, which can possibly complement broader corporate objectives, as part of a comprehensive content strategy.

Getting Started: Audience Analysis for Mobile Users

When formulating a mobile strategy, Hayes suggests considering Action, Context, Location, and Mood, as part of our user personas. Though Hayes was writing about marketing content, I believe the same questions apply to user assistance, delivered via the mobile web, or otherwise:

  • Action – what does your audience want to achieve?
  • Context – what is specific to their situation?
  • Location – where are they?
  • Mood – how are they feeling? (This point ties in especially well with Trends in Technical Communication: Affective User Assistance.)

Your Thoughts?

Has your documentation group used Madcap Flare’s WebHelp Mobile format? Do you have any additional tips on how to customize user assistance for a mobile audience? Can structured authoring achieve some of the same ends?

What ways can QR codes enhance the product documentation?

Finally, how can our collective organizations help technical communicators better understand our customers, especially the context in which they use our products? And how can technical communicators continue to learn more about their customers, on their own? (see Analyzing Audience Without Direct Access to Customers).

About This Blog: Copyright Information

Contacting the Author: Content for a Convergent World – Peg Mulligan’s Blog

Trends in Technical Communication: Exploring SEO-Friendly Authoring Tools

Another emerging trend in technical communication is making sure our documents get found on Google. Search engines are where our customers turn to first for answers, yet most frame-based topics from traditional help authoring tools aren’t crawlable by search engines.

When technical documentation is available on the web, it can be a major sales tool and revenue generator. So says MindTouch CEO, Aaron Fulkerson, in The Evolution of the User Manual:

Fulkerson reports that for some companies, documentation is bringing in over 50% of qualified leads, through organic search results. At MindTouch, 70% plus of site traffic comes from organic sources, with the documentation generating more than half of overall site traffic. More impressive, MindTouch documentation drives over half of all lead generation.

Are Traditional Help Authoring Tools Holding Us Back?

In Search Engine Optimizing Your Help Content for Google, Tom Johnson provides an excellent analysis on the limitation of most frame-based help authoring tools, in making our content available on the web. He raises the question of whether we should abandon these tools:

As the importance of visibility on Google grows, and as companies recognize and treat their help content as an SEO asset for the online visibility and ranking (not to mention marketing) of their products, shouldn’t we put our help content on web-friendly platforms that will maximize their visibility in Google’s search engine results? Are traditional help authoring tools holding us back from realizing the SEO power of our help content?

Workaround for Frame-based Help

In the comments of Johnson’s post, Tony Chung suggests an interesting workaround for getting Frame-based help on the web. The proposed workaround would not, however, solve the problem of people linking directly to the help content because “for the most part, the location bar only displays the URL of the master frame and not the topic within it.”

Considering Alternative Tools

In the post Experiences with Reader Comments on the Atlassian Documentation Wiki,  Sarah Maddox shows how incorporating user-generated content into a documentation wiki helps drive more traffic for her company, than the general web site. She discusses the importance of Google Analytics in measuring site stats, and in a follow-up post, she explains how she balances customer edits and documents, against other priorities (including ensuring the most sensitive documents remain accurate).

Help Docs as Community Hub

Returning to Mindtouch as an example, the Gilbane Group has written a case study, Managing Content for Continuous Learning at Autodesk: When DITA Flows into a Social Web Platform, showing how Autodesk has created a customer-centric community experience, around their help docs.

Your Take?

How important is it for our help topics to appear in search results? What do you think about Tom Johnson’s question: “Are traditional help authoring tools holding us back?” Are alternatives like Confluence and MindTouch, the future of technical communication? How do these approaches fit in with a more structured approach to documentation?

Finally, can the help docs not only help drive sales but also help reinforce our customer community? Would this model help unify communications across the various content disciplines?

About This Blog: Copyright Information

Contacting the Author: Content for a Convergent World – Peg Mulligan’s Blog


A Tribute to Julia Child, Technical Writer: Resourcefulness in the Kitchen and Life

On occasion, I’ve wanted to share here one of my more personal past-times–that being cooking, and collecting recipes, from the various family and friends in my life, who are part of me, and are represented in an evolving tome, known in my family, as “the recipe book”–really more of a life scrapbook. It contains stories about everyone most important to me, as well as the continuing adventures–sometimes mishaps–that I’m sharing with my own kids, in the kitchen.

I couldn’t think of a way to occasionally tie these recipes back to a blog on technical writing, but Thanksgiving seems like the perfect opportunity.

I also recently came across an article I’d saved years ago from Intercom, the Magazine of the Society of Technical Communication, on the occasion of Julia Child’s passing. It was called, “Julia Child, Technical Writer” (September/October 2004), and was a reprint of the tribute by Sheila Jones, that originally ran in the June 1998 issue of Intercom.

At the time, I so appreciated Jones’ description of Child’s cookbooks:

The model she set with her cookbooks intuitively incorporated the most important guidelines in organization, conversational writing style, easy-to-follow page design, strong indexing, clear illustration, and step-by-step directions. She separated nice-to-know information visually, so when you returned to a recipe, you immediately knew where to look for direction. She had it all.

The Art of Improvising

In the original article, Jones described seeing Child at a bread-making demonstration for the Culinary Institute of America in Vancouver. Jones reported:

In preparation the day before, she reported, nothing went right. The Canadian wheat didn’t produce the expected effects, and the hotel’s gas ovens were totally inadequate. She and her team had worked until midnight, retooling the recipes, making adjustments and substitutions. Julia wasn’t complaining: she was explaining how to manage under difficult circumstances to get the best results. After the show, she stayed. Hundreds of us lined up to talk to her—she gave each of us time, asking questions and listening carefully.

Jones further noted, “Julia is the best of all possible models of technical writers: adventurous, humorous, outspoken, able to admit mistakes and get on with the job, disciplined, and precise.”

Qualities of a Good Technical Writer

Jones provided the following ways, we as technical writers can still apply Child’s example and attitude to our own work:

  • Understand quality and work to achieve it, regardless of the conditions.
  • Listen to your audience.
  • Communicate the good news and the bad news, forthrightly.
  • Respect your tools and resources—human and otherwise.
  • Pay attention to new techniques and innovations and incorporate them efficiently into your work.
  • Encourage the expertise of your team.
  • Credit and assist new professionals.
  • Enjoy your work; confidence and competence are contagious.

Jone’s insightful tribute still inspires and reminds me of the technical writer’s essential resourcefulness, versatility, and helpfulness, in the midst of changing circumstances and multidimensional objectives.

Julia Child, In Her Own Words

In conclusion, here are few recipes for life, in Julia Child’s own words:

On Living:
      “Life itself is the proper binge.”
On Art:
“Noncooks think it’s silly to invest two hours’ work in two minutes’ enjoyment; but if cooking is evanescent, so is the ballet.”
On Work:
      “Find something you’re passionate about and keep tremendously interested in it.”

Happy Thanksgiving! And be on the look-out, for the occasional Mulligan recipe, in celebration of all that I’ve learned and enjoyed, from cooking…


About This Blog: Copyright Information

Contacting the Author: Content for a Convergent World – Peg Mulligan’s Blog

Knowledge Integration Requires New Skills for Technical Communicators

In a recent webinar sponsored by Scriptorium Publishing Services, Tristan David Bishop, Senior Principal Business Analyst at Symantec, describes an emerging new role for technical communicators, as knowledge integrators.

According to Bishop, the knowledge integrator “partners with other teams across the organization to gather content that can proactively solve customer issues, reducing the need for incoming support calls.”

For technical communicators, knowledge integration involves these four steps:

Gathering content. Seek key topics missing in the doc, Bishop advises, by reviewing customer comments on published topics, studying web search results, and monitoring Tech Support Forums.

Ensuring accuracy. Through close relationships with Dev, QA, Support, and other SMEs, coordinate rapid cross-checks of the documentation.

Ensuring compliance. Through close relationships with Marketing/Branding, ensure repurposed content is compliant with corporate branding requirements.

Delivering repurposed content. As examples, Bishop suggests posting the repurposed content to the knowledge base for browsing, pushing updates into local installations, and optimizing for mobile viewing.

Bishop goes on to describe the key skills, required for successful knowledge integration: topic-based writing skills, XML publishing skills, and social media skills.

For background on the forces driving knowledge integration as an essential new responsibility for technical communicators, see the informative Scriptorium presentation, about the future of technical communication. There, Bishop provides specific examples of how Symantec is incorporating knowledge integration into its business processes, with some noteworthy results.

Additional webinars are available from Scriptorium Publishing.

About This Blog: Copyright Information

Contacting the Author: Content for a Convergent World – Peg Mulligan’s Blog

Three Roles for Technical Communicators on the Social Web

In her recent presentation, “Strategies for the Social Web for Documentation,” sponsored by the STC Education Department, Anne Gentle described three possible roles for technical communicators, on the social web.

  • Reporter/Observer
  • Enabler/Sharer
  • Collaborator/Instigator

Reporter/Observer Role

In the Reporter/Observer role, technical communicators use tools like Google Alerts, blog-only searches (via Technorati and Google Blogs), and Delicious to listen to conversations on the social web. They then aggregate information and curate content from users.

Enabler/Sharer Role

In the Enabler role, technical communicators enable comments and conversation through their user assistance deliverables. In the Sharer role, technical communicators share content through linking and syndication.

Enabling commentsJS Kit ECHO embeds the comment form on web pages and stores comments locally.
Enabling conversationsDISQUS – Hosted comments provide threaded conversations and moderation features.
Sharing Role: Linking.
AddThis – Register on the site, embed the code, and configure the sites, on which your users can share content.
TweetMeme– Add a retweet button to any web page.
Sharing Role: Syndicating Content. Offer users notifications of content updates. Embed content from RSS feeds.

Collaborator/Instigator Role

For the Collaborator/Instigator role, Gentle advises applying best practices from Social CRM to identify your organization’s influencers. She also advises thinking of your alignment in the organization. What corporate objectives does the technical documentation support?

  • Marketing & Sales – purchasing decisions
  • Service & Support – notifications, sharing, reciprocity, reputation
  • Invention & Development – users sharing ideas
  • Collaboration – shared goals, shared tasks
  • Customer Experience – convert prospects to customers
  • Learning & Education – study groups

Are You An Instigator or Enabler of Conversation?

In her book Conversation and Community:  The Social Web for Documentation, Gentle explores these themes in greater detail, in the chapter, “Defining a Writer’s Role with the Social Web.” In that chapter, Gentle refers to a post from the Web Worker Daily site, in which Anne Zelenka discusses the information age, versus the connectivity age.

Gentle expands on Zelenka’s post, with the following question for technical communicators: “Are you an information worker or a connection worker, and does your corporate culture support you more in one model or another?” (p. 72).

Gentle defines the instigator of conversation versus the enabler of conversation, in these ways:

An instigator provides a starting point for a conversation, perhaps by communicating a controversial decision or a highly debated strategic choice. A writer in an instigator role should know customers’ business needs and be well-connected with those he or she plans to talk to online.

An enabler of conversation understands the underlying concepts of a product or service well enough to help others understand those concepts as well. An enabler gives a community the authority to make decisions or provides patterns that help a community develop and grow. (p. 73)

“Whether you’re an instigator or enabler, you can repeatedly gather knowledge from communities and conversation, then bring it back and incorporate what you’ve learned into the documentation,” Gentle concludes.

What’s Your Business Goal?

In summary, what business objectives does the technical documentation serve in your culture?  Where is your natural alignment in the organization? Are you more of an instigator or enabler of conversation? What role on the social web—reporter/observer, enabler/sharer, or collaborator/instigator—best supports your company’s business goals for the technical documentation?

For me, these questions are among the most important take-aways from Gentle’s STC presentation and book.  The answer to these questions are probably at least as important as the answers to the traditional audience analysis questions, which technical writers are trained to always ask.  And the answers about business objectives for technical documentation are as diverse, as each of our organizations. The cross-disciplinary and often inconsistent objectives for technical documentation (across various corporate cultures) remains the greatest ongoing challenge for positioning the technical communication discipline for the future, on the social web, or otherwise. The diversity of business goals that technical documentation deliverables support is simultaneously technical communicators’ greatest business opportunity.

About This Blog: Copyright Information

Contacting the Author: Content for a Convergent World – Peg Mulligan’s Blog

The Role of the Gatekeeper is Changing: Guest Post by Sarah O’Keefe

The following  guest post is by Sarah O’Keefe, the founder and president of Scriptorium Publishing, specializing in content strategy for technical communication.

Sarah reflects on the benefits and challenges that user-generated content poses for technical communicators. She calls on organizations to develop a content strategy, identifying the specific scenarios where user-generated content is valuable, alongside a different set of scenarios, where professionally-generated content is still highly relevant. She proposes an emerging role for technical communicators, as content curators.

I remain very indebted to Sarah, not only for this guest post, but for all the content strategy resources she generously offers the technical communication community.

Without further ado, here’s Sarah, in her own words…

The Internet is removing the traditional gatekeepers for content.

Until quite recently, content distribution was a challenging process that required expensive equipment (printing press, video production facilities, trucks, warehouses) and in some cases government permission (TV and radio broadcast licenses). Now sites like YouTube and software like WordPress make content distribution trivial.

This change has profound implications for professional content creators of all types. In this post, I want to focus on technical communicators — people who create information to explain complex technical products.

(Technical communication is also called technical writing, but that phrase is falling out of favor because it excludes non-text communication, such as graphics and video.)

For technical communicators, the rise of user-generated content is a decidedly double-edged sword.

Benefits for technical communicators

Technical communicators can communicate directly with their target audience — the end users of the product. If technical documentation is published on the Internet, end users can provide comments or edit information directly. This feedback helps technical communicators improve their content by identifying errors or unclear writing.

There’s never enough time for in-house professionals to create all of the content that’s needed. Contributions from the user community can provide additional support and build on the official core content. The organization’s strategic plan for content should identify areas where users are most valuable (such as unusual ways of using the product) and areas where corporate technical communicators add the most value (such as information that requires high production values, configuration/installation instructions, and conceptual information). The overall content strategy can then ensure that the various content contributors have appropriate frameworks in which to operate.

Challenges for technical communicators

There is a temptation for business executives, especially in cash-poor start-ups, to dismiss their technical communication staff and simply rely on the community to provide documentation. There are a number of problems with this approach, but let’s take some obvious ones:

  • New products, in general, are perceived as riskier than established products. A new product without documentation raises that risk even more. Lack of documentation will make the product an even harder sell.
  • Although vibrant communities may help out with documentation, start-ups don’t usually have communities yet. Somebody needs to provide a starting point for technical content.
  • The open-source community has great difficulty in getting volunteer help for product documentation. You can expect this difficulty to increase for a commercial product.
  • Technical communicators are needed more than ever to plan, organize, refine, and curate content.

I believe, however, that we are entering a new era of accountability. Web analytics software makes it quite easy to measure whether content is being viewed. Technical communicators — and their management — can see how many people are accessing their content, and specifically which content is most or least popular. These metrics will drive decisions about not just technical communication but also product designs, marketing, and more.

More on this topic:

Many thanks to Peg Mulligan for sharing her space!

Sarah O’Keefe, President, founded Scriptorium Publishing in 1996 to provide editing and production services to technical writing departments. From the beginning, Sarah focused on efficiency—-selecting the right publishing tools, creating templates, and training writers on how to use their tools.

Today, the company is known for expertise in cutting-edge tools and technologies. With a dozen employees, Scriptorium specializes in streamlining publishing processes for numerous high-profile clients in telecommunications, defense, technology, and other content-rich industries.

Please contact the author Sarah O’Keefe direcly, at Scriptorium Publishing, for any rights to republishing this post. Peg Mulligan’s blog is protected by copyright, but I give any appropriate rights back to guest bloggers, for posts they may have authored, but which were hosted at this blog.

6 Emerging Trends in Technical Communication (Scriptorium Publishing’s Webcast)

Wondering where technical communication is headed, in 2010 and beyond? Sarah O’Keefe (from Scriptorium Publishing Services), Ellis Pratt (from Cherryleaf), and Tony Self (from HyperWrite) offer their insights, in a more than hour-long presentation, offered through Scriptorium Publishing’s highly informative webcast series.

According to these respected thought leaders, here are six emerging trends in technical communication:

  • Trend 1: Documentation will become more of a [positive] emotional experience for the user.
  • Trend 2: Technical communicators will start writing in a more persuasive (rhetorical) style, rather than their traditional neutral (explanatory|expository) style.
  • Trend 3: XML is now a prerequisite for supporting wider business objectives, providing much more than cost-cutting localization or single source formatting benefits.
  • Trend 4: The paradigm for how users refer to Customer Support versus User Documentation is changing.
  • Trend 5: Autogenerated Documentation—turning task models into procedures—is on the horizon.
  • Trend 6: As the proliferation of information continues to explode on the Web, technical communicators will find their jobs involving more and more content curation.

Make sure to listen in to the audio, in the SlideShare presentation (XML is now a prerequisite, not a feature). This webcast represents one of the best one-stop resources I’ve found, summarizing and exploring today’s technical communication landscape.