Top Ten List for How to Make Coach Designer Better
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.We’re partners of
- 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).
- 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.
- 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.
- 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.
- 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).
- 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)
- 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.
- 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.