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 »

eContent Magazine reports the shifting change in the Help Authoring Tool / content authoring market:

In 18 months, use of Flare has grown to 25% of the content authoring market, according to the 2007 WritersUA Skills and Technologies Survey, while usage of RoboHelp declined from 63% in November 2006 to 56% a year later. The company [MadCap] reports being profitable since its first month shipping the Flare product.

There are some graphs from the 2007 WritersUA conference which confirm this. Mike Hamilton and I discussed their growth in the December Podcast as well.

Sustainability? Innovation!

We’ve discussed their Web 2.0 Tech Support as a major competitive edge. Now they have the office space to expand, they have the budget to expand… What’s going to be next?

I’ve seen the new announcement for an upcoming workflow process that looks like it encompasses even more than Blaze by itself.

If MadCap is profitable now and still launching new products by the crateload does that itself qualify as a competitive edge?

I think that MadCap’s core focus on software development rather than expanding cubicles and their tight control of middle management has been key to the past two years of success. There’s one competitive edge.

Anthony Olivier, CEO, at one time was the eHelp CFO prior to his eHelp CEO position. He knows how to flip a dime about four times. The relocation to the 7777 Fay office was a coup as well; I’ve never heard of someone being able to MAKE money on an office move.

Where do you see the tipping point coming? Or will Adobe (NASD: ADBE) reverse the defections and keep selling its product in increasing volume?

After all, according to Vivek Jain, TCS Group Product Manager, Quality IS Innovation. :p

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 »