Design for non-ideal UI states

sadielbartholomew commented 5 years ago

Issue #87 covers design in the case where the full Cylc-to-UI system is working seamlessly or ':+1:' (ample standard workflow data exists & is coming through to the UI without any noticeable delay). But we should also capture & discuss what we want the UI to show for states where there is not true, which will undoubtedly occur & can be designed with the aim to inform & guide users in each case.

I think a separate Issue is best for this, as #87 already records a lot regarding the "ideal" path.

There are three main "off-the-ideal" umbrella cases (& they are summarised nicely in e.g. this UX blog post) & in our context, I anticipate they could emerge as follow:

the empty state: when there are...
- no suites to show in the gscan-like sidebar;
- no tasks left to show (the suite finished running, etc.) for a suite being viewed under any UI View component (e.g. the Tree);
- no results for some user input e.g. a search or filter query;
- no views in the main display component area.
the loading state: for any component, where key things to aim for are:
- providing feedback so the user knows the component is loading & how much progress has been made towards it being fully-loaded;
- in appropriate cases, progressively rendering the component (c.f. 'skeleton screens' & 'lazy loading' in the UX sphere, with a nice summary post here).
the failed/error state: some client or server problem that means that:
- the whole page can't display & we get a bad HTTP response code such as a 404, e.g. when a URL is typed manually incorrectly or in rare cases where the whole UI is down;
- the data is not getting through for whatever reason (see also #103), meaning a component can't be populated initially or update at some point thereafter.

For each case above, we should try to put some consideration into the following aspects, at least:

what, if any, message to display to indicate the cause & resolution to the non-ideal state (e.g. "You currently have no running suites. Start up any suite with cylc run & it will appear here.")
what the UI component will look like otherwise, e.g. greyed out, blurred, displaying some image or symbol as an indicator?

Please add thoughts &/or sketches on this topic here, or discuss on Riot & we can summarise here as appropriate.

sadielbartholomew commented 5 years ago

I'll kick this off with one suggestion! (It includes a question, as it depends on whether this would data provision will permit this in an intrinsic way).

As we know the Graph View will take the longest to load of all the Suite Views, since it is the only one to show dependencies, & in the old (but surely less-performant) UI, gcylc, it could take ~10 seconds order of magnitude or even longer for large enough graphs.

From our Cylc 8 discussions, we are planning to implement the Graph View so that it displays only tasks within a configurable number of dependency connections from the currently selected task (see https://github.com/cylc/cylc-ui/issues/81#issuecomment-330254260).

Could we (i.e. 1. should we, & 2. would our data model allow this to be natural & efficient) have the task nodes load by increasing number of dependency connections? E.g. the task itself loads, then the tasks connected to it directly, then the tasks connected to those tasks, & so on?

That way the user can see the tasks closest along the dependency chain to the task in question they are concerned about, which is usually I imagine going to be the ones they are interested in? And perhaps they can stop the loading once they are satisfied they have a sufficiently large sub-graph to work with for their requirements?

hjoliver commented 5 years ago

Could we (i.e. 1. should we, & 2. would our data model allow this to be natural & efficient) have the task nodes load by increasing number of dependency connections? E.g. the task itself loads, then the tasks connected to it directly, then the tasks connected to those tasks, & so on?

I like that idea. If edges are paged by "level" that could work. If difficult though, as a first cut just gray out the view and display a throbber/loading animation until loaded.

sadielbartholomew commented 5 years ago

If difficult though, as a first cut just gray out the view and display a throbber/loading animation until loaded.

Yes, a more standard loading component would certainly be fine for now. There are lots of nice loading components on the Vue Awesome listing. Heck, we could even have a pac-man eat up (little representations) of tasks!

Though, I have also thought of an alternative to my own suggestion, too: if the data provision instead means that dependencies are (or could be) loaded in before full information is received on the tasks (&/or their associated jobs) included in the loaded dependency chain, we could as an intermediate state between entirely unloaded & fully loaded have a generic 'image & info' skeleton (like the one here, as a demo of this component) against displayed task nodes.

hjoliver commented 5 years ago

I like the skeleton idea too (if it proves to be feasible ... but again, it could potentially be a follow-up improvement, after initial basic functionality is implemented)

oliver-sanders commented 4 years ago

To answer the data provision questions above:

We don't really have control over the order in which nodes and edges are delivered.
The delay in rendering the graph is more to do with dagre than it is to do with the data provision.
The type of graph layout system we need (e.g. dot/dagre) cannot do incremental layouts.

So an intermediate graph rendering isn't really possible, however the n-nodes solution should protect us against large graphs. Skeletons / placeholders with spinners / throbers as suggested above are probably the only option (dagre doesn't give progress information as far as I'm aware).

I think I've captured this in #334, #332 and #329 which if accepted should be sufficient to close this. If anything is outstanding please say / raise another issue.