Top Ten List for How to Make Coach Designer Better

Scott Francis
Next Post
Previous Post
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!

Tags:

  • Pingback: Tweets that mention Process for the Enterprise » Blog Archive » Top Ten List for How to Make Coach Designer Better -- Topsy.com()

  • I don’t disagree with your top ten… but I think the long term solution is to Model the Behavior of the Coach and hook widgets into that model.

    Coaches have functional requirements that should be specified by Business folks and that should be Modeled so that everyone can “see” what the Coach does.

    Whether you go to the Server via AJAX or a Form submit – Who honestly cares? It’s what that server round trip is accomplishing that matters to the Business user.

    Once that Model-to-Widget mechanism is fleshed out, then by all means we should have pluggable widgits.

  • I don’t disagree with your top ten… but I think the long term solution is to Model the Behavior of the Coach and hook widgets into that model.

    Coaches have functional requirements that should be specified by Business folks and that should be Modeled so that everyone can “see” what the Coach does.

    Whether you go to the Server via AJAX or a Form submit – Who honestly cares? It’s what that server round trip is accomplishing that matters to the Business user.

    Once that Model-to-Widget mechanism is fleshed out, then by all means we should have pluggable widgits.

  • John –

    Agreed – and apologies, but that point got lost in the weeds in bullet #3 above :) I’m not convinced that the same model-to-widget mechanism will work for all the interaction styles , but let’s assume that was the case, i definitely want that mechanism to handle asynchronous communication (Ajax-style).

    And actually, in this case, you do care if it is AJAX or Form Submit – because in the former the user is still interacting with the screen while server interaction is happening, and server interactions are not modeled on the server. in the latter (form submit) the user has to surrender control while the form is submitted, wait for a response, and then act… and the actions the UI takes after form submit are already modeled in the activity / service modeler.

  • John –

    Agreed – and apologies, but that point got lost in the weeds in bullet #3 above :) I’m not convinced that the same model-to-widget mechanism will work for all the interaction styles , but let’s assume that was the case, i definitely want that mechanism to handle asynchronous communication (Ajax-style).

    And actually, in this case, you do care if it is AJAX or Form Submit – because in the former the user is still interacting with the screen while server interaction is happening, and server interactions are not modeled on the server. in the latter (form submit) the user has to surrender control while the form is submitted, wait for a response, and then act… and the actions the UI takes after form submit are already modeled in the activity / service modeler.