KS Element Search

1 Initial Problem

The Search is comprised of an input and a button but is no form. 

2 Conceptual Summary

UIComponent > Input > Container should get a new entry Search >Standard

Purpose
To input a keyword and trigger a search
Composition
An text input field is provided for term to be searched. It is combined with search button.
Effect
After a term is entered and the search button is clicked ILIAS presents results in the main view.
Background
Search results are ordered according to relevance.
Context
The search element can reside in slates or panels.
The search is offered in the meta bar and in secondary panels of some objects like wiki or forum.
When in doubt the search gets the first / topmost place above other elements in this context. This supports accessibility.
Rival
Filters and View Controls allow for narrowing down objects and subjects to a criterion-specific collection.
Usage
Searches are offered to find objects or sub-objects according to a term.
Interaction
After a term is entered and the search button is clicked ILIAS presents results in the main view.
Wording
The input field has no visible label. The button is labeld Search.
Responsiveness
The combination of input and button is always kept together and never separated.
Even on 320 px screens.
Accessibility
The search carries the search landmark.
Keyboard interface: Tabbing takes user from field to button. Return submits the search. 

3 User Interface Modifications

3.1 List of Affected Views

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

{ Necessary technical information have to be provided here, e.g. dependencies on other ILIAS components, necessary modifications in general services/architecture, potential security or performance issues. }

4.3 Privacy

{ Personal data that will need to be stored or processed to implement this feature have to be listed here. For each date give a short explanation why it is necessary to use that date. }

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

4.5 Contact

Person to be contacted in case of questions about the feature or for funding offers:  {Please add related profile link of this person}

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

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}

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