While this approach may be the most efficient to meet one single defined need, or solve one single problem, it is not scalable and can soon lead to development dead ends and an inability to meet new customer requirements. In an agile development environment this can cause real problems.

ePublisher is unique in that it uses the concept of Parcel Publishing to deliver unmatched flexibility and scalability.

Parcel Publishing uses a series of pipelines with well-defined start and end points that break the publishing process down into a series of discrete segments.

Want to know more about Parcel Publishing? Ask for a copy of the latest WebWorks White Paper, and we’ll be happy to send it to you.

During the course of our investigations we came to believe that this was an issue that should be discussed more openly. In particular we felt an obligation to help raise awareness of how and why you need to look at your Online Help as a potential security risk.

Following that original post we planned to host a webinar on the subject. It turned out to be one of the most popular webinars we have ever held and was oversubscribed – twice. That single webinar turned into a series of three.

For anyone who was unable to attend, we have now collected the information presented in those webinars in a new WebWorks White Paper.

The white paper includes sections on:

• Background to our own interest in Online Help security issues.
• Notes on industry trends.
• Why Online Help is particularly vulnerable.
• Security as process (the title of this post comes from that section).
• Taking steps to ensure that you are protected.

If you would like a copy of “Is Your Online Help A Security Risk?” either leave a comment with your email address below, or email me directly  with your request.

For the first week we only offered the paper to people who requested a copy directly after seeing the announcements on various sites such as Twitter, FaceBook, LinkedIn etc., as well as through the wwp-users group.

From various conversations over the last twelve months or so, I knew that interest in using wikis for delivering online content was high, but I never expected the response that the announcement of the paper generated. I spent a significant amount of my time last week just sending out PDF copies of the wiki white paper.

Initial feedback has been very positive:

- “A very good intro into the world of wikis and how you have
implemented them at WebWorks and in ePublisher.”
- “Excellent new wiki publishing white paper.”

Given the paper’s unprecedented popularity, we decided to try a little experiment and convert the WHite Paper into an eBook format so that it would be easier to deliver and more accessible.

If you have a Blackberry or an iPhone you can now download a copy of “WHY USE A WIKI?” using the free shortcovers eBook reader, or you can read it online HERE.

If you would prefer a PDF copy, then just send me a note to aporter@webworks.com

Here’s what I wrote in the white paper:

While the main focus of the wiki may be technical, you can speed acceptance by seeding the wiki with other topics that may have a broader appeal. For instance one of the things we use the wiki for at WebWorks is organizing the company Christmas Party!

By posting information on something that everyone was interested in, and wanted information on, the wiki quickly became seen as an authoritative source of information on what was happening in the company. Rather than have information going around in uncoordinated email threads, it was in a central location where everyone had access.  By asking for menu suggestions and comments, we also introduced the idea of using the wiki for feedback and commenting.

By using the wiki to organize a fun event in which everyone had a vested interest, the acceptance and usage of the wiki was a lot quicker, more user driven, and far more acceptable than any imposed mandate of “you must use the wiki from now on.”

And the end result of that particular wiki project last month?

WebWorks.com 2008 Christmas Dinner

I’ll admit I’ve become a big proponent of wikis, and the possibilities they offer for a more intelligent and targeted delivery of information in a way that doesn’t just project information to the end-user; but actually engages them in a bi-directional exchange of knowledge.

I’m currently doing a fair amount of background reading on various aspects of wiki technology and the use of wikis for an upcoming white paper on Wiki Publishing.

What I hadn’t thought about until I started the research is why this open editing web based publishing environment is actually called a wiki. I had heard that it was an acronym for “What I Know Is.” But it turns out that this is more accurately a backronym.

Wiki doesn’t stand for anything.

“Wiki” is the Hawaiian word for “fast.”

The story goes that Ward Cunnigham, the creator of the first wiki site , installed in 1995, was looking for a name that reflected how quick it was to set up a his new style of website and remembered a counter clerk at Honolulu International Airport telling him to use the “wiki-wiki” shuttle bus.

Wiki Wiki Shuttle Bus at Honolulu Airport

Well this is one bus ride I, and the rest of the WebWorks team, is committed to. Hop on board and join us – they’ll be some interesting stops over the coming months.

Free tools are not always the best tools – output

Your job is to produce user guides, help systems, training material, etc. It is not merely to produce topics. The tools you use to create PDF and CHM files is as important as the authoring tool you use.

This paragraph had a particular resonance for me as I’ve not long finished authoring a white paper on just this very subject. The paper, “DITA PUBLISHING: The true costs of taking your DITA content online”, is scheduled to be released at the upcoming CMS/DITA Conference in Santa Clara in April, but if any readers of this blog would like an advance copy, just drop me an email (aporter@webworks.com) and I’d be happy to send it your way.