Introduction
In the course of preparing Plasma Next, the developers asked the usability team whether or not to hide the search bar from the Kickoff plasmoid unless the user starts to enter text (cf. picture below). This approach makes sense but would be different from the current behavior. After investigating the diversity of KDE solutions we think it’s time to create a generic guideline for the search pattern. It should deal with the behavior, that means what kind of search to apply for a certain use case, as well as the appearance of input and output, including visibility, position, decoration etc.
Pandora’s box
Most KDE applications open a find bar below the content via Ctrl+F. It allows to search for entered text, provides access to next and previous occurrences, and has some options, e.g to use regular expressions instead of string comparison.
Find bar in Konqueror (as example for most other applications).
However, Find (Ctrl+F) activates in Dolphin a line input above the content (with extended functionality), and Ctrl+I shows a ‘Filter’ bar below (with the additional feature to make it sticky).
Find (Ctrl+F) and Filter (Ctrl+I) in Dolphin
Kate activates a line input below the content that can be extended by the replace feature via Find (Ctrl+F). ‘Search and Replace buttons (probably intended without the active Find bar) add a bunch of further options to the pane.
Find (Ctrl+F), Replace (Ctrl+R) and Search in Kate
The Find and Replace pane is activated and handled in KWrite similar to Kate, but without the extended search and replace feature.
Find (Ctrl+F) and Replace (Ctrl+R) in KWrite
Additionally to the Find bar (Ctrl+F) below the mail content, which highlights the search pattern in the mail’s content, a ‘quick search’ is shown via Ctrl+H above the tree view of all mails to filter them on various aspects. (Ctrl+H is used in Kate/KWrite etc. to search for the selection.)
Extended quick search bar (Ctrl+H) in KMail
KMail also provides an advanced Search dialog that opens up by the (unusual) short-cut S.
KMail’s search dialog accessed by the short-cut S.
The current Kickoff Application Launcher always shows a search. It replaces the tabbed tree view by a list view displaying the search result.
Search in Kickoff
KRunner is a search dialog itself (along with other features). It shows a simple line edit with the optional limitation to particular areas.
Search in KRunner
And last but not least – some kind of special solution: the default music player JuK applies a static search bar above the content (without any short-cut).
Search bar in JuK
Executive summary
We have roughly three different workflows that all call themselves ‘search’:
Emphasize a particular text:
Kate, KWrite, Konqueror etc. highlight search results and jump to their first occurrence
Restrict a list of items:
System settings (KCM), Kickoff, Juk and similar apps with large lists provide the feature to reduce the number of items for easier access
Search with the intention to generate new content:
Extended search, as used by KMail or Krusader, generates a new list based on items from various origin (in contrast to filter that operates on one list only)
The operation is currently started by one of the short-cuts Ctrl+F/R, Ctrl+I, Ctrl+H, S (plus F3/Shift+F3, Alt+W…). Sometimes the input is always shown, sometimes only on demand. The input is placed above or below the content, with or without additional features, and so on. What we need is a guideline!
Guideline
Purpose
A search function allows to generate a subset out of a big number of items based on a user defined pattern. It can usually be applied to various sources and has several options for fine-tuning.
Supplemental to search the filter function reduces the number of items. This operation works on the current list only and does not generate a new output. Filtering should always be instantaneous and must not interrupt the workflow.
Similar to filtering the operation might be used to highlight information. This preselection is a common feature in text processing and IS used to locate a particular piece of information without concealing the surrounding.
(Learn morn about the use case at the preliminary HIG.)
Search
Use a search function to generate results based on various sources with sufficient options.
Always provide search function via extra secondary dialog.
Behavior
Show hints on how to use the search effectively.
Run a combined AND search when two words have been entered unless the term is quoted (e.g. Hello World vs “Hello World”)
Follow the guidelines on delayed operations if the search takes longer.
Appearance
(Yet to be defined by the VDG)
Implementation
(To be defined by devs)
Filter
Apply filter to restrict the number of items of a list.
Do not overload the simple filter function by options. If necessary, provide an additional search.
Behavior
Perform filter operations always instantaneously.
Make the operation as simple as possible. For instance, do not apply multi-dimensional filtering or do not use logical operators for input.
Run operation case insensitive, unless it is important.
Make input control large enough to show at least 20 characters.
By default clear the filter input when the content is changed. But consider to provide a sticky function and keep the filter until it is cleared explicitly. With this option users do not need to research after selecting or referencing an item.
Consider to provide auto complete feature to the input based on previous operations.
Appearance
Show the filter pattern above the list of items.
Use Ctrl+I to show/hide the input.
Do not hide the input if the filter is an essential part of the application, i.e. when the list of items usually is large.
Show ‘Search…’ as place holder unless the control is focused.
Implementation
(To be defined by devs)
Highlight
Provide ‘highlight search’ when the content is relevant.
Do not overload the simple highlight function by options. If necessary, provide an additional search.
Behavior
Perform highlight operations always instantaneously.
Make the operation as simple as possible. Do not add options.
Run operation case insensitive.
Make input control large enough to show at least 20 characters.
Consider to provide auto complete feature to the input based on previous operations.
Appearance
Place the input control at the bottom of the content area.
Hide the input by default.
Active the control and focus it on ctrl+F.
Implementation
(To be defined by devs)
Conclusion
Basically the idea is to provide a simple Find (Ctrl+F) bar below the primary information that facilitates content review by highlighting the search pattern. Furthermore, lists or trees may contain a Filter (activated by Ctrl+I or always visible) for the items shown above the control. Both functions should be as simple and standardized as possible. And all extended search features get moved into a separate, perhaps floating dialog.
As a consequence, some applications have to adopt to this guideline, if the community agrees on the guideline. For instance in Dolphin, the upper Find function which is actually a quick filter needs to be simplified (or transferred into a full-featured search), renamed, and short-cuts have to be adjusted. If the search dialog is build up as floating dialog, the result might flawless replace many of today’s inconsistent quick filters.
What we now ask for is your participation: Do you like the idea, or not? Which aspects have to be improved? But we also need a fancy design that discriminates easily between the highlighter and the filter (additionally to the position), and an idea for the new search dialog. The first steps have been made (e.g. at these pics by Andrew Lake, discussed in the forum) but not on grounds of the recommended structure. You are very welcome to join the discussion.