Display/use new task metadata

[tcompa]

As of fractal-tasks-core v1.3.3 (now available) we have an example of a task package with the new metadata (authors, modality, category and tags).

We will now have to start introducing these attributes in several task views, and review how we can expose some filtering in some specific situations (notably the tasks page and the add-task-to-workflow modal).

For most of these attributes, relevant fractal-servers GET endpoints already have query parameters available (the only missing one is for tags - ref fractal-analytics-platform/fractal-server#1863). Depending on how filtering will work, we can either fix this issue backend-side, or we can re-implement all filtering in fractal-web.

[jluethi]

Looking back at my early mock-ups of this, I guess it will be simpler if we're only doing filtering, not sorting to start with. Let's make sure users can set 1 or multiple filters.
@zonia3000 do you want to draft something with this or are additional mock-ups from my side useful here?

[jluethi]

Ah, as part of that, let's also start making the task info more accessible! e.g. having a way for users to be able to see the Docs Info section directly on the "add a task" page

[zonia3000]

@zonia3000 do you want to draft something with this or are additional mock-ups from my side useful here?

Looking at the old mock-ups (#577 (comment)) I'm not sure about what the buttons under "Filter tasks" should do. Are that supposed to be dropdowns containing the available metadata values to filter on?

Ah, as part of that, let's also start making the task info more accessible! e.g. having a way for users to be able to see the Docs Info section directly on the "add a task" page

Consider that it is not possible to open a modal inside a modal, so the possible options here are:

1. Create a task "docs info" page and the "Info" button is a link that opens that page in a new browser tab;
2. Replace the content of the modal with the docs info and add at the end a "back" button to return to the task selection.

[jluethi]

I'm not sure about what the buttons under "Filter tasks" should do. Are that supposed to be dropdowns containing the available metadata values to filter on?

I think that would work.

Consider that it is not possible to open a modal inside a modal, so the possible options here are:

1. Create a task "docs info" page and the "Info" button is a link that opens that page in a new browser tab;
2. Replace the content of the modal with the docs info and add at the end a "back" button to return to the task selection.

Hmm, I had not thought about that. The design goal is to give people more context about what tasks do. Task titles are only somewhat descriptive. Could we do a similar thing as the (i) buttons on the workflow page? Or those these hover overlays also count as another modal?
The more we send people away to other pages, the trickier this flow will be.

[zonia3000]

Could we do a similar thing as the (i) buttons on the workflow page? Or those these hover overlays also count as another modal?

Yes, we can do that with popovers, but the content shouldn't be very long, as scrollbars inside popovers don't look very nice.

[jluethi]

Yes, we can do that with popovers, but the content shouldn't be very long, as scrollbars inside popovers don't look very nice.

Let's start with that then. We can also decide a max length we show and only show the first X characters. The rest is on the info page.

I think that may be a useful pattern to encourage anyway. In that way, we encourage task developers to have short info summaries.

Some tasks-side updates we should do:

• We'll certainly have to update some of our tasks to have more relevant & shorter infos
• We'll have to think more about what the task info of compound tasks should be (maybe that can be provided in the task list and is only taken from docstrings if nothing is provided there?)
• Depending on how this develops, we can consider exposing a short info vs. long info. Short info shown on popover, long info shown in the task on the workflow page in the info panel.

[jluethi]

Another thing we should add filters for is task input_types. Not many tasks have them, but they are very useful when they exist.

And it raises: Sometimes I want to filter for "not X", e.g. task does not require is_3D = True

[zonia3000]

Maybe we need to think about a different UI, especially if we plan to add things like "not X".

I'm trying to add all the filters and they already use a lot of space, making values inside dropdowns already truncated. I'm adding the slim-select menus with search inputs, but let me know if searching inside the filters is not needed, as plain select elements are easier to manage.

Maybe, if we just need the "not X" for input types, we can implement it with a checkbox and a select inside a bootstrap dropdown menu:

Please note that in this case, it appears that using slim-select is not feasible, as slim-select selectors within Bootstrap dropdowns do not function properly (the container closes when the search field is opened). Generally, working with multiple nested popup elements can become quite cumbersome.

In general I would suggest a different kind of UI, for example it might be something like the following image, with a button for dynamically adding new filters in a list:

This implies using more vertical space, but I think it might be quite difficult to concentrate all these functionalities in the same line.

---

Another question: should we allow the selection of multiple values for each filter? If so, using slim-select may become necessary.

---

Currently the UI loads all the tasks, so we can implement all the filtering on client side, to avoid making additional calls. This may change if we plan to have a huge number of tasks in the future and we decide to implement things like pagination in the backend.

[jluethi]

Thank you @zonia3000 !

I'd say the priority is making an easily browsable task interface here. I'd value a simple selection like this:

more highly than fancier selection modals like "not X". I'm not sure whether the different UI with the separate filters will not just be too cumbersome and make it less likely that people use the filters.
I'd be open for some multi-line configurations though

I'm adding the slim-select menus with search inputs, but let me know if searching inside the filters is not needed, as plain select elements are easier to manage.

I'd say search is quite useful.

Another question: should we allow the selection of multiple values for each filter? If so, using slim-select may become necessary.

I can imagine this will be useful, yes

[jluethi]

An additional thought: Can we add top-level search? We used to have search that just worked for task names. Currently, we have no search. If we had a good top-level search that would use both names & metadata, that may be an easy entry for many people

[jluethi]

Features we'd want for task addition page

• Search at the top: Searches through names & all metadata attributes (includes input_types)
• Simple filters: Single select, with search, slim. Included for filters (with dropdown with options): category, modality, input_type, tag, package
• (i) button with hover info for tasks (short beginning of Docs Info text, limit characters)
• Separate columns for category, modality & input_type. Author & tags remain in metadata column
• Category, modality columns have a unobtrusive color code

Out of scope for the time being (may later):

• Fancier search (accordeon, multi-options, not X)
• Showing long-form info & potential images

For other pages

New task page that is just task addition without add button

Current task page becomes "Manage Tasks"

---

Currently the UI loads all the tasks, so we can implement all the filtering on client side, to avoid making additional calls. This may change if we plan to have a huge number of tasks in the future and we decide to implement things like pagination in the backend.

We'll learn what queries are relevant and will build them backend-side once this grows enough

[zonia3000]

A first version of the tasks page with filters:

I'm currently displaying the docs_info in the popover, and some of them are quite big:

Notice that it might not be a good idea to truncate the text to a fixed size, since it contains markdown and we might break the syntax. As already discussed, it would be better to have a shorter description to be displayed in popovers.

I've also added the new tasks page:

Since here we are not inside a modal, we can open a modal to display the full docs_info data:

[zonia3000]

I've included the following library (MIT License) to generate the colors based on the text:

https://www.npmjs.com/package/color-hash

I tried also a simpler solution, but a couple of badges had very similar colors, so I decided to add the library. If we don't like the generated colors we might decide to add some hardcoded values.

[jluethi]

Oh, this looks awesome! I love it! ❤️

I like the overall color scheme, it's distinct but nothing crazy. Also, the pop-overs look great!

Notice that it might not be a good idea to truncate the text to a fixed size, since it contains markdown and we might break the syntax. As already discussed, it would be better to have a shorter description to be displayed in popovers.

Agreed, we should shorten the text. But let's just go with showing what's there for now and we can then add a feature later to provide a shorter summary in the manifest. It's useful to know that this displays alright even when not optimized.
This really highlights that showing info for both init & compute parts of compound tasks isn't very useful for most users I'd say => custom flavor text makes sense, but these docstrings are an ok fallback.

The standalone task page also looks great and great idea to use modals there to show the full-length info.