Page History

Intro

This concept is meant to illustrate what is needed in technical terms in order to implement the new new UX Pulse concept with particular reference to the workflow. The concept is about the UI implementation only, leaving aside the problem of how the workflow will provide the necessary data to Pulse, which will be the topic of a separate concept.

Problem

As of now, work items ( or tasks as we will call them from now on (work item is very jBPM specific) are treated like any informational Pulse message (i.e. errors, warnings) and there's no way to know what the status of a given item is, unless one tries to perform an action on it. What's worse, one can delete a work item without handling it, which might basically break the workflow, leaving a process pending forever, unless some other user in the same group the task has been assigned to, takes it over. 

The UX concept puts special emphasis on the handling of workflow itemstasks, how to display their current state (i.e. who's in charge, whether is has been already handled or not, what the outcome was, etc.), how to perform the necessary actions so that each workflow process can be successfully carried through. It also worth mentioning that, as specified in the UX concept "The user does not see the entire work flow and its current state in Pulse - there's actually a separate app for that".

Message inlay

This is probably the main novelty from a UX perspective. Messages (not only workflow items) will be displayed as inlays partially covering the messages list as illustrated by the mockup below

 Image Removed

This differs from the current way of displaying a separate message detail view.

Features

• it still has to be configurable as message views currently are 
• the "show more in app" button should be configurable as well, pointing to a suited app, in this case a workflow app
  
  • in general, if an app is configured to open the message detail, display the button, else do not
• the other buttons are still configurable but cannot be more than two, meaning that all other actions must be handled in the app

Implementation ideas

• use openOverlayOnView in PulseMessagesPresenter.Listener.openMessage(String) or something similar allowing setting the open top position

  • e.g. shell.openOverlayOnView(messagePresenter.start(messageId), pulseView, ModalityDomain.SHELL, ModalityLevel.LIGHT);

• pulseView.setPulseView(..) is currently used to set the message detail view and could instead be used to set the pulse view for CE or EE, i.e. EE has a workitem tab for workflow which CE should not have.

Tasks inbox

Of the many new things introduced by the Pulse UX concept, it was agreed that the first thing to tackle, which would solve most of the problems currently affecting the workflow, is the new Tasks inbox. As illustrated by the mockup below, the main novelty is the sub tabs (all items, not started, ongoing, done) introducing filters displaying the status of the each task assigned to the current user or the group he or she is part of. An additional status column has been introduced too.

Image Added

• we want to be able to display tasks independent of the presence of an underlying workflow engine
  
  • i.e a one-shot task (e.g. a short translation assignment given to a particular user) for which setting up a whole workflow process would be overkill.
• we want to be able to retrieve the status of a given task
• ideally we would like the list to be updated automatically as new tasks arrive, are taken, updated or completed. 

jBPM User Task or Magnolia Task?

As the plain messages we currently use don't work well with tasks, we figured out two options

1. Using jBPM User Tasks
   
   • PRO
     
     • would be the "proper" way to implement manual tasks in jBPM (we currently fake them with a Service Task, that is a task usually performed by an automated system, which sends a message to Pulse) 
     • we'd take advantage of all the properties already available there, such as groupId, actorId, comment, etc., no need to reinvent the wheel
   • CONTRA
     
     • no clear documentation on how to integrate it - one is basically left with the source code only. TODO verify that this claim is actually true
     • what about tasks independent of a workflow engine presence?
2. Extending the Message class into a generic Task
   
   • PRO
     
     • would handle any type of task, regardless of a workflow engine presence
     • easier to persist and query, most of the job already being done by the MessageStore API
   • CONTRA
     
     • would make our workflow solution still rely on our "fake" UserTask

TODO elaborate on both options maybe with some concrete implementation proposals