Description
The search field is an input field in which a searched pattern is typed by the user to search for objects.
The scope of the search may be global or local. The results found relies on the pattern the user has typed in and on the defined search algorithm.
Usage
A search field can be defined for two different purposes: starting a task or helping in an existing task.
Global search: A search field for starting a task
The search field can be used specifically to start a task by finding the object to work on and by finding an application to start with.
In that case, the search field:
- searches in the whole product area (global)
- is displayed in the shell bar of all product’s page (except for the search page)
- ignores the current content of the page and does not filter it.
- displays suggestions in a drop-down list while the user types
The user can then select a suggestion or execute the search. Then the system will navigate directly the item’s page or to a search page with the results if this page exists in the product.
For more information on this case, look at the shell bar guideline and the Enterprise Search Guidelines.
Local search: A search field for helping in an existing task
A search field can be used to filter a collection of items in order to help to user to select them and continue its task with that selection.
In that case:
- the search field is positioned above the content area that is filtered (see Layout and position)
- The content is filtered with live updates or manual update (see Input)
- The filtering is defined by the search algorithm that can be implemented in the front end for simple searches or in the back end using the enterprise search based on search models to be defined (see Search Algorithm)
- A matching pattern highlight is displayed where the matches occur.
- Matching items are temporarily sorted according to the matching score.
Note: The search field is not the only way for finding items from a collection. The user may also have the possibility of scrolling, sorting, filtering (at the columns level, with a filter bar, …) or changing the view.
Best Practices
The field is always displayed above the area that is impacted by the filtering.
Search in narrow areas
In narrow areas (small dialog boxes, right panel), the field can take all the width of the rest of the toolbar. The field can be alone and with a few actions on the list.
Search in the whole page
When the search concerns all the page content, the search field can be put in the middle of the page. The advised width is 32rem (512px).
Search in a table
The search field is displayed in the table toolbar as the first element of the right sided controls.
See details in the Table Toolbar Guideline.
Search in tables filtered by tab pages
When a collection of objects is displayed in several tables, each one included in a tab page, the search field is displayed normally in each table toolbar. Don’t display the search field above the tab pages.
When the user switches from one tab to another, the search pattern typed by the user is kept.
The number of items in each table can be displayed in the tab-page titles but this behavior does not impact the layout initially defined without it: search fields stay in the table toolbars.
To allow the user to configure its own lists, prefers to use the variants instead of the tab pages
Search in several lists
When a collection of items is spitted in several lists where the user can for example move an item from one list to another, it is possible (but not mandatory) to define an unique search field for all the lists.
When it’s not clear what can be searched for in several lists, the search placeholder describes the scope:
When the result is shown after the first character is typed, all areas participating to the search are automatically expanded in order to give a feedback so the user could see the results and decide to continue to type to refine the search or stop typing to select the item in one of the lists.
Search in trees
When a hierarchy or items is displayed in a tree, a search can have two completely different behaviors: displaying the results in the tree or displaying them in a list.
To display the search results, the tree is replaced by a list of node’s names, with, optionally, in a second column, the path of these nodes or only the last folder’s name). The list contains objects but also can contains folders that will have usually a matching score low enough to be displayed after the items.
To better serve the use case of looking for items in domain the user is focused on, the matching score can take in account -slightly- the fact that objects are in an expanded folder or not.
Folders that are part of a structure of the hierarchy are out of the search scope. These folders can be the immovable folders at the root level or can be a repetitive structure at a given depth of the hierarchy.
The clearance of the search field ends the search and restores the display of tree with the similar collapse/expand nodes status. If one or several items are selected in that list, the tree has, in addition, a specific behavior in order to keep visible to the user: All the parent nodes of the selected objects in the list are expanded, and the tree is scrolled in order to see the latest selected item.
This behavior must use the enterprise search back-end.
The advantage of a displaying through a list is that only the first 100*** best matches need to be loaded. The user will rarely scroll down to have more results but will continue to type to refine the search. But if it scrolls and arrives at the end of the list, the next 100*** items must be loaded and appended.
As the user types the search pattern, the tree is updated: the structure of the tree remains, non-matching items disappears, empty folders disappear, and all remaining folders keep their orders and must expanded.
If you can’t open all non-empty folder for performance or memory reasons, you cannot use a tree.
Once the search is finished, the behavior is the same as the “Results in a list” case described above.
Notes:
*As the best relative frequency as the first letter of an English word is 16% for the letter “t” in English language and considering that a folder contains an average of 5 items, the ratio between filtered nodes against all nodes of a tree is (1/5*(16*5)+16) / (1/5*100 +100) = 32/120 = 26% so approximatively a quarter.
**When displaying results in a tree, you are defining a threshold to display the nodes that have a matching score over it. For the end-user point of view, all the visible nodes will have the same matching score because we cannot rank them by matching score and need to keep the tree structure. If you want to take the advantage of the fuzzy search and the matching score, display the results in a list.
***the number of results retrieved is an example but is not specified by this guideline.
Input
The placeholder
The placeholder replaces the label before the input field.
The text of the placeholder starts by “Search” even if the real action is filtering a content.
The term “Search” can be followed by the description of the scope only if the position of the search field in the page layout cannot solve an ambiguity of the search scope.
The search pattern syntax
The search pattern is the text typed by the end-user.
This pattern has a syntax, depending on the search engine used. (Ex: the enterprise search or a simple client-side JavaScript).
The pattern can contain:
- Wildcards: “*”,
- attribute filters : “document:carbon amount:icon-LE50000”
Input behavior
There are 3 types of behavior during the input:
- Live Update: there is usually has a tiny delay that will trigger the search after the user having not typed anything for 400 ms. If the user modifies the search term while the search is still being executed, do not display the intermediate result. Example: Search needs 1 second and user types a letter every 0,5 seconds, then don’t “flicker” the intermediate results. This also applies to type-ahead suggestions.
- Manual update: while the user is typing the pattern, nothing appends; when the user executes search (Enter key or search button pressed) the search is triggered, and the filtered content is updated.
- Manual update with type-ahead suggestions: While the user is typing, suggestions are calculated and displayed in a drop-down list. At any time, the user can have two possibilities:
- Execute the search (same behavior that manual update)
- select a suggestion an item in the list that launches the search or go directly to the selected item’s page.
Search engines
The algorithm of the search drives the behavior of the filtered content while the user is typing in the search field. I can be the "Enterprise Search" or others front-end or back-end seach engines
Enterprise Search engine
The “enterprise search” is based on a search model of one of several tables/views. The definition of this search model is based on design specification:
- Which columns participate to the search?
- How is the matching defined according to the type of data?
- How much the search is fuzzy for each column?
- Which weight has the column score in the global score?
- How often the search indexes should be updated?
For more information see: Enterprise Search
Matching scores can be attributed to matches on the same attribute:
Score of a match on beginning of string is higher than a match on beginning of words.
Score of a match on beginning of words is higher that a match in the middle of a string.
Score on match in the middle of string can be set to zero and so restrict the search on beginning of words/string.
Other front-end or back-end search engines
Even if the complex but complete Enterprise Search services is not used for implementation reasons, the same design questions described above must be answered to provide a good user experience.
Displaying the searched results
Matching pattern highlight
The matching pattern highlight is the feedback indicating where the hits are, i.e which information of the object have matched the search pattern. It helps the user to understand why the object has been selected.
Sorting items
When the content has a predefined and fixed sorting order, (like cards of an overview page), the search result keeps this order while some cards disappear. The matching score is not taken in account to reorder the items.
When the content can be ranked by the user, for example by choosing the ascending/descending sort of a table’s column, the result list will temporarily be sorted according to the matching score of each object.
During this temporary phase, the user can sort the list as he wishes.
Once the search ended (the search field has been reset), the list recovers its initial sort order.
Note: Keeping the initial sort order makes using fuzzy search impossible: if the search is fuzzy, the search will not eliminate enough rows to see changes in the first rows that are visible on screen and the user will not have the impression that the search is working when he types the first characters of the pattern. In other terms, ignoring the matching score in the UI decrease the efficiency of the search.
Switching views
When an area has a content that can be searched and has several views, the search result, and the way it is sorted should be kept when switching from one view to another.