Some feedback points on the proposal, and suggestions. NB Mostly I’m running NWP suites or rose-stem tests.
The differently-sized icons to mark most recent job is not intuitively meaningful for me. The suites I run might have multiple tasks running simultaneously, but from different triggers, and not even in the same cycle. The idea of a most-recent job doesn’t make much sense (i.e. I don’t care about that), because that isn’t much to do with priority (i.e. what I do care about).
“Succeeded” to me means “done, moving on” so I don’t find green to be a choice because it is an active/vibrant colour. Although I see you’ve toned down the vibrancy across the board in your planned colours.
It would be nice to have some visual cue that a running job is on it’s second (or subsequent) run. I hope this is what you mean by the dismissable warnings to make task failures prominent. Sometimes a job will be retrying 10 times, but I only ever catch it when it’s green (running) and don’t realise it’s failed. I use the table view usually, but the number of retries is way across the far right side and not in view.
Finally, it’s a pain when a task is held, it becomes impossible to access log files from previous tries.
2 Likes
Thanks for the feedback @srennie!
The differently-sized icons to mark most recent job is not intuitively meaningful for me… the idea of a most-recent job doesn’t make much sense…
I think, from your description, you might have misunderstood the purpose of the “job status” icons. (In which case, sorry if it wasn’t clear from the design mock-up document … this is a fairly major change that really requires a written description).
In the new UI (unlike the old) we intend to make a clear distinction between “tasks” and “jobs”. A job is a real computational process that only exists between job submission and completion, whereas a task is a workflow abstraction that (a) has virtual states like “waiting” and “queued” that don’t correspond to jobs, and (b) potentially submits multiple jobs because of automatic retries and manual or automatic retriggering. So by “most recent job” we only mean the most recent job of a particular task, not the most recent job globally within the suite. If a task has three failed runs and then success, you will see three job fail icons behind the “most recent” succeeded one, and you’ll be able to click on each one to see what happened to each individual job. Hopefully that makes sense!
Succeeded” to me means “done, moving on” so I don’t find green to be a choice …
Enough users have given us this sort of feedback that I’m pretty sure we’ll be providing an alternative color scheme to keep you happy.
It would be nice to have some visual cue that a running job is on it’s second (or subsequent) run…
So that’s exactly what the new job status icons will give you - see above!
Failure notification is actually a somewhat orthogonal issue that we are still discussing.
Finally, it’s a pain when a task is held, it becomes impossible to access log files from previous tries.
Yeah, I’ll note this down and make sure it’s not a feature of the new UI.
Hilary
Finally, it’s a pain when a task is held, it becomes impossible to access log files from previous tries.
Good news on this front:
In the new design we display all of the jobs for each task, so if you have multiple failures you will see them as red boxes. Even if the task is held you should still be able to click on any job and get access
to the job log files.
1 Like
This is something I’m currently looking at, it may require some work on the internals of Cylc to make it possible but hopefully we can put a “retry” icon next to the task to make this clear. We may potentially be able to mark a manual retry differently to an automatic one. Though this functionality may not be present in the initial release.
1 Like
Succeeded” to me means “done, moving on” so I don’t find green to be a choice …
@srennie and @Fiona_Smith - I forgot to explain the reasoning behind the new default job status color theme (running=blue; succeeded=green; failed=red):
- succeeded is really the natural counterpart of failed, so (we think) it should be styled accordingly
- in terms of the abstract workflow, succeeded and failed are just two task completion statuses that can be used for triggering subsequent tasks, but the “heritage theme” (succeeded=gray, failed=red) assumes that succeeded is the uninteresting state - which is not always the case. Sometimes tasks are actually expected to fail and the workflow needs to be designed around that.
(For similar reasons we are also reconsidering the idea of automatically keeping failed task nodes alive in the GUI until dealt with … instead we should probably allows users to specify the task expected completion status within the workflow, and just default to the typical “success expected” case).