bupaverse / processanimateR

Token replay animation for process maps created with processmapR by using SVG animations (SMIL) and the htmlwidget package.
https://bupaverse.github.io/processanimateR/
Other
66 stars 11 forks source link

Show movement of separate tokens along the arrows to make bottlenecks visible? #2

Closed frkbr closed 6 years ago

frkbr commented 6 years ago

Thank you for this package! It's a great addition to the excellent bupaR package. I took a purchasing example dataset from Fluxicon to compare the two animations:

In the Disco animation the bottleneck at the activity “Analyze Request for Quotation” is more obvious. Perhaps there might be a way to show the movement of the tokens along the arrows and keep the different tokens separate from each other in processanimateR? This could make congestions visible as in the Disco animation. What do you think?

Code and dataset of my comparison: https://github.com/frkbr/Purchasing-Example.git

fmannhardt commented 6 years ago

Thanks for reproducing the problem so nicely. I am not entirely sure what Disco introduces in its animation feature. It seems that it also merges tokens that travel on top of each other to a larger token, which is a feature on my TODO list.

Looking at both animations, I think one cause that the bottleneck is not as visible in processanimateR is that the edge is rendered much shorter than in the Disco model. As mentioned in the disclaimer on the project side the non-equal edge length in process models is a drawback of these token animations. If the edge would be longer, we might see the tokens more spread out and perceive the problem as more severe. Actually, a whole set of problems associated with this and I plan to look at this in the future.

What could maybe work in this case, is to borrow the 'jitter' concept from scatterplots and randomly move tokens a bit from the actual path. Just have to figure out how to do this with the SVG animations I use.

frkbr commented 6 years ago

On the other hand, the length of the edges doesn't seem to play a major role, as can be seen in this and in this example. Bottlenecks are visible on short edges too.

In the SVG animation the tokens seem to jump from activity to activity and skip the edges. If several tokens are waiting for the next activity, they also seem to appear as one token. In the Disco animation separate tokens travel along the edges relatively slowly. Besides the merging of tokens that you described, one can also observe faster tokens overtaking slower ones on the edges.

Different vendors seem to use totally different animation algorithms, as can be seen in this example from Lana labs. The one from Disco gives an excellent visual representation of bottlenecks, but might be hard to replicate, if their algorithm is proprietary.

frkbr commented 6 years ago

I've just found this: the Disco animation seems to be an advanced version of the ProM plugin "Animate Event Log in Fuzzy Instance", which creates such animations. The co-founder of Fluxicon described an early approach in chapter 8.2 of his thesis.

Another animation where the tokens look more similar to the SVG-animation is produced by the ProM plugin "Mine with Inductive Visual Miner", which creates such animations.

Applying these two ProM plugins to the same data set creates the following results:

Fuzzy Miner animation:

fuzzy miner animation

Inductive Miner animation:

inductive miner animation

Maybe these could be combined or integrated somehow with the SVG-animation?

fmannhardt commented 6 years ago

This is going to take some more time.

fmannhardt commented 6 years ago

I have just added an 'animation_jitter' option to the animate_process call, which separates the tokens a bit. Another option available now is to reduce the token_opacity to see through tokens, which might help to see congestion better.

image

Replicating the approach of Fluxicon's Disco is not as simple since this library uses declarative animations with SVG SMIL. So I cannot simply plug-in to the rendering loop to do stuff like token merging. An interesting option would be pre-clustering the tokens according to their timestamps. If someone wants to give it a try or has an algorithm, please let me know.

frkbr commented 6 years ago

Your image above looks good, but I'm not able to replicate your visualization of the congestion. What value did you use for jitter?

When I try this with v 0.2.0 and jitter = 10:

Log %>% animate_process(token_color = "orange",animation_jitter = 10, rankdir = "TB")

... I get this result which looks different from yours: http://rpubs.com/frkbr/421046

Despite the jitter, my tokens seem to stick with the activity "Amend Request for Quotation Requester". When I use higher jitter values, the jitter seems to separate the tokens vertically, but not horizontally.

Could there be something wrong with my setup?

fmannhardt commented 6 years ago

I just tried again and it worked without problem. The separation should follow the shape of the edge and occur orthogonal to the edge. However, I also tried with Firefox and Internet Explorer and found that it is very slow and seems to not render the tokens correctly. Did you use one of these browsers?

I will investigate in a separate issue.

frkbr commented 6 years ago

You're right, the browser is the problem. I used Safari. When running the animation in Chrome, it looks just like your image. I think I'll ditch Safari, it's not the first time that this browser causes trouble. Thanks for the hint.

fmannhardt commented 6 years ago

Closing this issue and will continue the bug fixing in #7