The Lombardi screenshots look very close to my “process wiki” which uses more standard tools (Visio, DreamWeaver, and RoboHelp) then converted to MediaWiki.  Maybe with these new services, I will be able to automate the work required to produce my Product Design documents.  This would be a tremendous time saver.

To solve these issues, I would need to convert over hundreds of Wiki articles into another format. Unfortunately, I have not found any good solutions for these conversions or the printing of Wikis in general. I have looked at the wiki2PDF scripts where user enters a list of articles and the script makes a single PDF file. However, it is based on the assumption I want to directly output the list of articles for final printing, which is not the case.

The ideal solution would be a new type of Wiki where the stored format can be used for multiple sources. A DITA based Wiki idea was floated and attributed to Paul Prescod, Group Program Manager, XMetaL in Crystal Ball: A DITA Wiki by The Content Wrangler and elaborated on by Anne Gentle in Document Actions Darwin Information Typing Architecture, meet Wiki. However, no such product yet exists.

Therefore, we are looking at reversing our RoboHelp2Wiki conversion tool to roundtrip the data back to RoboHelp. An advantage of this method is the ability to leverage the independent table of contents capability found in RoboHelp and other help authoring tools (HATs). Wikis and HATs have a natural connection between the HATs topics and Wiki articles. The power of HATs is the ability to organize the topics to best present the data. Organization is through table of contents hierarchies.

As part of the RoboHelp2Wiki conversion process the RoboHelp table of content hierarchy creates a MediaWiki conversion article. To roundtrip the information from MediaWiki back to RoboHelp, we simple need to create a MediaWiki article with the desired table of contents listing all the article pages and the order to present the information. On conversion, the tool would read this Table of Contents article and create the matching Table of Contents in RoboHelp and convert each article page listed.

In truth, we have been thinking about the above since before we created RoboHelp2Wiki, however, we did not want to commit resources until RoboHelp Version 6 was released. We were hoping that version 6 would be XML based without RoboHelp’s priority tags (‘kadov’ tags). This is not the case.

So, before committing to a Wiki2RoboHelp strategy, we decided to look into creating the conversion tool to another HAT or editing tool. We plan to review Flare from MadCapSoftware and some of the DITA tools. We will also review the OpenDocument and Office Open XML. The minimum requirements would be ability to support an independent table of contents and the ability to round trip basic formatting, including tables. A nice to have would be the ability to round trip conditional tags.

In my RoboHelp and MediaWiki post, I explained why we use RoboHelp for Business Process Management design documents and the reason we are moving to MediaWiki once the documents were completed or at least signed-off. As I did not want to have to copy and paste the 400 topics from RoboHelp to MediaWiki, I began researching existing conversions tools. It seem there are only two primary conversions tools available: HTML2Wiki and Word2MediaWiki.  However, both of these tools are targeted for single uploads, not batch uploads.  Nor did they handle images. To me, using these tools would almost be the same as copy and paste. Matt Hart also started a RoboHelp to MediaWiki converter; however, it did not meet all of our needs. He did kindly let us review the code as our starting point. (Thanks Matt!)

So in the end, we built the RoboHelp2Wiki tool ( Thanks Ted!). I believe there is a small market for this tool, so we published the tool and the source code, under a GNU license. Our primary requirements included: (1) Create a new page if one did not exist, (2) Overwrite an existing page if a page already existed, (3) upload all images linked on any RoboHelp topic page, (4) Convert most common mark-up from RoboHelp/HTML markup to MediaWiki, (5) Covert the RoboHelp Topic Name to the MediaWiki topic Name, and (6) Create a upload history file within MediaWiki. With respect to #2 overwriting of existing pages, this was a special case for our needs. Our Requirements document already had four reviews completed and I wanted to capture these changes in MediaWiki. So, during the conversion process I generated 4 RoboHelp output files and upload each one in order using a different MediaWiki user name corresponding to the published Version. (Blueprint Version 1, Blueprint Version 2, etc.) Now we can see the full history of the drafts from pre-MediaWiki usage to post-conversion within The MediaWiki history files.

Next steps, if there is interest we would like to provide a GUI interface that is more configurable and provide some more precision on the markup handling. Also, some Version control in case the Wiki is changed between RoboHelp uploads.

Click Here to request a copy of the tool and source code.

RoboHelp2Wiki V 0.9 converts Macromedia RoboHelp Topics to MediaWiki pages. For this release, most of the structural and object elements are converted to proper wiki counterparts. Stylesheets and javascripts are mostly discarded. Display related markups, such as font size, colors, appearances, are not retained in most cases.

RoboHelp2Wiki is a product of The JK Group, Inc. released under GNU General Public License 2.0.
Requires Java Runtime Environment (JRE) 5.0 or later, RoboHelp HTML X5.0.2 Build 801, and MediaWiki Version 1.7 or 1.8.

RoboHelp is a product of Adobe Systems Incorporated.,
Mediawiki is a wiki engine released by Mediawiki.org,
Java Runtime Environment (JRE) 5.0 is a product of Sun Microsystems

My product design documents, average 300-500 pages for a medium sized Business Process Management project. The document includes process models, user interfaces (requirements and mock-ups), system interfaces, alerts, events, etc. For each process step, I create a RoboHelp topic page that contains the Description, Requirements, Unit Test Script, and associated page Help text. I then build a relevant table of contents and publish using the webhelp format (see image)

RoboHelp Standard Menu

and to Microsoft Word. The web format is used as a quick reference guide and Microsoft Word format is used during face-to-face review sessions and official delivery. Almost all my contracts specify delivery of documentation in Microsoft Word. MediaWiki topics and web-enabled the table of contents to duplicate the Webhelp navigation.

The downside of RoboHelp is change management and collaboration. Clarifications, re-engineering, and other changes can occur every time the document is opened, especially when you have 100+ user interfaces, 20-30 system interfaces, and a dozen or so processes and sub-processes. There is no better method to capture changes then to have a pen and the printed document. While updating RoboHelp topics are quite easy, viewing changes can really only be accomplished in Microsoft Word via a document compare redlining of the prior version. This is a bit taxing for the initial document delivery, but completely unworkable during the software design and construction phase of the project. The project team grows exponentially and many small changes and clarifications are realized. Capturing the information simple and republishing documentation is a nightmare. Even more of a nightmare, is the need to license RoboHelp for each user. There is no way I would ask my clients to provide RoboHelp licenses to the whole project team or ask engineers and developers to learn this application just to keep the documentation up to date.

Of course, if you can work in a full web environment Wikis are the near-perfect collaboration tool. Easy enough to use so engineers and developers are not burdened when entering notes and comments, plus providing history, redlining capabilities, recent changes and related links functionality.

For my current project, I converted the RoboHelp topics to

MediaWiki Home Page Example for Projects

Added benefits included image history capabilities and the RSS feeds on the recent changes page. I have subscribed to the RSS feed via my NewsGator RSS reader and can quickly review all changes as they occur. With respect to image history, we use a simply 4 digit file naming protocol (1234.jpg) for the User Interfaces. For each design iteration we simple upload a new User Interface snapshot using the same filename, overwriting the old image. When viewing the history, we can cycle through each mock-up while reviewing the requirements changes. Very powerful when trying to recall why you made changes a month later. We do the same steps for the process models.

MediaWiki Image Upload Page

"Ideal scenario:" I want to schedule a meeting. I know right from the start who needs to come to that meeting. I have access to everyone’s free-busy info and it is clean and accurate. The client software automatically picks the next available time-slot, I click Send and it drops auto-magically onto everyone else’s calendars…and another angel gets his wings ;o)

She goes on to frame the issues very well. This is an area that we have been working on leveraging Business Process Management (BPM) applications which provides the rules, collaboration, work-flow and multiple system coordination with our calendaring and scheduling background.

The following is a scenario we wrote with respect to a public opening of a procurement proposal for one of my clients.

Background: Public organizations follow formal procurement rules and for large purchases, these entities issue Requests for Proposals (RFP). In most cases, responses to RFP include a technical proposal and a separately sealed financial proposal. As part of the process, this organization holds a public opening of the financial proposal which all participants may attend. Participants include internal staff and external parties. For a particular organization only the internal project manager and the internal procurement officer are required to attend all others are optional. This event occurs after the technical proposals have been opened, evaluated, and the evaluation approved.

1. The BPM application tracks the status of the procurement and when the technical proposal has been approved, it automatically checks the free/busy of the conference rooms, the project manager and the procurement officer and then issues a meeting request.

2. The project manager and the procurement officer using their existing calendar client; accepts, delegates, or counters the request.

3. Once a date/time has been accepted by the mandatory participants, the BPM application issues a meeting request to all other participants, including the external bidders.

4. Responses including delegations are tracked and available to the internal staff to print the official sign-in sheet.

5. The day before the meeting, the information is passed to the security system for day badges to be issued.

The above scenario highlights how BPM can be used to assist with the scheduling of events. Mimi’s fuzzy time-frame options would be very helpful with #2, as this part is still a negotiation.

On this trip, I read and enjoyed Thomas Malone’s book “The Future of Work How the New order of Business Will Shape Your Organization and management Style, and Your Life.” I heard him speak at the BPM Gartner Conference after my presentation “Business Process Management in Action”.  Speaking with him afterwards, we talked about the parallels in technology advancing on the same line with his thoughts (or theories not sure which) on how humans and organizations are advancing.

Basically, his (I am not sure if he goes by Thomas or Tom – I will use Tom) conjecture is the cost in communication has driven and is driving these advances.  Tom has some great examples as humans went from bands of hunter / gathers to farmers to the rise of kingdoms and empires to democracies.  In short, farming enabled larger populations to live closer together which increased communication and the rise of herdsman. Larger groups required more communications and a centralized hierarchy was the cheapest method giving rise to chiefs, kingdoms and empires.  Writing, ~3000 B.C.E. was one of the key enables lowering communication costs greatly.  The next set of changes occurred around the year 1450 with the invention of the printing press. The printing press dramatically decreased the communication costs and was the necessary condition to promote the idea of democratic societies.  Examples provided were how the press brought forth the American and French revolutions.

With respect to business they too have followed the same general pattern.  Small business to large centralized corporations to now – where we are seeing the rise of decentralized networks.  Decentralized networks have a broad definition and include companies like Cisco who have subcontractors handle all their production.  The enabler from small to large was the rise of railroads, telegraphs, memos and the telephone. The enabler from large to decentralized networks is of course the Internet.

As an owner of my own company, I have worked with multiple companies from around the world to create and delivery a variety of products.  So, I can relate very well with how the Internet has enable me to create and manage international product teams.  While my experience has been in software, the book provide some other examples, such as, Hollywood.  In the movie business, directors, actors, cameraman, and engineers of all types come together to create a movie and then disband.  This practice is easily understood and practiced.

The parallel I saw in technology to his lecture was that stand-alone computers, moved to client-server models, and now moving towards peer-to-peer.  The same pattern as he discovered.

The book’s conclusion is that human societies and businesses will continue to move from command-and-control activities to coordinate-and-cultivate activities.  This seems true for technology also as we move towards web services.  And today’s hot topic Business Process Management is the tools and practices required to coordinate-and-cultivate business activities.

The more feedback – the more change orders – the higher the cost.

Since we now agree that feedback is required to achieve a good implementation we need to change the contract terms in order to benefit from the feedback.  My idea is to add "iterations" language into the contract with possibilities of 3 or 4 iterations to be completed before change order language kicks in. The first iteration would be a delivery as close to the original design specification as possible. Subsequent iterations would be based on feedback and reviews of the previous iterations.

By approaching this from a contract standpoint, negotiations with the service provider would be focused on the total level of effort, the number of iterations that will be completed, and the percentage of the level of effort required for each iteration.  These negotiations will be based on the quantity and quality of the initial requirements, the experience of the service provider, and the flexibility of the BPM application. For example, a very detailed specification may result in an allocation of 70% of the effort on iteration 1, 20% of the effort on iteration 2, and 10% on iteration 3. When only minimal requirements are at hand, four iterations may be best with equal breakdowns, i.e. 25% each. The more experience the service provider is in a specific knowledge domain the more accurate their work effort percentages will be.

Next up – can we use this model during the selection stage when picking a BPM Application?