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 recen