Design

[oliver-sanders]

Coverall issue for UI:

• Drop files here?
• Put discuss in chat?
• Copy conclusions into comments on this issue?

Most up-to-date design document:

[oliver-sanders]

[kinow]

The idea of tabs is really interesting! Something to quickly switch between views. Once we have the views, we can play with a few possible combinations, like tabs, or the combobox to choose the view, etc.

[oliver-sanders]

Jupyter labs use a strange combination of tabs and panes (like the views above) which is actually surprisingly intuitive (if not the prettiest).

[oliver-sanders]

[sadielbartholomew]

Lovely mock ups! There are some great UI ideas encapsulated within them too.

Saying that, from a first look at these I will put my critical hat on. There are some potential UX issues that I foresee may be an issue based on these prototypes, though I understand they are not your vision of the exact final design.

In general, even with these simple prototypes, I get the impression the amount of information displayed in this way will be overwhelming to the user, so I have some potential ways we could avoid information overload & make certain aspects easier to pick out.

Shapes

I really like your idea of using shapes to help distinguish & segregate the concepts of tasks (circles) & jobs (squares).

However, this works best when they stand out as the only distinct filled shapes. Having triangles as icons for both the widget to click for expanding nested items (in the tree view, etc.) & as warning symbols clutters this, IMO.

I think we should ensure there are no other such filled shapes, e.g. by having the expansion symbol as a shallow v/caret style icon. As for warnings, I am not sure of a better way, & these also need to stand out, but if we could do this without using a filled shape that would be ideal. Certainly I would advise against having warnings in the location & style they appear for gscan in these prototypes, as that looks hard to distinguish at a glance from a job icon (other than by a unique orange colour, but we shouldn't rely on distinction by colour - see below).

Colour

Cylc logo

I like the minimal use of colour, allowing the important information (task & job states, task groupings) to stand out from the various other information on display. Taking this further, though, I think that the Cylc logo would be too apparent as it is, given it is irrelevant to the user, especially having those filled circles which resemble the icons for tasks.

I advise we use a grey-scale version of the logo, so it does not distract from the information users care about.

Colour as a differential

This looks great for accessibility, because only a small set of colours (five for jobs?) has been sued to convey information, certainly enough to allow us to have a colour theme with colours that contract sufficiently to be distinguished by colour blind users etc.

Saying that, it seems you are suggesting colour also to distinguish family & subgraph groupings. That seems fine in most cases, but for the high-accessibility theme perhaps we could think of an alternative to colour to indicate groupings.

Use of Space

Space is obviously at a premium for the UI, & I am conscious of the fact real task names are not nearly as nice & short as foo, bar, baz etc. Even with a smaller font for the task names, real views would look a look messier & need more space for standard task names, especially in real operational suites, etc.

We might be able to further improve use of space in the majority of use cases. Some ideas off the top of my head:

• partially wrap some text around the circles (not so much that users need to rotate their head but enough to allow a little extra text in)?
• shorten long task names in some way (trim / replace with ... at either end?)
• trim the cycle points so that they are processed & cropped (except for on hovering or similar) to the part that is not in common with other cycle points? For example, though other shorthands may work better, 20000101T00Z, 20000102T00Z, 20000103T00Z becomes 200001**01**T00Z, ...02..., ...03...?

Changes

In general, it seems logical that users will be particular interested in aspects that have recently changed, amongst the uniform "noise". I realise this is hard to capture in a static prototype, but have we considered ways to emphasise updated information? E.g. a change in task state?

[hjoliver]

Just a general comment on "the amount of information displayed in this way will be overwhelming to the user,"

If you're running a complex workflow, the fact is there is a lot of information that you need (or might need) to be aware of. If we can reduce this significantly without hiding anything important, that's great, but maybe we can't? (e.g. a gpanel like summary view, that you can click on to get more information ... but we are talking about the full UI here - what you see when you need to know everything).

[comment redacted]

[oliver-sanders]

@sadielbartholomew, some good insight, summarising into bullet points:

• Filled shapes for job/task states, empty shapes for UI elements
• Use grey-scale logo
• Accessibility for task/job icons and family grouping (partly written up pre-Melbourne)

I'll include this in the next sketch-up.

[oliver-sanders]

Comments on "Use Of Space"

partially wrap some text around the circles (not so much that users need to rotate their head but enough to allow a little extra text in)?

Bending text around paths is a big UI no-no, it becomes really hard to read and doesn't associate well.

shorten long task names in some way (trim / replace with ... at either end?)

The new graph node design makes long task names much more acceptable so I think we can get away without having to do this.

One of the big problems with doing this is you end up with shortened task names like:

• foo_bar_baz...
• foo_bar_baz...

Rather than:

• foo_bar_baz_pub1
• foo_bar_baz_pub2

Which is confusing as heck.

trim the cycle points so that they are processed & cropped

Cycle points are typically shorter than task names (and in the new design they are in a smaller font) so I don't think this is necessary.

Side-note, I think cycle points are hard to read (e.g. what month is 20000101T0000Z?). I would like to look at improving presentation, even 2000-01-01T00:00Z is an improvement.

[hjoliver]

Side-note, I think cycle points are hard to read (e.g. what month is 20000101T0000Z?). I would like to look at improving presentation, even 2000-01-01T00:00Z is an improvement.

Agreed, I've never understood why more users don't make use of our cycle point format setting to do exactly that.

[matthewrmshin]

The main problem is the colon :. The cycle point is used as part of the directory structure. The colon can interfere if the directory becomes part of the PATH environment variable (or equivalents).

[hjoliver]

Minutes can usually be ignored though, in NWP and climate - just chop 'em off.

[oliver-sanders]

Minutes can usually be ignored though, in NWP and climate - just chop 'em off.

In a lot of suites hours can be too.

We should probably advertise the cycle point format feature as I think you're right, more people should be using it.

[sadielbartholomew]

Thanks for the thoughts, @hjoliver & @oliver-sanders. You have definitely pointed out some things I had not considered in my comments! Also thanks for your very concise summary of my points, Oliver, which amused me; my default verbosity is very high 😣, thanks bearing with that in the past & the future too, as I am working on reducing it but finding it difficult (old habits die hard, as they say).

Just to clarify a bit on some aspects. Quoting @hjoliver:

If you're running a complex workflow, the fact is there is a lot of information that you need (or might need) to be aware of. If we can reduce this significantly without hiding anything important, that's great, but maybe we can't?

Good point. I do appreciate that, at least to an extent (of course you will know a lot more about use cases & quite what, & how much, information some users need, which I imagine will be scarily large & varied). But I think before I did not formulate the ultimate point I was really trying to make (sorry!). It relates a lot to your elaboration:

(e.g. a gpanel like summary view, that you can click on to get more information ... but we are talking about the full UI here - what you see when you need to know everything)

Even when a user needs to know everything, I can't imagine there would be any case where they would need to see it all at the same instance i.e. all written out on the same UI tab (& if there is, please let me know!)

The key I think is that they quickly can, & it is understood how they can, access anything from the whole (huge) superset of information they might need, when they need it, & that the standard UI tab (by default or as configured by the user to their own needs) can display a sensible & useful-enough subset of all that, plus clear means to bring up the remaining information, in a way that isn't cluttered or overwhelming.

gpanel as you mention is a really good example, it provides a very convenient overview of core information, but the further information users will need is still accessible & in an organised way, on a suite-by-suite basis.

So overall, taking this back to the mock-ups, is that in some cases we might want to consider having some information shown condensed or collapsed until the user indicates they want to know more, e.g. upon hovering over or clicking to expand. Like my suggestions for the cycle points & task names, though it seems from comments here that they are harder to condense they I anticipated. Or information could be reduced on a per-tab basis by having some items swappable, like say the job status & the cycle point for the graph view sketch. It would save space & users can then filter some of the information they want to see.

(Saying that, I appreciate that for these mock-ups, we are probably trying to show the maximal information that would be available to show at once, to cover more of the design in one sketch.)

[HO comment redacted]

Relating this to the above, as an example, weather forecast views show a lot of information, but they don't put it all up at once. The uncertainty would be there, but probably not up to begin with in the first displayed view, as probably most people wouldn't care about that aspect (wrongly, but due to conditioning).

And quoting @oliver-sanders:

Bending text around paths is a big UI no-no, it becomes really hard to read and doesn't associate well.

Roger that! I am not going to disagree with UI tried-&-tested good practice principles.

It sounds like it wasn't a good idea after all. But overall that was just an example I could think of there & then as an illustration for potential ways to utilise space more creatively. Hopefully together we might be able to come up with some sound ideas for that.

(Really interesting link, BTW)

Side-note, I think cycle points are hard to read (e.g. what month is 20000101T0000Z?). I would like to look at improving presentation, even 2000-01-01T00:00Z is an improvement.

It's not necessarily a side note; even if we don't get round to tweaking the cycle point standard format in general, we can process & display it in a more readable way for the UI.

[hjoliver]

@sadielbartholomew

Even when a user needs to know everything, I can't imagine there would be any case where they would need to see it all at the same instance i.e. all written out on the same UI tab

Fair point. So I'm certainly up for considering how best to avoid overwhelming users with too much info!

[oliver-sanders]

Latest iteration with amendments from June meeting.

design document.pdf

[kinow]

Expense reports done, pull requests and issues updated, now finally having time to sit down and enjoy looking at the PDF, compare with notes, and start planning next steps for the new layout 🎉 .

Thanks for updating it! And I liked the text under the logo with $USER @ $ENV! Much nicer than the dropbox.

[sadielbartholomew]

'Dot View' design for task-job separation

As per #127 (comment), here are some sketches to convey ideas for the design of the Dot View (#79), with the core design problem being to segregate the task and job icons in a way that is clean & readable.

This is tricky, since the Dot View is already a condensed display with a high icon density, so it would for any suite of reasonable size (read: any real-life suite) become an overwhelming & indiscernible collection of icons if we tried to include icons for all jobs per task, & the task icon naively e.g. side-by-side, in one simple table.

@oliver-sanders has kindly volunteered to convert my conveyed ideas into Inkscape mock-ups to add to our '"official" design (working) document, but since that takes a decent amount of time & effort, I want to discuss general ideas from quick rough sketches & from that narrow down these candidate designs before drawing up anything more polished & detailed.

General design proposal

Note: I am not showing nesting of tasks by family etc in these sketches. I'm treating that as a complication to address later.

Support three different displays, which can be switched/toggled between by some clear & simple means, of tasks &/or jobs against cycle point, namely displays where:

• both task & job icons are shown together (but probably just the most recent job per task, in this case);
• task icons are shown only;
• job (all those for a given task) icons are shown only.

---

Display with tasks (=T) & jobs (=J) together

Essentially this is a 3D table of cycle points against tasks against jobs, but we are naturally constrained to 2D. There are two general design schemes I have thought of here:

1. Use a simple table, showing both task & the most recent job icon together against the corresponding task name.
2. Show tasks & jobs in essentially separate tables, but in a way that makes it easy to map between the job and the task that belong to each cycle point.

Approach (1) T & J information in same row-column

(1a) T & J in consistent corners	(1b) T & J in alternating corners*	(1c) Basic side-by-side (with slight overlap?)

Approach (2) T & J information in separate "columns"

(2a) Reflected, J on different side to T	(2b) Effectively wrapping 2a around in a circle

Displays with T & J separately

The task-only display would have one icon per cycle point so is trivial design-wise, but there can be multiple jobs per task, so how do we display that? Some ideas, where each icon here would be numbered to indicate the submission order

(i) Central larger icon for most-recent J, others collect in corners	(ii) Central larger icon for most-recent J, others sit linearly (or gridded) below	(iii) Basic grid, most recent not larger than others

---

* This pattern would be clearer with more columns. The intention is that task icons & job icons separately cluster in groups of (up to) four, creating an interleaved grid that might be easier to comprehend, & could work nicely with some animated movements to toggle between the three displays.

[hjoliver]

@sadielbartholomew - I love the diagrams! Maybe at Cylc 8.5 we have a "handrawn/handwritten" theme, just like that!!!

[hjoliver]

Note: I am not showing nesting of tasks by family etc in these sketches. I'm treating that as a complication to address later.

That's fine; I expect it's not a great complication. Probably the same as for the current dot view: family collapse is just a matter of removing all family members and replacing them with a family "dot" (with group status summary styling).

[hjoliver]

Initial reactions to your design suggestions:

Approach (1) T & J information in same row-column:

• 1c is probably best because it's both compact and clear which job belongs with which task
• (1a is also clear, so long as the grid lines are clear)
• (in 1b the jobs create interesting-looking patterns, but that might just be distracting as the patterns are meaningless)

Approach (2) T & J information in separate "columns"

• I quite like 2a, but probably still not easy enough to associate task and job at a glance?
• 2b wouldn't work for bigs suites? (1000+ tasks = huge circles!)

Displays with T & J separately

• the first case (i) wouldn't work if a task has more than four jobs?
• the second (ii) is probably best, but will still require expanding table cells for tasks that have a lot of jobs (or do we restrict to 4 most recent?)

[hjoliver]

Another idea that might work for displaying all jobs in a dot view without expanding table cells for tasks with a lot of jobs: stack jobs on top of one another like this:

with most recent job on top; then if you click on the stack they expand out in some kind of an overlay?

(Actually that could work in all views; but in non-dot-views the expansion wouldn't need to be in an overlay).

[sadielbartholomew]

Nice, thanks for the thoughts @oliver-sanders. It seems like you & Hilary & myself have opinions on similar lines for the sketches which is good! I'll wait in case others want to comment, but the next step is to go ahead & agree something that you can draw up nicely on Inkscape when you have time.

But I think task and job status need to be together as they should have primary association.

Sure, I agree. For the ideas sketched for (2) I was trying to create in each case some way to map between the corresponding task & icon, but for two separate tables that is not going to be possible in a clear way, at least by means of the ideas I could come up with as drawn. So I'm happy to go with the approach of (1) unless anyone else has ideas for (2) (or a completely different approach).

1c. Kinda nice! I think removing the overlap and just having them side my side might be an improvement.

I was initially concerned that it might look too cluttered without the overlap, but because the task icons & job icons look different enough due to shape & colour (or lack of), I do not think that would be the case after drawing the sketches. But I do think I prefer the slight overlap, just to keep them tied together.

Though if we decided to stack the jobs as per Hilary's suggestion, & it seems like there's agreement to do that at least for the Dot View, it would require us to have some space between the icons, so the stacking is clear.

1d. Another idea, toggle task/job status?

Yes, I think we should do that. As I commented (but it probably got lost in the noise, sorry, there was a lot of text on that comment), I think we should support :

Support three different displays, which can be switched/toggled between by some clear & simple means, of tasks &/or jobs against cycle point, namely displays where:

• both task & job icons are shown together (but probably just the most recent job per task, in this case);
• task icons are shown only;
• job (all those for a given task) icons are shown only.

(1a) or (1b) would lend themselves nicely I think to switching between the task-&-job & task or job only views, as the table would just collapse away the relevant icon. There could be a quite seamless transition I think, at least more so than for (1c).

2b. Wow, really thinking outside the box! Literally!

😆

[oliver-sanders]

There could be a quite seamless transition I think, at least more so than for (1c).

I would have thought 1c would work really well with a toggle.

[sadielbartholomew]

I would have thought 1c would work really well with a toggle.

True, actually, it would also lend itself well to the transition. And between the task or job only cases, we could have the square deform into the circle as it loses colour (or do the opposite), something very smooth!

[oliver-sanders]

BTW I'm leaning towards 1c (though maybe not overlapping) perhaps with a toggle 1d.

[hjoliver]

representing xtriggers in the tree view

(Raised by @oliver-sanders today). We intend to represent these as special nodes in the graph view, as in the old GUI, but need to figure out how to show them effectively in the treeview - especially as retries are being re-implemented as clock xtriggers.

Ideas so far:

• an xtrigger badge on the task icon, with more info on hover-over (what about mobile?)
• expand vertically like for job icons (but without confusingly intermingling the two concepts).

[kinow]

Replied in the Riot chat, posting here too for posterity. Updated documents look great! Was reading about state charts and was going to suggest something similar but your updated document seems to be covering that already, great job!

Here are some links I have in my bookmarks to read later.

• https://sketch.systems/
• https://statecharts.github.io/
• https://xstate.js.org/viz/

[kinow]

I've pinned this issue, because I keep coming back to it, and always have to go to issues, search, scroll down, etc... now if you click on Issues in Cylc UI, it should appear at the top in a separated card.