Human Interactions: Task List UIs Requirements

Most of the times the Front Ends Applications which are built on top of Process Engines contains a fair amount of screens/components dedicated to deal with Human Interactions. On this post the requirements to build these panels will be dissected to define which bits are important. The main idea behind this analysis is to be able to evolve the current state of art of the Human Interactions screens/components to the next level.

State of the Art

Nowadays most of the BPM Suites offers the following set of screens:

  • Inbox  – (Personal) Task Lists
  • Task Creation
    • Task Details
    • Sub Tasks
    • Task Help
    • Task Content
  • Task Forms
  • Group Task Lists
  • Identity related screens

Let’s dive into each of these categories in order to understand in details what is required in each of them:

Inbox a.k.a. Personal Task List

This is the main screen for a User to interact. This screen will contain a list or a data grid which will display all the pending tasks for the currently logged in user. The following image describe in detail the key bits:

Personal Task List (Inbox)

This screen is usually compared with the Inbox folder of any Email Client application where per each mail we have a row and in order to see the content of the email we need to drill down into each item.

It is not necessary to explain each button and piece of information that is being displayed in the previous picture but for the sake of this analysis we can divide the features into two big groups:

Basic Features

A set of Basic Features can be quickly coded based on the mechanisms provided by the Engine:

  1. All the pending tasks for the user
  2. Generic data about those tasks (Columns)
  3. A set of actions to interact with each task (also bulk actions as displayed in the image)

All these features will represent the basic pieces that needs to be provided by the, but on top of those bits a set of user customizations needs to be allowed by the tool.

Domain Specific & Usability Features

In order to adopt a Generic Task List interface most of the companies requires a high degree of customization on top of the basic set of features provided by the tools. Most of these customizations are domain specific and are extremely difficult to provide in a generic way. But what we can provide, as tools designers, is several layers of flexibility to allow each company to modify and adapt the generic tooling to their needs.

Specifically for Task Lists these custom features can be:

  1. Filter/Search by generic and domain specific data inside or related with the tasks
  2. Define Labels and Label Tasks
  3. Define different perspectives to display the same information. For example: Number of Columns to Display, Default Sorting, etc
  4. User defined graphical annotation and comments,
  5. User defined timers and alerts
  6. Find other users associated with each task and use different communication channels to get things done, etc
  7. User defined Meta-Data for future analysis

I can list a very extensive list of features that can be added, but we need to be careful and be focused on the features that will make our task lists/inbox usable and not more difficult to use.

So there is an extra factor that we need to consider, and that factor is how the end users want interact with our software. The cruel reality is that there is no single answer, we need to provide an infrastructural framework flexible enough to allow each user to customize his/her experience in front of the software. Each user will need to be able to add or limit the set of features that they want to use. The company need to know that if there is a feature missing, the learning curve to add it is almost none and the developers needs to be comfortable with how these additions or removals are done.

 Task Creation & Task Details

If we do a similar analysis for the screens intended to allow the user to create a new task or to modify an existing task we will start finding a lot of repeated requirements.

The following figure shows a set of screens that are usually involved in the Task Creation and Task Details Edition process:

Task Creation + Task Details

The previous figure shows a very simple and fluid mechanism to quickly create new Tasks.

In order to create a task we just need a name and all the rest of the properties will be defaulted based on global or the user configurations.

If we want to edit the task basic properties we will have a different panel with the most common things that the user will want to change, like for example: Due Date, Priority and Assignment.

Advanced Details

More advanced options can be displayed separately and only if the User wants to see them:

Advanced Task Details

Sub Tasking strategies, Deadlines and Escalation Options can be shown if they are needed. There are cases when these advanced behaviors are not required, and for that reason they should be all optional at the UI level.

Sub Tasks

If Sub Task are allowed by Default a separate panel embedded in the Task Details view can be added to allow the quick creation of subtasks that are related with a specific parent Task.

Adding Sub Tasks

Once the Sub Task are created, they can be edited via the normal panels, which will probably add the reference to the parent Task and some bits of extra information (like for example the parent task name and assignee for reference).

Task Help

Something that we usually leave to the end is the Help feature. As you can see in the following figure, with a very simple panel we can write a set of localized help texts which will guide to the person that needs to work in such task. For simple Tasks, the help can be avoided, but for more complex tasks, such as legal, medical, government tasks which usually contains CODEs and regulations this can be very useful.

Task Contextual Help

Task Content

One very important aspect of every task is the information that the task will handle and how this information will be exposed to the user and how the UI will gather the required input from the user.

For this reason we will need a way to define the Task Input Data and The Task Output data.

Defining Task Content

The Task Inputs represent all the information that will be displayed and is required by the user in order work on the task. The Task Ouputs are the data that the user must enter in order to complete the particular task.

As extension points we can also add a set of Completion Rules that will need to be validated in order to automatically decide if all the data is coherent and the task can be successfully completed or if the user will be pushed to add more or modify the current information.

In the same way we can define a simple mechanism to define which actions will be available for each specific task. Creating a set of Default set of actions the user just can select between different groups of standard actions that will be rendered inside the Task Form.

Most of the time, if our task is in the context of a Business Process, the Task Inputs and Task Outputs can be inferred by the process data mappings specification around the Task.

Task Inputs and Outputs can also be defined by using a Form Builder which can aggregate information from different places and allows us to have a more flexible way of defining the information that will be handled by the task. A mixed approach is also valid.

It’s important to understand that Task Inputs and Outputs are vital to handle complex tasks that are in some way standard to the company and are executed multiple times. For a simple TODO task, which will merely serve as a reminder to ourselves, we can avoid adding such complexity. The idea of Inputs and Outputs also make more sense when we are creating a Task that will be executed by a different person who doesn’t fully understand the goal of the task. Specifying the Inputs and Outputs we will be formalizing the task expected results as well as the required information needed to do the expected work.

Task Forms

The final goal of Task Lists and all the previously introduced panels is to help and guide the users to do their work. In order to do the work, the users needs to interact with we usually as a Task Form. The most simplistic and generic representation of a Task Form can be the one shown in the following figure:

Generic Task Form Structure

There are no limitation on how the Task Form needs to look like, but it will usually contain the information displayed in the previous figure. Most of the information that will be displayed is based on the Task information that we have stored and the graphical arrangement of components that we can do using  Form Builder tool. No matter the technique that we use, it’s important to highlight that there is no good or bad way of structuring the information. We can say that we did a good job if the user who is interacting with the task:

  1. Have all the information required to work
  2. Is not delayed by the tool
  3. Doesn’t feel that there are too many options that are not used in the normal course of actions

Group Task Lists

As you may know most of the Task Lists systems also provide the possibility of showing in a separate list all the tasks assigned to the groups were a certain user belongs. The tasks displayed in this list are not assigned to any person in particular, but they can be claimed. So, let’s say that you don’t have any task to do today, you can go to the Group Tasks list and claim a task from there. Once you claim the task, the task is automatically assigned to you and no one else can work on it. For this specific kind of tasks you will have a specific Task Action to release it if you can no longer work on it. As soon as you release the task, the task is placed again into the group tasks and anyone inside that group can claim it.

Group Task Lists

There are sometimes when we will want to display both lists in the same screen which make total sense if the user wants to have a quick overview about the overall work load related to him/her.

Identity Related Screens

All the identity information is usually handled by a separate component and it is usually central to the company. From the UI Perspective is important to have a set of simple tools which allows us to query the company directory and relate a User to a Task or query for Groups to be able to assign a Task.

Identity Utility

One important thing here is to notice that this panel depends on the underlaying technology used to contain the Identity information. If your company uses Active Directory or LDAP or a Database this component will need to be adapted to connect to your Identity Directory and consume data from it. There is no single generic solution that fits all the environments.

Get Involved

If you think that all the features described here are important, or if you are planning to adopt a solution like the one described in this post please get involved and share your thoughts and extra requirements that you may need. I will start sharing my personal experiments on the basic components exposed in this post. This is a very good opportunity to join forces and help in the creation of these components. If you wanna help and learn in the process please write a comment here or contact me via the public jBPM5 channels. The more requirements that we can gather, more re-usable will be the end results.

Summary

This post cover what I believe are the most important bits that every Task Lists Oriented Software should provide. I’m not saying that these features are enough but this post will serve as the starting point for more advanced mechanisms to improve how the work is being done. I’ve intentionally left out of this post two important topics: the Form Builder and Task Statistics and Reporting. Both topics will be covered in future posts. Now that you reach the end of the post please read again the “Get Involved” section and drop us a line with your comments/suggestions.

Advertisements

17 thoughts on “Human Interactions: Task List UIs Requirements”

  1. Hi salaby,
    I am a Middleware SA North America working particularly more on JBPM POC for NA customers.I have been working with several financial customer and got lot enhancement and customer expectation on human task UI functionality. Most of the customers expecting , user management UI where admin should able to manage user task. Example , create and assign new user to the exiting task, remove user from existing task. Example, I will prepare in detail document and send it you. I would like to contribute this one. What framework are you going use for building this UI?

    Like

    1. Hi Jey,
      That will rock! If you can share those requirements we can take a look and see which ones are generic enough to include or provide them as extensions.
      I’ve already have a set of experiments working with GWT. I will try to share a video about what I have in the next couple of weeks, so feel free to send me the functional requirements and we can see what I have working until then.

      About the Admin MGMT UI it shouldn’t be difficult to add with the already proposed panels, it’s just about the Roles and how the task details can be modified to achieve your desired behavior. I’m really interested to understand how you are providing such functionality to see if we can include that as well.

      Cheers

      Like

  2. Hi Salaboy,

    Are we planig to move into differnt UI framework other than GWT. Most of the customer don’t like GWT. Reason most of the business users/developers are experience with more fancy UI like accordian styles and other styles using jquery/json flexibility. I don’t have that much experience in GWT to comment. Anyway, I will prepare the usecase for the human task and send it you ver soon.

    Like

    1. Let’s stay technology agnostic and let’s try to define as much as we can the functional requirements. Then how each company prefer to implement it is a different matter.
      GWT offers a componentized model to develop software which I believe that is good for this kind of developments. Usually business people doesn’t care about the technology they just want something that works.
      I will really appreciate the use case document or any other comments around the use cases.

      Cheers

      Like

  3. Hi Salaboy,

    In some implementations, I had to prepare a Task List so users could follow Process Instances in which they had participated (similar to what you define as Group Task List, but with former tasks).

    In there, the users wanted to check the current status of the instances, even if they weren’t abled to take them.

    The problem arises when the Process trascends a Unit of Business, or a Company, and the user belongs to the “outside”. i.e., User A is a client and creates a request, and now user B (inside the company) is checking some legal data. If the company does not want to reveal the details of the inner process, we need to show “wrapped” information in the task list.

    The content of that folder, then, should be flexibly customized for each role.

    Regards,
    Roger

    Like

    1. Hi Roger,
      Interesting comments. I will keep them in mind for my next post that will go out next week. For this conversation I was trying to be focused on the Tasks trying to not mention processes, or the Task Creator (Task Parent from the WS-HT specification). I understand that this information needs to be displayed and I will add it.

      If we talk about process which involves different parties we should probably talk about Collaboration Diagrams from the BPMN2 spec. I will keep that in mind as well.

      Like

    1. Hi Cristiano,
      The tool is called Balsamiq, and I think that you can use it in jira.jboss.org to create mock ups for the issues.
      If not you can download it from their web. It’s based on Adobe Air.
      Cheers

      Like

  4. Very interesting posts and nicely written so thanks for writing this up and also for requesting comments.

    In your previous posts on human tasks, the end user who will use this was very clear – i.e., only one end user.
    Here, I think it would be better if the UIs are designed specifically for the end user. i.e., specific one for each of this role.
    • person who creates the assets
    • person who apmanages it – who takes care of packaging / administration
    • Person who needs the assets runtime view

    If these UIs are based on the end user who will use it, I think it would be more beneficial.

    Regards,
    Ana

    Like

    1. Hi Ana,
      Thank you very much for your comment. The main intention of the post was to get this kind of feedback.
      About your bullet points to improve the UIs, The idea of this post was to create a set of screens for the End Users that works on the Runtime Views. Human Task Lists and Tasks Forms/Details are for End Users. Asset creations like for example Rules or Process Authoring are a different thing as you mention, but for that reason those weren’t excluded from this posts. The same for the Management/Deployment roles.
      Do you have any other feedback regarding only to the End Users screens? what we should provide in order to deliver a single place for the end users to work on their daily tasks? What we must include besides from the specified in this post?

      Cheers

      Like

  5. Hola

    Genial la información, y me surge una duda.

    En mi proyecto tengo embebido jBPM5.3-Final y el servidor de Human-Task como servicio conectandome a él a traves de HornetQ, en terminos generales tengo una tabla propia de mi negocio en DB, cada uno de los registros de ésta tabla va relacionado con una Human-Task, el problema que tengo es que cuando muestro la lista de las Human-Task de un usuario tengo que hacer lo siguiente:

    * Buscar en mi tabla propia los items que le corresponden a mi usuario.
    * Obtener la lista de Human-Task que le corresponden a el mismo usuario.
    * Iterar para cada uno de los items la lista de las Human-Task hasta encontrar en los comentarios del Human-Task el id del item en turno(Cuando se crea la Human-Task le paso el id del item como comentario).

    Esto obviamente es un problema, ya que el sistema esta creciendo exponencialmente y las Human-Task estan creciendo demasiado, lo cual disminuye el performance. En si lo que necesito es el id de la tarea relacionada a mi Item para poder reclamarla y cerrarla.

    Que me puedes recomendar hacer en este caso? Pintar la informacion directo de la Human-Task en lugar del Item no es opcion, ya que la pantalla me exige mostrar muchisima mas informacion que con la que cuento en los comentarios de la Human-Task.

    Saludos y gracias de antemano.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s