Friday July 4th, 2014byHeiko TietzeandThomas Pfeiffer
We prepared a preliminary human interface guideline (HIG) on search some time ago, and created mockups for core application to prove the concept. Th discuss on the KDE forums (with announcement on the respective mailing) for Kate, Dolphin, and KMail.
First of all, many thanks to the developers who took the time to discuss alternative solutions and to explain why search functionality was realized in the current way. Of course, after many years of working on a successful tool like Kate, workflows are highly differentiated. For instance, in Kate it is needed to refine search results. This way an user can search for a pattern in several files and afterwards filter the resulting list again. As this operation is an iterative process a secondary dialog for search is not an option for Kate. But in other applications such an extra dialog still makes much sense.
One thing we learned from the discussions was to discriminate further between static and dynamic filters. The first one is always shown and has no option to toggle it on or off by a short-cut. This kind of filter is known from Amarok for example as a way to access a song out of a potentially large list. On the other hand most applications need fast access when users just do not want to browse through a list. An example for this type of filter is Dolphin: by default you want to see all files, but sometimes it makes sense to restrict it to documents only. This difference between static and dynamic filters has to be taken into consideration.
Generally, the KDE usability team recommends to discriminate between search, static filter, dynamic filter, and highlighter. The full guideline can be found at the KDE wiki.
A proof-of-concept example is based on KMail. To have both the static and dynamic filter in one application (which is not recommendable) the list of accounts can be reduced to a particular item.
The search function generates a subset out of a big number of items based on a user-defined pattern. The query can be assembled using an extra dialog but it should be also possible to use direct input.
The extra search dialog makes use of a pattern introduced by Amarok. All available options are provided in the upper list, selected per drag ‘n drop for the actual filter below (this needs some refinement for accessibility), specified with a certain value, and aggregated into the complete search query. The query can be saved with a user-defined name, and will be listed and reloaded under a folder with this name.
The idea for easy depiction and modification of the query is based on the query parser by . The query is shown above the result list and should get activated by the short-cut ctrl+H.
A filter is used to restrict the number of items of a list. This list may also be the result of a search. In this case, the filter would be dynamical, that means the user can switch it on or off (per short-cut ctrl+I). Dynamic filters are shown below the list to avoid jumping content. Many filters have options for fine-tuning, like applying a case-sensitive pattern or to interpret a pattern as a regular expression. Those options could be combined into one control in order to make the filter widget plain and simple on first glance. Usually the filter is cleared when the context is changed. Introduced by Dolphin, the idea is to add an option to make the filter sticky so it persists until the user clears it by herself.
In contrast, the static filter is part of the navigation and always shown. Users cannot toggle it off except using the menu or via configuration switch. Static filters are placed above the respective control. It is recommended to not use both static and dynamic filters in one dialog.
Almost every text processing tool has the option to seek for a certain word. Since the function usually highlights the result we call it the highlighter search. The common behavior is to open the input below the content on ctrl+F and to provide a forward/backward function with next/previous buttons (F3 and shift+F3).
Most highlighters have options to a) highlight all occurrences and b) to run the operation case-sensitive. Thus, we recommend to add a combo-box for multiple selections with at least these two options. To reveal the actual selections without the need to expand the combo box, its caption can be used. Initially the text would be ‘Options’ which makes it clear what users can do, and if one or more options have been checked it shows something like ‘Case-Sensitive, Regular Expression’ or in case of narrow width ‘Case-Sens… +1′. The +1 denotes that one more item has been chosen (the tooltip shows all selections).
The guideline should be in a state where it can be used in existing and new applications. Needless to say that the recommendations are not obligatory. For example, Kate has a sophisticated UI and an elaborated workflow for search. But at least short-cuts should be consistent over applications.
Some ideas are adopted from other applications or completely new. Now it’s up to the visual design group to create fancy layouts, and to developers to implement algorithms.