You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Intro

This concept is meant to illustrate what is needed in technical terms in order to implement the new Pulse 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) 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 items, 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

 

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.

 



 

 

  • No labels