It’s Adobe’s party, and we’ll cry if we want to

Alan Pringle / Conferences, Opinion20 Comments

I had a lot fun meeting all the great tech comm folks who attended LavaCon in Austin earlier this week. (I’m also dreaming about the next time I’ll get a divine Buffalo Bill burger from Hopdoddy.)

On Monday night, Adobe sponsored a birthday party for FrameMaker and RoboHelp. I had some good food and great conversations. Many thanks to Adobe for a fun, well-planned event.

During the party, though, I witnessed simmering resentment that didn’t jibe with the festive mood Adobe was trying to promote. And that anger was coming from at least one user of the spotlighted products.

While Adobe representatives were on stage celebrating RoboHelp, I had a conversation with someone whose department was using RoboHelp. She was very unhappy with product—and even less pleased with Adobe’s support. I heard the words “out of touch” and “they just don’t get it.” Ouch! Instead of upgrading, her group is currently evaluating an XML workflow with a non-Adobe authoring tool.Still from the theatrical trailer for Happy Birthday to Me (1981)

I have <mumble> years of experience with FrameMaker. I’ve used structured FrameMaker since the mid-1990s (when it was called FrameBuilder), and it has been a key part of many, many successful projects.

But even I had mixed emotions about attending a birthday party for FrameMaker. In the past five years, there’s been a rising tide of complaints from users and consultants about the product. Issues include poor product positioning, lousy support, and new features that are not useful to the people who use the product. Just check out Val Swisher’s excellent post about FrameMaker and Scriptorium’s review of FrameMaker 10 to see what I mean—and be sure to read the extensive comments on those posts, which provide additional context.

Was I the only person who experienced the disconnect between the party atmosphere and widespread user dissatisfaction?

Adobe must listen to its customers. Otherwise, the next party might be a wake.

flickr: akuchling

About the Author

Alan Pringle


Content strategy consulting. Publishing (electronic and print). Eating (preferably pastries and chocolate). COO at Scriptorium.

20 Comments on “It’s Adobe’s party, and we’ll cry if we want to”

  1. I have never used Framemaker, but have wanted to learn it for a while. Now reading posts like yours and Val’s, I’m debating whether I should or not.
    It is still a very much in demand product, but with competition from MadCap and ePublisher I get the feeling it isn’t the best one.
    My company doesn’t use a structured authoring tool like FrameMaker, but I am evaluating the options on the market and Adobe should be worried that when I read articles like this I second guess their plateform.

  2. I have to suspect that Adobe knows that the writing is on the wall for FrameMaker. It is a long-document applications in a world that is moving to topics. It is a desktop application in a world that is moving to the cloud. It is a paper-oriented application in a world that is moving online. And whether you love its quirky interface or hate it, it just does not look or behave like a modern application.

    Adobe has treated it like an aging cash cow for many years now: Just enough updates to keep people on the upgrade cycle, just enough nods in the direction of new methods and trends to keep current users from switching, but no real commitment to being modern or leading edge — that would require too much of an investment.

    Actually, it would require starting again from scratch, and building something completely different, because in the world of distributed structured topics targeted at online delivery, it is the repository, not the editor, that dominates the writing process.

  3. I too have heard the grumblings. In fact, I think I’ve heard a number of folks who mention that the interface feels like it’s getting worse than improving (sounds like my feelings about a product from another company that I won’t mention here). Makes me wonder how much usability testing is being sloughed off. Can it be that Adobe doesn’t really consider these products fun and shiny enough to make a difference? I hear that other parts of the TC suite feel better than RH and FM but can Adobe afford to ignore the TC base that uses FM and RH?

    Only time will tell.

  4. Mark’s comment makes me want to comment. 🙂 All this talk of moving to the cloud, etc. might be true for software companies, but there are still manufacturing companies out there who, for various reasons, need a solid tool to produce paper. When I worked at a semi-conductor company a few years ago, FrameMaker was the perfect tool for my manuals. They averaged 500 pages each! They are not cozy-up-on-the-sofa manuals. They are reference manuals for engineers. I remember one had 450 tables in it. Now that I am in manufacturing again, I recall grumblings in the past from others in manufacturing. The feeling then was that discussions revolved around software’s needs and rarely the needs of manufacturing.

  5. @Karen. Interesting. Why do manufacturing companies still need paper? Software certainly used to produce 500 page reference manuals, sometimes with hundreds of tables in them, and they are definitely moving to online because it is so much easier to look stuff up online than in a big paper book. Why wouldn’t the same be true of manufacturing?

    If it’s an access issue, because people are not in front of terminals, don’t tablets address that?

    Either way though, money follows trends. Customers who aren’t changing the way they do things can be served with existing tools, so there is not a lot of reason to spend a lot on developing updates for them, other than to generate upgrade revenue. Serving people still producing long docs on paper does not require Adobe to spend lot on R&D for FrameMaker.

  6. Sandy: If your needs analysis shows FrameMaker to be a contender, you should consider it. That being said, Adobe has shot itself in the foot so many times with useless features and horrible positioning, I would take those negatives into account when you’re weighing tools against your requirements. Longevity and “future proofing” are absolutely something to evaluate when comparing tools and technologies.

    Julio: I’m among those doing the grumbling. It doesn’t make me happy to see a tool I once loved go so off the rails.

    Mark and Karen: Some companies still have paper requirements, so a page-based tool like FrameMaker can be a good choice. (We have some clients who are well served by FrameMaker because they are still in a page-based world, mostly for regulatory reasons.) However, if those companies have different output needs in the future, the tools equation starts to change a lot…

  7. Approaching FM in the future primarily as the preferred PDF output engine for XML-based publishing systems, not as an authoring solution, has not been mentioned above.

  8. How do I start? While I too enjoyed the party I agree that I had my own misgivings.I am not a writer by trade, but I’ve been involved in implementing very successful structured content solutions and have many years of experience moving clients away from FM and into native XML infrastructures. I understand enough to know that continuing to placate the community with tools that contradict known and proven better practices is detrimental to the it at large. I have long been evaluating bridge development to native XML/DITA CCMS, though to justify this only to support the (undetermined) market potential would be disingenuous.

    I have as well made some suggestions for improvements to help make the case to support, which support the opening comments made by Mark Baker, though I suspect this would require they accept his closing comments to actually do this.

    I could go into a diatribe about being penny-wise/pound-foolish… about doing the same thing again and again and expecting a different result… but I will refrain (for now).

    The bottom line here is that unless there is a major and swift shift, the next event may be a retirement party.

  9. Alan and Sandy: As for any feature-rich application, a challenge for rolling it out as the tool for a writing team is to identify which features to avoid/prohibit using. Use FM on a nontrivial project, then identify which of its features you really don’t need, then either modify the tool’s UI directly or compose author instructions (e.g., style sheet) to enforce those rules or to provide usage guidance. Structured, reusable authoring has always been possible in FM, despite what today’s DITA promoters would have you believe.

  10. Point taken, Alan. After reading your comments to Mark and Karen maybe I should reconsider. We are still largely a paper doc company as it is written into many of our customer contracts. Trying to transition so something more electronic would require a huge effort in getting them to reword their RFPs to include electronic docs

  11. @Alan: Indeed, regulatory and contract restrictions can keep people in the paper world. The catch, of course, is that at some point, the regulations or contracts will change.

    The interesting question then is, how much notice will people get that the next contract of the next regulation is going to demand online docs?

    Would it be better now to move to a structured doc format that allows you to deliver to both paper and online so that when the regulation or contract changes, you will simply be able to plug in a different output mechanism? Or would it make more sense to wait until you know exactly what you are going to be asked to create before you make any process changes?

    Switching now could mean you are not optimized for the change when it comes, and could also mean that you spend money now and don’t get the ROI for several years. On the other hand, waiting could mean that you are caught unprepared and unable to deliver on time when the contract suddenly changes.

    If you could switch to a structured authoring process now and have the switch pay for itself with your current deliverables, it would seem to make sense to change now. If not, it’s a bit of a head-scratcher.

  12. Adobe’s problem with FM is it’s a mid-point specialist product that sells on Adobe’s name but never in large volume. A company that’s big enough to believe it needs an ‘enterprise’ product probably won’t consider an FM solution. And a small company won’t do anything Word can’t, if only because the cheque-signer has never heard of the alternatives. Really: Despite all evidence (RH looked like a sunset product at the time) I’ve known a Reaseach Director dump MadCap simply because he felt Adobe must have the ‘better’ product… I’ll leave you to decide whether FM would, or even could, exist without Adobe. Much as I grew to love FM, the truth is that TCs rarely own documentation these days; quite often we provide the frameworks and publishing routes that allow others to deliver. I may deliver one fish, or the meanest fishes, but my real job is to make it easy for ‘you’ to fish. So I may have cried at Adobe’s party too, but I doubt I’d have been shown the door. But I sure hope MS never invites me to an Office party; I do a great rant on smug, self-satisfied, 80%ers who don’t get structure that’d make you weep.

  13. Paul: Using FrameMaker as a PDF publishing engine for XML is a good solution, especially considering that quality PDF files are a benefit of using FrameMaker. (I’m frankly surprised Adobe hasn’t pushed more on this angle in their own marketing.)

    Cynthia: You may not be an end user, but as someone in the tech comm tools trade, you know how important it is to keep users happy. Unhappy users release after release = no future users.

    Mike: I had a good laugh when I read the last bit of your excellent comment: “I do a great rant on smug, self-satisfied, 80%ers who don’t get structure that’d make you weep.”

  14. @mark @alan
    I know of situations where electronic devices cannot be or may not be used or where a network is unreliable or non-existent. Batteries do have a limit, and people have been know to forget to charge them! 🙂
    Also, some medical devices are locked down – meaning staff cannot run a DVD with videos or see online videos for how-to information. The document-producing company might be willing to provide new-fangled solutions, but the client was still in the horse-and-buggy stage.
    I wasn’t saying all this to defend or criticize Adobe. I was just playing the devil’s advocate to point out the scenarios where the dreamy online world is just not yet possible or feasible. And I argue that we cannot just leave those poor souls behind.

  15. I am a user of Adobe software and have been for years. However putting that to one side, the real issue here seems to be an end user’s ability to adopt new working practices. Trust me.

    There are loads of manufacturing, engingeering and public sector sites that could move away from paper / print output. The trouble is they either can’t or won’t. Not everyone works in an environment where the latest technological gizmo is accepted as the way to go. Add to that the sites that Karen describes. We are in just that scenario. We produce online help for our users but have to produce an offline version for those whose devices are locked down.

    One of the things that bugs me a little, is the ease with which we as a profession jump to conclusions. I know I’ve done it on occasion when a little more retrospect would have been better. There are a lot of technical communicators working in software companies. They tend to be very vocal too, but there are many other techcomm professionals out there who don’t work in software. Add to that regional differences and you get an even more complicated picture. Time will tell whether Adobe’s position is right or wrong. Personally I can’t say with any certainty which way it will go. I suspect however that it could take a long time to reach the point where we’ll know.

  16. @Karen No argument here. But it means that paper becomes increasingly a niche market (and tech pubs is already a niche market, so it becomes a niche withing a niche). If a niche market is well served by an established product, then the right business strategy for the company that makes that product is to tweak it just enough to keep people on the upgrade cycle, but not to invest any money in a major overhaul which would never pay for itself.

    I think that what I perceive Adobe’s strategy to be with FrameMaker makes perfect business sense. They own a shrinking niche. They can milk it for upgrades for a long time to come — perhaps indefinitely. Of course, you can never ever admit that that is what your strategy is. The strategy depends on customer’s believing that the company is 100% committed to the long term future. You never tell people that a product is going to end-of-life until you are ready to steer them into a new product.

    But the new products that matter in the current direction of tech pubs aren’t editors, they are repositories. The successor product to the big DTP packages of the 90’s aren’t big desktop publishing systems, they are content management systems. I just can’t see how a major overhaul and modernization of FrameMaker would make any kind of business sense for Adobe. But don’t expect them ever to admit that.

  17. Alan – Thanks for your post and for the reference to my post. We are having quite the interesting discussion over on my blog, too.

    I want to answer your question specifically about the party (since my thoughts on the product are already quite well-known!). I was at the party and many things about it surprised me. The first is the notion that having a piece of software that has been around for 25 years is something to celebrate. Is it? Or, is it time that Adobe really invigorated the product and revolutionized it to the point that the old name doesn’t even fit.

    For example, I’ve heard Adobe say that RoboHelp (now 20 years old) is a great tool for creating eBooks. Well, if I’m searching for an eBook tool, am I going to think that RoboHelp is the name of such a product? Note that I am not saying RoboHelp is or is not a good tool for eBooks – I have not tried to use it this way, so I cannot comment. I’m just saying that in the world of software, old is not necessarily a good thing. Heck, I’m feeling old compared to a lot of the people who attended Lavacon, and I’m not so sure that’s a good thing either.

    Then, of course, there was the atmosphere. On the one hand, I think it is really nice for Adobe to shell out money on us. Everyone likes a nice party – it makes us feel important. On the other hand, maybe Adobe should have taken the opportunity to have a focus group to LISTEN (not speak, just LISTEN) to the community about how they feel about FrameMaker. Afterall, I’ve seen dozens of people voicing very strong feelings on our blogs. And you spoke to someone *at the party* who had feedback for Adobe. But, I don’t recall Adobe taking the opportunity to sit in a room with us, eye-to-eye, and listen while there were a couple of hundred people at Lavacon that they could have asked. Sure, they held a big Adobe day before the conference, and we had a party. And we got to listen to them. But they did not ask us or listen to us.

    Finally, there was the vibe of the party. I know that I was so personally offended when said person screamed said things into the aforementioned microphone that I simply left. I had no need for being in a room with that type of energy. I think that aspect of the celebration could have been better controlled.

    Bottom line – Instead of giving us a lot of alcohol, Adobe could have used the opportunity to give us a chance to speak to them. I think we have good things to say and if they are going to keep the product alive, they need to ask and listen.

  18. Val, your last paragraph really says it all, doesn’t it?

    BTW, I had ducked out of the party before the screaming began. Can’t say I’m sorry I missed that.

  19. Alan, I found your blog post on FrameMaker while researching publishing DITA XML to WebHelp. I’ve used RoboHelp for over 10 years to produce WebHelp and printed docs, and started learning FrameMaker last year for DITA structured authoring. I’m new to DITA and FM, and I find both very complex and difficult. But our goal is WebHelp more than printed docs. The DITA Open Toolkit’s WebHelp requires a lot of customization, and I want something quick and easy. I tested publishing WebHelp from FM DITA to RoboHelp with TCS 3.5, but am blocked right now because CSH and other features aren’t working correctly. I just started testing XMetal as the authoring tool, which is extremely easy to use. I published the files I created in XMetal with Madcap Flare to WebHelp. It was simple to customize and publish the WebHelp, and Flare provides out-of-the-box features not included with XMetal’s WebHelp. However, I haven’t yet tested CSH and conditions with XMetal/Flare.
    I do believe Adobe is listening, and their product managers have gone out of their way to personally help me several times. I can’t really say that about their Support team, though. I don’t really want to switch from Adobe to other tools, since I’m comfortable with RH and Acrobat. But I’m going to use the right tool for the job. I think FrameMaker is difficult to use for new DITA authors. RoboHelp is not that easy to use to publish WebHelp from DITA files, as much as I wish it were. I am sure FrameMaker is the right tool for some publications. But I’m not going to try to force a tool to do what it’s really not designed to do.

  20. Gina, I think your last sentence is key: “But I’m not going to try to force a tool to do what it’s really not designed to do.” As is the case with all other authoring tools, FrameMaker is an excellent choice for some situations, and a lousy one for others.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.