Introducing Course and Group Table of Contents

1 Summary

Courses and groups in ILIAS can contain nested folders, learning modules, exercises, sessions, tests and other objects. Members often cannot see the overall structure of a course or group without opening several levels, which makes orientation and content discovery unnecessarily difficult.

This Feature Request proposes an automatically generated, collapsible table of contents for courses and groups. It will be opened in the Slate through a context-specific trigger, allowing users to inspect and navigate the visible content hierarchy without leaving the current context.

2 Problem Statement

Courses and groups are central container objects in ILIAS. They often contain a large number of objects, including folders, files, learning modules, sessions, exercises, tests, surveys, web links, forums and other learning resources. In many installations, these objects are additionally structured across additional hierarchy levels.

The current course or group view only shows the current level of the repository hierarchy. To understand the overall content structure, users must open containers one by one and repeatedly move forward and backward through the hierarchy.

This makes the following tasks unnecessarily difficult:

A recent large-scale needs assessment identifies navigation and content discovery as major usability issues in ILIAS. Better and more intuitive navigation was the most frequently requested improvement, while respondents additionally reported difficulties finding content, particularly in deeply nested course structures. The open-ended feedback confirms a need for clearer overviews and shorter navigation paths. These issues are especially relevant for mobile use, as smartphones and tablets are widely used and navigation is rated less favourably on smartphones.

Existing mechanisms do not sufficiently solve the problem:

A course or group table of contents should therefore provide a compact, context-specific overview of the visible hierarchy inside the current container. It should reduce the amount of exploratory clicking required to understand a course or group without replacing search, breadcrumbs, global navigation or existing course administration functions.

3 Concept

3.1 Core Idea

ILIAS should provide an automatically generated table of contents for courses and groups. The table of contents gives members an overview of the objects available inside the current course or group. It reflects the existing repository hierarchy of the container and enables direct navigation to visible and accessible objects. The feature is not a second manually maintained course structure. It is generated from the actual repository structure of the course or group and automatically reflects changes made by course or group administrators.

The proposed feature answers a context-specific user question:

This distinguishes it from a global repository navigation, which addresses a different question:

3.2 Entry Point and Placement

The table of contents should be triggered from the current course or group context. It must therefore not be placed exclusively under a generic "Tools" category in the Main Bar. "Tools" is not a meaningful or expected category for a content overview. Users looking for an overview of a course or group are likely to look at the container itself, especially near its title, a sticky (float) button or a dedicated main menu entry, rather than under a global collection of technical functions.

The entry point should use a clear text label, for example:

The final label should be selected and validated through usability testing and language experts. 

The interaction pattern can be compared to Wikipedia’s table of contents: when the overview is not persistently visible, it remains accessible through a clearly associated control near the page title. The user can expand the overview when orientation is needed and collapse it again by button when the main content area should receive full attention.

3.3 Slate-Based Presentation

Activating the table-of-contents trigger opens the Slate containing the structure of the current course or group.

The Slate is appropriate because it:

The feature should use progressive disclosure rather than rendering all nested levels at once (if possible or advisable). The initial view should show the course or group's top-level objects. Containers such as folders can be expanded to reveal their contents.

This avoids recreating a complete, permanently visible repository tree. The table of contents should support orientation, not overwhelm users with every possible branch of a complex structure.

3.4 Content Structure

The table of contents should reflect the actual, visible hierarchy inside the currently opened course or group.

It should include all relevant and accessible repository objects. The exact display treatment for individual object types may be refined during implementation. The basic principle is that members should receive a coherent overview of the course or group structure, regardless of whether content has been organised in folders, sessions, learning modules or other compatible repository objects.

The table of contents should preserve the established object order of the course or group. It must not introduce a separate or competing sorting logic.

3.4.1 Headings and Object Blocks

The concept should also consider headings as structural elements. Similar to the table of contents in the ILIAS Wiki, headings can group consecutive objects into meaningful sections, such as Course information, Week 1, Learning materials or Assignments.

Where headings are used in a course or group, the table of contents should display them as distinct structural entries and group the following objects beneath them until the next heading of the same level. This would make flat or only lightly nested course structures easier to scan without requiring folders for every thematic block.

Headings and container objects serve different purposes:

Element	Function in the table of contents
Heading	Groups related consecutive objects on the same level
Container objects	Can be opened and may contain child objects
Content object	Opens the respective resource or activity

The feature should work without headings, but should improve the overview where course authors use them. The exact handling of multiple heading levels and object blocks can be refined during concept and UI development.

3.5 Navigation Behaviour

Each entry in the table of contents represents an existing repository object.

For content objects, selecting the entry opens the object directly.

For container objects, users need to be able to distinguish between two actions:

This distinction is important because a folder, course section or similar container may have its own view while also containing deeper levels of content.

The proposed interaction model is:

The disclosure control should use an understandable visual indicator, such as a chevron. The title and disclosure control must remain separate interactive targets. Clicking a container title must not unexpectedly expand it when users intended to open the container itself.

3.6 Current Location

When users are currently inside a nested object belonging to the course or group, the table of contents should indicate that object and its path within the current container. For example, when a user is viewing an exercise located in a nested folder, the table of contents should make the relationship visible.

The current object should be visually distinguishable and programmatically identifiable. Parent items along the path should be expanded or otherwise clearly represented, so users can understand where the object is located inside the course or group. The feature should not use colour as the only indicator of the active object or active path.

3.7 Permissions

The table of contents must reflect the user’s effective permissions. Users must see only objects they are permitted to access. The table of contents must not disclose object titles, metadata or structural information about inaccessible content.

Where objects are hidden because of permissions, the table of contents should remain structurally understandable for the visible content. It must not create links to inaccessible objects or misleading representations of the available structure.

3.8 Relationship to Existing Functionality

The feature complements existing navigation mechanisms:

This Feature Request is especially closely related to, but distinct from, the proposed Feature Request Introducing Global Navigation.

The course or group table of contents answers:

The global navigation answers:

Both features should use compatible interaction principles and possibly shared UI components. They should not be merged into one feature because their context, scope and user expectations differ.

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.9 Impact on Existing Workflows

The feature does not require course or group administrators to create, curate or maintain an additional navigation structure.

Administrators continue to create and order objects as they do today. The table of contents updates automatically based on the existing hierarchy and object order. Members gain an additional way to inspect and navigate a course or group. Existing entry points, direct links, bookmarks and course workflows remain valid.

The table of contents must not alter the underlying repository structure, object permissions, URLs or existing object-specific navigation.

4 User Interface Modifications

4.1 List of Affected Views

4.2 User Interface Details

4.2.1 Course and group title/content area

A new trigger is added near the title of a course or group, in the main menu or as a sticky (float) button.

The trigger should be a text-based button. An icon should be included, but it should not replace the text label. Testing for small screen sizes may be necessary, whether a text-based button is meaningful.

4.2.2 Table-of-contents Slate

4.2.3 Visual hierarchy

The hierarchy should be represented through a combination of:

Object-type icons are optional and must be supplementary. The hierarchy and object type must remain understandable through text and semantics.

4.3 New User Interface Concepts

The Feature Request introduces a new, contextual Course and Group Table of Contents.

The table of contents is opened in a Slate through the Contents trigger in the course or group title area. It uses the Expandable Tree component from the UI Kitchen Sink to display the hierarchy of the current course or group. The Expandable Tree is suitable because it can represent shallow nested structures while allowing users to expand or collapse individual branches. It should display the existing hierarchy of visible course or group content, including headings, object blocks, folders, sessions and other repository objects.

Object titles open the respective object. Separate expand/collapse controls reveal or hide child objects. The current object and its path are marked where applicable.

The component is limited to the current course or group and does not replace the repository tree.

4.4 Technical Aspects

The table of contents retrieves the visible repository hierarchy below the current course or group. It must preserve the existing order, respect permissions and visibility settings, and support nested containers, headings and object blocks. For large structures, child levels may be loaded when a tree branch is expanded. If the current object is nested, its parent path should be available when opening the table of contents.

The feature is additive: it does not change existing URLs, permissions, course structures or object ordering, and it requires no content migration or additional maintenance by course administrators.

5 Non-Functional Implications

5.1 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. }

5.2 Privacy

{ Please list here all personal data that will need to be stored or processed to implement this feature. For each date give a short explanation why it is necessary to use that date. Use the Privacy Guidance for Feature Requests to fill out this section correctly. }

5.3 Accessibility Implications

The feature introduces a new hierarchical navigation component. Its accessibility must therefore be explicitly designed and tested.

The implementation should be tested with:

6 Process Information

6.1 Involved Authorities

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

6.2 Contact

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

6.3 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'.

7 Discussion

8 Implementation

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

8.1 Description and Screenshots

{ Description of the final implementation and the changed behaviour in the related components. Please add screenshots to visualise the changes if possible. }

8.2 Test Cases

Test cases completed at {date} by {user}

8.3 Privacy

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

8.4 Approval

Approved at {date} by {user}.