Allow for a more flexible Editor User Interface

Description of the limitation and why it is relevant to address

As a developer I want to have more freedom to arrange input parameters and views so that I can design the best user experience for a given use case.

I think this is relevant for the VIKTOR platform because:

  • in a single view you have more information, reducing friction that was there because of clicking
  • it makes many apps more user-friendly, where users not always realising that there are more results behind certain tabs.
  • this results in less instructions
  • less manual iterations if information is divided between views
  • enhances decision-making
  • and… maybe most importantly… it will make developers happier, knowing there is more flexibility and freedom.

Submitter proposed design (optional)

VIKTOR’s design currently assumes a panel on the left for input parameters and buttons (defined in the Parametrization class), and the right for views (defined in the Controller class). The new design should either consider making the existing panels adjustable/configurable, or to add panels within the existing design (from a definition perspective I prefer the latter).

Taking the latter case, an idea would be to have something like a ViewField, where the developer can embed a view on the left-hand side. The right could have something similar, with for example a MultiView decorator, where the user can then configure multiple views as columns and rows, similarly as to how plotting packages handle subplots.

This design solves a lot of the requests that are there related to get more views on one page, but does not yet resolve requests such as have input fields divided in sections that represent columns (multiple panels next to one another) on a page. I leave it up to the comments section for ideas.

Here is an example of how the code could look like:

class Parametrization(vkt.Parametrization):
    length = vkt.NumberField("Cube Length")
    width = vkt.NumberField("Cube width")
    height = vkt.NumberField("Cube Height")
    number_cubes = vkt.NumberField("Number of cubes")
    view_field = vkt.ViewField(view="get_plot_view", flex=100)


class Controller(vkt.Controller):
    parametrization = Parametrization

    def get_plot_view(self, params, **kwargs):
        ...
        return vkt.PlotlyResult(...)

    def get_web_view(self, params, **kwargs):
        ...
        return vkt.WebResult(...)

    def get_map_view(self, params, **kwargs):
        ...
        return vkt.MapResult(...)

    def get_table_view(self, params, **kwargs):
        ...
        return vkt.TableResult(...)

    @vkt.MultiView("Label of Plot")
    def get_multi_view(self, params, **kwargs):
        subview_grid = vkt.MultiViewGrid(rows=2, columns=2, ...)
        subview_grid.add_view(self.get_plot_view(params), row=0, col=0)
        subview_grid.add_view(self.get_map_view(params), row=0, col=1)
        subview_grid.add_view(self.get_table_view(params), row=1, col=[0, 1]) 
        return vkt.MultiResult(subview_grid)

And the result:

Current workarounds

None

I really like this!

I can imagine quite some use-cases develop from adding a WebView, where we can create custom, complex inputs.

Do you think that would be a possibility?

In theory that would be possible, where you would make use of the VIKTOR JavaScript SDK to then make a web view interactive, which then pushes the data to a hidden field or so. But I think that the setup will be complex, and most probably the interface will be slow to update (potentially).

An alternative idea was defined in this feature request, which in short is a WebField (a field as flexible as the web view):

A suggestion from @Enrique is to get inspiration from the approach that Streamlit takes with “elements”:

The flexibility, however, should not come at the cost of performance, according to @Johan_Tuls .

Nicely summarized @mslootweg :slight_smile:

What naturally complicates things is that what we consider good design isn’t suitable for everyone. If you want Viktor to be a truly versatile product that can adapt to a broad audience, both beginners and experienced users, then you’ll have to take steps toward the ‘elements’ approach of Streamlit.

Beginners can simply use the interface that Viktor offers out-of-the-box (parameters on the left, output on the right) and experienced users who want to design a tailored solution can use the Viktor elements to build their own custom interface.

Both solutions use the same Viktor API underneath.

I don’t see another solution to the problem that could satisfy everyone than this.