task metadata view

[oliver-sanders]

Cylc 7

Cylc supports task metadata e.g:

[runtime]
    [[mytask]]
        [[[meta]]]
            # the standard metadata fields used by some cylc commands
            title = My Task
            url = https://...
            description = """
                Lorel ipsum ...
            """
            # you can create custom fields too
            system = xyz
            group = abc

Cylc 7 made minimal use of task metadata, namely in commands like cylc show but some metadata was also used in the GUI.

Cylc 8

Cylc 8 has greater potential here. Earlier design sketches had an info "pane", "tounge" or "panel" which was intended to show the [meta] info for the selected task (or the workflow itself as workflows also support [meta]). The GUI has moved on since then, the Lumino tab system is now the natural place for displays, I think dividing the screen beyond this would be unhelpful.

So here's my suggestion, we implement a "metadata view" (or "info" view). This view gives you a text box to type in the name of the task (we should be able to make this a combo box with all task names pre-loaded). Once you've selected a task it displays the [meta]. For convenience we can create a shortcut from the task menu which opens a new "info" view pre-initalised at the specified task. We should also consider adding the "title" field to the task menu.

Sketch

Here we have an info view showing some basic metadata. The task menu has been opened for the task "baz" on the right. The "title" has been added to the top of the menu along with an info button which is the shortcut for opening the info tab on the left.

Metadata & Formats

Some sites are already making use of the "URL" field. In [at least] one case, using HTML pages generated from markdown. We can make this much easier (rendering markdown in a web app is trivial).

• Suggest rendering [meta] items as markdown by default.

This part is more cylc-flow / cylc-rose focused but bringing it up here for context

Many tasks already have extensive documentation in the form of Rose application metadata. There is an existing Rose config to ReST generator which is used by the Rose documentation.

• Consider adding a [meta]_markup_format config to allow this to be configurable in the future?
• Or should this be a marker in the content itself e.g. #markdown, #rest, ...?
• Consider a cylc-rose plugin to drag in Rose application metadata where available.

Workflows & Documentation

Workflows can have [meta] too. We might want to add an option for viewing the workflow metadata here too (and possibly a shortcut for it in the workflow toolbar).

Cylc has documentation too! We might want to add an option view viewing it here!

Additional context

Once discussed / agreed this should be quite quick to implement.

• List of task names can be obtained by listing taskdefs (called Tasks in the schema).
• Metadata can be obtained from the taskdef.

Pull requests welcome!

[hjoliver]

Great idea. We should discuss details in the next meeting though.

[oliver-sanders]

(flagged as a question for raising at the next meeting)

[dpmatthews]

Maybe think about how we can view other task info?

• Relevant broadcasts
• Runtime config (including broadcasts)
• Dependencies

Should any of these be included in the "info" view?

[wxtim]

Should any of these be included in the "info" view?

Could the info view have config as a separate tab/window/section? Some of the runtime config can get quite chunky, especially the script settings, but websites have shown worse!

For extra brownie points why not add syntax highlighting to the script settings?

[MetRonnie]

Should the Task Info view open in a tab to the side, or in a new tab in the same panel as the view you were in? Opening to the side might not gel well with already-split panels (i.e. if you've already arrange tabs in > 1 panel)

[oliver-sanders]

Should the Task Info view open in a tab to the side, or in a new tab in the same panel as the view you were in?

The way new tabs open is down to the workflow component. The current behaviour is to open the new tab in an existing panel (but behind, I think it should go in-front but that's a different issue).

Could the info view have config as a separate tab/window/section? Some of the runtime config can get quite chunky,

This section could be collapsible.

E.G. We could show the title and description at the top and have the rest pre-collapsed.

For extra brownie points why not add syntax highlighting to the script settings?

Yeah, why not. If we are displaying the [runtime] config then we will probably want Cylc highlighting anyway.

[oliver-sanders]

Discussed in developers meeting. My takeaways (please correct if otherwise):

• We are happy with the idea of a view to show metadata.
• We are happy with this opening in a new tab but questions have been raised about how new tabs should open.
• We would like to add more generic information about the TaskDef (i.e. the full [runtime] config).
• We would like to look at adding TaskProxy information here (e.g. broadcasts [may obsolete #463], prereqs & outputs).

Suggest the following:

• Add an "Active Tasks" section listing any n=1 TaskProxy instances for the selected TaskDef.
  • These items should be collapsed by default but if the user navigated here by clicking on the info button on a task we could expand the relevant TaskProxy in this list.
  • Include within this section broadcasts, prereqs, outputs and any other TaskProxy specific info.
• Add a section for the [runtime] config.
  • This should probably be collapsed by default as it could get chunky.
  • Note we don't have this info in the schema yet so this will have to wait a little while.
  • If we are printing the whole [runtime] config here it might make sense to implement trigger-edit from within this "info" view?
• Start small, grow features slowly.
  • No need to get all of this in right from the start but good to think ahead so we leave room for expansion.
  • Suggest starting with basic task/workflow metadata and going from there.
  • With the exception of the [runtime] config I think all of the required data is already in the schema.

[hjoliver]

All good, thanks @oliver-sanders

We are happy with this opening in a new tab but questions have been raised about how new tabs should open.

I think we concluded the tab should open in the same way for all views. However, it would be good if the default (for all views) was new tab on top. Not sure if that's an option out of the box.

[oliver-sanders]

Should be easy to do, I think JupyterLab works this way so it's probably just a configuration matter - https://github.com/cylc/cylc-ui/issues/1090

[oliver-sanders]

There are two sides to this view:

1. Task Definitions (i.e. Tasks in GraphQL).
   • [meta] data.
   • Other [runtime] config.
   • Possibly average timings.
2. Task Instances (i.e. TaskProxies in GraphQL, requires a subscription).
   • Prereqs and outputs (i.e. what cylc show gives us).
   • Active broadcasts

The most critical thing is "prereqs and outputs" as it is not currently possible to see why a task is not running in cylc-ui.

Suggest starting off with just "prereqs and outputs", calling the new view "Info" and adding a link to open the info view in a new tab on the mutation menu e.g. with an (i) button e.g. http://cdn.onlinewebfonts.com/svg/img_51582.png.

Putting this on the 2.1.0 milestone for the "prereqs and outputs" bit.

[oliver-sanders]

The boilerplate is a little different from other views due to its nature so not especially obvious:

• Deltas subscription (keep this data up to date).
• Local store not global store (don't add this data into the central store where it can get into other views).
• Dummy mutation (add this to the mutation menu).

I've put together a view template that covers the cylc-ui boilerplate needed to get started on this: https://github.com/cylc/cylc-ui/compare/master...oliver-sanders:cylc-ui:metadata-view-template?expand=1

Note, I've named the view "info" rather than "metadata" (more user friendly).