Top Ten List for How to Make Coach Designer Better

  • January 21, 2010
  • Scott
  • 6 Comments

We’re partners of Lombardi, and we’re avid users of their BPM software, as it is one of our preferred tools.  And we use the coach designer all the time, but I’d like to take a moment to propose a “Top Ten” list for improvements I’d like to see in the coach designer and UI generally.  The coach designer was originally conceived to have the product better support the agile methodology of the professional services team at Lombardi – and it succeeded in that.  It makes building UIs that display, edit, and leverage process data trivial to build.  However, like any good old friend, it also has room for improvement, and as friends, we’d like to put our ideas down on paper (bytes?) for what Lombardi/IBM should consider in their roadmap for the Coach Designer.

  1. Either adopt a 3rd party standard UI framework for component-izing UI controls, or add component-building capabilities to the Coach Designer.  Presently, you can build template controls, but they aren’t first order library components (Teamworks authors will know what I’m referring to).
  2. Provide controls and control-flow for building mashup UIs.  This is already possible via a html controls in Teamworks, but too much of the code ends up inside the coach, rather than abstracted in the service layer.  Intalio’s mashup editor is one example to look at, but there are lots of others (including inside IBM), which could be leveraged. I think the key is to consider how to make this interact with the service layer in Teamworks, because the end-product to display in the UI may depend on a series of external calls rather than just one client-side javascript call-out.
  3. Ajax as a native capability.  Sure, there are a couple of controls that can be populated or pre-populated via Ajax calls to Teamworks services.  But the Ajax calls need to be modeled in a way that can be seen in the Activity/Service modeler.  The way to make really rich Ajax interfaces currently obscures a lot of what is going on in javascript code.
  4. If you look at some of the open source solutions out there- they are working to support existing forms development frameworks, rather than developing their own.  This might be the path of the future.
  5. Perhaps easy integration of GWT, YUI, etc. so that they can be first class components in the Coach Designer.  After all, GWT is heavily used by blueprint, so we know Lombardi has the in-house talent on the toolkit to put it to work.
  6. Access to tasks should be opened up considerably – available via RSS feed, or via twitter. SMS text to my phone.  Give me options.  No more notification-by-email or go-to-the-browser-page.
  7. The process instance could be viewed more as a stateful webservice, which I can manipulate through web services calls even more than I can today through the external activity interface.  These external mechanisms of advancing the process should interact seamlessly with internal mechanisms (for example, if I push a close-activity event from a webservice, it shouldn’t require the model to be different than if a user closed that activity from a Teamworks Coach – and I should be able to force the process to soak up the outputs from the active activity rather than ignore them).
  8. Break the portal up into component pieces that are accessible as UI fragments or as webservices.  But don’t just replicate the exact portal functionality for each of those pieces – because some of that functionality really doesn’t make sense once you separate from the portal at large.  Really think about the API someone would want, not just the API required to support the portal/coach functionality today – there is a gap there. (technically the portal isn’t a coach… but maybe it should be)
  9. Make it easier to skin the Coach Designer with whatever look and feel makes sense.  Currently its easy to change color scheme, but not very easy to change structure and size of elements, etc.
  10. Keep investing.  If you make the right investments, you can get a multiplier effect – meaning, the investment will give process authors more power over the UI, at less development and maintenance cost, to the development team.  If you make the wrong investments, coach designer will become a closed system incapable of building the right kinds of UI the processes require.  But no investment could be worst of all – as no investment in the Coach Designer could mean that customers and consultants abandon it altogether as the cost of building UI’s outside of Teamworks continues to decline as the tech improves.  The right investments will let Teamworks ride on the coattails of these outside technologies at minimal cost.

I’m sure other people have their own ideas.  And I could write a similar list for other products.  Maybe at bpmCamp next week other attendees will have better ideas than mine for their top ten!  Welcome your top-ten comments below!

Related Posts
  • November 15, 2018
  • Joe
  • 0 Comments

Editor's Note: This is a series devoted to the migrations from the IBM Digital Process Automation eclipse base...

  • November 8, 2018
  • Larry
  • 0 Comments

[Editor’s note: This guest post is the ninth in a series from Larry Taber, BP3’s Digital Strategy Officer ...

  • November 6, 2018
  • Joe
  • 0 Comments

Editor's note: This is a series devoted to the migrations from the IBM Digital Process Automation eclipse base...