It's official. RoboHelp Lives!

[jdaigle]

Thanx to Chuck Martin, scribe at the WritersUA conference here in Palm Springs, there's good news about RoboHelp.
http://ua2006.blogspot.com/

There have been group forums and nearly 20 separate one-on-one meetings between RoboHelp engineering and product managers and RoboHelp users over the past two days and more sessions tomorrow. Adobe has had an earful of requests for future development. Clearly, Adobe has a way different attitude and is aggressively pursuing new development.
Stay tuned.
John

[jdaigle]

There are still some who have not see the messages on this and other message boards. To clarify and bring together the various reports, I will try to be as specific as I can about what I know regarding RoboHelp's future. This is based on reporting at the WritersUA conference, April 9-12.

1. On April 11, at the WritersUA conference Karl Matthews, Adobe Group Product Marketing Manager made a public statement to several hundred technical writers at the gathering. He said that Adobe is committed to RoboHelp and that a new release was in progress and expected "in the first quarter of 2007, if not before." So, while this may not be the "date certain" that many would like, it is about as specific as can be expected, given that Adobe is a public company and they must be careful because of SEC regulations.

2. Among the 7 Adobe representatives at this conference in addition to Karl were Vipul Bansar, RoboHelp's Product Manager and Vivek Kumar, directing RoboHelp's engineering effort on the next release, Michael Hu, RoboHelp's Product Marketing Manager, Jeff Booher, engineering (who goes back to Blue Sky Software and eHelp), RJ Jacquez, RoboHelp and Framemaker evangelist (also formerly of eHelp), and Raul Ramos, Product Support Specialist (also formerly with eHelp)

3. During the three-day conference, there was a RoboHelp Customer Advisory Forum held with the Adobe representatives with 12 writers representing many facets of the user community offer their ideas on the next release. In addition, there were more than 20 additional one-on-one meetings between RoboHelp users and Adobe engineers.

4. The meetings of these more than 30 RoboHelpers resulted from a public invitation to submit a questionnaire offering their thoughts on RoboHelp's future. Anyone can still download this questionnaire and submit it so that their thoughts are included. You will find it here http://www.hypertexas.com/

5. From my discussions with the engineering team, I gathered that considerable progress was made at WritersUA. We often think of these kinds of gatherings as superficial marketing events. But as an instructor, concerned about Adobe's commitment, I was pleased to see they came to WritersUA to "work" rather than schmooze.

6. Adobe is positioning RoboHelp as part of a family of technical documentation tools that include Framemaker, Captivate and Acrobat. Personally, I think this is a great group of products as they can all thrive on the synergy.

The Adobe folks remarked that the rich input they received will actually accelerate the process because it both validated some key development areas as well as exposed others that should receive more attention than they first realized. I got the impression that because of WritersUA, the release would be sooner not later.

As for working with WIndows Vista, future XML help formats and the rest, it certainly makes sense that a company of Adobe's stature would release a product that is compatible with such a major operating system.

I am not an Adobe employee, nor an official spokesperson. I am an independent RoboHelp instructor since 1992 and very happy to see that Adobe has taken a 180 degree turnaround from the previous management.

John Daigle
Adobe RoboHelp/Captivate Instructor
www.hypertexas.com

[Versifier146]

I think it is also important to note that at this conference, the news broke that WinHelp will not be functional on the new Windows Vista operating system.

That means that "RoboHelp for Word" will be affected.

~Jessica

[Peter Grainge]

Just to clarify Versifier146's comment lest it worries RoboHelp for Word users, I cannot see that RoboHelp for Word will be affected in any way.

The CHM and WebHelp outputs, indeed all the outputs, will still be capable of being produced. The point is that the WinHelp output will not run on Vista so if your users are on this platform, one of the other outputs will be required.

For anyone whose customers are remaining on the current operating systems that support winhelp, you can continue to produce it using RoboHelp for Word. Obviously, it would behove you to advise your product manager to consider changing to another format as in time your customers will be buying new PCs with Vista and will then need a different output.

[Captiv8r]

Hi all

One further bit of clarification as well. I believe that Microsoft is also working on a new version of its Office product too. Typically, when a new version of Office appears, a new version of Word appears. It's quite likely that any new version of Word will break the ability to use RoboHelp for Word with it, as RoboHelp for Word is only as good as the version of Microsoft Word available at the time RoboHelp for Word was produced. So this may also coax some holdouts to also bite the bullet, take the plunge and shift into using RoboHelp HTML.

Note that as long as you don't upgrade to the latest or newest Word, RoboHelp for Word should be unaffected and continue working just fine.

Cheers... Rick

[Peter Grainge]

Yes but provided Adobe don't just update RH HTML, the new version of RoboHelp for Word will surely be compatible with the new version of Word given the proposed timing.

Some years back when I was producing my first html help output, you gently chided me for using RoboHelp for Word. I had stuck with it as I had some expertise in that area. However, I decided to go with your advice, always a good plan, and haven't looked back. There is quite a learning curve though and I think for some authors RoboHelp for Word will continue to be the better bet.

The main point of my post though was to correct the statement that RoboHelp for Word would change.

[Guest]

Hello,

Very instructive thread. I knew of the general issues but was not knowledgeable at all on the specifics of it. It helped me a lot. Thank you to all participants. Everything is focused on moving the discussion ahead. Everyone is respectful. That is a good model of how to deal with a given issue. Thanks to those of you who contribute to provide the profesionalism with which this forum is being used.

Dan

[Guest]

Interesting topic. Most informative.

Does anyone have information about howmuch re-work / new features is expected int he new RoboHelp version. Also has a beta program been mooted?

thanks

[Captiv8r]

Hi Andy R

LOL, asking what you have is a bit like asking if our existing hardware will work on the Windows version that comes after Vista. Or what it may take to make it work.

The fact is, we have a spoken commitment from Adobe advising that a new version is being geared up for. There is no beta yet that I'm aware of. I would certainly hope to be a part of any such beta, given my long history with the product, but you never know. Even once a beta version would become available, you likely would not receive reports from anyone touting how much (if any) rework would be needed. Typically one signs a non-disclosure agreement with the party performing the beta. This means you can't openly talk about features.

Cheers... Rick

[Rickferrell]

Well Raul Ramos is no longer the Product Support Manager for RoboHelp, He nows works with Brezze. Chris Valiqet is the new RoboHelp support Manager.

[Guest]

As both a Flare and Robohelp user I was interested to read these two posts. Some interesting points made about documentation and HAT tools.

Is their information regarding Robohelp up to date? It is hard to work out what is the real state of play, with the variety of different stories being told.

http://monkeypi.net/?p=55

http://monkeypi.net/?p=54

[CraigCC]

Hi Andy,

the latest statement is contained within this thread

http://www.adobe.com/cfusion/webforums/forum/messageview.cfm?catid=447&threadid=1167119&enterthread=...

We have been reliably informed that developement work is taking place and that Adobe are looking into emerging issues. As Rick says, we do not currently have details of the features that will be made available in the next release. I don't think even Madcap make announcements about the 'content' of future releases. Also, as far as I'm concerned Flare and Robohelp are two quite different products, quite different companies and it is hard to compare the two.

Anyone can post enhancement requests for RH to Adobe at:
http://www.adobe.com/cfusion/mmform/index.cfm?name=wishform

Personally, I'm now very optomistic about the future of Robohelp with Adobe.

Kind Regards
Craig

[Peter Grainge]

Adobe did an about turn on Macromedia's decision so, as clearly described in the earlier posts, a new version is under way. The expected date is spring, 2007.

All the recent posts state that RH development has resumed so I am not sure which posts you refer to when you talk of a variety, unless you are including stale posts which would be pointless.

[Guest]

That's good to hear. Thanks for the reassurance.

My confusion arrises from information outside this forum. I'll have more of a read of the suggested threads.

[monkeyPi-nuCyRw]

I respect Adobe's interest in continuing RH development. As a long-time RH user, I look forward to seeing what Adobe can pull off with RH.

However, I have quite a bit of 'inside knowledge' regarding the state of RH code and development before the acquisition by Adobe.

It is true that Macromedia tried to 'sunset' RH, laying off the team and sending the X5 code to India. But I was told by a _very _senior RH developer that since 12 years of legacy code was sent to India after the layoffs and not documented, retrieving it for the purposes of producing an X6 version would be pointless, because there's no one left at Macromedia/Adobe with a complete understanding of the legacy code.

Therefore, any future RH development would have to be pieced together from whatever was retrieved from India, and none of the (qualified) original software engineers would be there to help. A _monumental_ task, to be sure. Of course, nothing's too difficult for a company as large as Adobe... and I'm sure they can scrounge up _someone_ that worked on RH at some point or another... but it's still a tall order for any company to fill.

In other words, the point is that Adobe will be forced to either (1) practically re-design RH from scratch, or (2) spend an equal amount of time and money wrestling with the legacy code and finding ways of tricking it to work with Vista and IE7.

Adobe may also have a unique challenge with Macromedia's activation servers. They'll have to provide a fix for the current versions of RH that are out there, when those versions get re-installed on new hardware.

Based on our experience with Adobe, which do you think is the most likely scenario? Personally, I worry that Adobe is going to end up giving RH the "FrameMaker treatment."

I know I speak for the seven RH users in my project team when I say that even though we've already converted mostly to Flare, we're all very loyal to RH and will use it if it provides a good product for our clients. However, if Adobe releases X6, and I open it and still see Kadov tags cluttering up my topics...

theMonkey

[Guest]

This topic is really interesting, thanks for all the info.

We've started asking the budget to buy Flare at my office, we need more than 40 licences now and RoboHelp's future is still too incertain for us. We have dozens of bugs and problems that still aren't solved, and we can't get any help from the tech supports (it's been like this for more than a year).

Anyone can give me a good reason not to get Flare and still wait for X6?

And I know it's off-topic, but the Adobe website seems to use more than half of my UC when it's opened, it slows my computer down to a crawl, and it's the only website I've ever seen do that (even Flash heavy websites work alright...) Anyone knows what the problem is?

Thanks!

[CraigCC]

Duplicate post, apologies.

[CraigCC]

Hi ?,

It may be worth checking out the following link. This FAQ may answer some of your questions. Adobe have not be in control of Robohelp for very long, so you may wish to give them a chance to consolidate their plans before spending your money elsewhere, but it is your money of course.

http://www.adobe.com/products/special/crossproduct/tech_communication/faq.html

In my most humble opinion what still keeps Robohelp one step ahead of the rest, is usability. Still a very affordable and credible solution for the majority of my clients.

Kind Regards
Craig

p.s. The forums/site is a little slow today, but that is quite unusual.

[Peter Grainge]

Starforsaken

You say "We have dozens of bugs and problems that still aren't solved" but you don't say which ones affect you so that people can comment.

You say "Anyone can give me a good reason not to get Flare and still wait for X6?" How can we without knowing what help you are generating and how it is that your tests have proven Flare to be better?

[Guest]

Sorry Peter! I wasn't really asking for help to my problems, just trying to know if right now it would be better to stay or to switch.

My main problems are :

- Still no French version available for RoboHelp (Madcap promised us a French version of Flare).
- The search function in WebHelp doesn't work really good enough, so we're stuck with CHM files for now. (it's even worse that our help is in French, some words aren't even found).
- The integration with SourceSafe doesn't work as well as it should. We have problems with .apj files getting checked out for no reason.
- RoboHelp crashes a lot when playing with conditionnal build tags (when removing them in batch), even after several reinstalls.
- Again with the tags, RoboHelp can't seem to be able to remove them when there are more than one on an object. We can't even create new colors, it crashes the software.
- Projects with more than 1000 topics cannot be compiled (in CHM), we have to make 2 different projects and merge them.
- We cannot use French quotes (« ») since it's mapped to the undo keyboard shortcut.
- We use both lowercase and uppercase letters to code our files, and RoboHelp (maybe it's SourceSafe fault) sometimes decide to make a file lowercase only. Kinda give problems when working with javascript files.
- The Kadov tags make the debugging hard to do.
- The multi-find search and replace tool doesn't work as it should and crashes most of the time.
- Converting from Word doesn't give good results.

I could go on for a while, but we've decided to stop trying to solve those issues, and either wait for X6 or get Flare.

[Peter Grainge]

OK Let's first offer what little I can.

- Still no French version available for RoboHelp (Madcap promised us a French version of Flare).
PG So Flare doesn't solve that one either.

- The search function in WebHelp doesn't work really good enough, so we're stuck with CHM files for now. (it's even worse that our help is in French, some words aren't even found).
PG You are not stuck with the WebHelp Search. See what is on my site. I have seen that seamlessly integrated into RH from a toolbar button. Cost under £100.

- The integration with SourceSafe doesn't work as well as it should. We have problems with .apj files getting checked out for no reason.
PG Cannot comment.

- RoboHelp crashes a lot when playing with conditionnal build tags (when removing them in batch), even after several reinstalls.
PG. I don't see too many reports of this. No consolation to you but nothing I can add.

- Again with the tags, RoboHelp can't seem to be able to remove them when there are more than one on an object. We can't even create new colors, it crashes the software.
PG. I have had no problems on this and again don't see many reports. KittyLiz did report the colour issue yesterday with X4 but I tested it and it all worked fine.

- Projects with more than 1000 topics cannot be compiled (in CHM), we have to make 2 different projects and merge them.
PG. This really should NOT be a problem. I am sure there are many people compiling with significantly more topics.

- We cannot use French quotes (« ») since it's mapped to the undo keyboard shortcut.
PG No comment

- We use both lowercase and uppercase letters to code our files, and RoboHelp (maybe it's SourceSafe fault) sometimes decide to make a file lowercase only. Kinda give problems when working with javascript files.
PG No problems experienced here either.

- The Kadov tags make the debugging hard to do.
PG Yup, everyone hates that. Learn to enjoy the madcap stylenames instead. :-)

- The multi-find search and replace tool doesn't work as it should and crashes most of the time.
PG Everyone knows that is bad and most use the low cost FAR application.

- Converting from Word doesn't give good results.
PG See the topic on my site. It does offer some tips. Better still though, if you can afford 40 copies of Flare, you can afford one copy of Dreamweaver 8 to import a Word document. Does a lovely job with nice code. Then import that into RH.

****************************************

The extent of the problems does make me wonder if these problems are really stemming from importing from Word to some extent or the use of source control. But whatever the cause, my concern would be that given it is not normal for RH to exhibit all these issues it sort of points to your projects or environment. To then expect Flare to handle these projects without such issues might be a bit optimisic is where I am coming from.

Have you tried it? As you are talking about merging, I would be worried about using Flare. I know you are merging CHMs and that may be different. Quite simply you have to do a load of multi file find and replace work to merge webhelp to the point where I decided it was a poorer application for my needs. There's a little bit of information on my site about Flare.

If you are buying 40 copies, I would test it to death before risking my job.

[Guest]

Most interesting reading on the thread. We all need to think carefully about where we invest I guess.

Peter, can you clarify the issue with madcap style names. I think this may be fixed now, but wanted to be sure I wasn't missing a clanger. The clear XHTML was the main reasons I'm leaning their way.

quote:

---

PG Yup, everyone hates that. Learn to enjoy the madcap stylenames instead. :-)

---

[Peter Grainge]

It wasn't a serious criticism. When you import anything with inline styles, Flare creates css styles and these all get the name MadCap in them instead of say Style1, Style2 etc.

It's easily fixed if it does seriously bother anyone.

[Guest]

Thanks for your comments Peter!

We don't use Word that much, it's only that we have about 70 writers, but only 40-45 spend enough time writing to need a RoboHelp licence. We've tried having the 25 or so other writers use Word then import the file, but that doesn't really work as it should.

Problem with Dreamweaver is that most of our writers don't know much about computers and software, I'm even impressed they can use RoboHelp. You wouldn't believe how many problems we get because the software is in english, since most of them don't understand what the error messages are saying. We did make a guide to let them know what to do with each message, but it's still an issue for us. If we're to buy Flare, they've agreed to make a French version, which is something that BlueByte/eHelp/Macromedia/Adobe never agreed to.

We've been using RoboHelp since 1999 I think. I've been trying Flare since February, and we even had Mike do us a little presentation and answer our questions. I've tested it a lot, and I'm really impressed of all it can do, and they're still at version 1!

I know SourceSafe can cause a lot of problems, but what can I do? RoboSource control is a lot worse, and with 40 writers, I can't work without multi-user support. We've tested Flare running right from our network, and didn't experience any problems, even with 5 users connected on the same project. RoboHelp didn't even work with ONE user on a network.

I'll have a look at your search engine suggestion. Price is not really a concern for us. I've been using FAR for a while, and it works well, but when using SourceSafe, I have to make sure I check out all the files before using it while an integrated find and replace tool should be able to do it automatically.

The lowercase/uppercase problem is pretty common I think. I remember a long thread about the subject here, with you and Rick trying to help a guy that had a similar problem. Maybe I'm wrong, but anyway we have the problem here, and since JavaScript is case sensitive, it can be a pain to deal with this.

The problem with the 1000+ topics (1150 I think) is something I never understood, but we have a project where it compiles with say 1151 topics or less, but won't work with 1152 or more. Maybe it's because we've converted this project from 3-4 different RoboHelp versions in the past, but I can assure you it doesn't work. I've tried the same project in Flare and didn't have any problems.

Anyway, I'm not trying to bash RoboHelp, but it's hard to keep waiting when the support hasn't been able to help for more than a year, and without knowing ANYTHING about the new version. And since the approval and purchase process is pretty long at my office (we're talking about 8-10 months from the start of the evaluation to the final installation), I don't expect to have RoboHelp running here before summer 2008 if we were to wait for the next version.

And thanks for worrying about my job 🙂

[Guest]

Hello Starforsaken,

About Conditional Build Tags, you may want to compare your Conditional Build Tag names within your topics (in TrueCode) with Conditinoal Build Tag names in Project's Conditional Build Tag list. Does every tag in the project list have the very same upper-case lower-case pattern as in your topics. For example, if you have a conditional build tag named "BeeHive" in a topic, but your project list has "BEEHIVE" or "Beehive", it will crash RH when you try to change that Build Tag in one of the topics. The issue is easily resolved by changing the case of the conditional build tag where they don't match the case of the corresponding tag in the project list. I found it impossible to even deactivate a conditional build tag without thus renaming it. The problem occured because there were two of us working on the same project. It came up after having merged both project, and only when we tried to unapply a conditional build tag so that another build tag could be applied to the same portion of text instead.

Hope this helps.

CTM Dan