User Interfaces in #BPM – #bpmCamp 2010 @ Stanford session

Scott Francis
Next Post
Previous Post
We had a session on User Interfaces built on top of Teamworks at bpmCamp.  It was an interesting, technically detailed discussion – but what I took away from it were some key questions for process authors or process application developers:
  1. When should one deviate from the “stock UI builder” included in a BPMS?  Teamworks ships with a great out of the box prototyping UI builder.  It let’s you build simple interfaces extremely quickly (integrated with process data), but has some limitations when it comes to more customized look-and-feel.  But when is a departure from the standard UI worth it?
  2. Once one decides to roll a custom interface, which frameworks have the most currency?  There were people present that had worked with ExtJS and Flex, or just used Ajax to customize the Teamworks user interfaces.
  3. Why can’t access to process work be more universal?  There was a lot of discussion about the process portal, but why aren’t tasks and updates available via twitter, RSS, SMS, SalesForce, and email among other things?
  4. There was general consensus that the reporting framework should be more “open” out of the box- providing useful data for charting in a simple XML format, along with optional detailed information in an XML format, in order to make it easier to support alternate visualizations.  This approach would make it much easier to plug in different charting tools.  (Note: to that end, bp3 has built a reporting framework that supports Google Visualization (and soon Fusion charts).
  5. There was a lot of interest in using the newer REST api’s for Teamworks.
I think the key take-away for me is that BPM practitioners want it to be easier to publish process information to whatever platforms their users want to receive them.  BPM information still needs to be further democratized. The second take-away, related to the first, is that “portals” have gotten a lot less interesting.  In some environments, a portal is needed for a specific process- and only for that process.  In other environments, a portal needs to support multiple processes in one unified interface.  There’s no one right answer – as evidenced by divergent opinions at bpmCamp.  BPMS vendors either need to re-imagine the concept of the process portal, or they need to open their platforms for more innovation by embracing social media.