Can someone tell me how Adobe Tech Comm Suite 4 compares with Arbortext?
-especially with regard to DITA
Be sure to consider the collateral damage.
A study I read from several years ago (since updated, but behind a paywall), indicated that switching to AT:
You got my attention.
Got a URL for that paywall?
> Got a URL for that paywall?
It might have been:
Here's an older [free] white paper:
Don't speak ill of PTC. This discussion caused our PTC Slow-E license server to crash this morning.
Good luck with that.
Both support version 1.2 of the DITA standard, but you should also thoroughly test HOW they support DITA functions/mechanisms such as conref, keyref, ditaval etc. Arbortext Editor's functionality is comparable to FrameMaker's. I don't know about the price of Arbortext because PTC is very secretive about this (you have to contact a local sales rep, if you can find one).
If you manage to get hold of a trial version of Arbortext, which is not easy either, you should not just evaluate the authoring process, but also the publishing process. Using FrameMaker, it is easy (and inexpensive) to design templates to publish your DITA content to PDF and you can publish to other formats with RoboHelp. With Arbortext, I think you will also need Arbortext Styler to design stylesheets and templates.
A little known fact for you; PTC are the worst company in the entire world.
In fact, I'm not even 100% convinced they actually exist.
Well, PTC actually does exist, but unlike Adobe, they're a very "closed" company and conspicuous by their absence from conferences, trade fairs and user groups (LinkedIn, dita-users on Yahoo...). Fortunately, Adobe has understood that listening to customers and getting user feedback is important these days, so they actively participate in all the social groups and communities. You will find a wealth of information on the TechComm Suite, including webcasts, video tutorials (tv.adobe.com). You can easily download a 30-day trial version of FrameMaker 11, whereas it took me several emails to get a 15-day evaluation version of Arbortext Editor last year.
Contrary to critics': Arbortext is alive and well - as both a product and engineering team within PTC. It's confusing to many because PTC does not have a direct-to-consumer model, you need to go through a reseller (there are many - search for "Arbortext"). There is a lot of misinformation about Arbortext's current status (and pricing model) out there since it's acquisition by PTC in 2005. (Error7103's comment above is a prime example; most 'papers' were written by competitors or operations that didn't have a relationship with Arbortext so wrote it off without direct, current facts.) In fact, the older Scriptorium paper has a lot of wrong information; the more recent Scriptorium paper had input from one of the resellers.
I'll stop here because this is the wrong forum for that discussion.
You're better off figuring out your requirements and talking to customers who have used both (and those who have switched -- both vendors will supply a list of folks who have gone from one to the other). In the end, you have to choose the tool that best fits your requirements, not someone else's. And remember, that in the end, it's not the tool that matters, it's the change process and the people who will be doing the work who make the difference between a successful project and a failure.
> I'll stop here because this is the wrong forum for that discussion.
Why? The basenote poster has specifically asked for an FM-AT comparison.
When considering a product like AT, a basic question is: what is it, exactly, that your management is trying to do?
tyljar hasn't told us, but because DITA was mentioned, I suspect the comparison that's desired is of FM vs AT as structrured authoring and publishing solutions. Any responders would also need to know where the content is coming from, and what the deliverables are (including any databases, web servers and web apps involved).
I worked at a company that used ArborText, and if structured authoring is the goal, I did not find it to be a bad tool...of course we had an entire "Document Engineering" department to support us poor writers when things went south
I have been using FrameMaker for less than two years, but after using ArborText, I think FrameMaker makes it easier for users to change and update templates. Trying to update templates in ArborText took an entire team as I recall...
But, like all the other posters mentioned, you should really think about what the needs of your projects are and consider the skills of the writers that will be doing the work. The "getting-up-to-speed" time when learning ArborText (especially for writers who have never used XML) is significantly higher than just learning structured Frame. Especially if your templates are complex.
Although I cannot speak much for ArborText, I can speak for FrameMaker and Adobe suites. More current versions of FrameMaker are totally convertible to DITA and XML. There is a good Tech Comm Tools publication out there that gives a lot of info about the conversion tables and how their used. I've been using FrameMaker for both structured and unstructured documentation for about 10 years. Fortunately, I was using an XML Content Management System before I went to Structured FrameMaker, so moving over was fairly easy.
There is probably far more training and information available for FrameMaker than ArborText. If I had to guess, there is probably far more Frame users as a result. Not sure, as others state, what the cost comparison is for both. I use Frame 12 at work and also have the Adobe Technical Communications Suite. As a publishing package I just prefer Adobe products for technical writing and publication.
From other blogs, my understanding is that ArborText is used more for XML and content publication. Whereas, FrameMaker is used more for the printed page. Although probably somewhat true, FrameMaker actually does it all. I can be used in concert with a CMS and XML exported to a database. Therefore, FrameMaker is apparently good for almost all types of publications including XML, SGML, PDF, and HTML.