[kde-guidelines] HIG for search needed (?)

[Heiko Tietze]

On Thursday 17 April 2014, 20:29:13 Thomas Pfeiffer wrote:
> As stated before, I see three different things (filter a list, search
> anywhere and highlight within opened document), and in order to keep HIGs
> short, we should in fact create one HIG for each, and interlink them.
> I'd focus on the filtering first, since this is what the current draft
> mostly talks about.
After talking with Thomas we agreed on having three types of search for 
different use cases. The HIG proposal is now as following:

== Purpose ==
A ''search'' function allows to generate a subset out of a big number of items 
on ground of a user defined pattern. It usually can 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 be always 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 used to locate a 
particular piece of information without concealing the surrounding.

(Use case)

== Search ==
* Use a search function to generate results based on various sources with 
sufficient options.
* Always provide search function via extra secondary dialog.

=== Behavior ===
* Do not inherit artificial intelligence from users. Search operations have 
always be clear and comprehensible to users.
* 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+H 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. Do not use 
'filter' or other labels.

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