Custom Visualisation

[oliver-sanders]

Supersedes #58
See the Cylc Flow counterpart - cylc/cylc-flow#3379

Open up the ability for minimal customisation of the appearance of tasks / families.

The main use case for this will be visually distinguishing between different groups of tasks (e.g. ones belonging to a particular model or system).

Now that task icons are not colour dependent we are free to use colour for this, see the design issue (#87) for more info.

This is roughly analogous to the old [visualisation] section in Cylc 7 which allowed users to specify custom Graphviz attributes.

[hjoliver]

This is roughly analogous to the old [visualisation] section in Cylc 7 which allowed users to specify custom Graphviz attributes.

Apart from my never-merged experiment for the old GUI, the [visualization] section is only used for static graphs, with no effect (except for initial family-collapse settings) on the control UI.

We still need both:

1. static visualization capability with high customizability
2. minimal customization of the task icons in the live UI views

For case 2. we should allow small badges of customizable colour, on the task icons? (Any more than that and we risk obscuring the meaning of the task icons).

[oliver-sanders]

static visualization capability with high customizability

This is something which kinda bugged me about Cylc7, you could customise the hell out of the static graph appearance but when you actually ran the suite it looked completely different.

I would prefer to only support minimal customisation for both but develop more advanced grouping and representation systems for the future built around sub-workflows, parametrisations and logical task groupings without the need for manual configuration.

[hjoliver]

Huh, I see the two use cases as very different:

• in the control-and-monitoring view:

  1. task (and job) states are primary and we can't let other styling interfere with that
  2. you don't (necessarily) have to see the entire workflow
  3. (but some additional styling would be useful to distinguish groups of related tasks)

• in static visualization

  1. the primary purpose is to understand to the structure of the workflow
  2. you do have to (at least be able to) show the entire workflow
  3. "impressive" styling is important for presentations and managers etc., but is highly subjective (hence customizability needed)
  4. (there are no task states to represent, which frees up styling a lot)

I do agree about advanced grouping and sub-workflows etc., but I think that's orthogonal to the kind of styling I'm talking about.

The kind of thing that is nice for presentations and impressing managers, but useless for a control UI:

[oliver-sanders]

the primary purpose is to understand to the structure of the workflow

I kinda feel that this is just as important for monitoring / control, the aborted PR cylc/cylc-flow#1932 shows the desire for uniformity between the two.

Rainbow suites are admit-ably kinda cool, but I don't think they do the best job of conveying structure. Using your above example, collapsing parameterisations would make it much clearer.

[hjoliver]

I totally agree that we should have the kinds of grouping you've illustrated above. (Something else to think about for the graph view @MartinRyan !) There may still be a good case for arbitrarily customizable styling of static graphs though - e.g. to highlight sections of a workflow during presentations, or just to make your workflows look as impressive and sophisticated as possible. However, we can worry about that later.

[hjoliver]

A better example of how I've found static graph styling to be useful, from our CiSE paper:

(Shape distinguishes groups of related tasks, and colour distinguishes the different "runs").

[hjoliver]

Might be useful for graph collapse?: https://github.com/iVis-at-Bilkent/cytoscape.js-expand-collapse

(From #74 (comment))