Feature Wiki

Information about planned and released features

Tabs

Tree Behavior for Categories with Huge Amounts of Data

Page Overview

1 Initial Problem
2 Conceptual Summary
3 User Interface Modifications
- 3.1 List of Affected Views
- 3.2 User Interface Details
- 3.3 New User Interface Concepts
4 Technical Information
5 Contact
6 Funding
7 Discussion
8 Implementation

1 Initial Problem

We know of screnarios where masses of objects need to be dumped into categories.
The data dump is too big to be performantly displayed in the normal Tree: categories with huge amounts of objects will potentially slow or stop rendering all repository-tree-based explorer UIs.
Repository-tree-based explorer UIs are needed for actions as "Move" or "Copy" as well as for just displaying the repository tree as a navigational device.

2 Conceptual Summary

The repository-tree-based explorer UIs will be modified in a way that a maximum number of children presented. The respective cut-off value is to be configured in the administration.

If this number is reached an additional input filter field will appear on top of the corresponding node.
This allows the user to filter for objects that are not listed in the initial presentation.

This behavior should be implemented for all explorer trees, that show the repository tree.

3 User Interface Modifications

3.1 List of Affected Views

Views using the repository tree:
- Tree in Trash in Administration,
- Content-Tab of Categories,
- Courses,
- Groups
- Folders,
- Target Selection Views,
- Modal invoked when adding an internal Link of the Type "Repository Item" is added in Page Editor
Settings-Tab in Repository-node in Administration

3.2 User Interface Details

Settings-Tab in Repository-node in Administration

The Settings-Tab in the Administration node Repsotitory gets a new Checkbox setting labeled "Limit Items in Tree". If the checkbox is activated a new subsetting "Maximum Number" opens up.

Repository Trees

If this max number is reached an additional input filter field will appear on top of the corresponding node and the number of children elements will be cut off. Some nodes will always been in the initial presentation (if the parent is expanded):

Nodes of the current repository path.
Nodes which are currently in the "last visited" set.

The input field allows the user to filter for objects that are not listed in the initial presentation. After using the filter only nodes that titles match the search term (not necessarily at the beginning of the title) are listed. This behaviour starts to work after three letters have been entered.

3.3 New User Interface Concepts

The implementation extends the current implementation of the tree UI element. It is currently not our plan to provide a completely new implementation in the UI framework.

4 Technical Information

In extreme cases the performance of the presentation will still slow down, since the limitation will only have an effect after a certain number of visible nodes has been determined. Extreme cases are the ones where such categories contain a very large numbers of objects, but the current user has only granted access to a very small number of objects. In these cases the limitation may not be reached before the access on all objects has been checked.

In general we asks users to avoid these kind of scenarios.

5 Contact

Author of the Request: Tödt, Alexandra [atoedt]
Maintainer: Killing, Alexander [alex]
Implementation of the feature is done by: {The maintainer must add the name of the implementing developer.}

6 Funding

If you are interest in funding this feature, please add your name and institution to this list.

7 Discussion

13.10.2016, Glaubitz, Marko [mglaubitz]: There are stil some open issues with this idea that affect especially those users who move, copy, link, ... a lot of stuff around.

it ios quite a hassle to always type a cunning string that will provide you ith the object that you are looking for
how does the "search" / filter work: is only the title of the objects affected or are other metadata information parsed as well (e.g. description)
there should be a short list of recently used objects in the current context that could be displayed above the text input field (as it were a subset if the user's "recently visited" list)

15.11.2016 Amstutz, Timon [amstutz]: Would that not be the perfect oppurtinity to create a centralized UI-Tree component? If not now, when? What is the reason behind the decision not to do it now? This is obviously not clearly a new component, introducing a new component is therefore NOT a MUST, nevertheless, to me it seems akward to adapt various implementations of the tree instead of creating now I generalized new one. Pleaso note, that trees are for some time now quit far up in the list of things we need to tackle.

Killing, Alexander [alex], 21 Nov 2016: I am not against the implementation of a tree component in the new UI framework. But for us, it would be better if this would be an optional part (that could be tackled during 5.3 developments) and not a requirement by the JF. The main FR behind this is the Category for Huge Amount of Data. This FR includes now the efforts for implementing the responsive filters. This already increases the costs and risks for the project. Having a second non-trivial KS discussion in this development just makes it even more difficult to handle.

JourFixe, ILIAS [jourfixe], Nov 21, 2016: We highly appreciate this suggestion and schedule it for 5.3. In case we have the money to fund a general revision of the explorer tree implementation for 5.3, we will use this new implementation for this feature as well.

JourFixe, ILIAS [jourfixe], 24 SEP 2018 : We re-schedule the feature for 5.4. A new explorer tree implementation still is not available. Please improve the labels of the setting to make clear that the maximum number of items is always related to one single node in the repository (and not to sub-items).