Help authoring tools, or HATs, have been around for a long time. RoboHelp, the second oldest HAT, appeared in 1991/92 – impressive longetivity in a technical field.
HATs stay alive (business issues aside) by constant adaptation in the face of technical changes. For example, HATs in general could have disappeared in 1997 when Microsoft introduced HTML Help, since we could now create online help with web authoring tools like Dreamweaver. Many of the original HATs did in fact fail to make the shift to HTML and disappeared. But the larger, better funded ones like RoboHelp and Doc-To-Help did make the shift and are with us today.
That large-scale adaptation has continued since 1997, with the incorporation of support for PDF, XML, DITA, and now, mobile output, the focus of this post.
The mobile space has been chaotic since the late 1990s. Technologies like Windows CE Help and Wireless Markup Language looked good but failed to penetrate the mass market for several reasons, a major one being the fact that mobile output looked like this in 1998 (a screen from a Wireless Markup Language presentation that I gave back then):
This was a simple mobile app designed to teach the coding, but full-scale apps weren’t all that much more exciting. The screens were grey and bland compared to what we expect today, which looks more like this…
So mobile content and mobile apps are more inviting than they were a decade ago. And the explosive growth of the iPhone, Android, RIM, and other mobile devices has given mobile a degree of market credibility that it hasn’t had before. So it makes sense to start looking at mobile. And yet…
Many companies are reluctant to try mobile for three reasons:
• There may not appear to be any environments in which their apps can be used in a mobile mode. But some uses just may not be immediately obvious. For example, accounting apps might be used in the field for inventory control and need mobile-style online help. Or reference guides containing settings for pollution sensors in a food processing plant might be more usable on a mobile device when the sensors are mounted up near the ceilings.
• Companies may be looking at the market for mobile apps or help or “content” and find the choice between the various platforms to be too confusing or chaotic to be able to pick one.
• Companies may have tried mobile before and been disappointed by the feature set or burned by the reception in the market.
In each of these cases, companies will be rationally reluctant to invest in new tools. But if your company uses certain HATs, and I’ll focus on RoboHelp here, there is a way to test the mobile waters almost effortlessly.
On April 23, Adobe released a RoboHelp 8 script that converts RoboHelp projects to the ePub format. ePub is a standard from the IDPF (International Digital Publishing Forum) for “reflowable” text, which essentially means that content can change its width to take into account the width of the screen on which it’s being displayed. You can find the instructions for downloading and installing the script, along with suggested best practices for coding content, on the blog of Ankur Jain, RoboHelp Product Manager, at Adobe’s Technical Communication blog at http://blogs.adobe.com/techcomm/. The instructions for the script itself are in the April 23 post. The preliminary announcement was in the April 12 post.
The reason this script release is important is that it’s strategic. If you’re a RoboHelp shop but have wanted to try mobile output, you no longer have to buy and learn new authoring tools. Instead, mobile simply becomes one more output in a tool you already own. And if mobile turns out not to be what you need, there’s no money wasted on a dead-end tool - just abandon the mobile output and go back to your regular RoboHelp work.
I’ll be describing the feature set and some test results in an upcoming post.
HATs stay alive (business issues aside) by constant adaptation in the face of technical changes. For example, HATs in general could have disappeared in 1997 when Microsoft introduced HTML Help, since we could now create online help with web authoring tools like Dreamweaver. Many of the original HATs did in fact fail to make the shift to HTML and disappeared. But the larger, better funded ones like RoboHelp and Doc-To-Help did make the shift and are with us today.
That large-scale adaptation has continued since 1997, with the incorporation of support for PDF, XML, DITA, and now, mobile output, the focus of this post.
The mobile space has been chaotic since the late 1990s. Technologies like Windows CE Help and Wireless Markup Language looked good but failed to penetrate the mass market for several reasons, a major one being the fact that mobile output looked like this in 1998 (a screen from a Wireless Markup Language presentation that I gave back then):
This was a simple mobile app designed to teach the coding, but full-scale apps weren’t all that much more exciting. The screens were grey and bland compared to what we expect today, which looks more like this…
So mobile content and mobile apps are more inviting than they were a decade ago. And the explosive growth of the iPhone, Android, RIM, and other mobile devices has given mobile a degree of market credibility that it hasn’t had before. So it makes sense to start looking at mobile. And yet…
Many companies are reluctant to try mobile for three reasons:
• There may not appear to be any environments in which their apps can be used in a mobile mode. But some uses just may not be immediately obvious. For example, accounting apps might be used in the field for inventory control and need mobile-style online help. Or reference guides containing settings for pollution sensors in a food processing plant might be more usable on a mobile device when the sensors are mounted up near the ceilings.
• Companies may be looking at the market for mobile apps or help or “content” and find the choice between the various platforms to be too confusing or chaotic to be able to pick one.
• Companies may have tried mobile before and been disappointed by the feature set or burned by the reception in the market.
In each of these cases, companies will be rationally reluctant to invest in new tools. But if your company uses certain HATs, and I’ll focus on RoboHelp here, there is a way to test the mobile waters almost effortlessly.
On April 23, Adobe released a RoboHelp 8 script that converts RoboHelp projects to the ePub format. ePub is a standard from the IDPF (International Digital Publishing Forum) for “reflowable” text, which essentially means that content can change its width to take into account the width of the screen on which it’s being displayed. You can find the instructions for downloading and installing the script, along with suggested best practices for coding content, on the blog of Ankur Jain, RoboHelp Product Manager, at Adobe’s Technical Communication blog at http://blogs.adobe.com/techcomm/. The instructions for the script itself are in the April 23 post. The preliminary announcement was in the April 12 post.
The reason this script release is important is that it’s strategic. If you’re a RoboHelp shop but have wanted to try mobile output, you no longer have to buy and learn new authoring tools. Instead, mobile simply becomes one more output in a tool you already own. And if mobile turns out not to be what you need, there’s no money wasted on a dead-end tool - just abandon the mobile output and go back to your regular RoboHelp work.
I’ll be describing the feature set and some test results in an upcoming post.
No comments:
Post a Comment