Moving the Advanced Search to KS

1 Initial Problem

The presentation of search results does not use KS-Elements. Existing filter elements are to be transferred to KS filters. In addition, the displayed information will be discussed so that search results are more clearly structured and understandable.

Advanced Search

• Besides Title, Description and Keywords the Advanced Search allows filtering results according to (mostly) metadata. Consider adding these criteria as filter elements and thus dispense with the extra tab.
• There is not neccessarily a Search Term which is hard to grasp. 
• If the advanced search is integrated into the normal search results, then we have to deal with the fact that normal search results may include a folder and if then Metadata filter of the LOM Metadata is used the results lists is emptied because the folder has no LOM Metadata

2 Conceptual Summary

• The Advanced Search can be configured thus there is not always an input field for a search term. 
• For the LOM Meatada the section title (i.e. Lifecycle) should be used as a prefix to the actual filter title. 
• It is not possible to support all types of Custom Metadata with KS-Filter elements. Thus we can not longer support all types of Custom Metadata in the Advanced search. 

3 User Interface Modifications

3.1 List of Affected Views

• Search > Advanced Search

3.2 User Interface Details

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

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

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

{ 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

{ 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: {Please add your name.}
• Maintainer: {Please add your name before applying for an initial workshop or a Jour Fixe meeting.}
• 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

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