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.