Mediacast: support of subtitles

1 Summary

The mediacast object currently does not support uploading and presenting subtitels. This feature request deals with the support of subtitles adapting the functionality of media pools and media objects.

2 Problem Statement

Supporting subtitles is important because they make content accessible to people who are deaf or hard of hearing. They also help viewers understand different accents and languages, and allow them to follow content in noisy or quiet environments.

At media pools and media objects (e.g. at the ILIAS page editor) this already is supported.

The user interface for presenting/activating subtitles is the same at both places.

In addition, when adding a media object at the ILIAS page editor from a media pool, all properties including the subtitles are taken over. This is not the case, if adding a media object from a media pool to a mediacast. The subtab "Subtitles" is missing.

3 Concept

The support of subtitles are to be extended for the mediacast. The functionality is adapted from media pools and media objects.

If media objects are added to a mediacast from a media pool, all properties including the subtitles are taken over.

4 User Interface Modifications

4.1 List of Affected Views

4.2 User Interface Details

The Subtitles subtab of media pools and media objects is adapted at the media cast and moved to KitchenSink UI.

Instead of the various input fields and buttons at the toolbar, there should be only one (or two) buttons in order to start the upload process.

After clicking the button, a form or a modal is shown with the following input fields:

4.3 New User Interface Concepts

{ If the proposal introduces any completely new user interface elements, you might consult UI Kitchen Sink in order to find the necessary information to propose new UI-Concepts. Note that any maintainer might gladly assist you with this. }

4.4 Technical Aspects

{ Necessary technical information have to be provided here, e.g. dependencies on other ILIAS components, necessary modifications in general services/architecture, potential security or performance issues. }

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

There are no privacy implications.

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

6 Process Information

6.1 Involved Authorities

6.2 Contact

Person to be contacted in case of questions about the feature or for funding offers: Lowe, Simon [simon.lowe]

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