Improve Filter Default Visibility in Category

1 Initial Problem

Filters are a useful tool for categories in which a large number of objects is stored / linked. However, filters must be enabled at least once per user session. Accessing a category with activated filters will lead to only one filter field being shown initially, the "Title" filter. Many users do no realize that other filters are available through the "+" button. And users who frequently access this category are unnerved to be required to activate the filter fields each time they access the category (once per user session). 

2 Conceptual Summary

To improve the usability of filters, we propose to introduce two things:

1. a new sub-setting for filters in categories "Filter switched on by default" (default value for the checkbox "activated"), which sets filter to "On" when a user accesses the category (default "Off" is always off at the moment). Alternatively we could also imagine changing the default state to "On" permanently,  if filter has been enabled for a category.

2. Introducing the option to choose,which filter fields are automatically shown besides "Title" via a new set of checkboxes on the screen "Category" > "Settings" > subtab "Filter"

3 User Interface Modifications

3.1 List of Affected Views

• "Category" > "Settings"  ---> new option in additional features, subset for "Filter"
• "Category" > "Settings" > subtab "Filter" --> new column in table with checkboxes for each row, Save buttons 

3.2 User Interface Details

see above

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

none

6 Security

none

7 Contact

• Author of the Request: Glaubitz, Marko [mglaubitz]
• 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.

• Universität Freiburg

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}

Privacy

Information in privacy.md of component: updated on {date} by {user} | no change required

Approval

Approved at {date} by {user}.