In a simulation, highlighting time for transitions is too short

[RainerKlute]

In a simulation, transitions are highlighted when they are taken. However, the period of time the transition is highlighted is way too short. Sometimes the highlighting isn't visible at all, at least on Linux.

In any case, the brief highlighting period requires the user's utmost attention and might be especially challenging if many transitions are located close to each other or if the user is visually impaired.

Possible solutions might be to keep the transition highlighted for several seconds or even until the next transition is taken.

[BeckmaR]

I tried out the solution to keep the transition highlighted as long as the target state is highlighted. @tkutz and @rherrmannr agreed that it looks like the transition would still be active and it's not clear if the associated action was actually done. The change can be found on branch issue_1529 though.

Another thing to consider: I don't think the taken transition is that important. After all, if I'm in a certain state, and I know where I was before, I know which transition was taken. If that's not clear for a user they can still choose to debug the statechart and look at it in slo-mo.

[RainerKlute]

I beg to disagree. A transition always happens in an instant, at least conceptually, and thus it can never be continue to be active. That means that if a transition is highlighted, it cannot mean that it is still "active" resp. that it is in the process of being taken. Instead it should be obvious that the transition has completely been taken. This is even more obvious since the transition's target state is highlighted, which means it is active, which means the transition has brought us there.

Yes, agreed, if the state machine is in a specific state, perhaps the user should know where it was before and how it went where it is now. But why not help him remember, especially if he left his state machine simulation idle and comes back after a couple of hours?

Knowing where I am and knowing where I came from, however, does not necessarily tell me how I got there. I might have a few dozen transitions all from state A to B – and all of them with different reactions. So, yes, I might want to know which event caused exactly which transition to fire, which guard condition was fulfilled, and which actions were executed.

[andreasmuelder]

@terfloth please decide

[rherrmannr]

Consider a case like this: The transition would be highlighted all the time. You won't see the trigger action any more.

[BeckmaR]

@RainerKlute Wouldn't a tracing feature for the simulation be better suited to solve these problems?

[SimonEit]

I just tested this out with the most complex statechart i had in my workspace and have to agree with both sides. My suggestion for a quick and easy fix would be to experiment some measures to make the highlighting more visible, my suggestions:

• Make the color change last a tiny bit longer (my guess would be it is at something like 500ms at the moment, so change it to 750ms)

• Try to make the transition arrow a few pixels wider (i.e. bolder) while highlighted

These should provide a more noticeable highlighting in a quick&easy way.

I agree with @BeckmaR though, the introduction of a tracing feature in the simulation would be the optimal solution.

[BeckmaR]

We could make the highlighting bolder, but what we can't do is change the highlighting timing because it's not set per microsecond. It's just highlighted when it's taken and de-highlighted when the target state is reached. That's it.

[andreasmuelder]

We should prototype how it looks like with bold transitions