Task &/or job state transition monitoring

[sadielbartholomew]

To allow the user to keep track of any changes in task or job state (especially for those progressing from "inactive" to "active" categories of state, or having failures) so they can easily monitor the progression, i.e. dynamics, of their workflow**, I propose a minimal animation that fires any time a (desired sub-set of) task or job state changes, & that remains until the user dismisses it.

That way, a user is notified whenever a task or job transitions, but in a way that is flexible, such that any time they are not monitoring the UI (e.g. away from their desk, working in a different tab, etc.), they can return to it & know what transitions have occurred.

I have opened a WIP PR (#128 ) where I have implemented this as a Proof of Concept, using a nice pulsation animation, so you can try it out live on the current UI, to demonstrate that the notification animation can be done in a subtle but detectable (& useful) way.

My vision is that ultimately we can support configuration to enable & disable the state-transition notification animation for:

• the entire view i.e. all tasks;
• on a per-task or per-family basis (users could set it only for the tasks/families they particularly care about the state of).

Some related questions:

• Tasks may transition through a number of states, e.g. waiting -> ready -> submitted -> running, & we may want to skip certain tasks transition flows such as these if they happen quickly, but not more quickly than the UI detects them & raises the transition alert (e.g. 'ready' doesn't seem relevant to alert on in that example).

[hjoliver]

Interesting idea @sadielbartholomew - I'm keen to see how it looks.

Just to add to your speculation on what the dot view is good for - the original intent was to show in a glance, for cycling suites, how the suite is spread over multiple cycle points. In a clock-limited operational suite, for example, it gives the best view (IMO) of how catch-up is proceeding after a delay or downtime. (I suppose this gels with your point about "progression of the workflow", actually).

[hjoliver]

I think we should should show task-job separation in all views, if possible.

[sadielbartholomew]

Thanks Hilary.

I think we should should show task-job separation in all views, if possible.

I agree, for a consistent distinction.

I have ideas for how we could do that for Dot View (that aren't the way as for the plan for the nodes in Graph View i.e. to have extra separate icons to the side of the task status icon for each job, which would make the whole view in this case far too cluttered IMO) but need to do some mock-ups. I'll add those to the Design Issue #87 when I get a chance to do them, soon.

[oliver-sanders]

how the suite is spread over multiple cycle points.

And it's pretty good at doing this!

The dot view can summarise the suite's cycles in a much more condensed way than is possible in any of the other views. This is really helpful if you have a suite with a large number of max active cycle points or even just a rapidly cycling suite.

To me the niches are:

• Graph View: dependency information
• Tree View: job information
• Dot View: cycle information

A USP for Dot View

If we go down the animation route (and I think some subtle animation would be good) all views should benefit, I don't think this should be a USP for the dot view. The easiest way to handle animation will be in the Task & Job components which can react to state change.

[sadielbartholomew]

Good counter-arguments, @hjoliver & @oliver-sanders.

the original intent was to show in a glance, for cycling suites, how the suite is spread over multiple cycle points

Dot View: cycle information

Actually I (am pleased to) stand corrected on Dot View lacking a USP, as we attended some internal user groups today with a short slot to hear some feedback after a call for this in advance, & two "power" users in individual sessions expressed that they found Dot View extremely useful ("the most useful") for certain suites they personally worked with (though the emphasis was on certain ones only), based on the cycle-point focus as you both emphasised, such that they would be very unhappy if it were not included in the new UI.

(I will shortly put in a brief write-up to Cylc Admin with a summary of our notes from those sessions).

So I feel now that I was a bit harsh; Dot View is loved how it is, after all! And for the reasons you both emphasised, which is nice to hear confirmed.

I don't think this should be a USP for the dot view. The easiest way to handle animation will be in the Task & Job components which can react to state change.

Sure, I like the idea of having this as a view-agnostic feature that is tied to the task &/or job components.

[sadielbartholomew]

I am adapting the title & comment of this Issue to reflect the more general scope desired, as above.

[oliver-sanders]

I am adapting the title & comment of this Issue to reflect the more general scope desired, as above.

State change animation is covered by #109

[sadielbartholomew]

Okay, we've expanded on that here so I will just link that item into this Issue, to save us losing this discussion.