task status icon tweak proposal

[hjoliver]

[hjoliver]

Trying to kill two birds with one stone:

• the current "Queued" icon stands out for having a big old letter "Q" stuck in it, which in addition to being less pretty won't translate to other languages
  • (so does Expired, but that is at least rarely used)
• the "ready" state currently has no icon, and (see below) users do need to know what it means sometimes (and "queued" is actually a good description of its meaning).

rationale

• the three dots represent a queue (of dots!), and an ellipsis for the transition waiting ... submitted

• "ready" is actually a queued state - queued to the subprocess pool for job submission.

I don't agree with the suggestion that we represent "ready" as "waiting" in the UI because:

• It will look to users like something is broken if a task appears stuck as "waiting" even though its prerequisites are satisified
• users need to see if tasks are taking too long in the subprocess pool for job submission - this is the primary sign that pool size needs to be increased

Finally, representing "ready" as queued (which again, it is) is good because "queued" is generally understood to mean "waiting in line to be actioned". Whereas, "ready" is too generic a term to be useful less descriptive.

[hjoliver]

If need be we can distinguish between the two queue cases:

• queued (held back in a size-limited named internal queue)
• queued (held back in the size-limited subprocess queue for job submission)

... by attaching a badge to one icon, or using a different number or shape of dots. Or perhaps it would be enough to explain in words when the user accesses additional info about a task

[kinow]

won't translate to other languages

Oh, good point! Since we already have i18n, +1 for a graphical representation instead.

[kinow]

Sounds good to me. +1, not sure about distinguishing between types of queued... but at least UI-wise, sounds like a good idea.

[hjoliver]

Getting on a roll here...

(so does Expired, but that is at least rarely used)

("expired" is short for "clock-expired")

[sadielbartholomew]

I really like this proposal in general, especially the drive to make the icons language agnostic.

If need be we can distinguish between the two queue cases:
... by attaching a badge to one icon, or using a different number or shape of dots. Or perhaps it would be enough to explain in words...

I'm just thinking the job submission queue case is a stage approaching submission which then all being well goes to running with the progress bar, so in light of that perhaps the same "ellipsis" dot design but with a solid bar at the running-stage "zero progress" upwards-vertical position indicating that the execution is "blocked" from progressing to & within execution in the external subprocess queue? I.e. the leftmost design here (where I included some other possibilities for the different icon option too):

[hjoliver]

@sadielbartholomew - good ideas!! but my initial thoughts are:

• the vertical bar would have to be added to the submitted icon too, to make sense, but that would make submitted hard to distinguish from early execution (and besides I like the simplicity of the original submitted icon).

• dots maybe need to be horizontal to give an "ellipsis" impression? (rather than a snowman's coat buttons 🤣!)

... the job submission queue case is a stage approaching submission...

However, you've given me another idea here!

"queued" and "ready" (the current state names) are both technically queue states, but they are not actually independent. Jobs are released from internal queues (if used) to the job submission (subprocess pool) queue. So, I think this would be both simple and progressive:

[hjoliver]

(And, users can still distinguish when the sub-process pool is getting overloaded).

[kinow]

Wouldn't a combination of dots and colours be easier to distinguish perhaps? I think if you had a few tasks near to each other, telling apart 2 to 3 dots could be hard too?

[hjoliver]

Wouldn't a combination of dots and colours be easier to distinguish perhaps? I think if you had a few tasks near to each other, telling apart 2 to 3 dots could be hard too?

Well, that's a point, but:

• I meant them to be similar because they are both "queued" states, and the user doesn't normally need to care about the difference (except for rare occasions when the subprocess pool is crammed).

• the progression of dots does correctly show that the two queued states are progressive (one does follow the other)

• finally, you won't normally see "ready" (queued/proc-pool), unless the proc-pool is crammed).

[hjoliver]

On the other hand, if using internal queues that will be the most commonly seen queued state by far, so it might be nice to have 3 dots rather than 2 for that.

Which kind of supports your idea @kinow

What about 3 dots for both, but a different colour for "ready" - because that is a more critical state (too long in that state means the process pool is crammed)

[kinow]

What about 3 dots for both, but a different colour for "ready" - because that is a more critical state (too long in that state means the process pool is crammed)

Sounds good to me. And it's not too hard to change it later if we realize it didn't work well.

[hjoliver]

Whoa, back the truck up. Actually, to users, "submitted" really is a queued state - queued to the batch system. In fact they commonly think "queued" means "in the PBS queue". So, getting fully progressive here:

[hjoliver]

Now adding in @sadielbartholomew's idea 💐 :

[sadielbartholomew]

Nice thinking @hjoliver, I do like the progressive designs as they make the standard flow between states nice & clear, will have a seamless transformation in displayed image, & will lend nicer to eventual features to notify users of transitions between states (#127).

Wouldn't a combination of dots and colours be easier to distinguish perhaps? I think if you had a few tasks near to each other, telling apart 2 to 3 dots could be hard too?

I'm not keen on the idea of using colour, except perhaps the grey colour we have for the angular progress bar in the running state icon. We should, & believe it is the agreed plan from the Design Issue #87, reserve colour for job states & for family (etc.) groupings, to make those important aspects stand out amongst the wealth of other information.

[oliver-sanders]

I get the motivation and I do kinda like the 321go thing but I think the dots are getting way too confusing in an icon which is already too complex.

A couple ideas to prevent complicating the symbol:

• We could move the "queued" status to it's own icon.
  • Which you could click or hover over for more info e.g. how many tasks are ahead of me in the queue).
• We could make "waiting" tasks transparent.
  • This way it is clear when a task has met its prereqs.

[kinow]

These icons look nice @oliver-sanders ! Does it matter that the queued and held would have a similar badge (not sure how to call it?). While queued has the three bars (similar to hamburger menu icon), the held has the pause symbol I think.

[kinow]

I mean, the held (in the Task component) is like a property of the task, not really a state. Would we do the same with queued?

[oliver-sanders]

Does it matter that the queued and held would have a similar badge (not sure how to call it?)

Wan't actually proposing that particular icon just the notion of displaying the queued status separately.

Was thinking about this the other day as it would be good to provide more information than just "task is queued":

• What queue is it in?
• What is the limit on that queue?
• How many tasks are ahead of it in the queue?

Would be good to have some kind of an icon to go to for that information.

Another option might be to represent the queue similarly to an xtrigger as a prerequisite external to the suite graph.

the held (in the Task component) is like a property of the task, not really a state. Would we do the same with queued?

Mmm, we could but it only makes sense for a task to be queued in the following states:

• Waiting
• Retry (which is really just waiting + held)
• Submit-Retry (which is really just waiting + held)

[hjoliver]

Mmm, we could but it only makes sense for a task to be queued in the following states:

Ah, I don't follow you there. Waiting (for prerequisites to be satisfied) is not queued. Retry is not a queue either, it's just individual tasks waiting for a time interval to come up.

[oliver-sanders]

Mmm, we could but it only makes sense for a task to be queued in the following states:

Ah, I don't follow you there. Waiting (for prerequisites to be satisfied) is not queued. Retry is not a queue either, it's just individual tasks waiting for a time interval to come up.

I mean that a running task could never be thought of as queued. That queued is kinda a special state so it might not make sense to chip it off in the way we have done for "held".

[hjoliver]

OK let's really try to simplify the UI here. I think we can absorb the current queued, ready, and submitted states into a single new queued icon. This is perfectly logical (see below) and it would be a significant reduction in UI complexity (there are too many states!) while still allowing crucial extra information to be revealed on demand.

The thing is, under non-exceptional circumstances all that users care about is:

• task is still waiting for prereqs to be satisfied
• task has satisfied prereqs but is not running yet
• task is running
• task has succeeded or failed

Waiting is not a queued state (see above; and users need to know if prerequisites are satisfied or not), but task has satisfied prereqs but is not running yet is actually a succession of three queues: internal queues ('queued'), then subprocess queue ('ready'), then batch system queue ('submitted').

So why not just condense the three queue states in the middle into a single queued icon, with the following detail available on demand:

• I'm still in this internal queue with this size limit
• I'm now in the subprocess queue waiting to be submitted
• I've been submitted and am now in the batch system queue with this Job ID.

Exceptional states (submit-failed here) will still be signalled as now. And if the user wants to know why a task is still queued, query it to see the above detail (or simply infer that the task is in the batch queue if it has a Job ID already).

What could be simpler than that? 💥

[hjoliver]

I mean that a running task could never be thought of as queued.

OK we agree on that. But, in the context of this discussion I think you were playing a bit fast and loose with the term "waiting" there! It has never meant "waiting to run", only the much narrower "waiting for prerequisites to be satisfied".

[oliver-sanders]

I think we can absorb the current queued, ready, and submitted icons into a single new queued icon.

Good.

The thing is, under non-exceptional circumstances all that users care about

Agreed, my original idea for task icons was "inactive", "active" and "completed".

What could be simpler than that? boom

Like this?

[hjoliver]

BTW I anticipate that absorbing submitted into queued will be controversial. But think about it:

• users do commonly think of submitted jobs as "queued" in the batch system (and some therefore get confused about the current meaning of "queued" in cylc)
• why should users need to distinguish the three queued states under normal circumstances?

[hjoliver]

@oliver-sanders - missed your previous post while I was typing!

Like this?

YES - I love it! So simple.

[hjoliver]

Agreed, my original idea for task icons was "inactive", "active" and "completed".

Yes, I'd forgotten about that - sorry it took me so long to see the light 😬

[hjoliver]

I suppose we don't even have to give the UI queued/ready/submitted icon a single name (I have been calling it "queued") The three internal states can just be mapped to the same icon, in the UI code.

[hjoliver]

Agreed, my original idea for task icons was "inactive", "active" and "completed".

Yes, I'd forgotten about that - sorry it took me so long to see the light grimacing

Self-analysis: I think I was originally concerned that merging status icons like this in the UI would inevitably hide important internal distinctions that users do sometimes need to know about (e.g. what it means if tasks stay too long in the ready state - sub-process pool is maxed out). But clearly that's not necessarily the case (just query the queued/ready/submitted icon for more detail).

[oliver-sanders]

I think I was originally concerned that merging status icons like this in the UI would inevitably hide important internal distinctions that users do sometimes need to know about

Yes, I've come to similar conclusions. For me "important internal distinctions" means triggerable states.

[hjoliver]

For me "important internal distinctions" means triggerable states.

I was also concerned about that ... but of course the job status icon allows us to distinguish submitted from the other "queued" task states.

[hjoliver]

I'll close this Issue as superseded, so we don't have to re-read the laborious journey to this point.