If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!
So, I arrive to work this morning, and am deluged with emails from Adobe, message threads in the HATT list and RSS feeds barking at me about Adobe’s “surprising” and long-awaited release of RoboHelp 6.
One blogger I really respect claimed, “Congratulations to Adobe for getting this out technically ahead of time!” Another wrote, “Well, the ‘RoboHelp is dead’ crowd will be disappointed to note their predictions were wrong.”
As a long-time RoboHelp (RH) user, I excitedly rushed to download the trial update, eager to see what five years, two corporate transitions, millions of dollars, and the motivational threat from new competitors (Madcap, AuthorIT) had done to my once-beloved RH.
I installed the update, launched the software, clicked the “Continue to 30-Day Trial” button, and…
…RH comes up. Hmm. Did I click on the wrong icon? I checked Help > About, and it confirmed version 6.
Seriously? No GUI changes? No support for dual monitors? No effort to bring it into the Adobe family using dockable tool palettes? We’ve decided to stay in 1995?
Okay, these are just first impressions. Calm down, monkey boy. I’m sure they at least they got rid of the proprietary Kadov tags, right? Create a new topic, add some fancy stuff… view source code, and…
Ah, heck nah!!!
So, what did Adobe do?
Well, for starters, they added a few features, like variables, command-line generation, and even Acrobat Elements to assist with printed output. Groovy. Props. The GUI, which had always been user-friendly, now sports drag-and-drop functionality. Groovy again. Adobe also spiced up the conditional build tag functionality, and made multi-author support easier. But as far as I can tell… that’s about it.
As far as output goes, I noticed nothing different from my old X5 topics. Same SSL folders, full of the same *.js, *.hh_, and *.vbs script files. The WebHelp skin editor is the same as X5, and there are no new flash skins.
I’m forbidden to have IE7 on my work machine, so I can’t test the output there. In IE6 there were no surprises. However, when I launched my sample FlashHelp file in Firefox 2.0, this popup appeared:
That looks pretty chintzy to me. Amateurish. I wouldn’t want a client seeing that, which means that this would go on my already-too-long list of After RH Generation Tasks — a list of things I always have to hack in the help system between compiling and delivery. (”Back door fixes,” if you will…)
Want some XML? You still have to go through the FrameMaker route (or use another XML editor).
Oh, and speaking of FrameMaker (this is just sad): no native FrameMaker support. You still have to MIF your files first, apparently. Oh, come on. This is just laziness. Even MadCap Flare lets you import binary FrameMaker files. Does that make sense? A competitor works with your files better than your own products do?
I could go on, but I’m too depressed. Maybe I’ll discover something awesome as I continue to play with it. If I do, I’ll let you know. But for now…
Verdict:
It’s the kadov tags that’s the killer for me. Although I do want to get a look at it myself.
Perhaps the performance is improved?
I didn’t notice anything different about the performance, Andy. Not that it wasn’t improved – only that I didn’t notice anything.
I agree about the Kadov tags. I once spoke with an ex-RH developer, and he told me that, “if Adobe releases a version with Kadov tags, then you’ll know that they’ve been struggling with the software.” In other words, if you see them, then you’ll know that Adobe hasen’t changed much “under the hood.”
Definitely download the trial version, and give it a shot. After spending the past half-year in Flare, though, using this seems like a step backwards to me.
Well, you have to admit it’s an improvement over the FIRST RoboHelp v6, circa 1997.
Lack of FrameMaker support is a deal killer.
Decent review, needs more … substance. Cute puke.
T.
Thanks, T.
Yeah, this was pretty superficial. Just a few first impressions after playing with it for only an hour or two. Although, once you encounter the Kadov tags… how much more digging is worth it?
I still think it’s an improved RH. If one is loyal to RH, and he/she hasen’t switched to AuthorIT, Flare, or WebWorks, then this will probably be a welcome upgrade.
In my opinion, though, the features and fixes included are not “full version number” worthy… had this come out five years ago, it would have probably merited only an incremental version (say, from 5 to 5.0.1 or something.) I guess my expecations were a little high. Whether that’s my fault or Adobe’s is yet to be figured out.
I haven’t looked much at the feature set beyond the marketing hype. It really doesn’t look like much of an improvement over X5. New retro versioning, some slight enhancements, and teal branding. it’s all about the teal.
I am not sure why Adobe supposedly made it easier to import Word documents rather than export printed documentation. Isn’t RoboHelp designed to be a single-sourcing tool, where your primary content is housed in RoboHelp and you export all your printed documentation from your RoboHelp file? They included Adobe Elements, but who immediately creates a PDF of the exported printed documentation without first cleaning up the output? I have 15 macros that I run first before the printed output looks acceptable.
Tom – I’m also not sure what Adobe’s priorities are.
I have been puzzled, business-wise, as to why Adobe re-invested in RH at all. For years, they’ve been pushing the FrameMaker & WebWorks solution for single-sourcing. Now they’re selling RH & Acrobat… what does that do for Frame/WebWorks? Is Adobe recommending one over another?
Thank you for this. I downloaded RH 6 the day of the release (which took forever from my home computer). First I gasped at the lack of GUI changes. Then I barfed (not really, but in keeping with the sentiment of the spouting angel above) when I looked at the “true code”. I proceeded to close the damn thing probably never to look at it again.
I’ve been using Flare since it was born and we have struggled tremendously with it. However, we’ve been very happy with their support and willingness to listen to customers. RH 6 would definitely be a step backward for me.
I use (and am quite happy with) AuthorIT. I’ve downloaded both the Flare 2.x and RoboHelp 6 Trial versions.
Our only output – chms. From my perspective, a chm is a chm is a chm. Anyone care to prove me wrong?
What matters to the end user – you know, the folks that keep us in business – is the information presented (i.e. the meat), not the tool that created the holder.
It seems like most TWs that I’ve talked to (cyber and/or face-to-face) are more concerned with the process versus the results.
Bottom line: Concentrate LESS on the tool and MORE on the content.
Jayne
Great point JSmithe. I agree, content should always be paramount.
However, if the users can’t get to your content because your tool doesn’t provide a file format that they can use/read… then all the great content in the world is as useful as white gloves are to a person eating a ketchup popsicle.
>>a chm is a chm is a chm< <
Assuming chm files will work in Vista. Already, chms don’t work over networks, and there’s some confusion over whether or not MS will support the format in Vista. From what I’ve heard (it is second-hand; I haven’t confirmed this myself yet), the 32-bit help viewer is not shipping with Vista, so if you want to use chm, you’ll have to make sure your clients have a really old legacy 16-bit version of the chm viewer.
In short, within a year or two, a “chm will not be a chm will not be a chm.”
You’ll have to switch to WebHelp, or use the new slick Longhorn help format. Or risk your clients not being able to read your help.
Hello MonkeyPi and all
You know, as a long time RoboHelp devotee, it’s really sad to see what I deem to be nothing more than bashing of an attempt to breathe life into a product. From what I’m reading here, you (and others) are decidedly Flare fans. You know what? That’s great for you. But why try and bash a product and effort for something that many others still find useful? What do you have to gain?
Let’s take a bit of a closer look at details, shall we?
Many are upset about the lack of a change in GUI. Anyone feel free to correct me if I’m wrong, but what other HAT allows you to choose any HTML editor you like as RoboHelp does? I’m doubtful that Flare allows this. Oh, wait. Flare only does XML and from what I understand there simply aren’t many XML editors out there. So perhaps that particular point is moot. However, I’m confused by a statement made later that says: The GUI, which had always been user-friendly, now sports drag-and-drop functionality. Ummm, so I sit here wondering how much wailing and gnashing of teeth would have erupted had a drastic GUI change occurred? Geez, at least they kept the good stuff there. And I’m not sure what you mean by additional drag and drop functionality. RoboHelp HTML has had that for a long while. Assuming one knew how to use it. I think version 2002 introduced the ability to drag a TOC item to the topic pane to establish a link.
Okay, I know folks are fussy about the kadov tags. Personally, they have never bothered me. I’ve never understood the big deal. Even in X5, although they are present in the source files, I have never encountered them in output files. And to me, I would think the output files are what really counts.
Keep in mind that the great and wonderful Flare has been and is developed by the same folks that gave RoboHelp HTML kadov tags. Can’t help but to wonder if some of the same things will later be said about some method that Flare uses that users find equally objectionable. That isn’t intended to take a swipe at Flare. Only to illustrate that developers do what they can to make products work.
So MonkeyPi says:
As a long-time RoboHelp (RH) user, I excitedly rushed to download the trial update, eager to see what five years, two corporate transitions, millions of dollars, and the motivational threat from new competitors (Madcap, AuthorIT) had done to my once-beloved RH.
Personally, I don’t think this even comes CLOSE to being fair. After all, let’s just remember what happened. Macromedia put absolutely NO effort into any form of development. They actually did quite the opposite. Hmmm, let’s take a very popular product and just try to kill it, shall we? Sure sounds like a sound business practice to me. Then someone with actual sanity comes along and decides the same product has value. Personally, I’m amazed they have been able to accomplish as much as they have. Actually, I heard a podcast where Mike Hamilton claimed that the RoboHelp developers (the same Flare developers) tried for 3 versions to add command line compiling to RoboHelp. Hmmm, let’s think about that. 3 versions? So the same developers that so smartly developed Flare simply couldn’t manage to accomplish command line compiling with code they are very familiar with? Then along comes a group of developers that are pretty new to the code and they manage to accomplish straight away what those that had lots of intimate experience with the product were unable to accomplish? I’m not trying to bash Flare in any way, just making an observation and stating a fact.
You say they simply “Spiced up the conditional build tag functionality”. Hmmm, again, Mike Hamilton stated in the podcast I listened to that once again, because of the “old technology used” for RoboHelp, the developers (again, the same ones that developed Flare) were simply hamstrung to figure out a way to make the build tag functionality apply to the TOC and Index. And yet, once again, the current Adobe development staff in a single release managed to make it work. Geez, sounds to me as if they have a magick crystal ball or voodoo to accomplish what the original development staff said couldn’t be done.
One thing that wasn’t mentioned in this was that one of the enhancements to the conditional tagging is to now actually remove table rows and columns if you apply a condition to the entire row or column. Seems to me the original developers should have caught that straight off and got it right the first time. Again, I guess they probably claimed it was “technically impossible”.
You then said:
As far as output goes, I noticed nothing different from my old X5 topics. Same SSL folders, full of the same *.js, *.hh_, and *.vbs script files.
First off, whatcha been smokin there MonkeyPi? I’ve never known .vbs files to be any part of WebHelp output. I do see a single .VBS file in the FlashHelp output. Not sure if that one is new or not. Never paid any attention to that.
You mention something about RoboHelp HTML being unable to work with FrameMaker files directly and having to deal with .mif files. Now I’m not a FrameMaker user, so maybe I’m missing the point. But isn’t FrameMaker a HAT? Or am I misunderstanding? Personally, I say give Adobe a chance and I’m fairly certain that if this is truly important, they will step up to the plate.
You say: A competitor works with your files better than your own products do?
Keep in mind that the Adobe development staff is just coming to terms with code they have never seen. So far, they have my attention by simply managing to accomplish what the original development staff found imposssible. I think once they are totally familiar with the code, the sky will be the limit.
I see the following was said: I agree about the Kadov tags. I once spoke with an ex-RH developer, and he told me that, “if Adobe releases a version with Kadov tags, then you’ll know that they’ve been struggling with the software.” In other words, if you see them, then you’ll know that Adobe hasen’t changed much “under the hood.”
Again, if something works, why change it immediately? Additionally, I feel that the person that said that now has a vested stake in a new venture. Now I do wish them all the best in the new venture. But if it’s so much better, why feel the need to even remotely suggest things don’t work or aren’t quite “up to snuff”?
Later, the following appears: Although, once you encounter the Kadov tags… how much more digging is worth it?
Again, I challenge you to advise why these are so detrimental? What, specifically is it that stops working or doesn’t work as a result of them? I’ve personally used RoboHelp HTML for years with them totally intact. I’ve never actually encountered anything where they managed to impede what it was I was trying to accomplish. If there really is something that breaks, I’ve never seen it and would love to know about it.
Later, this appears:
In my opinion, though, the features and fixes included are not “full version number” worthy… had this come out five years ago, it would have probably merited only an incremental version (say, from 5 to 5.0.1 or something.) I guess my expecations were a little high. Whether that’s my fault or Adobe’s is yet to be figured out.
Hmmm, many of these features are what eHelp was planning on including in a total version release. Again, the same developers that created Flare. So I suppose you feel they don’t know what they are doing when they develop features that you don’t feel are totally “version worthy”. So yes, I do feel your expectations are high.
And again, this appears:
Tom – I’m also not sure what Adobe’s priorities are.
I have been puzzled, business-wise, as to why Adobe re-invested in RH at all.
Why not? There is a definite user base left and who knows how many may switch back as a result of the update? There were a great many folks that were whinging at the lack of an immediate release of RoboHelp. Seems to me they were simply listening to loyal customers.
Geez, I guess that means their priorities are screwed up? Glad you don’t run my business. If your priorities aren’t serving loyal customers, you won’t be in business very long. Even uneducated folks know that.
To Stacia, all I can say is: Happy continuing struggling with Flare! RoboHelp it’s not and it really should be that way. There is a reason RoboHelp was (and is) so popular with many of us. That reason is because it’s so darn easy to use. I guess you expected a nice change of interface. Lots of odd large arrows and mysterious windows that rearrange themselves and weird, bizarre cursors that change for no obvious reason. WebHelp output with some strange layout that isn’t familiar. (okay, well maybe I do admit that was a bit of a swipe at Flare, but I personally find it too “developer” like to suit my tastes.)
danielg says: I’m still a loyal fan of Frame, tho’; got to give it credit for its stability.
Hmmm, and who are the Frame developers? Oh yeah… Adobe!
JSmithe says: It seems like most TWs that I’ve talked to (cyber and/or face-to-face) are more concerned with the process versus the results.
Bottom line: Concentrate LESS on the tool and MORE on the content.
And I couldn’t agree more. Personally, it’s nothing more than personal preference and what makes you the most productive to achieve your goal. If AuthorIt is your tool. Go for it! Same with Flare. Same with any other tool.
The monkey responds to JSmithe and says something odd:
However, if the users can’t get to your content because your tool doesn’t provide a file format that they can use/read… then all the great content in the world is as useful as white gloves are to a person eating a ketchup popsicle.
Ummm, since when can’t users get to HTML content? Did they revise the whole internet and change things to XML while I wasn’t looking?
Wow, guess I’d best alert the troops that HTML is out and XML is in. Browsers galore suddenly stopped displaying the language of the web. Come on… get serious.
The monkey then reveals that he doesn’t know the difference between a WinHelp file (.HLP format) and an HTML Help file (.CHM format) by saying that the 16 bit .CHM viewer will make HTML help files stop working in Vista. Ummm, sorry. I think you need another banana. Believe it or not, a file format existed prior to .CHM and it was known as .HLP. And that, my friend, is what they are talking about in Vista.
The bottom line here appears to be that a great many folks are just irritated that Adobe decided to resurrect a product. A product that many believe in, like it or not.
My only request is that if you find a tool, and I do mean ANY tool, why bash the others? Well, not really just the others. For some reason, folks seem to be singling out RoboHelp. And personally, I think they are worried about it. Otherwise, if it REALLY did suck as bad as you claim it does, why all the press?
Do I love RoboHelp? You betcha. But I never go about claiming it is better than any other tool and you need to switch immediately or risk the world ending because the browsers mysteriously were changed overnight and stopped reading HTML code.
I guess that in the end, it’s a bit like a forbidden topic. Religion.
Okay, now anyone that wants to can begin flaming me.
Rick,
You’re not honestly stating that Adobe is putting the same amount of development work into RoboHelp as they have into their first tier products, are you?
If they were they would have looked at how to appease the community by putting out some free updates that are necessary to continue with browser updates, Firefox capability, etc. right? Dropping a couple free updates to an existing base – this was what, like a $36 million market that RoboHelp was top dog in three years ago.
Instead there are virtually no top changes that cost money. I don’t think they would have ever done anything with the product had MadCap gotten in their faces.
That market was given up for dead. It wasn’t like Adobe went and said, “Hey, we’ve now got Macromedia’s software through acquisition, so let’s put together cool items that give the help users more bang for their buck!” They are adding PDF functionality which is low cost. I mean, ELEMENTS?!? Good grief, at least bundle in Acrobat and migrate over the printed doc collaboration.
No XML?!?
No CLI (I know, it was a hard thing to do, and they’re probably never going to be able to pull it off)
And let’s talk about FrameMaker (FM). How on earth was the business decision made to launch without at least meeting the market standard?
Unfortunately it’s not RH it’s now Flare setting FM market standard for interfacing with FM.
Bottom line: Yes, Adobe is interested in staying in the game. They weren’t like that right from day one when they took over Macromedia. They don’t have RoboHelp on the front lines of the developers. They will swing that cat around their head until they get dizzy, but not put the money into the product development that it needs.
Why? Because nobody will understand that code and it would cost too much cash to get the pissed off (more like pissed on) developers that all got canned by Macromedia.
So I love RoboHelp – I still use X5. emotionally I love the product. But business is another term. What’s up with the server thing anyway? ‘Not yet available?’
Bottom line: There is no compelling reason for me to upgrade to a product which is not the CORE focus of the company manufacturing it.
And your post still hasn’t given me one.
Bohica – Bend Over, Here It Comes Again
I just can’t leave this alone.
Rick, you’re misinformed about .hlp working with Vista:
http://support.microsoft.com/kb/917607/EN-US/
Straight from Microsoft themselves.
Wupps, that was directed towards the monkey – sorry Rick!
But – my question with .chm’s is about the security issues they have executing over networks. I guess WebHelp will be the solution for that. However cross-browser functionality isn’t the best with RH – at least not market leading.
Here’s how I see deployment of RH based content for WebHelp and Flare based content for webhelp working:
1) RoboHelp doesn’t yet have ranked search results
2) RoboHelp doesn’t work well with others. If I used Dreamweaver or Contribute (Adobe products) to edit my code, RH6 will kill that code. That developer-based GUI you mentioned actually does the opposite of what RoboHelp does – not only does it NOT hose your code should you go in and modify your RH output, it actually helps you be a better author (well, sort of) by not letting you get away with crummy coding should you choose to go the HTML coding route.
3) .NET support? I don’t use it, but I think there are reasons that Microsoft is not so cozy with Adobe, as in they’re the two biggest kids on the block.
4) Which leads me to my next issue – That actually means that the end user loses, because word import / export capability will be limited, and other MSFT products will not be supported as they could have before the mergers with eHelp.
Hello Bohica
You’re not honestly stating that Adobe is putting the same amount of development work into RoboHelp as they have into their first tier products, are you?
Personally, I have no clue how much development work went into the update. But I will say, that as a long time and very devoted RoboHelp user, ANY activity after the silly Macromedia blunder is welcome. But that’s just my view.
If they were they would have looked at how to appease the community by putting out some free updates that are necessary to continue with browser updates, Firefox capability, etc. right? Dropping a couple free updates to an existing base – this was what, like a $36 million market that RoboHelp was top dog in three years ago.
Hmmm, that one is a tough call from a purely business perspective. You have a product that has a definite market that you paid good money for. You really can’t just immediately start giving it away. I’m not sure what you mean by Firefox capability. The stuff I do with it seems to work fine in Firefox as well as IE7. Then again, maybe it’s just me. With your bit about RoboHelp being top dog in the market, I have no idea where it stands today. But I’m positive from everything I’ve seen since the Macromedia debacle that many users immediately began running screaming with their hair on fire and jumping ship as if the product were going to immediately stop working the second Macromedia handed the developers their final paychecks and sent them along their merry way. There were many naysayers that said it would immediately stop working. It didn’t. Then they said it surely would break when IE7 came out. It didn’t. Then they said it surely would break when Vista comes out. That one remains to be seen. I would be remiss if I did not point out that Microsoft themselves have broken .CHM format here and there with assorted rounds of the Vista beta. I’ve been around long enough to know that RoboHelp will quite possibly absorb the blame if something like this remains. It may well surface that some issue is left surrounding using what Microsoft is recommending users use. .CHM format. And if that happens, many folks will immediately begin pointing the fingers at RoboHelp and chanting SEE! I told you it wasn’t going to work!
Instead there are virtually no top changes that cost money. I don’t think they would have ever done anything with the product had MadCap gotten in their faces.
This one is confusing to me. I know everything is submective, but ANY development of a software product costs money. And why would MadCap “get in their faces”? They are a competitor. They claim to pull RoboHelp files in seamlessly. What could they possibly have to gain by doing such? To me, the brighter move would be to remain quiet. So I respectfully see it a different way. I see it as Adobe listening to their customers and putting effort into what the customers wanted to see. And a large part of that was evidence of some form of committment that they intended to keep RoboHelp a viable product.
That market was given up for dead. It wasn’t like Adobe went and said, “Hey, we’ve now got Macromedia’s software through acquisition, so let’s put together cool items that give the help users more bang for their buck!”
Again, all subjective, but I think that’s exactly what they have done. Given the fact that Macromedia was as large as it was, it honestly surprised me they did what they did with the product. Not a smart business move by ANY stretch of the imagination. Adobe is a huge company. I’m sure they didn’t get that way by happenstance. It takes business savvy and strategic planning to accomplish that.
They are adding PDF functionality which is low cost. I mean, ELEMENTS?!? Good grief, at least bundle in Acrobat and migrate over the printed doc collaboration.
Yes, Elements may not be robust, but one has to consider how many users will actually use the full functionality Acrobat offers? It’s wait and see. I think Elements will do a superior job than RoboPDF. Additionally, if the user has Acrobat 6 or 7 installed, RoboHelp uses it instead of Elements.
No XML?!?
Personally, I’m not a XML person. From what I see at this stage of the game I struggle to see what all the XML hype is all about. But I would point out that the foundation is XML based. I’m talking RoboHelp project files here. Additionally, X5 introduced the ability to Import and Export XML. I distinctly remember Mike Hamilton (the Flare guy) being very excited about it at the time. So I’m not really sure what you are looking for here other than to try and bolster FUD.
No CLI (I know, it was a hard thing to do, and they’re probably never going to be able to pull it off)
Ummm, have you LOOKED at 6? Well, I suppose I should say I’m interpreting “CLI” as meaning Command Line Interface. And if you re-read what I posted, the Adobe folks managed to accomplish adding a CLI right out of the gate when the former crew said they tried for 3 versions and it was just too difficult to do.
And let’s talk about FrameMaker (FM). How on earth was the business decision made to launch without at least meeting the market standard?
Again, isn’t FrameMaker a different HAT? The point I’m trying to make is WHY would someone put effort into reinventing the wheel with working directly with the files of a different product? just so one could use the RoboHelp HTML interface to manipulate content that the other product does? Yeah, it would make total sense if they were trying to phase out FrameMaker. But why reinvent the wheel if you sell the other product. If you like FrameMaker, don’t use RoboHelp, use FrameMaker. Admittedly I’ve never used it so maybe I’m missing something here. So even though you are saying it’s the “market standard” (which seems odd, since I’ve seen way more job advertisements listing RoboHelp as a desired experience set than I’ve ever seen FrameMaker) I’ve gotten along quite happily with only RoboHelp for all the years I’ve used it.
Unfortunately it’s not RH it’s now Flare setting FM market standard for interfacing with FM.
Can’t speak to that. But as FrameMaker is also an Adobe product, I’m sure they are monitoring the situation.
Bottom line: Yes, Adobe is interested in staying in the game.
I think that bodes well for those of us that like using the RoboHelp product.
They weren’t like that right from day one when they took over Macromedia.
The appearance may have been that way. But keep in mind that the company is HUGE. It wasn’t simply an acquisition that involved the single RoboHelp line of products. They got a plethora of products. Dreamweaver, Flash, Captivate and a raft of others. Exactly how to proceed from there takes time and sorting out. I personally see it as very wise not to immediately jump in and say, let’s kill this product off. Let’s put out a release with that one. The fact they are proceeding carefully is a good thing in my eyes.
I’d also like to add that I’ve never been a “Blind Adobe Cheerleader”. (I was accused of the same when the company was eHelp) So I have no pre-existing alliances that are shading my views. All my judgements are based on what I’m seeing of how they are responding.
They don’t have RoboHelp on the front lines of the developers. They will swing that cat around their head until they get dizzy, but not put the money into the product development that it needs.
I’m not sure how you can make that claim. The only folks that really know that for sure (unless you are an Adobe employee on the front lines, in which case I would question your sanity for making the claims you are, as they are rather negative toward the situation and product) are Adobe themselves. Everything else is just observation and conjecture.
Why? Because nobody will understand that code and it would cost too much cash to get the pissed off (more like pissed on) developers that all got canned by Macromedia.
Ummm, if they are all off developing their own product (Flare) why would they want to return? I wish them the best with Flare. I personally feel that competition is a good thing.
So I love RoboHelp – I still use X5. emotionally I love the product. But business is another term. What’s up with the server thing anyway? ‘Not yet available?’
You can say I’m just putting my head in the sand here, but again, my view is that it’s simply taking time to put development effort in.
Bottom line: There is no compelling reason for me to upgrade to a product which is not the CORE focus of the company manufacturing it.
Hmmm, that’s fine. I’m not trying to convince anyone to upgrade. I am simply seeing what I am inferring as misinformation transmitted via a blog that others read and trying to keep the record straight. At least as I understand it. However, I am human and I may be misinformed about a point here and there.
And your post still hasn’t given me one.
See above. That isn’t the intent of my post.
I’m really having a chuckle at all the hubub surrounding this. It’s almost as if there is as much wailing and gnashing of teeth as I saw when the RoboHelp empire began crumbling.
Sincerely… Rick
Rick – Thanks for your insight. I really appreciate the time it must have taken for you to write that.
Rather than respond here in the comments section, I’m going to use your points as inspiration for a new article on the main page. Check there for more on this ‘Flare vs. RH’ discussion.
Hi again Bohica
Cool, I see you were directing the Vista 16 bit issue at the monkey. No biggie.
*** But – my question with .chm’s is about the security issues they have executing over networks. I guess WebHelp will be the solution for that. However cross-browser functionality isn’t the best with RH – at least not market leading.
Fair enough. I completely agree that RoboHelp can be improved substantially in this area. Hopefully we will see more work there in the next version. I think the whole .CHM security thing is in Microsoft’s side of the court. There isn’t much RoboHelp could do to influence changes that break even Microsoft’s own .CHM files if one places them on a network.
*** Here’s how I see deployment of RH based content for WebHelp and Flare based content for webhelp working:
1) RoboHelp doesn’t yet have ranked search results
True, and until users tell Adobe about it via the feedback mechanism ( http://www.Adobe.com/cfusion/mmform/index.cfm?name=wishform&product=38
) It’s probably not likely to be fixed. Keep in mind that the development staff is new. We had to inform them that those of us bearing the Adobe Community Expert logo might just have half a clue what we are doing with the product. They simply didn’t know us. Likewise, they may simply be unaware of the browser issues. Additionally, that’s really a tough call, as in my mind, browsers are the epitome of a moving target.
*** 2) RoboHelp doesn’t work well with others. If I used Dreamweaver or Contribute (Adobe products) to edit my code, RH6 will kill that code.
As far as I know, RoboHelp will leave your code alone as long as you don’t open topics using its own WYSIWYG editor. Then again, I don’t work in this manner. I’m quite accustomed to the WYSIWYG editor and all its little quirks.
*** That developer-based GUI you mentioned actually does the opposite of what RoboHelp does – not only does it NOT hose your code should you go in and modify your RH output, it actually helps you be a better author (well, sort of) by not letting you get away with crummy coding should you choose to go the HTML coding route.
I’m assuming you are referring to Flare here. As one of the original beta testers, I can attest that the interface made me struggle. A LOT. Once the beta concluded and I was not offered a complimentary copy for all the time spent testing it and providing feedback (which had always been the case to this point with the same folks when they worked for eHelp) I decided to back away from it. I was certainly not spending what they were asking just so I could assist their user base as I had with RoboHelp. Had they offered up a copy, the situation would have likely been quite different. But that’s simply life. You make choices and move on. I say this to say that I’ve not seen it since, so it may not be a fair impression, given they are into version 2 now. Maybe it changed and is easier. But I’m doubtful.
*** 3) .NET support? I don’t use it, but I think there are reasons that Microsoft is not so cozy with Adobe, as in they’re the two biggest kids on the block.
Again, I’m at a total loss here. I’ve never quite gotten my mind wrapped around the whole .NET thing from a general standpoint. Then again, I’m not a developer. So maybe I’m not supposed to. But I do know RoboHelp has had a .NET version for a long while. I also recall Mike Hamilton (the Flare guy) saying that unless you had a requirement for some very specific features of .NET, that buying that version was essentially a waste of money and WebHelp would work quite happily.
*** 4) Which leads me to my next issue – That actually means that the end user loses, because word import / export capability will be limited, and other MSFT products will not be supported as they could have before the mergers with eHelp.
Well, I do suppose that in any merger or acquisition somebody loses. From the redundant employees that lose out to customers that cry when certain functionality has been lost. As far as Word Import/Export, 6 did make some improvements. For example, they made certain changes to the Import bit so Bulleted and Numbered lists come in as true lists and not a kludge. They did something with importing Tables. But I’m not sure what. I performed a test with the same document using X5 and 6. Tables looked the same to me. Then again, I tend to avoid mixing Word and RoboHelp if I can at all do it. Yeah, I know it’s odd, given the fact that RoboHelp began life initially as a simple Word add in that allowed one to produce .HLP files. But so it is.
Again, for those of you interested in continuing with RoboHelp, your feedback is crucial. Adobe simply cannot fix what they don’t realize is broken. And my only hope (or request) is for others to treat the product as they would when encountering people where the religious beliefs aren’t aligned with yours. The fact is, there is no “one size fits all” HAT that will be the end all and be all. If Flare speaks to you and you like using it, then use it! Certainly isn’t in my interest to try and convert you. I’d be silly to try. Same with AuthorIt or any of the other products out there.
Personally, RoboHelp is like a really comfortable outfit. I’m comfortable, productive and believe it or not actually enjoy using it. Is it perfect? LOL! It’s my belief that the perfect software product is a mythical creature. All are flawed to some extent and will leave you wishing for more. If they didn’t, there would be no need for new versions and development cycles.
From a purely personal standpoint, I’m really bothered by all the competitors that have advertisements up stating “We now import RoboHelp content!”. As if the product were dead with no future. It’s similar to all the ads I see on TV and the radio when a major election occurs. Candidate A waffled on Issue X. Do you really want a waffler? Vote for Canditate B or you will be sorry you didn’t! My preferred approach is to simply list the strengths and weaknesses of each product and let the user decide. Now I know they have a product to sell, so this isn’t likely, but it’s a bit like Sharks or Alligators or Crocodiles just waiting for a meal. Not that I’m saying the others are bad by making that comparison. Simply that this is the perception.
Sincerely… Rick
Wow. Talk about comments!
Now where to start…
I tried to install the RoboHelp beta on Vista (to see if it would work), but the beta versions have all expired. I’m willing to go out on a limb and say that it will work (so far, everything else that we’ve installed has).
I forecast several years ago that all vendors would add RoboHelp import functionality. At that time, Macromedia had purchased RoboHelp…and nothing was being done. I’d look at it more like a compliment…after all, RH was the “market leader” (their marketing department said so
and then folks started using that as a reason to purchase it), and if no future enhancements are being made to the market leader, other vendors are going to step up. Besides, it was necessary to create special importers, because the RHH code was non-standard and didn’t import nicely otherwise.
I believe that Doc-To-Help lets you use other HTML editors. I don’t remember which other tools do…I’d have to check.
Frame is not a HAT. It’s a word processor used to create long print documents. WWP and Mif2Go are considered HATs, because users can produce online Help output based on Frame output.
I don’t remember anyone stating that RoboHelp was going to stop working after being purchased by Macromedia. In fact, I remember the opposite…the lists were full of entries on how no one had to hurry to replace RoboHelp because it wasn’t going to stop working (just like ForeHelp was still viable for some folks, even though development had stopped and ForeFront had gone out of business years before).
It will be interesting to see where Adobe goes from here with RoboHelp. Macromedia had done a lot of work on implementing W3C standards, and I really figured that they would never let RoboHelp go out with a non-standards-compliant editor. However, Adobe doesn’t have the same reputation, and as much as I’d like to see RoboHelp use DreamWeaver, I’m not sure it will happen.
But the output from RoboHelp is, to say the least, non-compliant. This matters to those who care about W3C standards (not so much to others). I look at it this way: I care about the standards, I code to those standards, and I create websites that use those standards. This doesn’t make me a better person than the person who ignores the standards. But it does mean that I tend to use tools that produce the type of output I want.
Rick, great discussion! I have to take some time to read everything, but I really appreciate your providing a fair and balanced viewpoint.
My stipulation is that there is still nothing compelling for X5 users to spend the money to upgrade to RH6 – the aftermarket continues to have low cost purchasing – Ebay link:
http://search.ebay.com/search/search.dll?from=R40&satitle=robohelp+x5
as of today there was a copy with ten bidders at $35. I would expect that to top out around $200 or so. Most ‘new in box’ versions are selling for $500.
That’s if you stick with the RoboHelp standard. MadCap and other vendors are really ’sticking it to the Man’ with their competitive pricing and updated features. I found Char James-Tanney has a link on her website that is dedicated to Help Author Tool competitive feature analysis – http://hat-matrix.com/
I noticed that monkey started a new string – should we continue here or answer his points over there? http://monkeypi.net/?p=141
Hi Rick!
I think nobody comes in ahead of you when it is about RoboHelp. Nevertheless, with RH6 coming out now I can really just laugh about it. This release is way too little and way too late. Macrobe abandoned every single RH user by firing the development and support team, stopping development for years, and making me believe that they do not want me as a customer every time I contacted Macrobe for any reason.
Sure, RH6 does produce some fine help, but the way it does is with technology from the last decade. I personally do not like XML either as it is humanly unreadable, but many machines read it easily and that makes exchanging information much easier. Besides that, while the content in Flare is handled as XML internally, the files are currently in XHTML and there are quite a few very nice editors out there. And that puts Flare into the position to easily transition to XML with XSLT, which currently IS where things are going. Kadov tags go nowhere as they are proprietary and proprietary is generally bad.
I used to love RH with a passion, but since Macrobe told me multiple times to go away, get a life, and stop bothering them with support requests (for which to do I paid as long as they offered service contracts) I found myself stranded in the HAT desert. RH X5 has quite a few bugs and several of them made my work more complicated and nowhere was anyone around to help. The forums are great, but posters cannot change the source code. So then MadCap came along and brought a soda truck with them. Shall I drink their stuff and thrive or stick with RH and die? I chose to drink the soda and after I got used to the taste it isn’t bad at all. By now, MadCap added a BBQ and tents and some fine support waiters that answer any question.
I know that the cooks at the grill are the same that cooked up RH and its kadov tags. Apparently, they learned from their mistakes, but weren’t given a chance to start over. Macrobe rather canned them and now hired some programmers in India to plug in some minor enhancements. Of course it took them years to dig through the code, because Macrobe rather dumped the experts than to continue development of an industry-leading product.
Rick, not to be meant personal, but I really wonder under which rock you live….or how much Macrobe pays you. Oh, they don’t? You should ask them for a few grants or whatever defense attorneys take these days.
Rick,
I cannot speak to the amount of credit that the Adobe development team in India deserves for the enhancements that they put into the RoboHelp 6 release. However, I do know that the RoboHelp team that was let go by Macromedia had put a lot of work into the next release of the product and were close to doing it, but they were laid off right before an X6 version of the product was to be released.
That RoboHelp development team and Mike Hamilton (who went on to work at Madcap Flare) that you complain about were working on the items you mention such as command line builds and enhanced conditional tag functionality for their X6 product.
The Adobe development team inherited all the work that Mike Hamilton’s team had been doing…
p.s. As for the Kadov tags, a lot of people see them just as unneccessary bloated code. Our translation department sees them as a big issue because their inconsistancy in the source files makes it so that we can not fully take advantage of text stored in translation memory. Bottom line, they cost us money.
I have used RH for the past decade. I was forced to Flare because I needed a double-byte solution. I have seen the RH 6 presentation and there is nothing in it that would have changed my decision. For me it appears as a marketing release – keep the market quiete until we decide what we really want to do …
I know there are probably a lot of downsides to the new RH version 6, but one huge improvement is that the new source control database is no longer based off of Access, it is now based on SQL 2005. That alone for me means a huge improvement in stability and speed for source control integration.
I’ve used RoboHelp for 7 years. I find it is a fast authoring tool wiht a lot of flexibility, lacking in other tools.
I tend to work in start up software companies, wher I am the sole source or at best have several contributing authors, usually hire on a contract basis.
I often have to produce several forms of help: JavaHelp, CHM Help, WenHelp etc. for the same product(s). Sometimes I need to add a quick knowledge base website for engineers to store source docs that is searchable, and occasionaly a customer wants a subset to embed into their own aplication incorporating our tools. No other authoring tool I’ve worked with in the past allows you to do this as efficiently as RoboHelp.
Content and presentation is king, and I agree with Rick, most end-users don’t care what’s under the hood. They’re looking for context and reference.
For those of you who actually have a dozen or so TWs and Editors in your midst, and have the luxury of collaboration meetings with content providers and fellow authors with months of planning and authoring time – I’m somewhat envious.
If you live in an environment like mine where content providers meet with you ad-hoc, editors are your engineeers and new releases come out every quarter because they drive revenue, then you need something that’s robust, quick and produces compatible cross-platform output. That’s why I like RoboHelp and am glad that Adobe has finally seen the light. Though my guess is that they likely saw that MadCap was making inroads in the industry, and that RoboHelp may still have some value. I’m no longer worried so much for RoboHelp, but I’m glad I don’t own any MadCap stock.
I actually had a chance to meet several key RoboHelp people just after Macromedia acquired them. Several were out on the road trying to prove their worth to Macromedia, I think. I think Macromedia intended to replace the RoboHelp product with its Flash tools, but they surprised everyone and sold to Adobe.
I beta tested Flare and have downloaded a trial version since then. I find it non-intuitive and hard to use, exactly the qualification required by some TWs – especially those who like hard to use tools for other content authoring. So those who think hard to use tools offer more TW job security, it’s probably a good tool to use.
I think that in the future Flare could get to be more robust and easy to use with a more coherent interface. Then it might be worth switching; but right now, I’m sticking with RoboHelp.
No tool will be for everyone. Neither is RoboHelp. Code monkeys hate the kadov tags. Purists hate the code bloat. I like the speed for content development and output options.
Cam wrote:
Content and presentation is king, and I agree with Rick, most end-users don’t care what’s under the hood. They’re looking for context and reference.
RamonS replies:
Well, that may be OK for someone who is on a three month contract at a startup and once the time is up walks away from there and to a different job.
If you are a permanent employee on an engineering team and are in charge of delivering and hosting the content as well as making sure that it works with any misbehaving Windope / IE version out there, then for sure you are interested in what is under the hood. I used RH and published to FlashHelp. It really looks and works great – but then came XPSP2 and all hell broke loose. IE from then on considered any dynamic content as evil and required a dozen steps to make it work. That the Flash people threw in their own security settings interface just made the list longer.
I want to be sure that the output the tool I use creates is standards compliant. I also want to be sure that it works with the most browsers as I typically do not have the time to test on all browser versions on all OS out there.
In regards to standards compliance is RH really “craptastic” (I love that word).
Cam wrote:
I think that in the future Flare could get to be more robust and easy to use with a more coherent interface. Then it might be worth switching; but right now, I’m sticking with RoboHelp.
RamonS replies:
Flare to get more robust? Maybe my PCs I use are special, but Flare rarely crashes, which I cannot say about RH. More coherent interface? I like to say that RH and Flare are par in regards to coherence. Flare uses some different terms and combined stuff that belongs together. The Flare GUI follows the “Microsoft Standard”, which is a form of coherence to how modern Windows applications look like. RH looks like applications that are a decade old, mainly because the most part of RH is a decade old. RH6 is like buying a “pre-owned” (used) vehicle for the price of a new one and under the pretense of it to be the latest technology out there.
Gorbatchov once said “Those who come too late get punished through life!” Same applies to Macrobe and RH6. Too little too late after all the years of being in my face of not wanting me as a customer.
Switch to something that uses halfways current technology, generates standards compliant output, and is not hampered by zillion of lines of legacy code that went through the hands of who knows how many hired and fired developers. Flare is a bit more challenging in use, but since I use Flare I am finally forced to understand what is going on. All the great content doesn’t do a thing when delivering it fails.
Rick Stone must be sleeping with someone at Adobe, or he’s simply a corporate sucker period.
ADOBE always do that. They take a GOOD product and make it theirs. Once theirs it always craps out.
I’m still thinking of Harvard Graphics, MicroGrafx Designer and many more have beed destroyed by the big corporate a..holes.
The only product ADOBE has that is usefull is Photoshop and Acrobat. The rest is only marketing software to make more money. Have you ever tried any of their other softwares? Crappy like hell! Especially the website designer, can’t remember the name now….anyway, it’s the crappiest website designer I’ve seen in years. I prefer coding in NOTEPAD than using their ugly interface!
Anyway, only my 2 cents, and that’s what their worth.
(I’m not Rick Stone, I don’t think that god is under me!)
WhiteWica,
I dunno… In addition to Photoshop and Acrobat, I think InDesign is an awesome tool. Illustrator changed the entire marketing industry, especially when Macromedia stopped updating Freehand. FrameMaker is the most popular and stable document maker out there, for good reason. Premiere is up there with Final Cut Pro for pro editing.
I know they’ve had a few duds (LiveMotion still gives me the shudders), but more often than not they produce great products. Their recent behavior with RH aside, I’ve always been an Adobe fan.
Hi WhiteWica (ummmm, why not call yourself White Wicca? Just wondering)
I guess I’m guilty as charged. (Waving hand wildly) Corporate sucker here. If, as you claim:
“ADOBE always do that. They take a GOOD product and make it theirs. Once theirs it always craps out.”
I would seriously have to question how in the world they have managed to remain in business and make HUGE acquisitions such as Macromedia. But that’s just me.
You also said:
(I’m not Rick Stone, I don’t think that god is under me!)
It may surprise you to hear that I totally believe I AM God. But then again, I also believe that You and MonkeyPi and all the other billions of people in this realm are God. We are all simply God expressing itself in billions of different ways. God is in us, as us and through us. Within and without. No angry old man in the sky in serious need of mood stablizers, just an ever loving presence permeating the universe, seeking to express in many ways.
Then again, I’m not sure where you managed to infer my thoughts when it comes to religious beliefs based on my replies here.
Namasté… Rick
Wow, Rick. God, eh? Whoa. This blog really is getting popular. I should start cleaning up the place.
“In the beginning… Stone said, Let there be Kadov! And it was good.”
Thanks as always for chiming in, Rick.
monkey,
about to update robohelp then read your blog!!!!!!!!!!!!!!!!! which authoring tool do you recommend authorit webworks doc-to-help????????????
Hi Dick,
Check out http://www.writersua.com/articles/robohelp_6/ for a review of the specific components.
The only change *I* would say that article needs is a look at the HTML Help section – more users use that than it states use HTML Help.
See http://www.writersua.com/articles/robohelp_6/#install specifically for that comment, but that’s more of an opinion of the article writer because the same site has a Skills and Technology survey that has over half of the polled users stating that HTML Help is very important to support. See http://www.writersua.com/surveys/skillstech05/skillstech_techs.htm for the comparision I’m referring to.
Compare them to the rest of the tools. I have presented a solution to my clients of a better workflow with Word docs used as source documents with Flare – see their features on the MadCap website – but it really depends on the project and your contributing authors. My greatest pain is herding the cats – getting all the subject matter into the project from multiple sources. If you face the same challenge, that QuickSynch (or whatever it’s called) feature for Flare may help you too.
Some legacy projects with RoboHelp are best kept with RoboHelp – but the new version is not compelling enough for most people to put $1000 down on when eBay has a resell market for X5 around $40 – $250.
What are you working on specifically? That goes into the decision process also.
I gave up on RoboHelp years ago! I use HelpBreeze, which is a much less complex tool and supports standard HTML Help (without all the proprietary stuff in RoboHelp) and exports nicely to Word format. It simple, reliable and it works without the constant hassle of dealing with Robohelp. Yes, sticking to standard HTML help is a tradeoff – but I have no worries about future support for RoboHelp-specific stuff, and I have clean HTML source and project files that will compile anywhere.
In response to DickV, I would wholeheartedly recommend Help & Manual (http://www.ec-software.com) as, overall, the best Help Authoring Tool (HAT) currently on the market. I’d used RoboHelp for several years, but when I needed to buy a new HAT for a new company , I didn’t want to put my money in a product that, at the time, appeared to have no future. I was a beta tester for Flare (from cycle 2 of beta testing), and was very hopeful, but ultimately, I couldn’t get it to run on my system (which was top-notch at the time). I found AuthorIT’s lack of context tags and embedded topics a deal killer. Regarding DocToHelp et al, I found authoring in a word processor to ultimately publish on-line oxymoronic.
As a HAT, Help & Manual has been wonderful. It is powerful and feature rich, produces great, customizable output in several formats, and has a shallow learning curve. I liked RH5, but H&M is better. Apart from performance, I thought Flare looked good too. However, I think H&M has a better feature set, and it is definitely easier to use. If H&M has limitations relative to other HATs, they would have to do with not having AuthorIT’s level of support for Enterprise-wide collaboration. (BTW, I am just an enthusiastic user of Help & Manual, not an ecsoftware employee!)
Any idea how to acquire a product key for the Robohelp demo? My current Robo x5 key won’t activate it, there’s nothing on the Adobe site to indicate, and their support line outwaited me.
The way the activation engine works you’ll have to contact eHelp (wupps, Adobe) Sorry. There’s no hack or anything else.
The other thing is… my copy of X5 actually activates EVERY time I boot it up. Annoying, but it still works. I heard that the server went down last year for some time, not sure about how all that works. So if you DO hack it, there’s no guarantee it will still work.
I feel bad that you’re not getting the support you need from Adobe. When I was at eHelp all it was to get it done was about 30 seconds with Customer Support, or an email with a response level of usually three to five business hours.
Hi jho
When you visited the page where you download the RoboHelp 6 evaluation, if you look near the top of the page at the end of the first paragraph in bold print right above where you select the version to download, it lists the serial number you use to activate the trial.
In case you don’t wish to visit the page again, here is a copy/paste of the paragraph:
Thank you for your interest in Adobe RoboHelp 6. Your trial period is 30 days from the time you install the product. To complete the trial download process, please use this trial serial number: 1316-1030-9508-9122-9700-7932.
Cheers… Rick
Thanks Rick. That did it.
Just for the record, I like the overall usability of Robohelp as a HAT, but the people who accuse its haters of being tool-obsessed (mind-out-of-gutter-NOW!) need to think beyond mere help systems and into long-term information management. Flare is few baby steps further along in this respect due to its respectable degree of XML adoption, but really, data composition, data storage, data management, and data publishing are *very* different things which cannot be well served by any one HAT. The bigger the organization, the more obvious this becomes.
Signed,
A CMS-aphile temporarily adrift in a Robo-ocean.
I read this conversation last night, and it occured to me afterward that Microsoft’s decision to drop WinHelp support in Vista has major implications for RoboHelp, and maybe for other tools as well.
RoboHelp 6, in addition to RoboHelp HTML, includes RoboHelp for Word, which exists mainly for WinHelp support. When Adobe releases an update that supports Word 2007 on Vista, it will be interesting to see how they handle the issue.
I have a new system with Office 2007 on Vista, and I’m waiting for that update.
As I have read reviews for RoboHelp I found that most users are not terribly impressed with RH 6.
As a potential customer of RH would you recommend buying it or going with a different hat such as Flare, Doc to Help or Authore IT?
Jesse,
Any recommendation of which tool to use would depend on your needs & situation. A good place to start is the HAT-matrix:
http://hat-matrix.com/
As for RH 6, keep in mind that most folks’ disappointment comes largely from the software’s stagnation over the past few years. In other words, while I wouldn’t recommend upgrading from version X5 to version 6.0, that doesn’t mean that RH should be ignored as a possible HAT alternative for a new user. All tools have strengths and weaknesses. It just depends on your situation.
It’s my feeling that putting out this half-a’d release is just Adobe’s way of saying that it has not abandoned the product completely. Which is good news as far as I am concerned. I don’t need a huge leap in functionality; small improvements are welcome. I like Robohelp a lot and did from the beginning (about 10 years ago). It provides a nice clean interface to a database of topics that I can do just about anything with (help, manuals, variable text, bug fixes, etc.).
Are there any security steps we can take with RoboHelp X5 or with 6 if we upgrade? Some of our info is being googled by people other than our agents. For example, commissions info that is supposed to be available only to our agents.
Apologies for chiming in much too late in this rant and ramble.
It’s always amazing to discover what otherwise ordinary folks can infer about corporate motives, resources, decisions.
Kudos to Rick Stone for taking on complex issues at some length and detail and maintaining a reasonably balanced place in the process; to Bohica for critiquing, to Char for corrections, to the monkey for hosting.
Two critical items that have slipped under the radar in all this back-and-forth about what Adobe did or failed to do in their release of RH 6 release:
1) RoboHelp’s code base, when Adobe got the tool, included over 2 million lines of undocumented code. Mike Hamilton, former eHelp project mgr and now Flare same, once described the code base as “a nest of string and busted twigs.” He mentioned that the original code for several key .DLLs had long ago been lost; that to add a feature or change a function produced outbursts of bugs, and that to put those back in place took more time than the change itself.
Because MM fired the RH development staff, Adobe’s development crew had to start from zero. Their achievement in publishing RH 6 in Q1 2007 needs to be understood in that context.
2) In that release–RH 6 in Q1 2007–Adobe did exactly what they said they would do. In the marbled history of RoboHelp, contrast that corporate behavior with anything else by Macromedia or eHelp or Blue Sky Software.
I’ll agree with some of the major complaints about features and functions still part of RH that we’d like to see gone: kadov tags and bloated code, non-compliant WebHelp output and inconsistent dialog boxes; and more.
But two cautions: don’t mistake Adobe and its corporate culture for what we came to know and love from Macromedia and eHelp. They area an entirely different animal.
And: listen to STC announcements about RH 7. Now that Adobe developers have the code base under control, I think you’ll begin to see the kinds of changes that result from commitment, and from having listened to users.
I’ve worked with RH since rev 1–use, teach, consult. Over the years I built a lengthy list of specific changes the tool needed. The list moved through Blue Sky Software, thru eHelp (all those years), thru Macromedia.
The development team at Adobe are the first to contact me to discuss the issues, and to rank order them.
The process of tool choice for a project or a client includes a number of critical assessments: audience(s), users, workflow, dimensions, outputs, maintenance, more.
But any reasonable process answer to Jesse’s query (which tool?) has got to include Adobe RoboHelp for consideration. It’s here, it’s real, and it’s got the faith and credit of Adobe behind it.
Normally I stay clear of the blogs but since I was called out by name I will jump in here.
It amazes me how many people seem to want to re-write history, especially those who weren’t there in San Diego to live it when it happened.
In David’s comments above I take some issue, not with the sincerity of what he writes but with the accuracy of its basis. Having not been part of the team back in 2004 he may not be aware that much of what he writes is factually incorrect.
First to the comment:
“Because MM fired the RH development staff, Adobe’s development crew had to start from zero. Their achievement in publishing RH 6 in Q1 2007 needs to be understood in that context.”
I’m hearing this statement over and over lately as if it is some Adobe talking point that has been sent out in a memo or something. Has everyone forgotten that RoboHelp X6 was scheduled for release in February of 2005? This isn’t secret, it was widely shared with the public. Much of its capability was even demoed for the public and the development was at a level that the RoboHelp X6 online help system had already been placed online on an eHelp/Macromedia public server. In fact, that same RH X6 documentation remained up for the world to see into 2007 until just a couple of months ago when Adobe took it down. Not to worry though, I managed to get some screen shots before it went away and one can be seen here http://www.madcapsoftware.com/robofacts/robohelpX6features.aspx .
Based on the above information the new crew in India obviously didn’t start from scratch, but rather inherited all of the RoboHelp X6 code written by the original San Diego RoboHelp team before they were kicked to the curb by Macromedia. In fact, it amazes me how combining both the features from the Adobe RoboHelp 6 release and the RoboHelp Next announcements at the STC show you come up with an almost identical list to the features that were coded back in 2004 by the original San Diego team as documented in the screen capture at the link above. Is the Adobe team simply using the old code my team wrote in 2004 and trying to take credit for it? I don’t know, but the similarity between the two feature lists is remarkable. Now, it is absolutely Adobe’s right to use any code my team wrote back in 2004, after all they purchased all of the old RoboHelp assets from Macromedia. I just have to scratch my head about all of the fanfare and “look what we did with the RoboHelp code that the original team couldn’t” announcements. Obviously the original team could, as I was already doing RoboHelp X6 demos before Macromedia killed the development program.
Then to his point 2:
“In that release–RH 6 in Q1 2007–Adobe did exactly what they said they would do. In the marbled history of RoboHelp, contrast that corporate behavior with anything else by Macromedia or eHelp or Blue Sky Software.”
Adobe did exactly what they said they would do? Contrast that with anything else done by eHelp? OK, what did Adobe do? They added a couple of minor features and called it a full release (features that look mighty familiar to those we wrote in 2004). Let’s contrast that with the types of things my old RoboHelp team did. We pioneered the concept of browser-based help before most people were even coming to grips with the new .chm format. We also were able to innovate around the WinHelp format inventing the WinHelp 2000 extension that gave new life to the older format. It was the original RoboHelp team that brought the first turn-key documentation analytics server to the market at an affordable price point. This was one of the hallmarks of the RoboHelp team, we didn’t wait around and copy others, we invented, we innovated, we stretched the technology available to better support the industry. Now at MadCap Software we are doing the same thing again. We have many capabilities in Flare that are so unique that they have patent filings. We have developed and shipped a brand new help format for .NET applications that is far more modern and secure than anything else on the market. We have pioneered the concept of taking single-sourcing across media types allowing authors to use variables not only in their documentation text, but also in their screen caption callouts and in the text bubbles in their tutorials and demos, all of which can be controlled during the output generation process. The list goes on. What in RoboHelp 6 was actually innovative? What did Adobe announce at STC for RoboHelp Next that isn’t already in MadCap Flare? Adobe isn’t innovating, they are copying and following. MadCap Software takes that as a compliment as they obviously recognize our expertise in the industry.
Also:
“But two cautions: don’t mistake Adobe and its corporate culture for what we came to know and love from Macromedia and eHelp. They are an entirely different animal. “
I’m not so sure about that. Adobe is definitely different than the original RoboHelp team but they seem to be following in the footsteps of Macromedia. Just as Macromedia fired the entire RoboHelp management, development, and QA staff back in 2004/2005 I have just learned that early this month (June) Adobe fired the remainder of the old RoboHelp faces from the San Diego office that were in the technical support and customer care areas. Those few remaining names from the RoboHelp days, while they had nothing to do with development, were still a glimmer of hope for a lot of people. Now Adobe has made sure that they too are gone. How does firing the few remaining people with any legacy RoboHelp knowledge and shipping their jobs off to another country support the concept of Adobe being committed to RoboHelp and RoboHelp customers?
The adoption of MadCap Flare and our other products is nothing short of amazing, we have been recognized for awards and accolades, and we are the fastest growing tool in the market. This is good news for customers. Additional choice in the industry will force everyone to get better and stronger. However, it is very clear that Adobe is trying its best to simply play catch-up with MadCap Software and we wish them the best of luck. As mentioned above, we are the original developers of what once was the leading tool, and just because someone buys Picasso’s paints and brushes at an auction does not mean that they can now magically create the same masterpieces as Picasso, that requires the skill of the master. Adobe may have bought the RoboHelp paints and brushes, but they are certainly no master in the Help authoring industry.
Wow…
Last week I’d heard of the same issue about the Tech Support / Customer Care staffers being let go. Guess this post confirms it.
So things are going as I expected it would. Unfortunately this strategy of ‘Raise a finger, see which way the wind is blowing, and try to move with the crowd’ doesn’t help users when they can’t get jobs done.
Very good about the patent submissions. IP for the help authoring tool will be difficult to beat if you can’t copy it.
Good luck Adobe with your innovation struggle.
Vendors of software know that most technical communicators have no idea how to shop for tools. They know that we ask the wrong first question (”What’s the best authoring tool?”) and that we often rely on listserv and blog posts to guide our buying decisions (”Hey, that MonkeyPi guy likes it so we ought to throw out our old tools and buy that new thing he says is way cool.”)
Smart software vendors capitalize on this. They customize their advertisements to address our lack of knowledge (”The RoboHelp replacement”) and they sprinkle in — for good measure — a spice packet of industry jargon and flavor-boosting keywords (XML, DITA, reuse). They can stretch the truth because they know we don’t understand the subtle, yet important differences between various software products (e.g. “XML is not the same as XHTML”). And, they also realize we don’t know much more about our own industry standards (”They say the new version doesn’t support DITA, but it does support topic-based authoring, so it will work just the same”).
They also bank on the fact that we are unlikely to follow the guidance of our best and brightest industry gurus (analyze existing content, identify needs, make changes in processes, develop content models, select tools that best match our needs – Rockley, Hackos, etc.) because it’s faster to skip those steps and hope things will work out fine. After all, we’ve skipped these steps for years and look how much better we do today than in the past.
While some software vendors are smart to target our weakness in the tools and technology arenas, they miss the mark when they create campaigns designed to sell “return on investment” to documentation managers who can’t/don’t/won’t/aren’t made to collect any metrics. How on earth can you make an accurate business case for changing tools (who cares which ones or who used to work at the companies that make them) if you don’t know what it costs to do business at your company today? How will you know which tool has the best chance of helping you speed up your processes, reduce expenses, and eliminate manual tasks that can be automated, if all you know about your own environment is how you feel about what you’re doing and what you think might make good improvements. It’s about time we introduced a little science (and math) to the field of technical communication.
Buying the right software for the right reasons can provide your organization with a strategic advantage. As such, software purchasing decisions ought to be done with a strategy in mind and based on real, actionable data about your environment, your authors, your customers, and your organizational needs and goals. And, the decisions should be metrics-based (quantifiable).
Features are nice, but they have little to do with the true cost of adopting software.
As a profession, we ought to seek ways to become smart software shoppers. Once tech docs managers adopt tools that can aid them in collecting metrics (”No, Excel is not a technical publications management metrics gathering tool”) we may be able to select products that actually provide us with both an excellent return on our investment and a long-term strategic advantage over the competition.
We at TheContentWrangler.com expect the issue of software tool selection — and metrics gathering — to become a popular topic over the coming years. We’re planning a special Management Summit at the upcoming Documentation and Training East 2007 Conference (October 16-20, 2007) that will provide managers with the skills needed to understand how to collect, maintain and utilize metrics to make smart business decisions. And, we’ll provide guidance on shopping for and selecting the right tools (content component management, web content, and XML authoring). Learn more: http://www.doctrain.com
Scott Abel
TheContentWrangler.com
Good grief. Picasso? Artists and brushes? More like a shotgun blast. Blam and blooey.
But with a purpose: Mike Hamilton’s “discussion” seems an excuse to wave the Madcap flag. Well and good. He’s supposed to.
But not by hacking my words and climbing on top of them, claiming my error.
This’ll be brief. Maybe get discussion back on track, about RoboHelp, and product features.
Three points to amend/correct:
1) Who did what for RH6.
2) What Adobe did and does.
3) Adobe contrasted with others.
1) Adobe developers started from scratch with RH, and they deserve credit for it.
No one–no one–disputes that eHelp announced and began development of many of the functions that emerged in RH6.
But: when Adobe acquired Macromedia, look what they didn’t get: they got no developer with any knowledge of the code in which development of those functions had begun. The “San Diego” team was gone. There was no institutional memory left.
What did they get? A collection of disparate code types and functions–12-years old, 2 million lines. Hamilton doesn’t dispute his own description of the code base: “a nest of string and busted twigs.”
No company–including Adobe–would or could release RH6 on unknown, untested code just as they got it from Macromedia. Imagine the marketing twist: “Hey! Get RoboHelp 6, as-is. Bugs? Not our problem. Talk to San Diego.” Before Adobe (or any other owner–Adobe’s not peculiar here) could release product, they had to some extent know to own it–tear it down, test to break it (what good testing aims to do), re-tune, and learn it. They did that, with a whole new development team.
2) Adobe has kept their corporate commitments.
They said they they would release RH6 in Q1/07, and they did–after a three year hiatus, on a code base that was not their creation. They never claimed they were building the new functions and enhanced older functions from nothing. After the roller coaster rides of the previous ownerships, this was a welcome, substantive change.
3) Adobe’s corporate culture sets it apart.
A tool is more than its functions. As developers and consultants, teachers and trainers we have to live with the companies that make the tools we use or recommend.
And here, Adobe stands out. They consistently honor relationships and commitments with people in and outside Adobe who are part of the larger community–customers and partners and more.
Not one of the other companies in this thread–Blue Sky, eHelp, Macromedia, Madcap–can make that claim. Not one. If anybody disputes this point, I’ll be happy to cite chapter and verse in private communications. It’s not pretty and it’s documented.
About that “firing” of the “old RoboHelp faces” in the San Diego office? Mike Hamilton makes it sound like a targeted crackdown. In fact, it was part of a larger rebuilding of Adobe’s entire product support function that involved much more than RoboHelp.
“It amazes me how many people seem to want to re-write history….” said someone in this thread, around Jun 7.
I’m not spouting–as Mike Hamilton suggests—talking points from Adobe. I’m not talking anybody’s points but mine. I develop and consult and teach this stuff. My clients depend on my independence to trust my work and my recommendations with them.
Picasso? The “skill of the master?” Good grief.
That’d be the level of skill needed to design and maintain the much-loved “kadov” tags, right?
David,
We’re about to go head to head on a couple issues here. This is about committment versus revenue streams. Step away from the Kool-aid and stand by…
In Brief:
a) I use both RoboHelp and Flare Help Authoring Tools. (my site, http://www.3nw.com has four RoboHelp published areas which predate blog usage) and I am in favor of innovation.
b) I am increasingly skeptical of Adobe’s commitment to providing quality upgrades and innovation.
c) I am frustrated about hearing about how great something is going to be from RoboHelp for almost nine months and then seeing something that should be a point release in the manner of quality.
d) … and personally I’m really not impressed with the argument of a vendor not having a fair shot. This is a FREE MARKET and the best tool with the best features gives content management departments / personnel the best way to quickly and efficiently take content from industry standards like MSFT Word and XML and plug them into a work process.
I like people at Adobe. I like and use plenty of Adobe software products like Captivate, Contribute, DreamWeaver, and Acrobat. I don’t have a beef with 95% of their market domination. However…
Response to David’s #1) It’s not an issue regarding Adobe’s starting from scratch. It’s a matter of releasing a point release and calling it a ‘full version’ simply based on the time elapsed between releases. I don’t care about the | in between | with MACR where everyone got let go… I cae about my client base which ask me about whether or not to upgrade and what benefits they will get.
Honest question: Why is updating to RH6 better than using Word 2007 and producing a product with Flare? Long term, what has Adobe shown me that demonstrates they are committed to the RoboHelp product.
Maybe you’ve heard the adage about producing breakfast: for eggs, it is required for the chicken to make a contribution but for bacon the pig is COMMITTED. Adobe is merely contributing to RoboHelp. MadCap’s core product is Flare. They are committed.
Response to David’s #2) So they accomplished this. And then they charged the users for it. See my point (d) above. It’s a free market. Hooray for Adobe. Big deal.
3) Honor relationships? By releasing a software version and claiming that it does things it doesn’t?
Here’s a cluetrain manifesto point for Adobe: Give me something competitive. Not just something that I expect. Not just the bare minimums to keep your product working with the main technology like Firefox and IE7. I want new, innovative features. Best bang for my buck.
Exceeding my expectations will make me a raving fan. Merely meeting your (Adobe’s) internal metrics will only bore me. Give me something you spent money on for free and I’ll be happy to believe you’re in it for the long run. Otherwise it’s just a software legacy management technique and I’m too savvy for that…
Sorry David, I am failing to see why I should spend my money for a new model when the old one (RH X5) works just about as well AND I’m not guaranteed that new new model is going to be providing me a better bang for my buck.
My baseline on this subject is wait-and-see; when or if Adobe releases two more versions of RoboHelp AND they have something innovative to offer I’ll be cheering.
Until then, steps like letting go of the final knowledge resources in the company just doesn’t build confidence. Can anyone see the glaring example of FrameMaker or is it just me?
Have you any idea how many technical writers are fed up with hearing about the history of robohelp and madcaps new world domination? We are all intelligent enough to make choices based on what is presented to us. Please move on madcap/monkeypi, stop bashing competitors products and enjoy a bit of healthy competition.
Sorry to have to comment on a meta-comment, but I disagree with anon. I’m finding the discussion interesting and helpful. Regarding Picasso et al, I think Mike H inadvertently raises a good point. RoboHelp 6 might be something of a letdown (see CharlesJet’s comment), but when we compare it to Flare, we are really comparing, RELATIVE TO OTHER PRODUCTS IN THE INDUSTRY, daVinci to Michelangelo. Compared to tools available as recently as 2000, both are terrific. However, I do not use either currently. After using RH5 extensively and being on board with Flare from beta cycle 2 to first release, I chose Help & Manual (ec-software.com). You can think of it as Raphael. It has been a wonderful tool, and both customer support and the dev team have been wonderfully, impressively responsive. I’ve pushed all three of these tools to the limit, and I don’t see how one can go wrong with any one of the three.
anon,
You insult my carefully thought through (albeit non-spell checked) response by stating that opinions shouldn’t be expressed.
“We are all intelligent enough to make choices based on what is presented to us”
This only works if the information presented to us is accurate. If it’s not, then once again I fall back on cluetrain to provide the answer:
Thesis 12: There are no secrets. The networked market knows more than companies do about their own products. And whether the news is good or bad, they tell everyone.
http://www.cluetrain.com/#manifesto
I would also agree with the other anonymous poster. Here’s why.
I have similar feelings come election time. I have learned to dread it and refuse to watch TV. By the time it’s voting time, I will almost vote for an unheard of candidate because I’m just so sick and tired of hearing all the “He did this and he’s bad” or “She did that and she really sucks”. I see Madcap’s approach as being eerily similar. I’m almost more inclined NOT to purchase a product if the company is on a constant mission to slam or undermine its competition. Let your product speak for itself. If it’s so much better, then it will sell itself. But if it takes slamming the other products in order to make yours seem better, it’s probably not as great as you are saying it is.
eHelp had a very agressive reputation for sales. And I remember that it often made many in the Tech Writing profession angry. Particularly when they would mail out claims that “Developers can produce effective help – Just by buying our product. You don’t even NEED an expensive Technical Writer!”. Mr. Hamilton is claiming that they (Madcap) know the help development business better than anyone out there. After all, they developed RoboHelp for so long. And while it’s true that just because one purchases the equipment that Picasso used, they don’t have the same skills and won’t produce the same work that Picasso did. But what if the new tool owners are every bit as savvy? Or, gasp, dare I even suggest, possibly MORE savvy?
Personally, even with all this “experience”, I would find it odd if the Madcap developers were able, totally on their own with no feedback from the true subject matter experts (the tool users) were able to deliver exactly what I wanted in a tool. I’m afraid I’d end up receiving a tool that only a developer could use effectively and didn’t do what I as a help author wanted it to do. This isn’t to say that Flare is a bad tool. Just that it takes much more involvement than developers in order to create a tool that does a good job. Incidentally, one page I follow from time to time lists a very interesting bit about Madcap making a HUGE blunder by announcing a new product dealing with translation (Lingo) while at the recent STC conference. ( http://www.scriptorium.com/palimpsest/ – It’s near the bottom of the page. Search for the word “blunder”) How odd is that? These guys that claim to have all this inside industry knowledge totally space off the fact a company bearing the same name as their shiny new product exists? I guess they may have been too busy coding to conduct a Google search before naming their new product.
Finally, I suspect a large part of Mr. Hamilton’s anger towards RoboHelp and its current owners is due to an expectation that after the layoffs and no development with RoboHelp, they fully expected to waltz in and have a wide open market to fill with a new tool to replace RoboHelp. But since Adobe has decided to put more development effort into RoboHelp, it could be impacting sales more than Madcap would ever publicly admit.
Hrmm.. My post didn’t get put up. My guess is it’s because of too many hyperlinks. I’ll try again…
Anonymous, I just finished quite a bit of research work regarding Intellectual Property (IP) and rights management in software for a game concept I’m collaborating on – http://msdance.3nw.com if you’re interested. So this issue comes on the heels of my recent IP research.
>>>Incidentally, one page I follow from time to time lists a very interesting bit about Madcap making a HUGE blunder by announcing a new product dealing with translation (Lingo) while at the recent STC conference.>>These guys that claim to have all this inside industry knowledge totally space off the fact a company bearing the same name as their shiny new product exists? I guess they may have been too busy coding to conduct a Google search before naming their new product.>>eHelp had a very agressive reputation for sales. And I remember that it often made many in the Tech Writing profession angry. >>Personally, even with all this “experience”, I would find it odd if the Madcap developers were able, totally on their own with no feedback from the true subject matter experts (the tool users) were able to deliver exactly what I wanted in a tool. I’m afraid I’d end up receiving a tool that only a developer could use effectively and didn’t do what I as a help author wanted it to do.
Hrmm.. My post didn’t get put up. My guess is it’s because of too many hyperlinks. I’ll try again…
Anonymous, I just finished quite a bit of research work regarding Intellectual Property (IP) and rights management in software for a game concept I’m collaborating on – http://msdance.3nw.com if you’re interested. So this issue comes on the heels of my recent IP research.
[anony sez:] Incidentally, one page I follow from time to time lists a very interesting bit about Madcap making a HUGE blunder by announcing a new product dealing with translation (Lingo) while at the recent STC conference.[end]
Not to be offensive, and just to clarify the referred ‘Blunder’ question you brought up about the appropriateness of the naming for Madcap’s Lingo product…
[anony sez:] These guys that claim to have all this inside industry knowledge totally space off the fact a company bearing the same name as their shiny new product exists? I guess they may have been too busy coding to conduct a Google search before naming their new product.[end]
After reviewing the offered blog link and the ‘blunder’ products found in the google search for ‘Lingo translation’ I found primarily four companies and checked each one. They are services companies, not software companies. They are not selling a software product that does the same thing as Lingo offers, therefore there is no conflict. So that sort of kills the ‘Ummmm, you’re in troubbblllleeeeee’ finger pointing.
The term ‘Lingo’ is in too common of usage. It’s not Xerox, or Kleenex, or as you used, Google (to define your search) and having Yahoo advertise ‘googling’ by using Yahoo. To think otherwise would be akin to restricting the use of ‘Language Translation’ with a copyright. If there’s other Lingo branded software doing the same purpose, I could be wrong. I couldn’t find it though.
So, no blunder found. At least not one enforceable in American or most international courts. Maybe it’s something that could be brought up in Tunisia, or Luxembourg, or Malta.
Some other things confused me about this latest post:
[anony sez:] eHelp had a very agressive reputation for sales. And I remember that it often made many in the Tech Writing profession angry. [end]
Yeah, I remember that also. Then again, eHelp was dealing with a $30 million a year market and making that market it’s prison b—-. They were the major big gorilla in that market. Cool thing was, they could call it ‘Babe Ruth style’ and swing for the fences because they still did a tremendous amount of innovation. Features were added every year like clockwork and refined several times annually in free point releases (think v1.4 or v12.7 – see, the point equals the period in the version number). Code bloat of RH made it harder and harder to integrate those new features without consequences, which makes me wonder about how Adobe’s going to handle RH’s legacy code management.
I’m thinking MadCap’s focus is a bit beyond eHelp’s model of ’sell a lotta copies of RH, and make everyone in the company learn to use it in order to modify the help system’. I don’t see Jorgen Lien, founder and CEO or any of the former eHelp Marketing VPs working over at MadCap so I’m guessing those tactics aren’t in favor over there.
Instead, MadCap is appearing to examine the workflow and analyze what can help each company keep theirs working cleaner. It’s appearing to be a different business model that results in a cheaper and more efficient end product. MadCap’s making nice-nice with MSFT which means Word users won’t be alienated. Since Word is taught in Junior High / Middle School typing classes nowdays, that’s what I think is a good strategy. Adobe is head to head with MSFT…
[anony sez:] Personally, even with all this “experience”, I would find it odd if the Madcap developers were able, totally on their own with no feedback from the true subject matter experts (the tool users) were able to deliver exactly what I wanted in a tool. I’m afraid I’d end up receiving a tool that only a developer could use effectively and didn’t do what I as a help author wanted it to do. [end]
Hmm. Easy way to confirm / deny this theory that Madcap doesn’t care about the Help Author tool-using community is to take a look at their peer to peer support forums. I suggest anyone with questions to use their own judgement – http://forums.madcapsoftware.com and what I found there was an active community consisting of many layers of user experience. Not just Dev gurus.
The second part of this issue deals directly with innovation. Anyone knocking MadCap’s efforts has yet to point directly to other product features which are more innovative than Flare’s.
I’m looking for stuff that is really hot and compelling. Not just price point. Not ‘just as good’. I want smoking, hot features for my dollars.
The third part is purely opinion. Having personally known the lead team at MadCap, some of them over ten years, I know that they’re currently reveling in their opportunity to provide feature sets that the market’s been looking for years to use.
And the fourth and final part of my objection to that statement about is that technical writers who are able to provide source documentation in Word 2007 don’t really need to know the Flare system to take advantage of it. That’s where the HAT expert user can shine.
Well, I won’t comment on the past of RoboHelp as others know that better than I do. I do question Macrobe’s commitment to anything that came from the eHelp/Macromedia line. I use Flare and Craptivate. While I get first class service for Flare calling Macrobe for Craptivate support is a bigger challenge than getting an answer from the IRS. And how committed is Macrobe? I help maintenance contracts since day 1 for RoboHelp and the last time I checked the contract stated that I will get the next version even after the contract expired. I am still waiting for my RH6 copy to arrive, not that I’d plan to use it.
Commitment doesn’t start when one buys another company, but also includes what happened before. And regardless if the Macromedia folks or the guys running Adobe are at fault, fact is that during the time Macrobe claimed to be fully committed to RoboHelp all RoboHelp-savvy staff was canned. Wow! What a commitment! We have nobody who knows what is going on, we don’t give a damn about supporting our customers, we fire everyone who knows anything about this product line, but we claim to have made a great achievement by cranking out at “craptastic” version by the help of dozens of Indian developer bees. Yes, every RoboHelp user must have a warm and fuzzy feeling now.
If the code really was in such a bad state, why not show some real commitment and create a new version from scratch. A small shop like MadCap managed to get Flare out in a year, so why didn’t the gigantic company of Macrobe manage to do this? Because they are really so strongly committed to RoboHelp?? Gimme a break!
I’m an old-hand with FrameMaker, a past user of RoboHelp, and a current Flare user.
Adobe hasn’t done much for FrameMaker, IMHO. I’ve been using FrameMaker since V3. Adobe has kept up in it’s own awkward way and done a so-so job. But still, there’s neither rhyme nor reason to the way files are sorted in dialogs, it still crashes at awkward times, there’s still no way to repair a corrupt file, no margin releases, etc. Many of the simple things that Ventura Publisher provide in the early 90’s are still not available to FM users.
Adobe’s Support is still problematic and no where close to the level that was available from Frame prior to Adobe’s acquisition of FM.
IMHO, Adobe pumped out RH6 simply to maintain product visibility. Feature-wise, RH6 was not a worthwhile release. They would have been money ahead had they just waited until they had something polished and up to today’s expectations (MDI, source control, standard html, etc.).
It really isn’t about what code now is behind Adobe’s RH release or where it came from. That’s a moot point. RH remains hard to use for large scale help systems, the output is still non-standard, and Adobe puts out their hand as often as they can manage.
Don’t misunderstand, I’m a staunch Adobe supporter. I love FrameMaker. However, I also love Flare. I used RH for years. But getting Flare was such wonderful relief. Adobe may not manage to salvage RH after this.
Please stop the ethnic slurs ramon!
“Indian developer bees” is not a racial slur. The term speaks to economics, not ethnicity. It could just as easily be African developer bees, Mexican developer bees, or even, were the economics the same, American developer bees.
RamonS brings up a good point I did not consider:
[Ramons writes:]
And how committed is Macrobe? I help maintenance contracts since day 1 for RoboHelp and the last time I checked the contract stated that I will get the next version even after the contract expired. I am still waiting for my RH6 copy to arrive, not that I’d plan to use it.
[end]
This would be a major oversight for Adobe to not enforce this contract stipulation. I would be willing to understand that they would immediately remedy this by mailing out box sets or download links to everyone with a valid upgrade to X5 now that they’ve been made aware of it.
OR, RJ – should everyone use your provided phone number and request their copy through you?
[RJ Jacquez wrote:]
I’m RJ Jacquez, a senior product evangelist at Adobe.
While I’m pleased that my eSeminar on RoboHelp has been receiving a lot of attention recently, I’ve noticed that there have been a number of questions raised regarding its content. I’d like to give personal attention to anyone who has such questions. So if you have any comments or questions regarding my presentation, please give me a call directly, on (858) 847-7410. If I’m not at my desk when you call, leave me your number and I’ll call you back.
[end]
I’ll be calling on behalf of my clients who have a valid claim on Wednesday when I return. RJ, I know this updates directly to your email so please post whether or not this is valid so people aren’t confused. I’m using you as a point of contact because first and foremost, you’re honest and a great guy. Second, you’re local here in San Diego.
Another good source would be Vivek Jain whose blog is here – http://blogs.adobe.com/techcomm/
GuyH, me using the term “Indian worker bee” was not intended to be racist, demeaning, or derogatory in any way. It mere sums up a fact that I experienced while working with several Indian engineers. It also is pointed out in many publications, such as a the recent article in eWeek “Russian developers in search of partnerships” (see http://www.eweek.com/article2/0,1895,2150086,00.asp).
In that article various experts bring one important point into the equation: cultural alignment. As stated before, I worked with Indian developers and they all had a very optimistic “can do” attitude. If they stayed around long enough to produce anything it typically showed what they really could do. They all were highly skilled and very knowledgeable programmers who knew all about the most recent technology (although mainly Microsoft). When we asked them “Can you do this or that?”, they always said “Yes” even when they had no idea what we are talking about. Indian culture forbids to say “No” to superiors and that is not how people take it in the US or especially in Europe. Many companies learned it the hard way and now rather look for talent in Eastern Europe. For example, Russian developers are as skilled as their Indian counterparts, but they do have a genuine interest in the business for which they are asked to create software. They ask the tough questions and bluntly tell someone if they are full of it.
I dealt with Russian developers as well and their attitude is more like mine. Be honest and speak your mind even when it hurts, but have some darn good reasons for that. Indian developers generally do not enter a discussion, they do what they are told, and blindly follow specs even when those make no sense. Also, the turnover in India is insane, but explainable. I’d switch employers if the guy across the street wants to hire me and pays more per hour for the same work. At that point loyalty doesn’t pay as companies outsourcing to India also come and go. Mayn large companies such as SAP learned it the hard way. They still hire Indian talent, but tend to do so for commodity work, where a skilled, busy worker bee is at its best. I guess that the trend changes once Indian developers figure out that cranking out code as fast as possible isn’t what it is all about. It is about understanding what one needs to do way before a single line of code is written.
My guess is that Adobe had the same misconception as many other companies. They took a “Yes” as what it means to us. Under that assumption laying off US developers and supporters and moving it all to India makes perfect sense. But taking the fact that RH6 code was done for the most part and that it still took almost three years to get a new version out are indications that exactly that happened what I think happened. Adobe heard the folks asking for a new RoboHelp, but since Adobe wasn’t fully committed to RoboHelp (although they always said they are) firing the US experts and dumping off the code in India was their way to go.
Let’s give the Indian developers the benefit of the doubt that they really got into it, were more committed to the cause than Adobe, but didn’t get out of the gates due to shoddy source code and interface documentation, and layers of code crud that piled up around the real code throughout the years. If indeed Adobe was as committed as they always said, why didn’t one make a decision to ditch RoboHelp as it is and start from scratch? MadCap did that with probably just half a dozen developers taking a year to bring a product to market. OK, Flare 1.0 wasn’t as good as it could have been, but the bug ratio and stability problems were on par with RoboHelp X5. A year later Flare is a very reliable tool whereas the “brand new” RoboHelp 6 earns a “craptastic” at best. And RoboHelp still doesn’t work together with FrameMaker while others like Flare do that with ease. And with Blaze coming out some time this year it may just be that there is no point in using FrameMaker at all. FrameMaker is another example where Adobe just seems to sell off CDs instead of bringing one of their flagship products into the 21st century.
Honestly, where is the commitment to customers? Where is the new stuff that Adobe claims they put in? It is sad to see that a big corporation with industry-leading products leaves its customers out in the desert for years and then cries foul when MadCap comes along with the soda truck and makes people happy.
My guess is that Adobe is hellbent on saving a buck on every corner and tries to ride the wave of their name recognition instead of being really innovative and committed. Ever tried to get support for RoboHelp or Craptivate? Even with a valid support contract? Getting a straight answer from the IRS is easier. What the heck is wrong with Adobe? And not only Adobe, Corel is another example of braindead software company management. After pretty much killing Paradox, Corel now bought ULead to maliciously dismantle their great line of products, such as MediaStudio Pro. And look at the recent versions of PaintShop. There is a reason why I still use version 6.
There are probably hundred good reasons to use RoboHelp, it’s just that I cannot think of any at the moment.
Full disclosure: I’m independent. Certified trainer/consultant in several tools and methods. Nobody’s agent; my own mouthpiece.
This blog needs a truth filter. Maybe an accuracy filter. Maybe just a filter.
It’s degenerated into flinging gobs of innuendo and promoting the SlyLie (an untruth slipped into a stream of text).
RamonS just plain shovels the stuff, and some of it needs correction.
From RamonS we get:
——————————————————————-
….Macrobe….
….laying off US developers and supporters and moving it all to India….
….RH6 code was done for the most part and that it still took almost three years to get a new version out….
…. firing the US experts and dumping off the code in India was their way to go…..
——————————————————————-
1) Adobe is not Macromedia.
2) Adobe did not fire US RoboHelp developers. Macromedia did–well before Adobe purchased the assets of Macromedia.
3) The Macromedia sale was completed in late January, 2006. Adobe released RH6 about 12 months later. Not three years.
And there’s lots more stuff, bent and broken.
But hey! RamonS knows this. RamonS is a moderator on Madcap’s Flare Forums–with something over 1600 posts, where he first used the soda metaphor about a year ago.
MonkeyPi: enough of masquerades and posers, already.
Aha! Well, Adobe is Macromedia as Adobe bought Macromedia. Adobe did recently lay off the last members of the RoboHelp support staff way after Adobe bought Macromedia. The time between the release of RoboHelp X5 and RoboHelp 6 is about three years.
I agree that there would be a benefit to hear from Adobe/Macromedia about the facts. So far, anything that Adobe/Macromedia put out was identified as not entirely correct or plain wrong.
That aside, I am a user of both Adobe/Macromedia products as well as MadCap products. I use RoboHelp since 2000 and yes, I am still using it as I need to create .hlp files for a legacy system. I am also sure that if Adobe/Macromedia would have been both upfront and open about their plans with RoboHelp and showed true commitment I would still be a RoboHelp user. But I was one of the many RoboHelp fanboys who got kicked to the curb. I think that is reason enough to be upset about it.
Adobe bought Macromedia and with that it bought the assets as well as the reputation. Since then I didn’t notice any change in behavior towards customers. Luckily the peer-to-peer forum has Rick Stone who is as a great help.
True, I am one of the MadCap Forum mods. And that because I am a recognized as a customer. I also have a great relationship with the MadCap folks, but not because they made me a forums mod or buy me beer, but because they convinced me right from the start that they have the answers that Adobe / Macromedia didn’t want to give me, especially a new version of RoboHelp that has truly new features and bugs fixed. Uh, and something silly like real support and not some automated phone system that eventually gets me in contact with someone who has no clue about Captivate or RoboHelp.
And what is so bad about autoplagiarism? I never insisted that my analogy was brand new. Nevertheless, it still holds true today as I am anxiously waiting for my RH6 copy that was promised to me by my last support contract with Adobe/Macromedia. And yes, Adobe also bought those responsibilities from the contracts Macromedia signed with its customers.
Ramon; the constant generalizations continue to make an ethnic slurs! These guys did not take anyone’s job and are all individuals.
GuyH, if they did or not is in the eye of the beholder. Those developers who got laid off in the US may think otherwise. I for sure see no malicious intent of those who now do the work. They do it for their living and not to ruin someone’s life. And then there is a degree of how sensible one is. I was called everything from “Kraut” to “Nazi”. I’d be quite flattered if one calls me a “worker bee” or considers my talent good enough to give work to me rather than to someone else.
My generalizations are as good or bad as any generalization. Do they apply to everyone without exception? Of course they don’t. But my experiences are identical with reports from other reputable sources and may just hold true in the case of RoboHelp.
Your frequent derogatory comments suggest that India workers are not as good as US workers. I’m outta here!
GuyH, I never stated nor intended this, quite contrary. I guess the case is closed anyhow.
this is good but mast be better
GuyH,
Your comments are destructive, and I find your attempt to slander and censure RamonS deeply offensive. Perhaps you are insecure about your ethnicity, but RamonS’s comments have NOTHING to do with ethnicity and EVERYTHING to do with U.S. companies giving U.S. job to foreign workers. If the workers to which he refers were in Switzerland, I am sure RamonS would have called them “Swiss worker bees.” His words implied nothing of what you suggested. Please try to read the words for what they say. If you really can’t see what they say, then I would suggest that your mind is not of a sufficient caliber to deal with social issues, your “contribution” just more sand in the social machine. Regardless, please do try to keep your simplistic understanding of race issues out of IT. If you need an outlet or have compulsion to find a racist bogeyman around every corner, you should tune in to one of the many polemical radio talk shows on the air.
Hey monkeypi – are you (madcap) responsible for yet another childish prank?
‘TecWriter is your single solution for Help authoring news and product reviews.’
http://www.tecwriter.com/
I’ve just installed the trial of RoboHelp 6.
Totally underwhelmed.
It’s every bit as annoying as RoboHelp 5. The trial not only has a time limit, but also has a cap on the number of topics. So importing old projects, and then testing how well the Create New Topic feature works is not possible.
In summary: it sucks just as much as Version 5. What the heck they been doing all this time?
Trackback:
http://charlesjeter.com/2007/08/10/backlash-grows-from-high-cost-poor-quality-adobe-technical-support/
When is Robohelp X7 released?
As both a RoboHelp / Flare trainer, I am not surprised to see this amount of discussion over the two tools.
RoboHelp 7 is about to come out. That means Adobe is still continuing support of it. I have seen and ran all the betas. It works just dandy.
Flare 3 is also out. It is pretty good as well.
So really, take your tomato and run with it based on your content, your desired featureset, and ease of learning curve for each tool.
And Hi Ramon, I have not been on the MadCap forums in a while…but on my end anyway its been more Robo training than Flare of late.
Adobe Robohelp 7 is finally out…. let the reviews begin!
Wow! A massive release. Respect to Adobe!
I am still waiting for my upgrade to v6 – promised in my platinum support package form almost 2 years ago!!
Hi Rick,
Sorry for the delay in the reply but I have so many people to chew up that it takes time!
You said:
“I would seriously have to question how in the world they have managed to remain in business and make HUGE acquisitions such as Macromedia. But that’s just me.”
That’s what I keep saying. Once in the corporate mole you could deal actual SHIT and people will still deal it, cause you have a corporate name. When they started I’m sure they didn’t make the goofs they presently do or they wouldn’t be where they are. But now, that’s another story, each and every goof is income deductible, so it is very paying to do such flops…
You also said:
“It may surprise you to hear that I totally believe I AM God. But then again, I also believe that You and MonkeyPi and all the other billions of people in this realm are God. We are all simply God expressing itself in billions of different ways. God is in us, as us and through us. Within and without. No angry old man in the sky in serious need of mood stablizers, just an ever loving presence permeating the universe, seeking to express in many ways.”
Love this part!! I have similar beliefs
you said:
“Namasté… Rick”
I’m surprised here…Namaste! What tribe?
I like Help & Manual best. It is simple and it works. I can create a variables file for all my product info and run it from the command line. Finding support information on H&M is much easier than RoboHelp also.