Adaptive Learning Paths: Input Conditions

1 Initial Problem

An adaptive Learning Sequence must be able to decide whether an object may be entered by a learner. Without Input Conditions, every object would either be reachable linearly or would have to be controlled outside the Learning Sequence. This prevents flexible learning paths with branches, prerequisites, point thresholds or logical combinations.

2 Conceptual Summary

Input Conditions define which prerequisites must be fulfilled before an object may be entered. They are created on the target object. During navigation, the Learning Sequence checks whether the conditions for this target object are fulfilled.

The implemented Input Conditions are:

Input Conditions not only control the release of an object, but also shape adaptive navigation. Some conditions form direct edges between objects, while others describe dependencies on several sources.

3 User Interface Modifications

3.1 List of Affected Views

3.2 User Interface Details

Input Conditions are created in adaptive content management through the action "Conditions" of an object. The condition belongs to the object that is to be entered.

When adding a condition, a drilldown with the available Input Conditions opens. Conditions with subtypes, such as Learning Progress or Logic Gate, show their variants as subentries.

Many Input Conditions require configuration:

Adaptive content management displays misconfigurations with badges and popovers. This makes it visible when conditions point to deleted objects or objects no longer present in the Learning Sequence, or when a Points Input Condition lacks a matching Points Output Condition.

In addition to normal condition configuration, Input Conditions use additional quality information:

This information helps check adaptive paths already in management before learners encounter blocked or unreachable paths in the Player.

3.3 New User Interface Concepts

No new UI concepts.

3.4 Accessibility Implications

The display must explain misconfigurations textually. Badges must not be the only source of information. Popover content should contain clear titles, descriptions and referenced object lists so that it is also understandable with assistive technologies.

4 Additional Information

4.1 Involved Authorities

4.2 Technical Aspects

Input Conditions are discovered automatically and registered in lso_condition_types. Each created condition receives an entry in lso_conditions; additional configuration data is stored in condition-specific tables.

Examples of condition-specific tables:

For adaptive navigation, certain Input Conditions implement a navigation-aware interface. It distinguishes, among other things:

Static misconfiguration detection collects issues from the Input Conditions, merges details and marks affected objects in the table. It is especially important that a condition can mark not only its own object as faulty, but also referenced source objects if a required counterpart condition is missing there.

4.3 Privacy

Input Conditions can evaluate learning progress and derived values such as achieved points. No new categories of personal data are introduced.

4.4 Security

No special security-relevant changes. Referenced objects are checked through existing object and reference IDs; missing or invalid references are treated as misconfigurations.

4.5 Contact

Person to be contacted in case of questions about the feature or for funding offers: Auerbach, Jeanine [jeanine.auerbach]

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 21 OCT 2026 by Vorkauf, Klaus [KlausVorkauf].