Suggestions for the optimal structuring in the metadata editor

[markusweigelt]

With an increasing number of DOM elements (structure elements and images etc.) the current concept of the gallery for structuring is not optimal. I think that needs to be rethought.

All structured elements of mets are loaded and this leads to performance problems regarding loading and editing.

First tests on my local computer have shown that it seems to start with at least 1000 images with the lack of editability. The start of the problem behavior depends on the client computer resources.

With a concrete process of approx. 1900 images divided into approx. 150 structure elements, editing is no longer possible. The problem will also occur with a smaller number of elements.

Failed solutions (in my opinion)

Rebuilding Drag and Drop

Rebuilding the drag and drop as a PoC without the drop area objects and additionally using global event listeners on the document object, creates a small improvement of the handling but not an optimal solution for processing the process to a process with a small number of dom elements in gallery panel.

Here is the PR (draft) of PoC: #5011

Lazy- and Deferred Loading

Initially, these variants will bring better performance, but there will be no advantage for editing. The more DOM elements are added by the loading, the more difficult the editing becomes.

Solution

The solution should be as far as possible independent of the number of images/pages in the process or the upper limit where the process can no longer be edited should be significantly higher.

The goal of the solution must be to reduce the number of dom elements.

Proposals

The current proposals are not a custom solution which is difficult for us to maintain, but uses as much as possible the components provided by Primeface.

All variants include that the unstructured images are separated in a separate panel.

Select single structured element

In this variant, a structural element can be selected in the structure tree and edited in the gallery panel.

Select current structured element with previous and following element

In this variant, a structural element can be selected in the structure tree and edited in the gallery panel with the previous and following element.

Select multiple structured elements

In this variant, several structural elements can be selected in the structure tree and edited in the gallery panel.

Pagination of structured elements

With this variant, a structure element can be selected in the structure tree. In the gallery, the structure element can be paginated using the pagination function. The pagination jumps to the corresponding page when the structure element in the structure tree is selected.

All kinds of suggestions are welcome to sustainably improve the behavior of the metadata editor for processes with many elements :)

[matthias-ronge]

The metadata editor is very powerful, and that seems to be its undoing. Many years ago, in the idea-gathering phase before applying for the DFG project, we once had the idea of breaking up the metadata editor into three individual sections:

• A pagination editor. Only the pagination is created in this. Maybe, comparable, for multimedia elements, adding or correcting timecodes. Metadata of images (metadata in <div>s with linked images) is edited here.
• A structuring editor. In it, the smallest sections to be described are marked (chapter / article / ... depending on the desired target granularity). Comparable, for multimedia, the marking of individual film scenes, or individual tracks on a continuously digitized side of a phonographic record. The physical structure tree is edited here. Metadata in physical <div>s without linked images (containers) is edited here.
• A hierarchy editor. In this, the previously marked areas are hierarchically structured. The logical structure tree is formed here, along with its metadata.

The concept then disappeared. I wanted to revisit it as an idea.

[solth]

If I remember correctly, one main goal of refactoring the metadata editor during the DFG project was to integrate all individual pages - pagination, structuring, metadata - of Kitodo.Production 2 into one editor. I think we should focus on finding ways to improve the performance without sacrificing this goal before resorting to reduced functionality to achieve acceptable performance.

[BartChris]

Another consideration here is - in my oppinion - that by putting all those elements on the same page, the display gets really crowded and the handling of the editor is quite cumbersome, especially on smaller screen.
If seperating out the different components in different pages is no option: What about having for example a tab based solution for switching between the different functionalities. At least switching between structuring/metadata on the one hand and pagination on the other hand. Another idea would be to reduce the amount of wasted space on top and the bottom of the screen, by hiding the Kitodo logo and the footer on demand.

[solth]

After several lengthy discussions, we came to the conclusion that the metadata editor - or at least specific parts like the gallery - needs to be refactured fundamentally to a) improve the performance while b) not restricting the existing functionality. To achieve this, we came up with two potential solutions:

1. Proposal: Virtual Scrolling in gallery

Virtual scrolling in PrimeFaces datatables (https://www.primefaces.org/primeng/#/tree/scroll) allows loading table rows on demand when they enter the viewport and removing them from the DOM when they leave the viewport, effectively solving the problem of too many elements in the DOM when editing large processes.

In order to apply this to the metadata editor of Kitodo.Production 3, the gallery has to be refactored from the current custom solution using nested panels to using a datatable instead. In this datatable each row would contain one thumbnail (or gallery stripe header) which - including their surrounding structures and event handlers - would only be inserted into the DOM when necessary. Virtual scrolling also means these thumbnails/rows would then be removed from the DOM when leaving the visible area/viewport.

This also means we need to reimplement the way synchronization between structure tree and gallery is achieved. Since datatable rows are displayed sequentially top to bottom by default, we need new CSS rules to prevent all thumbnails from being shown in a single column. Therefor the calculation of the scroll height within the datatable needs to be adjusted accordingly to those new CSS rules.

2. Proposal: Gallery tree

Instead of using a datatable for the gallery, we could also use a PrimeFaces tree component with heavily adjusted CSS to maintain the current gallery styling. Tests with large processes (> 10.000 tree nodes) show that the structure tree is loaded and then displayed nearly instantaniously when the gallery is disabled, meaning that the PrimeFaces tree structure is already very optimized for large amounts of DOM nodes.

Using trees for both panels - structure and gallery - also means synchronization between them could be simplified significantly. A single data model for both of those trees would mean custom Java methods for synchronization (updateGallery, updateStructure, updateSelection etc.) could be removed to improve update times.

One aspect of this solution that is difficult to estimate is the performance impact of displaying thumbnails in PrimeFaces tree nodes instead of icons and whether this impact would negate or at least decrease performance gains achieved by using a tree component for the gallery. Virtual scrolling in trees could mitigate this problem.

As far as we know, these two potential solutions are mutually exclusive. There seems to be support for virtual scrolling for trees in PrimeNG version 9.1 (https://www.primefaces.org/primeng/#/tree/scroll) but not in the main PrimeFaces library that we use in Kitodo.Production. If virtual scrolling is made available in PrimeFaces trees as well, the two proposals described above could be combined to potentially achieve even more performance improvements.

[thomaslow]

Sry. Was supposed to be a new comment.

[thomaslow]

FYI, I did some research on potential existing libraries / components for editing large hierarchical data in the browser. Unfortunately, most libraries / components only support two of the four main required features, meaning:

1. visualizes a hierarchy
2. is scalable to thousands of nodes (e.g. by virtual scrolling)
3. supports drag and drop
4. allows to drag and drop multiple items at once

There are two solutions that support the first three features:

• react-sortable-tree (see example).
• D3.js experimental demo, which renders the hierarchy as a classic tree to an SVG and is supposedly scalable to many thousands of nodes, see second demo.

There are some solutions that support scalable hierarchies, but no drag and drop:

• PrimeNG's Tree (I couldn't find an example that uses both virtual scrolling and drag and drop at the same time. I kind of doubt that it would work. There is definitely no support for multi-select drag and drop, see issue.)
• react-virtualized-tree (example without drag and drop)

There are a bunch of solutions that support virtual scrolling for simple lists, but not for hierarchies, e.g.:

• Primefaces 8 DataTable (unknown drag and drop support, probably not)
• Material Angular Virtual Scrolling (example with drag and drop)
• react-virtualized-dnd (example with drag and drop)

Of course, all but one mentioned component (PrimeFaces 8 DataTable) have the significant downside that they are not compatible with the currently used PrimeFaces library.