Improved Repository Navigation and Orientation

1 Initial Problem

Currently, ILIAS does not provide a user‑friendly navigation menu that is fully reliable and consistently communicates the user’s current location within the system. This can make orientation difficult, especially for typical end users.

Navigating “upwards” in the repository — for instance, from a folder to its parent course — is particularly difficult. This problem is even more evident when accessing a folder via an external link, as returning to the parent level then becomes unintuitive. This issue has existed for over 15 years (see FR) and continues to appear in more recent usability tests (see task 6). Further tests conducted together with bwOER-Connect and leifos revealed that, especially on small screens, none of the participants were able to navigate back to higher levels, as they could not locate the breadcrumbs.

The breadcrumb path provides orientation most reliably, yet due to permission settings it can display misleading information (see Mantis #45844). Moreover, breadcrumbs should act only as a secondary navigation aid (see analysis). Additional usability issues related to breadcrumbs have been identified in Mantis #45836 and Mantis #44551.

The tree view, a potential alternative for navigation, also fails to indicate the current location within the repository. It is cluttered, difficult to read, and therefore unsuitable for providing users with a clear orientation within ILIAS (see analysis).

2 Conceptual Summary

There are different possible approaches to address these challenges:

Preferred Option 1: New Drill-Down Navigation (affects the entire repository)

The preferred approach would be to implement a drill-down navigation, representing the full repository while supporting stepwise exploration through complex structures (see analysis). The purpose description in the KS documentation states accordingly: "A Drilldown Menu offers a partial view on a larger set of hierarchically structured navigation possibilities. While the entries of a Drilldown Menu are actually organized in a tree structure, there is only one level of branches visible at a time, so that space is saved and the user’s attention is not being obstructed by irrelevant options." Therefore, the drill-down is the ideal implementation for a navigation menu. Due to its clarity, the modal for object creation was also redesigned with a drill-down starting with ILIAS 10. A potential design is illustrated in the attached mock-up below (see 3.2).

In this concept, it is mandatory that the drill-down menu would visually highlight the currently active node and persistently indicate the user’s location during navigation (see Drill-Down Menus > First Example). Currently, the previously selected node is highlighted by color (using the color #a1b3ca). Every previous node that leads to the current object should be highlighted in this way, so that users can follow where they are within the navigation.

To implement the new drill-down navigation, the existing drill-down component (see KS documentation) would need to be adapted. Buttons should allow users both to view the contents of the current repository node and to explore one level deeper within the same interface. The tree (multi) select input (see KS documentation) introduced with ILIAS 11 offers a suitable visual template for this. Instead of the (+), a > symbol should be used for the right button, and clicking > should take the user one level deeper in the drill-down within the slate (similar to how clicking "Layout and Navigation" currently works in the administration). The left button should then open the selected node level (similar to how clicking "Layout" opens the layout section after "Layout and Navigation").

Following current logic, this content overview could technically be placed under "tools", but a more intuitive integration would be in the main menu bar or another prominent area that directly communicates its purpose as a navigation overview, rather than being hidden behind submenus (like the tree view). Usability testing has shown (see task 1) that users do not intuitively interpret the current tree view as a navigation tool.

Option 2: Content Overview (affects only the container types "Course" and "Group")

Since most user-facing content resides within courses and groups, a content overview could be implemented. This overview would display the user’s current location, the contents of the current container, and provide navigational access and orientation within that structure. Its design could be similar to the layout used in learning modules (optionally showing learning progress where activated).

The overview could list not only item groups and their contained items but also headings (as done in the wiki page overview). This would allow course administrators to logically structure their course content, since item groups already use H2 headings. A potential design is illustrated in the attached mock-up below (see 3.2).

For courses and groups, an accordion menu, similar to the current tree navigation (see KS documentation), would be appropriate. Courses rarely exceed two or three levels of depth, so such a design would remain compact and readable (see related analysis).

As with the drill-down menu, this content overview could technically be placed under "tools", but a more intuitive integration would be in the main menu bar or another prominent area that directly communicates its purpose as a navigation overview.

Additionally: In parallel, the breadcrumb component should be modernized. Even small CSS adjustments (see discussion) could align its visual representation with current industry standards and best practices, as documented in the analysis.

3 User Interface Modifications

3.1 List of Affected Views

3.2 User Interface Details

Option 1: Drill-Down Navigation

Option 2: Content Overview

Additionally: Visual Breadcrumb Overhaul

3.3 New User Interface Concepts

For option 1, an adaptation of the slate drill-down would be required. A new input, preferably based on the visual model of the Tree (Multi) Select input, would need to be introduced. This input should support two functions: opening the selected node level and navigating one level deeper within the drill-down. In addition, the path leading to the current object should be highlighted persistently within the drill-down, both visually and in a screen-reader-accessible way, so that users can better understand their current position within the repository.

For option 2, an adaptation of the expandable tree would be required. The expandable tree would need to be revised so that headings, item groups, and objects can be integrated as nodes in a way that provides a clear and meaningful structure and presentation.

3.4 Accessibility Implications

{ If the proposal contains potential accessibility issues that are neither covered by existing UI components nor clarified by guidelines, please list them here. For every potential issue please either propose a solution or write down a short risk assessment about potential fallout if there would be no solution for the issue. }

4 Additional Information

4.1 Involved Authorities

If this request is related to multiple components, please list both authorities for all related components.

4.2 Technical Aspects

For option 1, an adaptation of the slate drill-down would be required. A new input, preferably based on the visual model of the Tree (Multi) Select input, would need to be introduced. This input should support two functions: opening the selected node level and navigating one level deeper within the drill-down. In addition, the path leading to the current object should be highlighted persistently within the drill-down, both visually and in a screen-reader-accessible way, so that users can better understand their current position within the repository.

For option 2, an adaptation of the expandable tree would be required. The expandable tree would need to be revised so that headings, item groups, and objects can be integrated as nodes in a way that provides a clear and meaningful structure and presentation.

A technical aspect that would need to be clarified is which data is loaded when the navigation is opened. At present, the tree view appears to render the entire repository, at least to my knowledge. Ideally, content in the navigation structures should be loaded only on demand, for example when users navigate deeper in the drill-down or expand an accordion entry.

4.3 Privacy

{ Personal data that will need to be stored or processed to implement this feature have to be listed here. For each date give a short explanation why it is necessary to use that date. }

4.4 Security

{ Does the feature include any special security relevant changes, e.g. the introducion of new endpoints or other new possible attack vectors. If yes, please explain these implications and include a commitment to deliver a written security concept as part of the feature development. This concept will need an additional approvement by the JourFixe. }

4.5 Contact

Person to be contacted in case of questions about the feature or for funding offers: Becker, Matthias [matthias.becker]

4.6 Funding

Funding status and funding parties are listed in the block 'Status of Feature' in the right column of this page.

If you are interested to give funding for this feature, please get into contact with the person mentioned above as 'Contact'.

5 Discussion

6 Implementation

Feature has been implemented by {Please add related profile link of this person}

6.1 Description and Screenshots

{ Description of the final implementation and screenshots if possible. }

6.2 Test Cases

Test cases completed at {date} by {user}

6.3 Privacy

Information in privacy.md of component: updated at {date} by {user} | no change required

6.4 Approval

Approved at {date} by {user}.