Saturday, February 13, 2010

How I would design a forms workflow system for google wave

Yesterday, I posted a quick reply to a post on the google wave developer blog about creating a form based workflow system for google wave.  I was quite busy at the time and i think in my haste I may have been a bit brusque.    By way of making amends, here is how I would set up such a system.

A forms workflow engine needs a number of components in order to operate correctly.  In particular:

  1. A way of specifying relationships between people.  The Manager-Employee relationship is probably the most important here, but there are others too (like whom is in the HR department).
  2. A way of specifying what information is needed in the form.  What fields, how they are validated, that sort of thing.  Calculated fields would be important here.
  3. A way of specifying the workflow for the form, and working out which relationships to use and which form to use in that workflow.
  4. A way for a participant in a group to select which form he wants to fill in.  A particular person may be engaged in multiple organisations, so having a single form library to choose from isn't enough
All of this could be managed in Google Wave, but it would not be trivial.  If set up correctly, it could work quite smoothly however.  First, we need a bot that performs multiple functions, or multiple bots that co-operate to provide the functions listed above.  I think it would be more understandable for users to just have one bot, so lets use that model.  For the purposes of this discussion, I'll call it FormBot.

Next, we need a way of creating the models that are specified above.  An operator would create a wave, tag it with its function (so that the bot can tell what purpose the wave serves) and then adds FormBot to the wave.  FormBot adds a gadget to the wave which allows the operator to edit the data.

For the relationship diagram, the gadget/bot combo would be able to work out which users they were dealing with by looking at the participants of the wave.  This effectively becomes your personnel database, in lieu of having it hooked up to an LDAP server.  The gadget would then allow the operator to drop people into relationships.  The robot would detect any changes, and then suck up the information into its own database (this bit is quite important, as it is how the bot, when processing an instance of a form, will be able to find the information in needs).

The Form & Workflow models are linked together in a one-one relationship, so they can be added on another wave, this time tagged with workflowmodel.  There would be a couple of gadgets to allow the models to be edited, which are then sucked into the database again.

So finally, how does the bot process an instance of a workflow form?  A user would have an extension installed on his client which adds an entry to the "new wave" menu which would say "New Form".  This would create a new wave and add FormBot.  FormBot would check its database to see what Form Waves it has which are linked to relationship models with the user as a participant.  It would then present these as a list to the user to allow him to choose which form he wanted to fill in.  The Bot would then create the form and allow the user to edit it and progress through the workflow.  

In summary, what we've done here is create a couple of setting waves that the bot uses to configure the application, and to allow it to provide different form libraries to different groups of people.  I think its quite elegant and would work really well.  There'd be a lot of work to get it implemented though.  The gadgets to allow the editing of the models would be the key bit.  I'd love to do it but I doubt I'll find enough time to do it myself.  I did create a proof of technology some time ago, but it wasn't configurable, nor did it hook up to a proper user database.
blog comments powered by Disqus