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

Trends in Technical Communication: Web Content Accessibility (Part II)

Through the mobile web, overlapping best practices for web content accessibility are about to go prime time. (See Web Content Accessibility and Mobile Web: Making a Web Site Accessible Both for People with Disabilities and for Mobile Devices).

To prepare, I’ve been reacquainting myself with my treasured copy of Letting Go of the Words: Writing Web Content that Works, by Janice (Ginny) Redish. There, you’ll find in my opinion, what’s probably one of, if not the best books available, on writing online.

Tips for Writing Accessible Web Content

Throughout her book, Redish sprinkles generous tips on web content accessibility. Here are just a few:

Let people choose their own text size (p. 148). Provide buttons on the web page to remind site visitors that they can adjust the size.

Make illustrations accessible, with meaningful alt text (p. 305). To develop helpful alt text, Redish suggests following the World Wide Web Consortium’s advice, imagining that you are reading the web page aloud, over the telephone. Ask yourself: “What would you say about the image to make your listener understand it? (From

Mark headings with the proper HTML tags (p. 237). Those using screen-readers want to scan web pages, just as sighted visitors do, Redish explains. If the headings are properly tagged, your blind web users can “scan with their ears,” (p. 320), by jumping from heading to heading.

Start headings with a key word (p. 247). Those who are listening to screen-readers scan only the first few words, in each heading. Make sure to include your keywords, at the beginning.

Write meaningful links (p. 318.) Click here and More links are useless to web visitors who are listening via screen-readers. Instead, Redish suggests rewriting these links to specify what visitors will get “more” of” and to use more informative words, as the link.

Tips for Formatting Accessible Web Content

Meanwhile, the January issue of Intercom–the Magazine of the Society for Technical Communication–provides detailed tips on making your web content’s formatting more accessible.

Properly tagging web content helps blind visitors using screen-readers and other forms of assistive technology to skim your site. It also helps make your document more accessible because anyone who cannot read your document can reformat it, by importing a new template, or editing the styles in your document, until each has a format they find readable (pp. 13-14).

According to STC’s Cliff Tyllick (@clifftyll) on Twitter, here are ways to take control of your text:

  • Use heading styles.
  • Use styles—or at least automated formats—to create lists.
  • Use styles to control paragraph formatting.
  • Use styles to control special character formatting.
  • Insert tables—do not draw them.
  • Use tables to display data, never simply to position content.
  • When you use informative illustrations, position them in line with text.
  • Associate alternative text with each informative illustration.

Additional Resources

For more information on writing for the web, check out Ginny Redish’s excellent slide presentation (PDF link follows): Letting Go of the Words- Content as Conversation.

For a clearinghouse of information on web content accessibility, I also highly recommend STC’s AccessAbility SIG (@stcaccess on Twitter), by STC SIG manager Karen Mardahl (@kmdk on Twitter). In Jan.’s Intercom issue about accessibility, Karen wrote a great article on “Captioning Videos on YouTube.”

If you know of other resources, please feel free to add them to the growing list of Web Content Accessibility resources, which appeared in my last post. Thanks to folks for suggestions so far, including these resources: WebAIM: Web Accessibility in Mind, WebAxe: Podcast and Blog on Practical Web Design Accessibility Tips, and the IBM Developer Accessibility Guidelines.

I’ll make sure to add these and any other suggested resources to the final list.

Please also feel free to add your best accessibility tips, in the comments. I’m still very much learning and am grateful for your help and recommendations.

About This Blog: Copyright Information

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

Trends in Technical Communication: Web Content Accessibility (Part I)

In January, Intercom–the magazine for the Society for Technical Communication—provided an excellent issue on all things web content accessibility, including articles on “Accessibility 101 for Technical Writers,” “Captioning Videos on YouTube,”and an “Alternative to Universal Design in Mainstream Video Games.”

Minor Accommodations, Major Impact

The article made me recall a few contracts back, when I was working as a technical writer, in a government setting. For the first time in my fifteen-year career, due to government mandates, an accessibility check was a required part of the documentation’s production process.

At the time, I remember being surprised at how relatively painless most of the accessibility guidelines were to implement—simple changes at the markup level, including alt tags, page titles, headings, and lists, which were only time-consuming if they had to be revised globally, as opposed to correctly implementing them the first time.

For print documents, I implemented these additional accessibility guidelines: providing alt text for embedded images, making sure to include an alternative format (.txt, .doc, or .xsl) for PDFs, keeping file sizes down to less than 5 megabytes, and adding electronic titles to Microsoft Office documents.

Whether for print or online documentation, I learned the cardinal rule of accessibility: Content needs structure.

Optimizing our Process

Some of the accessibility principles were not so straightforward, especially structuring content. However, information design is part of many technical writers’ standard practice. Others were not difficult to incorporate into my writing routine, once they had been pointed out to me.

Given how much of an impact these relatively minor accommodations can make for a more accessible Web–and how a simple style sheet could remind writers to more seamlessly incorporate many accessibility best practices across their content–it seems almost impossible to me, that this government contract was one of the few times I have formally encountered best practices for web content accessibility.

Convergence: Web Content Accessibility and the Mobile Web

With the rise of the mobile web, we may finally see more mainstream settings start addressing accessibility. As it turns out, what’s good for designing for people with disabilities is also good for designing mobile content. (For more on these best practices and for resources on web content accessibility, stay on the lookout next week, for Part II of this post.)

Questions and a Call to Action

In the meantime, for technical writers especially, how much has web content accessibility been a part of your job? How does accessibility apply to user assistance and structured authoring?

And I’d like to conclude here, with a call to action mainly to myself, to do a better job incorporating alt tags for the images, in my blog posts, especially the retroactive ones, where I wasn’t following the practice. In the end, accessibility is about taking the time to do the little things–many times also the right things (both for our disabled users, and in the case of mobile content, our bottom lines)–consistently.

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

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.

Screencasting: the Future of Technical Communication, with STC’s Raymond K. Archee

In the March 2008 issue of Intercom (the magazine for the Society for Technical Communication), Column Editor Raymond K. Archee does an especially nice job in the article, “Sreencasting—the Future of Technical Communication,”describing screencasting and considering its implications for the future of technical communication.

The Growing Role of Video in Technical Documentation

This is the same Intercom issue, where in a different article, “Adobe Pleased with ‘Suite’ Success,” Michael Hu, Senior Product Marketing Manager at Adobe, had this to say when asked, “Does Adobe foresee a greater future role for video in technical communication?”

Yes, but not just video. Rich interactive information and user experiences are a trend that all Adobe embraces. First of all, we live in a global marketplace. As companies reach new markets, the need to localize information increases, but more important is the ability to effectively communicate to a broader audience. In many situations, it is easier to communicate visually and easier to localize the content if the information is visual.

Second, the next generation of customers, decision makers, consumers of information, etc., live in a world of instant information, with less text and many times more visual information.

Finally, we need to think about how we author, manage, and deliver this interactive information and user experience, with some of the new industry trends affecting Web development, such as AIR
(p. 4).

Screencasting, Defined

Reflecting on the future of technical communication, Archee defines screencasting, also known as online video/animation, in this way:

Screencasting, which allows novice users to understand how to use a certain program or service, consists of a computer-based recording of an experienced user, demonstrating how to use a program or interface. The screencast can be accompanied by a voiceover to add a documentary-like quality, and it has numerous advantages for software training: the added realism of the screen versus paper-based or static online screens, ease of use, and low cost (compared with traditional training or real video recording). My experience with students shows it to be an extremely effective medium of instruction and training (p. 37).

Screencasting Software: Captivate vs. Camtasia

According to Archee, there are two main programs—Adobe Captivate and Techsmith Camtasia—that “allow users to create small videos/animations assembled from screen captures, text, comments, picture files, audio, and actual video” (p. 39). “Usually, the output is placed on the Web, in the form of Flash-based tutorials or demonstrations.”

Archee considers tutorials as “carefully paced, interactive sessions, whereas a demonstration is traditionally a noninteractive video” (p. 39).

Captivate and Camtasia take rather different approaches to creating these online videos/animations. Camtasia started as a video creation tool—it records an exemplary video file of a single session of expert software usage, complete with mouse clicks. You can add extra tracks for captions, callouts, and narration (p. 40).

Meanwhile, Captivate “is much more object-oriented, with screen captures, buttons, text, comments, audio, and extra video that have their own timing.” There is no central focus in Captivate, which is used similarly to PowerPoint, slide by slide,” Archee explains (p. 39).

The Future Is Here

Archee prefers Captivate (despite its premium price, at $799, as of 3/2010) to Camtasia (at $299) because he says Captivate “allows you to produce a kind of super PowerPoint presentation, available for an online audience”…You can use the screen captures and mouse clicks, or you can simply use text, in the form of comment and buttons,” he recommends.

On the other hand, Archee observes,  “if you are coming from a video or animation background, you will probably find Camtasia a more comfortable transition” (p. 39).

Still, Archee foresees a future, already at hand, where Captivate “has the potential to author any manual, document, animation, or video and combine these media in highly effective and creative ways” (p. 39).

About This Blog: Copyright Information

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