You’re welcome to join us on our upcoming free webinar, “The changing nature of content”, which will be held at 7pm (GMT+1) on 24th April 2013.
In recent years, technical communicators have focused on improving User Assistance through new technologies and systems, with the assumption that the nature of the content the tone of voice, the writing style should remain the same. In this free webinar, sponsored and hosted by Adobe, we’ll investigate whether the tried and tested writing methods from past decades still make sense today. We’ll look at the reasons why some organisations are “breaking the rules” with the User Assistance they provide.
If you need a Technical Author who knows RoboHelp, then Cherryleaf can help. Our Projects team and many of our contractors have skills and experience in using RoboHelp to create great content for your users.
With the imminent release of DITA support in MadCap Flare, will competing Help authoring tools (HATS) suddenly seem inadequate to the task of technical writing?
Where does this leave Adobe’s RoboHelp?
I suspect it will be difficult technically and commercially (Adobe also owns FrameMaker) for Adobe to add DITA support into RoboHelp.
If writers are collaborating on a project or if a Help system needs be localised into foreign languages, then RoboHelp and other HATS may well lose out to Flare.
However, if a sole author just needs to write a straightforward Help File, then many may not feel the need to change from the tool they use today.
So what would you do if you were Adobe?
I wonder if Adobe will choose to compete with MadCap in other ways. RoboHelp could become more of an online training, performance support, tool. Also, Adobe could bundle RoboHelp with FrameMaker at a price that makes Flare seem very expensive.
This, of course, may be all academic if the DITA standard isn’t taken up by more authors.
We took a quick look at Google’s new Chrome browser this morning. MadCap’s Flare Web based Help seems to work fine, but there seems to be a problem with RoboHelp’s Web Help – specifically the Table of Contents.
We dragged some old RoboHelp 5 generated Web Help files into the browser, and we looked at some of the examples listed on Adobe’s Web site (http://www.adobe.com/products/robohelp/customer_examples/). We haven’t had a chance to do any further testing.
Update – The problem is also there with RoboHelp 6 generated Web-based Help.
Zoho has decided to use its own wiki to provide online Help instead of Help created in RoboHelp. They have posted on their blog the reasons why they have done this, together with the benefits resulting from this change.
We’re not anti wikis and we’re not pro RoboHelp, but nearly all the benefits seem to relate to how the Help was produced and not to what was delivered. For example: With a move to a wiki, the users seem to have lost a table of contents that follows where you are in the document. The individual pages are very very long, unlike the short screen size pages normally you get with RoboHelp generated Help. There’s no pop-up Help topics (for things like glossary descriptions).
These problems may be down to bad information design rather than technical limitations, but it seems fair to say that this change has brought disadvantages as well as advantages with it.
It converts RoboHelp 6 or 7 generated WebHelp files into a single AIR file, which can be shipped to the user as an alternative to WebHelp. Air is similar to PDF, in that it will work across different operating systems in a consistent manner.
With the recent releases of new Help Authoring Tool versions for RoboHelp, AuthorIT and Flare, plus the release of Quadralay’s ePublisher 9.3, does this affect which Help Authoring Tool you should purchase?
What I find interesting is the different ways in which the tool vendors perceive the issue of creating user assistance. If you want to create great online Help, with paper being a secondary consideration, you will probably prefer RoboHelp or Flare. If you have a team of people writing, you will probably prefer AuthorIT or ePublisher. If you need to translate the content, then all four of these tools have strengths in their different ways. If you want to generate XML, then Flare, ePublisher or AuthorIT.
The best approach is probably to create a statement of requirements for your situation and then use this as a benchmark when considering each tool. Here are a few factors to consider:
The need to localise content. How many writers will be involved. Whether you are creating new content or re-using existing content. If you need single or multimedia output. Your view of users and the feedback they might provide. How much content you might be able to re-use.