adobe robohelp,investigation,technical writing,tech writing,technical communication

My Beef With The Adobe Crew - Summarized

Sarah, an Adobe certified trainer, stated that I was incorrect regarding my posts about RoboHelp and that Adobe did in fact include RoboHelp within its Investor Relations documentations.

She said that I was wrong, and Bill / TechCommDood picked that ball up and ran with it. Without examining the raw data, he seconded her statement on his blog. Now they actually question what my intent is.

Let me be clear about why I write.

Easy:

It’s ethical to let other people decide what the facts mean to them. To give them information to make their own observations on.

I’m an insider who worked in the industry at the ground level and saw how the wheels turned for the winning Superbowl team who won, year after year. It’s like working for the Indianapolis Colts, contributing to their playbook, and watching some of the same players playing for other teams.

eHelp was that team because of their players. How well would the Colts play without Peyton Manning, or without their entire defensive line?

Adobe got the name of the team, but cleaned out the roster. That isn’t what a coach or team owner does if they intend to keep winning. It is what they do when they want to cut spending and drift along to maximize profits.

Back to the Beef: Is RoboHelp listed within the Investor Relations documentation from Adobe?

Previously I included just a link to the source document, but that was debated and I was informed, again and again, that I was wrong.

Oh, and if I’m not wrong, then my agenda is ‘questionable’.

Review my screenshots of the raw data, which can be seen in its entirety on the Adobe Investor Relations site. Read my analysis of that information and make your own determination.

Exhibit A: RoboHelp Not Listed Within ‘Other’ Category

Here is a screenshot of that raw data:

The image clearly shows that we cannot observe RoboHelp included within the ‘Other’ category. Thus, the crux of my question to the HATT community. These are SEC related documents, however they are not filed with the SEC.

The 10-K referred to also makes no mention of RoboHelp within ‘Other’. Hence my dysfunctional label for Adobe concerning RoboHelp.

Exhibit B: RoboHelp 6 Release Not Listed

Another raw data screenshot from another Investor Relations document:

< snip> So here we’re seeing that the RoboHelp 6 release is not included. Even Captivate is listed which, at the time of the 2003 Macromedia merger, had less of a market capacity than RoboHelp.

With this fact observed, I’m not buying the theory/assumption/argument that RoboHelp is too small to matter, therefore was excluded due to revenue.

The Product Manager for Captivate, by the way, was Silke Fleischer. She is a consummate professional who is now the Product Marketing Manager for Captivate. She is also an ex-eHelper. Her blog can be found listed to the right and I read it regularly for information that helps me make money.

I make a lot of money using Captivate. However I feel that without someone like Silke running the show, within three years it’s going to drop in leadership of the market.

She’s the only one experienced and innovative enough in this highly competitive field. Read the full analysis post about Captivate here.

< /snip > Here’s the end of the page.

Is everyone on board with the observed fact that these documents do not show RoboHelp?

Assumption vs. Observations Part 1

Sarah did state in response that she ‘assumed’ that RoboHelp was included in the Other category.

Assumptions are based in feeling. Sorry we don’t all feel good about what I’m saying, it has nothing to do with the observed facts.

Sarah, I’m sorry, that’s not what you blogged previously. You said I was wrong. And inferred that you could prove it with your hyperlinked raw data source. I had even corrected one of my earlier statements which resulted from a ham-handed Find command mishap to be completely accurate prior to your post but you didn’t say that. You just linked into the same doc and said I was wrong.

It’s okay to make mistakes. You’re a high level resource who a lot of people count on to be accurate. Your word counts a lot. But let’s not shift the purpose of the posting to be about an assumption instead of observed fact.

For that matter, RJ or Vivek could have posted that RoboHelp was included in the Other category and put the matter to rest a week ago.

I wasn’t planning on having someone falsely state I’m wrong… and then, have another blogger jump onto the bandwagon and say, in effect, that regardless of whether or not Sarah’s correct, my motives are questionable!

For the record, I totally dig Sarah and Bill’s content in other areas. I also think they are movers and shakers in the technical communication game.

That’s fair, I initially assumed the same and fully expected the assumption to be confirmed by someone such as herself who was Adobe affiliated because, as I know software vendors who I have strong business relationships with, usually a simple email will yield a hardworking company rep’s reply with results.

That opinion did not come. Athough Sarah was kind enough to post she would look into the fact on my site.

I can assume that someone within Adobe contacted either her or Bill about my blogging recently. That assumption’s based only on Bill’s snipe about my blog being totally anti-Adobe, his post about a backlash on my HATT thread due to my previous post about Adobe’s Tech Support issues.

Sarah, Bill, feel free to tell me I’m wrong here, because it’s only an assumption, not an observable fact!

I’m feeling, intuitively, that someone at Adobe bird-dogged you and has fed you a little bit of the story to disseminate.That someone has told you that Adobe counts RoboHelp as ‘Other’ but they’re not coming forward to confirm it.

Hey, if they’re part of ‘Other’ that’s okay. That’s to be expected.

Hello, FrameMaker Sequel!

The exclusion of RoboHelp reinforces the statement you made about it not being important enough to mention.

That should be important to all of us HAT users. That Adobe doesn’t see RoboHelp as being important, therefore resources will be limited. Umm… Screams Legacy Software Management a/la FrameMaker.

corporate authenticity,blogging,Adobe RoboHelp,cluetrain manifesto

Part 2: Assumptions versus Observations | Jetman’s Bent Pins Philosophy

Let’s tell a hopefully compelling story about how I view the matter of simply assuming things. This might explain to some why I looked at the RoboHelp details so closely.

When I was in military aviation, we were taught if we assume something eventually that assumption would kill us.

Like the pins that held the parachute in place in my Escapac ejection seat.

In nearly a thousand hours of flight time I always checked the pins on the back of my Escapac ejection seat parachute. If one of those pins were bent and I had to eject, the parachute designed to save my life would be rendered into a ninety pound silk (well, nylon) brick, helping me only to achieve terminal velocity rather than obtaining a relatively safe descent.

I found bent pins in my ejection seat only twice. Both times I brought this to the attention of the parachute riggers, devout professionals in all things survival related, who replaced the chute prior to the flight.

One of those two bent pin flights was a hotseat flight, the jet had just landed and we swapped crews out while the engines turned at low speed on the deck. This meant the aircrewman who had just left the jet had not checked those pins. He had hosed up his preflight which could have killed him. Or killed me if I had assumed that his preflight was done properly.

We had a discussion about it after I landed. It was pretty one-sided as you might well imagine.

After all, I didn’t assume everything would be fine and dandy. I might have needed that chute.

But hey, if I flew with the bent pin chute and nothing bad happened requiring an ejection, it wouldn’t matter, right? Think about that for a minute. A lot of things have to go wrong to require an aircrew to abandon their jet. Philosophically reflecting, I wouldn’t need that chute unless the rest of the day became very very bad.

Let’s talk about a very very bad day. One in which that ejection seat might have come in really handy for me.

Operating on Assumptions: A Case Study of Military Aviation

My worst bad day was returning from a training mission off the coast of San Diego (Whiskey -291 Op Area for those in the know) and having to attempt landing with unsafe gear, two five hundred pound bombs ‘hung ordnance’ (meaning fully armed and not dropping when the button was mashed) in the bomb bay, the bomb bay doors mostly open, and the flaps stuck in.

While my story is titled A Bad Day, check out NeptunusLex’s Worst Day Ever for a real Naval Aviation horror story.

Hung Ordnance: This means the bombs were ‘pickled’ but didn’t fall off the jet. Sometimes hung ordnance just explodes.

Boom.

You never feel a thing. But that would be if the arming wires got pulled out, and your luck ran out and the detonator triggered. The safe way out of this mess is the duty Explosives Ordnance Disposal (EOD) team which comes out and renders the bombs safe in some sort of arcane black magic way.

Flaps stuck in: that meant we had to take an arrested field landing, dangerous in itself because the cable could snap, we could get caught up in it and flip over, or we could just not brake in time and go off the end of the runway.

if we survived that, the bombs had to stay attached, otherwise they’d either fall and pull the wires arming the bombs which, .24 seconds later would be primed for detonation on impact.

Bomb Bay Doors: the bomb bay doors, if closed, would prevent the bombs from falling far enough to arm. Since the bomb bay wouldn’t close all the way this compounded our already big problem.

The bombs could, as we arrested on the cable during landing, pop out and skitter down the runway. This would become the crash crew’s problem as they would be rolling to meet us.

Or they could become everyone’s problem because at the end of this runway was the fuel depot.

Unsafe Gear Down: That means that once weight was put onto the gear, it could collapse. We all see commercial jets now and again that get wonked onto a runway and everybody slides to safety. Whee! In the military, someone who knows what they are doing has to pin that gear so if the landing gear fails, the pins catch it.

If we landed and survived the arrested landing without running out of runway, someone would have to jump out and pin the landing gear, because at any time without the 3/8" pin in the gear, the unsafe gear could collapse, on one side, both sides, or the nosewheel gear. This collapse could kill whoever was outside underneath the jet at the time. Or not only kill that person, the bombs could fall off the jet and kill everyone within the frag pattern - about a mile.

Before we landed, we flew in circles around Naval Air Station North Island until we burned most of our gas. I watched the sun go down for what could have been the last time. During that time, we talked about ejecting rather than landing. We all had a vote - all four of us.

We all decided to risk the landing even though everything had gone wrong except for lightning striking us or an engine falling off the aircraft.

I was the one who had the job of unstrapping and jumping out of the jet to pin the gear. If we survived the landing, if we were able to not run off the end of the runway, and the bombs didn’t go off, I could be lucky enough to be crushed underneath that 30,000 lb aircraft while I was pinning the unsafe gear.

So. I have to ask you, are you the type of person who would assume the unsafe gear would hold, and not pin the jet? Would you assume that the bombs couldn’t detonate and refuse EOD’s help?

Would you fly a combat mission with a bad parachute? Would you land, and taxi back with hung ordnance without pinning the gear?

I’m not the type of person who would. By the way, the types of people who would operate on assumptions in Naval Aviation… Never made it through the training program.

Assuming was treated the same as missing something. Missing something critical was grounds for a Signal Of Difficulty (SOD). One SOD in safety of flight meant an instant failure. Two SODs, pilot, flight officer, or aircrewman, and you were answering hard questions for a board of your instructors who would decide your future.

Nobody every got three SODs and still flew. Because at the end of the day, each instructor had to realize that they would stand a chance of their life depending on this individual at some future point in time. I never got a SOD by the way. Kinda proud of that.

I have six of my friends who assumed things during training and ended up with a vastly different Navy Adventure than I did. They ended up loading bombs onto jets, or refueling jets rather than flying in them.

Assumptions killed their career in training before it ever began. Observations, and acting appropriately through my training and judgement, gave me some of the best experience and best friends I’ll ever have.

By the way, to wrap up the story. I lived.

I lived. Because my team got their jobs done, and our technical support got their jobs done when we had problems.

Clearly this is not on the same level as the software. Or is it?

In fact, the teamwork required to get that jet into the air is a lot like the teamwork required to get a piece of software to work as advertised. Mechanics work like Developers, checking all the critical elements. QA is the same in aviation and in software. In my story, EOD is like Tech Support; they take care of the bombs.

Let’s say you make a software purchasing call for your technical communications department and it fails. Messily fails, like hung ordnance falling out and arming. Like the project fails right before deadline, and cannot be resurrected. In fact, even though you spend the extra bucks for maintenance, the software’s tech support team tells you, Sorry!

Boom.

Can you afford to assume that your manager won’t hold it against you? Would you assume you wouldn’t lose your job if the software you recommended couldn’t deliver what it promised?

What is the significance of RoboHelp not included in Adobe’s documentation?

This is a more philosophical question. It’s very subjective. That’s why I asked that others merely examine my raw data and draw their own conclusions.

Sarah had a very clear conclusion: That Adobe didn’t care too much about RoboHelp because it wasn’t bringing in enough money.

My conclusion is different, although her analysis did lead me to rethink some elements:

• Adobe had no initial intention of reviving RoboHelp. The Investor Relations documents don’t show intent to release RoboHelp 6, and don’t show historical data for RoboHelp X5.
• Adobe has not supported RoboHelp at the highest levels. Their brain trust of Tech Support was released, then requested to come back because they ‘made a mistake’.
• Adobe is fickle with the RoboHelp and HAT market. There is a strong push for maximizing revenue rather than investing in customer goodwill. Hence no following the previous pattern of one update every year for free, and annual product updates guaranteed for maintenance customers.
• Adobe is very interested in maintaining a profitable revenue stream, therefore will not jump into a complete code rewrite - critical for a HTML based editor to become an XML-based editor.
• RoboHelp is no longer the market leading HAT tool. Vivek didn’t answer the HATT communities direct question about his statement to this effect.

So let’s look at the HAT market data. This is admittedly dated information which should have been updated within the Adobe documents, but was left out leading to our current discussion.

RoboHelp’s Market: Help Authoring Tool Market Data

The data I recall is from the eHelp merger documents given to all eHelp shareholders in 2003’s Macromedia merger. I recall something like a $30 million / year market. That’s what - 30,000 copies / maintenance agreements per year?

That’s pocket change for Adobe, according to Sarah’s post.

Would you want to buy software from a company that, it is assumed by their actions, does not care about your needs? Or would you want to buy software from a company whose core competency and sole focus is Help Authoring Tools?

You probably know by now which direction I’m starting to lean in: I’m the kind of guy who wants a Parachute Rigger to rig my parachute, not a baggage handler. I’m the kind of guy who asked for the EOD duty team to disarm the bombs, and didn’t try it myself.

Same with my required software tools.

Adobe RoboHelp,MadCap Flare,MadCap,Adobe,Technical Writing,Technical Communication,Online Collaboration

I’m not perfect. I just check details if I’m going to bother to examine something at all. I’m within the circle in this industry. Probably to a greater degree than either Bill or Sarah since I physically deal with the product managers and software code developers. It’s the wings and beer connection and the fact that most of these eHelp people belonged to a family when they worked there.

Doesn’t mean I got tipped to Macromedia merging with Adobe. I had lunch in MACR’s SF lunchroom just a week prior and was just as surprised as everyone else. I was independently repping a media study for a great analyst firm at the time and even THEY were surprised.

Who Am I To Adobe And MadCap

I strongly believe that more innovation comes from a commitment to the end user and the ability to commit to listening to their conversation. I also believe that competition breeds a better product. That’s capitalism, right?

However, I’m into the truth. I’m into playing fair.

Let me be clear about this relationship. I get heavily discounted software from sources within Adobe and MadCap Software, mainly, among other vendors. I give them an honest, unbiased opinion which is valued by some and reviled by others.

I’m not an employee of Adobe or MadCap Software. I will, however, be looking into providing Help Authoring Tool services to my clients in the future and Adobe’s not impressed me with the RoboHelp solution to date. As you may have guessed from my posts.

I have been part of software beta testing for both companies however not for competing products at the same time, i.e. I don’t Beta test for MadCap Mimic and Adobe Captivate or Adobe RoboHelp and MadCap Flare. One year I’ll do Captivate and Flare, another year it will be other products.

Well, at least that was the plan up until RH6 came out and I started publishing my research.

I am very respectful of Intellectual Property and do not cross my Non-Disclosure Agreements. IP is bread-and-butter for a lot of people, and innovation is to be cherished, like a great tactical chess move gaining an advantage on the board.

To date, I have not received monetary compensation from either MadCap Software, Adobe, or any other HAT or eLearning software author. I sometimes get some cool swag like t-shirts and my kid has a killer Adobe bookbag. I don’t work booths at trade shows and unlike some bi-vendor technical communicators, the only logo’d items at these events you’ll see me wearing belong to my own company.

I personally like RJ Jacquez, but I will pound him in my statements for being untruthful if I catch him doing so. RJ’s done some spinning in the past year that MonkeyPi brought him to task about, and with RoboHelp he’s unfortunately drawn the short straw and been given a pig to put lipstick on. I just believe in Corporate Authenticity.

Doesn’t mean I won’t buy him a beer afterwards. He’s a heck of a nice guy. He might not take me up on it though.

Let me be clear about why I write.

Easy:I believe that more companies should work according to the Cluetrain Manifesto principles. Web 2.0 is an example of how this concept of integrating user feedback has grown from Cluetrain’s 1999 dotcom era Manifesto.

It’s ethical to let other people decide what the facts mean to them. To give them information to make their own observations on.

I’m an insider who worked in the industry at the ground level and saw how the wheels turned for the winning Superbowl team who won, year after year. It’s like working for the Indianapolis Colts, and watching some of the same players playing for other teams. eHelp was that team because of their players. How well would the Colts play without Peyton Manning, or without their entire defensive line?

Adobe got the name of the team, but cleaned out the roster. That isn’t what a coach or team owner does if they intend to keep winning. It is what they do when they want to cut spending and fly on fumes, coasting along to maximize profits.

Likewise, I will pound MadCap Software for being untruthful if I catch them doing so. So far, their marketing engine has not redlined my BS detection. Their confidence in providing a better product  - well, they tend to back it up.

By pound, I mean to at first request clarification, and if the spin starts getting too out of control, request more clarification. If there’s still spin, or a refusal to answer, then I post my question with my raw data research and let the free market figure it out.

I may sound partial to MadCap - well, I was on the fence about this whole thing until RoboHelp 6 was released. I was still very impartial, yet critical of Adobe until they lined up and shot their RoboHelp brain trust.

After that, I started analyzing what I now call the RoboHelp Timeline. My analysis was rooted around the request of a longtime client in what they should use going forward. What would save them the most money, and assist them in their own Software Configuration Management.

I have been reporting what I’ve discovered since then pretty much as it happens. Mostly as a cautionary update to Adobe, after all, if they’re reading it, they can change things.

I’m betting that not much will change with Adobe. I don’t think that big ship can turn fast enough. And I’m ashamed at the innaccuracies with the stories I’ve heard.