I’ve always been a vocal advocate of engaging users in process improvement and I firmly believe that direct feedback from users is one of the most import input channels for any development backlog.

We’re going to create (in IBM BPM v8.5.7) a Feedback Custom Coach View that can be included in all of your Coaches.

The core design objectives for the Feedback Custom Coach View are:

Let’s get into it...

You can get everything I have done on github. It’s a lightweight toolkit that will hopefully grow over time and include some useful stuff. It’s open for anyone to use but please do let me know if you use it.

If you’re just skimming this, you might want to jump to the Feedback custom Coach View under Core Components further down the page. Everything between here and there is all the supporting stuff.

AMD.js (github link)

Asynchronous Module Definition (AMD) will take care of efficiently and effectively loading all the javascript components that you use. Chances are that you already have something in place. I’m using the latest versions of jQuery and jQuery UI.

joyLogging.js (github link)

I have chosen to record and expose the feedback via the application logging framework and this server side Javascript adds some value on top of the basic logging API (e.g. "log.error()"). It essentially the same script that I used here.

System Service wrapper around logAction() in joyLogging.js.

AJAX Service wrapper around Log Action. This is the server-side component that our custom Coach View will send the feedback to. You can replace it with whatever suits you.

A couple of test harnesses for the custom Coach View. I would encourage you to look after your test harnesses. If they are only to be used during development then delete them when the work is done. If they are expected to live on them treat them the same as the other artefacts (e.g. ensure the documentation is good and that they are kept up to date). I generally use Tag and Tag Groups but I also like to prefix testing-based artefacts with “Test".

It’s my opinion that the BPM Developers (myself included) don’t make particularly good designers. Projects that have more than half a dozen developers should consider leveraging a dedicated designer (if you want to build something great). Here’s my attempt at an image for the custom Coach View...

Feedback (custom Coach View)

There’s nothing very interesting in the Overview Tab. I have used the image as both a Palette Icon and a Layout Image. No Boundary Events are fired and I think I prefer it without a Label.

Add the AMD.js script in Included Scripts and then create entries in AMD Dependencies.

Import the jQuery UI CSS and ensure that the Feedback text area uses the available width.

The load event handler is where all the logic lives. The script content is as follows:

I’m not completely sold on the way that openScript and closeScript work (comments and suggestions are appreciated). It probably worth highlighting the way that _context allows me to access the context object in my click event handler (which is called outside of the regular event handlers and lifecycle). I considered using data binding and shoe-horning my Ajax call into the change event handler but I think I prefer this approach.

Add the Log Feedback Ajax Service as a Configuration Service. This is what allows me to write "_context.options.LogFeedback()" in my JavaScript load event handler.

The markup is pretty simple. The only real points of note are that we assign unique IDs to the DIV that’s used to create the dialog and the TEXTAREA that’s used to input the feedback. I don’t really envisage multiple feedback coach views in a single coach but it feels like a better approach to always be explicit.

I’m hoping to make the Joy Toolkit (on Github) a Thing. My backlog currently includes: