Wikis seem to be the poster child of Web2.0 content delivery. But how practical are they for creating and delivering content that people can really use? Relive our experience of setting up not just one—but three different wikis—each designed to meet a different need and have a defined role in delivering information for different audiences. Find how we populated them, how they were received by our customers, and how we published traditional online help from wiki content.

Over the last 18 months WebWorks has deployed two external wikis, one technical and one event driven, as well as one internal wiki used for a variety of business process and knowledge capture activities. It’’s been a steep learning curve, and we did some things wrong, but we also did a lot right. The impact on both our internal business processes and our ability to provide our customers with “just-in-time” information has been immediate and beneficial.

If you are thinking about deploying, or have recently deployed, a wiki, then this session is for you. The session will share some of those lessons learned, how we approached wiki design, how we encouraged people to contribute, and perhaps more importantly, how we controlled those contributions.

The session will also include a practical demonstration of how we automated the initial population of the wiki with existing content from legacy Adobe FrameMaker and Microsoft Word documents, as well as DITA-XML, and how the wiki content was used to publish user documentation in a variety of formats.

The session will conclude with a look at how we intend to continue our adoption of wiki technologies and how we are investigating the role of wiki-based content as part of our overall publishing workflow.

The use of visual help authoring tools like Adobe Captivate has exploded in recent years because they’re a quick, inexpensive way to create training movies, tutorials, simulations, even e-Learning materials. All of these tools, and there are almost 30 ranging from mainstream tools to shareware and freeware, do basically the same thing, but they often do it using different development models and feature sets. In this presentation, we’ll look at three commercial tools, the market-leading Camtasia and Captivate and a new one, Mimic to see how they compare as far as their development models, features, and appropriateness for your needs.

DITA provides an end-to-end architecture for authoring, managing, and publishing topic-oriented technical information. DITA may appear to be an ideal solution for authoring and maintaining online help systems. However, the DITA specification does not directly accommodate many of the customary and expected features provided by conventional help authoring tools. Learn how you can use DITA today to deliver online help, and learn what the DITA Technical Committee is doing to make DITA more directly usable for online help in the future.

Attendees will learn the following:

• How features of the DITA architecture map to the structure of conventional online help systems
• Why DITA can provide an ideal solution for authoring, maintaining, and delivering online help
• Current issues and limitations when using DITA for online help
• Common features of help authoring tools and how they map to (or don’t map to) DITA
• Approaches for maintaining and delivering DITA-based context-sensitive help

Documentation deliverables have evolved beyond manuals and online help in recent years, and with the emergence of Web 2.0, things are changing faster than ever. Technical communicators have many more options to enhance the user experience, and developing many of them provide the opportunity to work with other departments to find a more holistic approach to content development and delivery. But there is no one-size-fits-all set of solutions. This session will review the types of analysis you need to do to determine which deliverables are right for your project, your customer, and your company.

Other factors that cant be ignored, such as translation needs, staff/time constraints, file size limitations, corporate image and control, and proprietary concerns will also be discussed, including: 

• Analyzing the Product - Intended audience; delivery method (desktop, web application, etc.); competitor offerings; software development methodology. The UI as part of the Help system. Product Management expectations.
• Identifying User Wants and Needs—Preferences and expectations for information; work environment; knowledge and experience levels.
• Ascertaining Internal Needs and Opportunities—Working with Training, Support, and Marketing to reduce duplication and provide the user with consistent, useful information. Finding ways to incorporate information from other departments to improve documentation.
• Accessing Deliverable Options what is the optimum mix for the product?—The traditional: online help, manuals, embedded help, job aids, forums, web sites, technical support knowledgebases. Emerging trends: wikis, blogs, RSS feeds, software demonstrations, podcasts, and other collaborative tools. They can supplement and/or enhance the traditional. Or, they may be a better fit for internal knowledge management or marketing use.
• Optimizing the Library—Single-sourcing; best practices for structuring information; continuous publishing.