zonia3000
commented
3 weeks ago Regarding the collapsed/opened state of the accordions, it has been defined in https://github.com/fractal-analytics-platform/fractal-web/pull/363#issuecomment-1840578396:
- Accordions containing required properties appear opened by default
So the "Normalize" accordion in the second screenshot is closed because the property is not marked as required.
As part of the work on https://github.com/fractal-analytics-platform/fractal-tasks-core/pull/738, we started seeing some limits of the customization of the interface that is built based on task manifests. It would be great to allow for finer control of manifest building as an advanced feature for developers.
This issue is to describe some examples of this and collect a wishlist of areas we'd want to expose more to developers during task building. Developed together with @lorenzocerrone .
We may come to the conclusion that sufficient documentation of how to use the Pydantic models for input is sufficient or that more customization for developers is needed. Let's collect examples here.
Example 1: Should a specific model with accordion options be shown expanded or compact when a user opens a task? This is currently controlled by whether that input is Optional, comes with a default or is required without a default. The first 2 scenarios, it's shown compact and the third option (required without default), it's shown expanded. That's a reasonable default, but a developer may want to control this more.
One of the reasons is that this gets fairly complex to figure out what the right state should be when the input model gets more complex (see the new
CellposeChannel1InputModelin Cellpose that themselves use aCellposeCustomNormalizermodel. Originally, we had a behavior where the normalize box was always expanded by default, with a pydantic class set up like:I now found a way to make it work that I think is reasonable. The model is set up as:
and the interface looks like this by default:
We could have a long debate on what the correct parts to expand are and we should have reasonable default. I generally like our default here, but it was fairly hard to set (and I'm not 100% sure yet I have the cleanest implementation for it). So we should brainstorm how we want task developers to set this.
More examples to be collected.
How we could address it?
3 options came up in discussion:
Trade-offs either way and this obviously adds complexity, so let's use this issue to collect more areas where we'd want to be able to control manifest building better and then decide which ones are worth addressing.