A great discussion has started over on MonkeyPi about the Sun Tech Writer who is suing regarding unfair work exemptions. I replied there but this is a far lengthier topic than the comments deserve.

Exempt Tech Writing: How To Not Get Sued

Personally, I tend to view this as a problem that needs a solution. Were I negotiating this matter I would bring up two specific issues which could have prevented this from occurring, or which could lessen the expectations of management.

First, one thing that Adobe does do right is that they allow telecommuting. This allows a 60 hour work week to be reasonably managed along with a busy life schedule because employees can manage their lives around the time they put in on their home systems.

Second, by having a workflow that allows input remotely without endless face to face meetings (the absolute largest waste of time I observed while working as a tech writer for a nameless military contractor) and proper collaboration, a lot of this time saved reflects working smarter, not harder.

Getting Granular about Exempt Status

I found the following definition of exempt status online:

EXEMPT means the job is NOT subject to payment for overtime hours worked. Employer policy may elect to compensate incumbents in these jobs for their overtime, but there are no restrictions on rates used or quantity of hours paid to incumbents in exempt jobs.

Overtime requirements apply to the JOB not the EMPLOYEE. It is the responsibility content of the job that determines if incumbent employees must be paid for the overtime they work.

There is a Highly Compensated Job exempt status but it only applies to Public-Sector Employees.

Legally, exempt employees are due overtime in California law if it can be proven that they regularly cannot complete their normal assigned tasks without working overtime. Two years ago a roommate of mine ended up winning a similar judgement simply by making a phone call to an attorney and having them contact the HR department where he was working.

What it takes to document your situation is at the very least, logging your hours worked along with the tasks you are assigned. Regardless of exempt/non-exempt status, in California the Overtime law states that you cannot be expected to be working for free, which is what regular overtime without pay is.

Summing up, legally Sun is responsible, at least to one employee. The judge’s court order has the attorneys searching for a second employee, a reasonable request given the frequency with which John Edwards-like trial lawyers tend to overuse the class action.

The lawyers will win one person’s case, that’s a given. A landmark ‘blow for Sun techcomms’ it may not be unless they find another employee to sign on the line.

Yet, as this attorney states on his blog in reference to the IT lawsuits:

In this situation, is it any wonder that, increasingly, some California companies are moving jobs across the border to work in other states where employees don’t have to be paid special overtime rates?

Just like the ridiculously high workers’ compensation rates hurt job creation in California several years ago, the overtime pay requirements are doing the same thing in the IT industry.

Below the fold are the boring legalese text from the California Labor site… You’ve been warned!

Read the rest of this entry »

Continued from eDMS Roshambo Part 2: Wikis vs eDMS posted a couple months ago. Sorry for the delay.

…And now you understand my RoShamBo comparison. Wiki, according to the authors I quoted in eDMS Roshambo Part 2 beats plain desktop publishing. In fact, Stewart Mader has an excellent book out that’s on my next-to-read-list.

Wikipatterns by Stewart Mader Read more about this book…

And as we remember from my eDMS Roshambo Part 2 quote from Dan’s blog, Dan Ortega feels that with the proper corporate restraint wikis can work well within a corporation.

This is with caveats, and not all of them are limited to technology. There are significant conflicting social elements regarding wiki implementation as well which is a point that Stewart Mader and I both agree upon.

Sacha Chua from The Orange Chair discusses this dilemma in It’s the culture, not the technology:

Corporate culture isn’t something you can change in a few months. You can’t install goodwill. You can’t enable cooperation.

In short, if you work in a hostile corporate environment, wikis might not be the best method to collaborate. Then again, in such an environment there’s probably zero collaboration going on at all.

Wiki Strength: Wiki Usage Resolves Siloed Content Challenge

No more of that developed content (.doc, .pdf, .fm) shoved somewhere on the eDMS or intranet with only desktop tools to edit it with. A wiki provides a single authoring framework that all can use.

Wiki Weaknesses: Homogenizing, Updating, and Repurposing Content

The primary objection / weakness that I have of a wiki integration is in single-sourcing and repurposing the resulting content.

Bringing exported content out into XML or another form is possible in some wikis but the end product still requires some sort of editing tool such as Microsoft Word, Adobe FrameMaker, or MadCap Blaze. Now you run into some issues.

The content’s single sourcing is critical, and if it’s updated in the wiki getting the changes into the technical communicator’s source working files could become a devastating bottleneck. 

The second weakness of a wiki is in the editing tool itself. The integration of concepts such as snippets and variables doesn’t currently existi in wiki editing. 

I would also add that the snippet suggestions and many other ‘homogenizing’ methods that MadCap’s Analyzer offers allow significant time savings in structuring content. This is a capability that the wikis I’ve seen don’t have and I consider this to be a particular weakness when overall content structure is considered due to the time required to get ‘er done.

Wiki content needs to be cleaned up if it’s going to see the outside world. I think behind the firewall a wiki gives everyone something to work with but there’s still considerable work to be done prior to integrating raw text into a corporate presence.

So even with a wiki there is still a workflow requiring a tool, and usage feedback can still be examined within the published online resources.

With RoboHelp or Flare the WYSIWYG is very sophisticated, the result of both product’s design team experience with help authoring. With a better editing tool for XML Flare tends to overrule both RoboHelp and straight wiki collaboration with the MadPak suite which has that killer app Capture, which takes the image variables into consideration so graphic inclusion isn’t such a chore.

I came across a few letters authored in Word 2.0 from my final cruise in 1995 and it got me thinking about my roots in TechComm. Have you had any experiences which led you towards TechComm which stand out?

Yep… Everyone Has a Story…

The initial knowledge management / content wrangling that I learned prior to using specific software tools was through my time in the service in the 1990s. I would have loved tools that MadCap, Articulate and Adobe now make for that. This was even before Microsoft Word and PowerPoint were adopted!

When looking at the time spent in communication simply in my collateral, non-aircrew duties, it seems that my “part-time job” of about 40 hours a week was a Technical Communicator. Somehow I managed to fit flying into this, probably due to the seven day work week that we military folks enjoyed while being deployed.

Workflow of a Typical Aircrew Technical Communicator

While I was in the military, we didn’t have a job description of Technical Communicator however once I was out of training and ‘in the fleet’ we were required to:

Read the rest of this entry »

What do you need to get started?

The Federal government requires that all applicants for Federal grants and cooperative agreements with the exception of individuals other than sole proprietors, have a DUNS number.

That means that if you’re an S Corporation or a C Corporation, or in any way shape or form NOT working as a d/b/a sole proprietorship you will need your DUNS number. 

Great… What is a @#@# DUNS Number

Sounds difficult, doesn’t it? Let me shortcut this for you: Before you can bid on anything as a small business, you must have a DUNS number.

Getting a DUNS number is free and takes only a few minutes. Just click beneath the fold…

Read the rest of this entry »

When you find new authors it’s exciting to read their viewpoints. I initially started this blog with a thread of analysis of Adobe’s RoboHelp 6 release with which I was thoroughly underwhelmed. I had been watching the discussion on MonkeyPi previously, and part of the enjoyment of blogging is responding to what I call distributed discussions.

Back to RoboHelp vs. Flare: The Blog Review

It’s interesting that today’s examples are all from Utah. Being a former Coloradan for several years I have to say it’s nice to see some of the Rocky Mountain crowd. Now let’s enjoy some distributed discussion of RoboHelp 7 and MadCap’s marketing.

First, a view from Paul Pehrson on RoboHelp 7’s competitive abilities with his analysis of Adobe playing the innovation catch-up game:

RoboHelp is now in catch-up mode trying to figure out how to emulate the innovative features in MadCap’s product suite. Now it is MadCap pushing the innovation envelope here.

Will RH be able to maintain pace with MadCap’s one (or more) releases per year? Will RH be able to come out with new features that aren’t already in Flare?

Maybe so, but RH 7 wasn’t proof of that yet. Again, it will be interesting to have this discussion in two years and see where the major players are at.

I found Ben Minson’s blog when he guest posted to Tom Johnson’s blog. Ben posted a critical thesis about MadCap’s marketing which, by the way, is a great opinion piece.

The thing that has bothered me the most about what has happened with RoboHelp and Flare is MadCap’s marketing approach, which caused “Flare” and “MadCap” to leave a bad taste in my mouth.

Granted, Macromedia’s treatment of the original RoboHelp team was probably less than professional. However, Hamilton seemed to make it his quest to blow RoboHelp to smithereens. It wasn’t business—it was personal. If he could carry that little ring to Mount Doom and throw it in the fire, it would be worth everything that happened in between.

In my research into my Web 2.0 Technical Support series about MadCap Software I hadn’t seen anything untoward expressed online or in print. They did, however, carry a gag gift of the die kadov tag die T-shirt, an inside joke about RoboHelp’s shortcomings.

In fact, in my podcast with Mike Hamilton in December 2007 he was neutral about Adobe. I asked Mike H. several tough and somewhat leading questions about RoboHelp and Adobe. Before, during, and after the podcast he never said anything truly outside the norm, and in fact was more generous than I was in his analysis regarding the level of dedication that Adobe may have with RoboHelp.

In my podcast program we find the relevant segment within the Hamilton podcast:

10:10
Clarifies MadCap’s focus on Adobe: “…we don’t care what Adobe does, we’re focused on solving the problems of the technical writing community… I want to dispel any myth that we’re chasing Adobe.”

11:40
Why I started analyzing the space closer: MadCap’s openness in summer 2007.

12:10
Thoughts on other blogger’s views about Adobe’s Technical Communications Suite (TCS) launch. Mike responds by comparing integration of tools within Flare and within Adobe TCS – Example of Capture’s integration with Flare to support the concept of single sourcing workflow.

We went into other discussion of workflow…

34:30
Remembering RoboHelp: we each discuss where RoboHelp came from and why it’s so different from this model MadCap’s following. Mike elaborates on the competitive edge MadCap has right now in integrating all of their products.

36:40
Mike believes that both RoboHelp and Flare will be around for a long long time, of course he and I differ on this viewpoint. He does mention the caveat of how much innovation Adobe puts into RoboHelp being questionable which we both agree upon completely.

Read the rest of this entry »

Indiana Jones & TechComm?!?

My first impression of government Technical Communicators  while in the military brought to mind that last scene in the classic film Raiders of the Lost Ark where, after the entire film’s adventures the Ark of the Covenant is being (air finger quotes) examined by top men.

Indy asks who, and the reply is the same: Top. Men.

As the film cuts away, we see the famous box holding the Ark being wheeled down the hall of a warehouse.

I tended to think of Technical Communication within the Government as being the same. Content repositories being siloed. It was hard to access and in the worst case in recent history, being responsible for the events of 9/11 according to the 9/11 Commission’s report. Agency A couldn’t communicate with Agency B in time to bring actionable information to bear, therefore… We all know the rest of the story.

How interested is the dotGov in listening to TechComm consultants?

Read the rest of this entry »

While I’ve been working feverishly these past two months on my NorCal project, Paul Pehrson talks about MadCap’s Blaze beta on his blog Technically Speaking » Early Review: MadCap Blaze. He specifically mentions MadCap’s new collaborative workflow tool:

If your reviewers don’t have Blaze or Flare installed, MadCap is introducing a new product called X-Edit Express — a free tool your reviewers can use to review, make suggestions and light edits, and submit back to you. All my SMEs can install X-Edit Express, and I can use Blaze/Flare to submit the file to them for editing.

They open it in X-Edit Express, do their review, and click Save. The file will show up again for me as being reviewed. I can open it to see what changes/annocations they made.

X-Edit Express isn’t available for review yet, but I’ll give you my comments on that one once I’ve had a chance to evaluate the program.

Replacement for Microsoft Word or…?

I can see Blaze being useful and complementary to Word however X-Edit pushes the envelope. Sharon has a great couple of workflow diagrams on her blogpost: Beta, beta, everywhere which show where it belongs in the workflow.

In my December 2007 MadCap corporate headquarters visit and subsequent interview of Mike Hamilton we talked about workflow and specifically about Word.

I think one of the tougher questions I asked him was whether or not it was an intent of MadCap Software to compete with Word. In my podcast program we find the relevant segment within the Hamilton podcast:

27:00 (minutes through podcast)
Mike answers the question about Word competing with Flare or Blaze. Since the MadCap –products are a complete workflow, does it compete with Word?

28:15
Getting granular about Word vs. Flare in typical generic user usage – where the breakpoint comes in.

30:15
Strategy and policy for supporting new Microsoft releases. Mike includes Internet Explorer web browser, Word, and operating system support in his answer.

Briefly, Mike answered that MadCap was not looking to create a Word replacement and that MadCap intended to work with Microsoft products as a valued Microsoft partner. My opinion is that… X-Edit was designed with a specific (ahem) industry problem in mind…

Hey SME, Don’t touch that template!

IMO, X-Edit fits well in preserving a doc template so it can’t be horked down by fatfingering.

With Sharon’s website showing the template form of X-edit and Mike’s previous statement I figure that either Word or X-Edit will be great for sourcing information and X-Edit Express wraps it up for those who don’t need to write it, just read and be heard.

Killer Application: Helping begin corporate conversations…

Ann Gentle has a complementary article about corporate conversations which IMO, is a critical application for this tool.

Imagine the Technical Support staff having a Web 2.0 window into documentation, becoming empowered to review the docs as they are published and implement troubleshooting into a software workflow.

Here’s yet another great article from Just Write Click >> Technical writers and conversations:

I had an “ah ha” moment at SXSW Interactive, when one of the social media metrics panelists Rohit Bhargava said he sees three areas or channels for measurable conversations - Public Relations, Marketing (Sales), and Customer Support.

For me, those three categories crystallized this connection: where our role as tech pubs is strongest in an organization, that’s where we might start successful conversations.

… Tech support seems the best alignment for many companies, as Charles Jeter’s follow-up points out. Tech publications that drive down support costs are another area where value proof lies.

Ann, you’re on a great thread with the conversations bit. Getting corporate cultures to open up and use Web 2.0 smartly is critical to their success against their competition.

Threat Assessment - Adobe TCS will lose even more ground…

My opinion is that Blaze coupled with X-Edit Express is what we called in the military a ‘Force Multiplier’. It’s another technological smart bomb, just like MadCap’s newly released Analyzer.

It will help the overall workflow of the Technical Communications Manager / Team Lead by allowing their subject matter experts (SMEs) to comment freely without impacting the installed software cost. This is a low (zero) cost high yield product befitting a hard look.

If this were the 1980s and the Cold War, X-Edit Express would be Star Wars or the smart bomb. As it stands, it’s just another reason not to renew the licensing on existing Adobe Acrobat Professional.

I’ll have to try it before I claim it beats the DevBlog concept, but I won’t be shocked if it kills my old workflow standby and raises the bar for MadCap’s competition.

I figure that X-Edit Express will compete with Adobe Acrobat’s reviewing workflow and will easily compete with the ‘next generation’ of Adobe’s Technical Communication Suite as Adobe moves towards true single-sourcing. 

As a free tool for reviewers it removes the requirement of a licensed copy of Adobe Acrobat for reviewing. It also swings into the single-sourcing workflow that FrameMaker so desperately needs - with a wrecking ball.

I’ll be watching Paul’s blog closely for more industry information - he’s really stepped up as an MVP in the MadCap community.

Mike, Sharon, that name has got to go…

Okay, I hate to knock MadCap, but I hate the X-Edit  / X-Edit Express name already.

On the (very) bright side this is what you get when your core competencies are user experience and programming and the brain trust won’t (waste)spend a lot of money on marketing weenies.

I’m sure the product will work excellent regardless of its name, I’m just being picky. 

My two cents: Stick with the tradition of a one or two syllable name.

Flare. Blaze. Mimic. Capture. All sound memorable. Like Rocky. Legend. Matrix. Halo. 

Besides, MadCap’s not staffed by ‘haters’. They can take a ding or two from little old me!

Related posts (some external):

• MadCap’s VP Mike Hamilton Speaks! (Dec 7th, 2007)
• DevBlog Collaboration | Your Internal Process Holy Grail
• Web 2.0: one man writes » Conversation V.I.P.s
• Technically Speaking » Early Review: MadCap Blaze
• Sharon’s MadCap Blog » Beta, beta, everywhere
• Communication from DMN » Staying on top of changes
• Just Write Click » Technical writers and conversations

Another successful example of Web 2.0 Tech Support usage as we’ve discussed earlier: HATT post 69635 Re: flare evaluation

I am nearing the end of my evaluation period with Flare (just 9 days
left!)

Here are my comments:

The MadCap (Flare) people came out of the woodwork to support me,
whereas Adobe (RoboHelp) never uttered a peep - even though I
downloaded free trials of both and have posted several times in this
group. It reminded me of the good ol’ days of Blue Sky Software
(original owners and the creators of RH) and I was delighted to learn
that MadCap is sort of a reincarnation of Blue Sky.

If you liked hearing that Regina, you should check out my blog article with pics of the new/old place and the podcast with Mike Hamilton done last December.

In my opinion, Rahul writes with better clarity than about 80% of America’s high school graduates and probably with better structure than I do.

He’s a professional and does quite well in an industry that the STC India figures show has consistently increased in wage by 20 - 30% between surveys.

From Rahul Prabhakar - when the muse strikes!: the new black gold of India

According to Prabhakar, Bangalore is the frontrunner amongst all Indian cities working on technical writing ’simply because most (technology-related) multinationals are based there’.

‘With no university courses, technical writers in India are left to the wolves. They are made to learn the ropes on their own,’ laments Prabhakar. But despite the lack of training possibilities, ‘India’s participation in the world of technical writing is something that everyone is talking about.’

I’ll be looking into trends of how the technical writing pipeline differs in India than in North America with later posts. Suffice to say, I think that there is real competition coming from India and it’s going to have an impact globally.

Everyone knows what Roshambo is - rock, paper, scissors. It’s a quick to learn children’s game with its basic roots in human psychology. Apply this to an area, say Policy and Procedure.

Documentation Management or What’s with all this stuff on the H Drive?!?

The existing concepts - eDMS with separate DMS documents, implementing and overseeing a corporate wiki, or the RoboHelp Server each have different strengths.

There’s a great article pointing out the pros and cons of eDMS vs Wikis that I have planned for Part 2.

With Part 3 I’ll go into the history and technology of the RoboInfo Server - a/k/a RoboEngine a/k/a RoboServer a/k/a RoboHelp Enterprise

So now we have a nice easy Roshambo with strengths and weaknesses in each. I’ll also wrap up with where I will be recommending my clients to improve their procedures.

Existing Paradigm: eDMS

Within an eDMS Word documents, disparate help files, PDFs are all available yet siloed with content that cannot yet be single sourced. Editing workflows vary from product to product but none are core technology and are stagnant in quality. The eDMS price point is upwards from $10,000 for the India-based developers into the mid five or low six figures for top of the line eDMS integration.

So cost is a weakness. It’s also risky for a middle manager to have to make recommendations on adopting usage. Editing is normally either a multi-desktop tool evolution or some sort of half-baked internal editing tool within the eDMS.

Proposed use: Wikis.

Wikis are easy for multiple users to use, however dealing with recommended corrections tends to lead towards anarchy without consistent management and oversight. Not a lot of corporations are thrilled about the open-editing functionality and that limits Wiki adoption currently.

I’ve not seen much to change my views from the research I did last year, How Wikipedia Works (Or Doesn’t) | Can Corporations Use Wikis?

Dan from Astoria has a great position contrary to mine. He feels that existing corporate controls will tend to triumph over the anarchy.

So if you take the notion of a corporate blog and loosen the filters to “evolve” it to a wiki, is this the equivalent of letting a pack of hyenas into your living room?

A lot of pundits seem to think so, however, with the proper review and approve mechanisms there is no reason to assume you can’t maintain the same level of control. The benefits of a wiki as an input mechanism to a documentation process that had previously been behind an information firewall are vast.

My response is in the comments and basically states that if a corporation is willing to listen to the unvarnished truth without punishing the contributors, they will be able to get the wiki job done.

I personally am skeptical about corporations not killing the messenger.

Yesterday’s Faded Glory: RoboInfo Server / RoboHelp Enterprise

RoboHelp / RoboInfo with the RoboServer is one method I’ve used for the past few years. RoboHelp can import content in, but it’s siloed and wrapped in proprietary format once it’s in. With the RoboServer other source information can be indexed. The Adobe Technical Communications Suite (Adobe TCS) brings things to ‘almost single source’.

In my opinion the Adobe TCS strategy with bundling the Acrobat 3D is that people will start drawing all of their documentation instead of writing it. Sort of like IKEA furniture instructions. I am beginning to believe that Adobe doesn’t know the true definition of Technical Communication, or they are attempting to change that definition.

Disrupting the Doc Management Roshambo - Analzyer and MadPak

MadCap’s solution set of the MadPak with their Feedback Server has been making a debut with its innovative Web 2.0 interface. Now, with the addition of the soon to release MadCap Analyzer, we’re looking at a true Roshambo contest for data management and documentation managers. 

After sitting down to take a sneak peek at the MadCap Analyzer, I’m realizing that workflows as we know them for documentation are about to make an abrupt shift upwards in efficiency. As far as I know, MadCap’s Analyzer will release sometime this January.

Analyzer is breaking that rock-paper-scissors deadlock with a wrecking ball.

Since keeping documentation as simple as possible is the hardest task to accomplish, Analyzer allows a Documentation Manager the capability to review consistency quickly, a task that would normally take hours or days to complete is now a matter of minutes and can be run on a daily basis.

I’ll post a review of Analyzer shortly, having first seen its close to release version just this week.

What I’m guessing is that the MadPak will fit nicely into an existing eDMS solution, bringing Web 2.0 capabilities and advanced authoring assistance directly into the documentation team’s grasp.

My proposed adoption: For managers who have eDMS, use of the MadPak with the new Analyzer will make their doc teams sing their praises louder than Vikings sending heros off to Valhalla.

For small companies who have data silos and have a need for single sourcing that data, FrameMaker, Word, and RoboHelp content can all be aggregated with MadPak. That’s if you’re planning on spending less money later on by having all the information in one place.

For Wiki proponents, read my article How Wikipedia Works (Or Doesn’t) | Can Corporations Use Wikis? because the quoted Harvard Business School professors do the Wiki adoption point much better justice than I could in one or two paragraphs.