Feature Wiki

Information about planned and released features

Tabok

Move Search Results Presentation to KS

Lapáttekintés

[Elrejtés]

For replacing the Search input field please consult KS Element Search

1 Initial Problem

The presentation of Search Results uses legacy UI. The table is not responive and thus not fully accessible.

In order to improve the usability, the existing elements are to be transferred to KS components. Plus information displayed could be structured more clearly.

Search Result Presentation

  • Consider list as an alternative format to replace the table presentation. 
  • What purpose does the action menu serve? 
Screenhot Search Results in ILIAS 10

2 Conceptual Summary

Search results are presented as individual items in a panel. The panel also contains pagination and sortation view controls.

  • Each item carries an icon of the found object.
  • The item is comprised of a linked Title, the text snippet is presented in the description.
  • Properties are
    • The regular description of the object
    • Path in text form
    • Created on (if enabled in the administration)
  • Objects with subobjects also have a main action 'See detailed results', which shows search results in its subobjects.

 No object specific properties are shown. Also, no object actions are offered.

Note that for performance reasons, the total number of search results is not always known. The pagination shows at most the page after the current one, and loads new pages dynamically while clicking through the pages.

Clicking on 'See detailed results' opens a lightbox modal with card pages. The modal contains at most 10 pages, each with at most 5 search results presented as items.

If more search results are available, the last page also shows a message: 'More results are available, please make your search terms more precise.'

Each item consists of a linked title and the found text snippet as a description. Also, the type of the subobject is shown as a property.

3 User Interface Modifications

3.1 List of Affected Views

  • Search Results Presentation 

3.2 User Interface Details

See conceptual summary.

3.3 New User Interface Concepts

No new UI elements needed.

3.4 Accessibility Implications

No accessibility implications.

4 Additional Information

4.1 Involved Authorities

If this request is related to multiple components, please list both authorities for all related components.

4.2 Technical Aspects

The search results presentation get checked via "access".

  • Online and offline is checked
  • The permissions visible, read and join are to be checked. These checks need to made available by the object service.
  • Preconditions are not checked, if there are preconditions and the clicks on the object, the user will be just presented with the information about precondistion in a modal.

4.3 Privacy

No privacy implications.

4.4 Security

No foreseeable security implications.

4.5 Contact

Person to be contacted in case of questions about the feature or for funding offers: Tödt, Alexandra [atoedt]

4.6 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'.

5 Discussion

Engländer, Ferdinand [fenglaender], 14 March 2022: Are there any decisions or plans yet which UI compenent will be used to display a search result item? Or will a new UI component be developed that could take slightly different appearances depending on the nature and requirements of an individual item?

Kunkel, Matthias [mkunkel], 08 APR 2025: The feature request is suggested for the JF agenda but it needs an update before deciding upon it. The presentation of search results already looks different in ILIAS 10 than shown above. And there is information missing in chap. 4.3 and 4.4.

Kunkel, Matthias [mkunkel], 22 APR 2025: In chap. 4 is written: 'Preconditions are not checked, if there are preconditions and the clicks on the object, the user will be just presented with the information about precondistions on the respective Info screen.' Recently we had a workshop about empty Info pages and decided to abandon the Info page in the future. So the Info page is no longer a reliable concept for presenting such an information. How about presenting the denial of access due to missing preconditions on a modal? This would work with every component and users stay where they are (which is better usability IMHO).

Schmitz, Tim [tschmitz], 22 APR 2025: I updated the article and mock ups, should be JF ready now. I like Matthias' idea of showing preconditions in a modal, so I changed chap. 4 accordingly.

Seiler, Yvonne [yvseiler], 28 APR 2025: Thanks for the approach to get away from legacy code when searching. When reading the concept, a few questions remained unanswered that I would like to ask here:

  • Could you explain the reasons why you decided for a workflow of a modal with multiple pages instead of a modal with scrollable content or instead of a content page with a back navigation to the “main search” for the Detailed Results? Are there similar types of nesting search results where users might be familiar with this type of search workflow within Modals?
  • When displaying the modal, I'm afraid users lose the connection to where they clicked. How could you make it more visible which Detailed Results are involved?
  • Can preconditions also appear for objects in the detailed results? If so, the approach of displaying the preconditions in a modal (chapter 4) would have to be checked to ensure that a modal cannot be merged into a modal.
  • I understand the problem that the search cannot calculate all possible pages and results in advance. But we should be aware that the pagination so far always shows at least page 1 and the last page (e.g. < 1 | 3 > in course news block indicates there are pages 1 to 3). Do you see a way to communicate that the last page is not displayed here (< 1 | 2 > ), but that there can be page 2 and more?

JourFixe, ILIAS [jourfixe], 28 APR 2025: We highly appreciate this suggestion and accept the feature request for trunk with the following modification:

  • After clicking on "See detailed results" the modal should clearly indicate for which object these details are shown (title of object). This helps users and give them better orientation.
  • We accept using a modal and page navigation within the modal due to currently missing alternatives in the modal implementation. A future way could be a "Show more" button at the bottom of the current list and showing all sub-items within a scrollable content presentation.

6 Implementation

Feature has been implemented by {Please add related profile link of this person}

6.1 Description and Screenshots

{ Description of the final implementation and screenshots if possible. }

6.2 Test Cases

Test cases completed at {date} by {user}

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

6.3 Privacy

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

6.4 Approval

Approved at {date} by {user}.

Utoljára szerkesztette: 28. Ápr. 2025, 15:02, Kunkel, Matthias [mkunkel]