Moving LOM Metadata Editor to Kitchensink

1 Initial Problem

LOM Metadata are implemented in HTML. They cannot be fitted into Property Forms or into KS-Forms, because users can add new field and this would require tables within forms.

The LOM Metadata has a total of 4 conceptual levels that need to be accomodated in the GUI

1. The Metadata-tab is home to LOM and taxonomy features and custom metadata in varying combinations. These services are represented as sub-tabs.  
2. LOM comprises 10 titles sub-sections. These sections are currently operated by a drop down in a toolbar. The toolbar is illegal above forms cannot be part of the proposed solution. 
3. In sections additional data sets can be added. This is currently possible for almost all sets in the current implementation. However mixing forms and tables is illegal. Adding additional data sets therefore must be done either in a form or in a table. 
4. Some form inputs carry a language dimension.  

2 Conceptual Summary

1. Opening the tab Metadata leads to its subtab "LOM". This tab shows the form "LOM Digest", basically the old "Quick Edit" form, with minor revisions to comply with the KS. Also, at the top of the page above the form, a bulky button "Edit the full LOM Dataset" leads to the new editor.
2. When clicking on the bulky button, one enters a new context:
   • In the tools slate an expandable navigational tree is offered. When in a fresh ILIAS object, it only comprises the root node "Learning Object Metadata" and its sub-node "General". For objects where the metadata is already better populated, the tree is correspondingly also more fleshed out. All nodes in the tree except the root node and the ones directly below it are of the node type 'paired', consisting of value complementary to the label (see PR #4919). This value helps clarify the nodes by giving a small preview to their content. Note that the final appearance of this node type is still subject to change and not yet included in the KS.
   • The element General is automatically created once the object is created since it carries the "Title" and in some cases "Description". Depending on the type of objects, other metadata elements might be pre-filled as well.
   • By navigating through the tree, users can navigate through the metadata. Depending on the nature of the element and its position in the tree, clicking on their node in the tree leads to a different view:
     • "Container" Elements: Some Elements only exist to house their subelements, e.g. the root element "LOM" or its sub-element "General". Their view consists in general of an item previewing their contents as properties, mirroring the information given in the tree. This item also carries an action dropdown where the container element can be deleted, and new sub-elements added. When a sub-element is unique and already exists, the option to add it vanishes from the dropdown. Adding a sub-element is done via a roundabout modal, which contains an input form.
       The view of the root element "LOM" is a special case. It consists of all the aforementioned items of its direct sub-elements, and also a dropdown in the toolbar to add those elements (if they have not already reached their maximum number of occurences). Further, container elements carrying pre-filled elements (e.g. General) cannot be deleted.
     • Unique Elements with no Sub-Elements: "End"-nodes of the tree can lead to a form, if their element is unique. Most of the time, these forms consist of very few input fields, with which the contents of the element can be viewed and edited. The form also comes with a "Delete this Element" button, which removes the element from the metadata. This form (without the delete button) is also found in the modal that opens when adding this element in the superordinate container element.
     • Non-Unique Elements with no Sub-Elements: "End"-nodes of the tree can also lead to a table, if their element is not unique. This table shows the individual occurences of the element as rows, which carry an action dropdown with a delete and an edit button. Further, the table has an "Add Element" command button. Both the edit and add buttons lead to a modal with a form, again the same modal that opens when adding one of these elements in the superordinate container element. The tables do not have a "Delete this Element" button, they and the corresponding node in the tree are rather removed when the last row is deleted.
   • Some special cases in the LOM Standard necessitate a slightly different behavior of the editor than what is laid out above, but everything fits into this general scheme with minor modifications in some isolated places.

3 User Interface Modifications

3.1 List of Affected Views

• ...> Metadata > LOM

3.2 User Interface Details

Alternative Self-Destruct Button

Alternative to the Alternative Self-Destruct Button

3.3 New User Interface Concepts

The implementation is changed to employ KS-elements wherever possible. A new tree node type is used, see PR #4919.

3.4 Accessibility Implications

No issue forseeable: The views are as acessible as the KS-elements they are comprised of. 

4 Technical Information

-

5 Privacy

• LOM Digest: "Author" to identifiy copy right holder by name 
• Lifecycle: "Contribute" to identify individual contributors by name 
• Meta-Metadata: "Contribute" to identify individual contributors by name 

6 Security

No foreseeable security implications.

7 Contact

• Author of the Request: Tödt, Alexandra [atoedt]
• Maintainer: Meyer, Stefan [smeyer]
• Implementation of the feature is done by: Schmitz, Tim [tschmitz]

8 Funding

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

• ILIAS-Verein for VerDatAs project

9 Discussion

JourFixe, ILIAS [jourfixe], 22 AUG 2022 : We highly appreciate this suggestion and schedule the feature for ILIAS 9. Thanks for adapting the suggestions from the last JF and for creating a PR for the necessary UI element. We accept the use of toolbar and form on the same page (and suggest the UI coordinators to think about modifying the current guideline accordingly).

10 Implementation

Implemented as described, except that the views of container elements use KS panels instead of items: they also have the required functionality, but look better in this context.

Test Cases

Test cases completed at 2023-05-11 by Spirou, Ilias [ispirou]

• 1466 : Quick Edit: Adding LOM Metadata to Objects
• 1467 : Individual Metadata Sections: Adding LOM Metadata to Objects
• 1278 : Adding LOM Metadata to ILIAS Learning Modules (Module, Chapter, Page)
• 6973 : Allgemein
• 6974 : Lebenszyklus
• 6975 : Meta-Metadaten
• 6976 : Technische Angaben
• 6977 : Pädagogik
• 6978 : Rechte und Lizenzen
• 6979 : Beziehung
• 6980 : Anmerkung
• 6981 : Klassifizierung

Approval

Approved at 05 SEP 2023 by Kunkel, Matthias [mkunkel]