WaDaYa KnO!

Getting surprising results from strategic project management, business analysis, content management, development, and delivery

Archive for the tag “DITA”

Best Practices are Always Best

If asked by a relatively small company to recommend tools and workflows for a moderately skilled author to create, manage, and deliver a body of content that might need to be consumed on multiple devices and exchanged with corporate wikis, websites, or other content repositories, what would you recommend?

This topic has long been close to my heart!


The most logical answer these days would be DITA or some XML authoring standard. When you use something that is non- proprietary, open, and standard, you have a better chance of withstanding the pace of changing technologies and being able to integrate with other systems without blowing a gasket.

DITA authoring tools have come a long way to be fairly simple to manage and deal with. Authoring in DITA is no longer the pain point it once was. Neither is storage, as you can now use SharePoint, or a number of well priced cloud solutions, such as DocZone or EasyDITA, or traditional locally hosted CCMSs, such as Blue Stream or Ixiasoft. SiberSafe even is offering their repository for free.

The pain point for DITA is still having to custom build the output transforms or customize the workflows. You almost have to be a programmer to handle that. Most authoring groups would prefer to be able to change their own outputs. WebWorks is a more writer-friendly tool for creating output and it takes DITA inputs. The WebWorks team have a nice selection of PDF, Help, and mobile device formats. I have been wanting to try it out for quite a while now, and  I suggest contacting WebWorks to get their white paper about linking their tool to DITA.

When you use tools that make it easier to produce outputs from DITA, or when you elect to use proprietary tools, like MadCap Flare and even the Adobe Communications Suite, you have to accept that you must live within their BOX. When you try to do things that these vendors have not built into their proprietary tools, you spend a lot of time trying to build out the customizations you need.

Ultimately, it depends on the specific requirements at hand. Today, there are so many options, including documentation frameworks like Dozouki and Vook for ePub. So, in my heart of hearts, I would stick to best practices and do not skip the requirements analysis and design phase. Even if it is done casually!


Killing Adobe Flash on Mobile Devices: We Saw This Coming

HTML5In his November 9, 2011 article titled “Jobs was Right: Adobe Abandons Mobile Flash, Backs HTML5,” Mike Isaac of Wired.com wrote about Adobe’s decision to stop developing its Flash Player plug-in for mobile browsers, and shift its focus to Adobe Air and HTML5. The decision to abandon Flash and embrace rival HTML5 may be controversial to some folks in the industry, but here at TechProse, we saw it coming. That’s why we have a production-ready HTML5 help solution for DITA-based content. (For details, see the September 2011 posting in this blog.)

There are many reasons why Flash and even Adobe Air are not the best solution for delivering content. Mobile devices need stealthy, small footprint apps, and the Flash footprint is just too large to manage on mobile devices. And, search engines can’t index content in Flash or Adobe Air. Search engines cannot penetrate Flash content, and Air uses frame sets that cause indexing to fail. What good is comprehensive help content if users can’t find it on the Internet or access it from their tablets and smart phones?

Many help authors think that by putting their help systems on the Internet, or on a corporate Intranet or Extranet, they have made help topics available to users. Unfortunately, that is not the case.

Now that Amazon has released Fire, its new tablet that costs under $200, tablets are more accessible to more people and the market will continue to grow. With technology advances like this, readers will expect more from content delivery systems. They will want to use powerful search engines to fetch precise answers that can be found within the top search results. To make that possible, help authors need to understand what impedes devices from accessing content and search engines from indexing it. Authors also need to know how to use metadata and manage it to enhance search results, how translation can be managed for help topics, what types of help systems support these tasks, and how to convert from what they have now to something that is capable of delivering content when and where it is needed.

It is time to trade in CHMs, RoboHelp, MadCap Flare, Adobe Air, Eclipse Help, and some WebWorks Help in favor of systems built using straight HTML5, JavaScript, CSS, and other open technologies that can provide access to content from any device or search engine.

Post Navigation