CAPE – Configurable Activity and Performance Export across ILIAS Tools

1 Summary

CAPE introduces a configurable, course-level participant activity table that combines selected participant-specific data from different ILIAS Performance and Feedback & Evaluation tools in one overview. Course administrators define the table column by column by selecting an activity or tool and one of its recorded participant-specific variables; the resulting table can be viewed and exported. If student access is enabled, each student sees only their own individual data.

2 Problem Statement

Instructors increasingly create extended online learning environments in ILIAS in which students complete several activities of different types, for example tests, self-evaluations, surveys and exercises. In some courses, participation in or completion of these activities, as well as achieving a required result such as passing specific tests, is relevant for course organisation and may, for example, be required for admission to an exam.

At present, obtaining one consolidated overview of such activities can be cumbersome. The instructor may need to open the individual tools, export the available statistics separately and then merge the resulting files manually. This becomes particularly demanding when a course contains many activities, when different ILIAS tool types are used, or when the same overview has to be updated repeatedly during the semester.

The current workflow also makes it difficult to give participants a simple overview of their own activity across the online course environment. A student who wants to check which relevant activities have already been completed may have to visit the individual objects one by one.

The problem is therefore not the absence of activity data in the individual ILIAS tools, but the absence of a configurable cross-tool view that brings selected participant-level information together in a single course-level table.

3 Concept

4 User Interface Modifications

4.1 List of Affected Views

The exact placement and breadcrumb should be agreed with the responsible maintainers. The following views are proposed as working concepts:

· New administrator view: “Activity and Performance Export (CAPE)” within the course administration/statistics area – configuration of the table structure.

· Administrator table view: “CAPE Overview” – display and export of the configured participant table.

· Optional participant view: “My Activity Overview” – display of the current participant’s own row if access has been enabled by the course administrator.

No existing component-specific result or statistics view needs to be removed or fundamentally changed.

4.2 User Interface Details

The CAPE configuration view should contain the following user interface elements:

· A list of already configured columns, beginning with the fixed LOGIN column.

· An “Add column” action.

· For a new column, a selector for the source activity or tool in the current course.

· A second selector whose available values depend on the selected source and list the participant-specific variables that source makes available to CAPE.

· A text input for the column name, prefilled with a default combining the source object/tool name and selected variable.

· Controls to reorder and remove configured columns.

· An optional action to create a derived column from already configured numerical or Boolean columns by combining comparisons and logical operators.

· A save action for the table configuration.

· An option controlling whether participants may access their own individual overview.

The overview view should present LOGIN plus the configured columns in the chosen order. Administrators see all participants they are authorised to evaluate; participants, if access is enabled, see only their own data. Export actions available to participants must follow the same restriction.

4.3 New User Interface Concepts

No fundamentally new interaction pattern is required. The feature can be built from established ILIAS concepts such as object selection, dependent selection fields, editable text inputs, sortable lists, tables and standard export actions. If reordering by drag and drop is used, an accessible keyboard-operable alternative should also be available.

4.4 Technical Aspects

A central technical requirement is that ILIAS components included in CAPE provide the participant-specific variables that can be used in the aggregated table. A component that supports CAPE should be able to provide at least: (1) the variables available for selection, (2) human-readable labels for those variables, and (3) the corresponding value for an authorised participant.

The CAPE configuration should primarily store references to the selected course object/component, the selected variable, the user-defined column label and the column order. Wherever feasible, the actual participant values should be retrieved from the source components when the overview is generated rather than copied into a second persistent dataset. This reduces duplicated personal data and keeps CAPE aligned with the current state of the source activities.

Derived columns should be calculated from values already available in the CAPE table and should not introduce additional access to participant data. Their configuration should store the referenced columns and the defined comparison and logical operations so that the derived value can be recalculated whenever the CAPE overview is generated.

Because a table may aggregate information from several components for many course participants, implementations should avoid unnecessary repeated queries and should consider batching or other efficient retrieval mechanisms. Components that do not implement the required data-provider capability simply do not appear as selectable sources.

5 Non-Functional Implications

5.1 Security

CAPE must respect existing course roles, permissions and access restrictions. Only authorised users may configure the table or view data for multiple participants. If participant access is enabled, the server-side permission and data-retrieval logic must ensure that a participant can request only their own row; hiding other rows only in the user interface is not sufficient.

CAPE does not necessarily need a new technical interface to exchange data. If such an interface is created during implementation, it must respect the same access permissions as the normal ILIAS pages. In particular, users must only be able to access participant data they are authorised to see and must not be able to retrieve data about other participants.

5.2 Privacy

CAPE processes personal data that already exists in the participating course components. The core data elements are the participant LOGIN and whichever activity-, completion-, result- or feedback-related variables the course administrator selects for the configured table. These data are required in order to create the requested participant-level overview.

The feature should minimise additional storage of personal data. Preferably, the saved configuration contains only references and column settings, while participant values are retrieved from the original components when needed. When a course administrator exports the resulting table, the export contains personal course data and must therefore be treated according to the same institutional data-protection rules as existing ILIAS statistics and result exports.

If student access is enabled, each student may see only their own data. No participant-level information about other students may be displayed, exported or obtainable through direct requests.

5.3 Accessibility Implications

The configuration and overview should use standard accessible ILIAS user interface components wherever possible. Form controls require programmatically associated labels; the resulting data table requires clear column headers and a meaningful reading order. Any visual reordering mechanism must have a keyboard-accessible alternative, and status or error information for unavailable source data must not rely on colour alone.

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:  {Kinga Sipos}

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

Funding status: To be clarified.

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