A big congratulation is due to Ismael Ghalimi and the Intalio team on the delivery of BPMS 5.0. Ismael recounted a portion of the 8 year (and $6 million plus) road to delivery an open source BPM platform in From Vision to Execution. I am not sure where Ismael is finding the time just finishing up the Office 2.0 conference and designing the Redux Model 1.0 an open source version of the Apple iPhone.
Posts Tagged ‘BPM’
I am very excited to see the SaaS based BPM offerings from Appian and Lombardi as reported by Sandy Kemsley today in her Column 2 blog. Her postings can be found here Appian also offering on-demand BPM and here Naked Process Modelling with Lombardi.
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.
When we create Product Design documents we include descriptions, requirements, test scripts, GUI mockups, and help text for each process step. We use RoboHelp conditional tags for each section, so the right information is outputted at the right time for the right audience. When we converted the RoboHelp files to MediaWiki with our RoboHelp2Wiki extension these sections become sub-headings on each article page. While we gained many benefits moving to a Wiki one important item was lost, the ability to output documentation. Printed documentation is still important for manuals, training materials, and sign-offs. Additionally, it would be very helpful to generate a hard-copy of the updated Product Design Document.
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.
On Friday, we released our RoboHelp to MediaWiki conversion tool. I thought I would provide some history on why we created it and some possible next steps.
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.