RFC: Search input design proposal

Development RFCs
,
1

Problem statement

  1. Old visual style - components used for searching and filtering used deprecated PF3 design system or other ad hoc alterations

  2. Inconsistency - similar use cases don’t often use the search inputs the same way. Search inputs and also additional filters wildly deviate across the product

  3. Searching features not supported by PF4 - There is no component in PF4 that would support all currently used search features such as autocomplete, complex queries with multiple operators, etc.

Design proposal

After mapping all the different search inputs across the Foreman, we come up with this design proposal to cover all use-cases currently in Foreman. See interactive prototype here.

Plain search input

2021-08-16-plain_search

Basic search input (with a bookmark functionality)

bookmark

Combination with filter(s)

Combination3

Supported functionalities

  • Search triggers - Enter/ Autosearch upon inactivity (possibility to switch on/off or alternate frequency in settings)
  • Complex queries (with multiple operators)
  • Fulltext search - for names / descriptions / messages (no need to add query format Name = maria)
  • Autocomplete
  • Bookmarks - it’s possible to bookmark a search query that was created also with an additional filter. This will be stored and restored in the form of a search query)
  • Deletion with X inside the search input or filter chip
  • Chip creation - at the end of the search, to better communicate selected values (results in better control over the search query - no need to scroll right/left within the small search input component) For extremely long queries, a chip truncation is an option.

Give us your feedback
These designs were discussed just with a small number of users, therefore we would like to invite you to share your opinions with us. You could either fill out a short questionnaire, leave a comment under the article, or drop me a message.

Note: This is just a design proposal, which may not be implemented exactly in this way. Recently, PF4 has been looking at our requirements and working on their own solution (not very different from the proposed one here).

1 Like
2

How does it interact with combinations? If we take the State dropdown as an example, does that mean I can no longer add state = installed in the Search query field? What happens if I do?

1 Like
3

You can still write state = installed inside the query. It won’t limit you. So you can write state inside the query and also (at the same time) inside the search input - the result would be the same. If you want to delete it, you need to delete both instances to take an effect.
You can write the entire query inside the search input (filters are just for quicker use).