Show Advanced KnowledgeHide Advanced Knowledge

Streamlining Mediacast and Mediapool

1 Initial Problem

Mediacast and Mediapool both offer upload forms for videos/images/audio.

• They are significantly different, even after implementation of Abandon obsolete settings of media objects and Introduction of a Video Podcast-, Image Gallery- and Audio Podcast-type for mediacasts.

The main differences are:

• The Mediacast defines a "description", while Mediapool & Page Editor define a "caption".
• The Mediacast can make assumptions about the mimetype according to the Mediacast type (i.e. Video/Audio/Image). Therefore only settings will be available, which make sense for the mimetype.
• The Mediacast allows to configure a Preview Picture, while Mediapool and Page Editor take the reverse approach of defining a Full Screen Resource.
• Mediacasts do not allow for uploading subtitles /srt. 

Differences like these can lead to confusion and create a steeper learning curve. Implicit knowledge about one form cannot be transfered to the other form.

It is also quite obvious, that the php code of both component isn't reused, potentially increasing the maintenance effort for both components.

2 Conceptual Summary

Streamline the upload forms of Mediacast and Mediapool and introduce a common implementation, which covers all current possible variations.

Suggestions

• Mediacast "description" and Mediapool & Page Editor "caption" should be the same thing
• The Mediapool & Page Editor should perform a mimetype selection or detection in step 1 and then present the same form as the Mediacast in step 2
• The role of "Full Screen Resource" should be reversed for Mediapool & Page Editor - with some form of legacy handling
• The setting "size: original | adjust" will become a local property of references to a media object (in the page editor) - i.e. it will be dropped for global instances in the media pool.
• References to a media object (in the paged editor) will acquire a new setting "use preview resource and allow magnification".
• The preview resource will default to the main resource - allowing for simple down-scaling + magnification.
• Mediacast should allow for uploading subtitles / srts. 

Migration

• Media Objects (of Mediapool and Page Editor) will perform the following swap (ONLY IF a full screen resource is defined)
  • former "full screen resource" will be the new "main resource"
  • former "main resource" will be the new "preview resource"
  • any reference to this media object (in the page editor) will get a flag "use preview resource and allow magnification" (which at the same time enables the "magnify feature" showing the main resource)
• If there is NO "full screen resource"
  • the main resource will stay the same
  • the preview resource will refer to the main resource (as is the default for new media objects)

Note

• A different caption/title for fullscreen-videos will be dropped! This feature currently exists for Mediapools and page editor, but not for Mediacasts.
• For new Media Objects in Mediapool and Page Editor it will only be possible to define a Preview Picture. Preview Videos and Preview Audios will only be supported for legacy content. They can be deprecated in future ILIAS versions to consolidate the code base. -- OR do we want to keep this functionality?

3 User Interface Modifications

3.1 List of Affected Views

• Mediacast > Add New Item
• Mediapool & Page Editor > Insert Media Object

3.2 User Interface Details

The process of adding items to Mediacasts or Mediapools will happen in two steps.

The first step will ask for all settings that are common for video-, image- and audio-files (titel, description, and a Resource-File or -URL). The next step will ask for details depending on the Mimetype of the Resource.

ADD NEW ITEM - step 1

Accordeon: File

• File

Accordeon: URL

• URL

Accordeon: Mediapool

• ... select from media pool

Button "Next" (or "Continue")

ADD NEW ITEM - step 1b

• If the mimetype cannot be detected, the user can either set it manually or abort

ADD NEW ITEM - step 2

ADD NEW ITEM - step 2b

• The user can set a new main resource. If the mimetype cannot be detected, this is equivalent to "step 1b". If the mimetype varies from the previous mimetype, the user can either switch the objects mimetype (potentially loosing settings), or abort. ALTERNATIVELY we could prevent changing the mimetype and ask the user to delete and create a new item instead.
• If the mimetype of small devices or full screen resources cannot be detected, the user is asked to set it manually or abort. If any sub-resource mimetype varies from the main-resource mimetype, the sub-resource will be rejected.

3.3 New User Interface Concepts

-

4 Technical Information

{The maintainer has to provide necessary technical information, e.g. dependencies on other ILIAS components, necessary modifications in general services/architecture, potential security or performance issues.}

5 Privacy Information

{ Please list 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. }

6 Security Implications

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

7 Contact

• Author of the Request: Kiegel, Colin [kiegel]
• Maintainer: Killing, Alexander [alex]
• Implementation of the feature is done by: {The maintainer must add the name of the implementing developer.}

8 Funding

If you are interest in funding this feature, please add your name and institution to this list.

• …

9 Discussion

Killing, Alexander [alex], 29 Aug 2022: I like some of the ideas, but this FW is currently "epic", meaning too many topics. Please create separate ones, e.g. for caption/descripton, creation process, srt support, fullscreen handling/migration.

10 Implementation

{The maintainer has to give a description of the final implementation and add screenshots if possible.}

Test Cases

Test cases completed at {date} by {user}

• {Test case number linked to Testrail} : {test case title}

Approval

Approved at {date} by {user}.