Flow Diagram in Humans Services

Mikael Eriksson

March 10, 2017 at 3:38 am #3966

Hi,

I would like to know if anyone have input on disadvantages or advantages for the “SPARK way” (none or a few script tasks, most/all functionality in the coach) to do the flow in Human Services vs. the “Spiderweb way” (a lot of script tasks in the Human Services with boundary events leading to script tasks and then flowing back to the Coach. (See attachment for example).

The arguments I have heard for the spiderweb way is that some thinks that they are easier to understand (which of course is a personal opinion) while the arguments for the spark way is that it allows more reusability and encapsulation within coach views. Also from my view this is also more like the normal javascript way to develop web pages.

 

 

Tomáš Navrátil

March 14, 2017 at 12:52 am #3973

Hi,

I think that building the logic directly in Human Service diagram is easier to understand for someone who didn’t develop the application, at least to some point of complexity. On the other hand, using event-based logic inside Coaches leads to a more disciplined way of development. From my experience, it is always safer to use the Coach events for all the things except navigation, because one can never tell how many features will be added during future development. To illustrate what I mean by this, I am attaching an example of CSHS from a real application, that has all the behavior implemented using boundary events.

Regards,

Tomas

Mikael Eriksson

March 19, 2017 at 11:31 am #4023

Hi Tomas,

Thanks for your response, and for the example!  You have a point in that small CSHS might be easier to understand with the boundary events showing the flow but as your attachment show it can go overboard :). In your experience, how often does it happen that they get as complex as in the example?

 

Regards

/Mikael

 

Tomáš Navrátil

March 20, 2017 at 2:32 am #4024

Hi Mikael,

The yellow box representing Coach in diagram has in total 12 separated entry/exit points. It is usually needed to navigate in and out, so you are left with 10 of them for your custom actions. Not counting demos, I have seen three real applications, and all of them contained complex screens with several tabs. Each of the tabs usually contains at least 3 actions. It is then quite obvious that we quickly run out of connecting points. While it is true that one point can be used for multiple outgoing arrows, I wouldn’t recommend doing that, because the diagram becomes difficult to read.

Regards,

Tomas