Functional Task UIs: Instructions, Context Information, Data Capture

When implementing a BPM solution, your first objective is to make sure that you get the Right Tasks to the Right Participants at the Right Time.  That's often easier said than done, but let's assume that we've accomplished that goal...

Now we need to start worrying about how to enable the participants to actually complete their tasks.

When a participant opens up a task, assuming that the task is meant for a human rather than a machine, we need to provide them with a user interface for completing their task and interacting with our BPM system. Implementing these UIs often consumes most of your development effort - I've had clients tell me that they spend 80% of their time on the UIs for the tasks in their process applications.  That sounds horrible, but when you dig a little deeper you'll usually find that projects as a whole are taking a lot less time than they did before - but it's still worthwhile to try to reduce the time is spent building task UIs.

 A functional task UI contains 3 categories of elements:

1. Instructions for performing the task
2. Context Information that is needed to perform the task
3. Data Capture controls for information that must be gathered

I find it very helpful to create "starter" screens for my tasks that break out each of the above categories into separate sections - folks always always dive right into developing polished UIs and skip this step, but they really shouldn't.  Build a "starter" screen as I suggest and you'll identify all the integrations that you'll need - and avoid a lot of headaches later.

Instructions:
What is the user supposed to do?
Instructions "should" be easy... but you'd be surprised.  Even after process analysis some folks are confused what a specific task really needs to do.

Many of the user interface designers that I know hate the idea of putting instructions on their screens.  Designers strive for the "Self Evident" interface where the users just intuitively know what it is that they're supposed to do when presented with a screen.  That's a fantastic goal - but I encourage you to write those instructions down even if your end goal is to build an instruction-less screen.  Even if the end user never sees those instructions, it will help all of the interested parties grasp exactly what the task is that the end user needs to accomplish... it will help you validate the requirements for the screen itself.

Note that the Instructions that we seek are those that help the user accomplish a task, not instructions on how to use a screen. I've blogged elsewhere on the advantages of User Manual Driven Development, which focuses on "how to use" - but don't fall into that trap for your Task UIs.  Focus on "What must be done" rather than on "How to use".

Context Information:
What information that is specific to the task does the user need?

This is where you'll discover all the "Read" integrations that you will need.  You can't display context information unless it's been passed to you, or you can "Read" it from somewhere.  It may take weeks to actually implement those integrations, but once you define the interface to the integration you can create a placeholder and keep on going.

Data to Capture:
What information does the screen need to gather from the user to perform the task?

This is where you'll discover all the "Write" or "Update" integrations that you will need.  The information that you capture on the screen needs to "go somewhere"... and that means you'll either pass it along or "Write" it somewhere.  As with the "Read" integrations, it may take time to build the "real thing", but you've got enough to define the interface to the integration and keep on going.


A Functional UI is way better than an Unfinished UI:
If the UI  for your task has Instructions, Context Information, and can Capture the required data, then you really ought to move on to something else.  It may not be pretty, but it's functional, and you can't deploy your solution until you have a functional UI for every task (so go work on the next one).

Confusing Business Complexity with Programming Complexity

Responses to my recent posting "Why Occasional Programmers Suck" were mostly positive, but I did get a few expected disgreements from offended "full time" programmers such as the following from Mark:

"I don't agree. What we doing is not simple. It is more than just putting parts together or drawing a diagram. I think our tooling has gotten better and has made it much easier. But Tools like VB and MS Access have done much to hurt our industry as it allows people to THINK they can program. So we end up with piles of unmaintainable code and code that can't deal with the complexity of business and the need for systems to integrate. Advancements of tooling should be to help developers develop, not end users." 

Mark misunderstood a bit what I mean by "Occasional Programmers"... It's not really the end users of business applications that need better development tools.  Developing Business Applications is an art that requires a proper mindset and many skills that you would not expect most end users to possess.Occasional Programmers are people who understand the concepts of programming.  They are folks who understand process flow, how to express rules, how to logically organize functions... but their full time jobs are something other than "writing code".


Where Mark's comment really missed the mark (pun intended) is with his tacit assumption that the "complexity of business" has much to do with the complexity of programming.

For example... I was recently working with some very experienced programmers who were completely aghast that IBM's Lombardi BPM doesn't provide support for rolling back database transactions that spawn multiple process activities.  In database programming, there is the concept of a "transaction" that spawns multiple database updates.  Many records can be "written" to the database as part of a single "transaction".  If for some reason you need to cancel the "transaction", you can roll back  (undo) all of the changes that have been made to the database.  The programmers I was working with naturally assumed that they'd be able to define database transaction boundaries in the Business Process that we were working on, to handle rolling back any changes in the event that the Business Process was canceled.

Programmers don't work on reality, they work on models of reality.  Canceling a process was, to these programmers, as simple as undoing any changes to their model.  They'd missed the fact that each process activity takes place in the real world.  People perform tasks, messages are sent, related activities and processes are started... "real" changes are made by the process.  "Rolling back" a Business Process when it's canceled has very little to do with restoring the state of a database.

The programmers building this application didn't fully understand the "business complexity" generated by canceling the Business Process in-flight.  In contrast, the Business SME on the project did know the necessary steps... and the Business SME was able to use the tools to diagram and define the necessary steps.

Here's the bottom line - programming tools intended for building Business Applications need to focus on dealing with common patterns of Business Complexity.  The underlying Business Machine worries about programming complexity... not an easy task by any means... but not the concern of the Occasional Programmers.

As an analogy, think of your car.  Your interface to your car is the steering wheel, the gas pedal, and the brake pedal.  With these three controls you are able to drive anywhere you want to (until you run out of gas). The complexity of the machine that accepts your input - what's "under the hood" - is somebody else's problem.  You just handle the complexities of driving the car.

This is what Object Oriented Design and Service Oriented Architecture is all about - providing the proper interfaces for those who build higher level (business) applications.  With the right interfaces, and the right tools, our Occasional Programmers can focus on dealing with those business complexities that Mark's worried about.