Difference between revisions of "Projects/Usability/HIG/SearchPattern"

< Projects‎ | Usability‎ | HIG
Jump to: navigation, search
(Input)
m (Small language edit)
 
(28 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
__NOTOC__
 
__NOTOC__
{{Construction}}
 
Ref's:
 
* http://www.userfocus.co.uk/resources/searchchecklist.html
 
* http://www.smileycat.com/miaow/archives/002015.php
 
* http://forum.kde.org/viewtopic.php?f=285&t=120079
 
  
 
== Purpose ==
 
== Purpose ==
A ''search function'' allows to generate a subset out of a big number of items on ground of a user defined pattern. The function is essential to find matching items in case of a extended list or if the position of target(s) is unknown, as well as when bulk operations should be executed to a subset. A search operation interrupts the 'predefined workflow' and bypass core functions to a user-defined data set.
+
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. Often search results needs further refinement by a filter.
  
Supplemental to search is the ''filter function'' which rather reduces a given number of items than generating an output. Filtering should be always instantaneous.
+
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. It makes sense to discriminate between a static filter that is part of the navigation and always shown, and a dynamic filter used for the current workflow.
  
== Guidelines ==
+
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.
=== Input ===
+
{| class="wikitable collapsible collapsed" style="border:none"
* Consider to allow iterative search on result lists.
+
* Do not inherit artificial intelligence from users. Search operations have always be clear and comprehensible to users.
+
 
+
* Prefer instant over explicit search.
+
** If the search can be performed quickly and with low resource usage, start searching as the user types.
+
** If the search requires more resources (such as computationally intensive search, reading lots of data from disk or transferring lots of data over the network), start searching only when the user presses enter or clicks the search button.
+
** Do not mix search types.
+
 
+
* Show hints on how to use the search effectively.
+
* Do case insensitive search, unless its important.
+
* Do fuzzy search by default, if applicable. That means extend the results by adding a wildcard to the item.
+
* Make the search box large enough to show at least 20 characters (at the moment: KRunner & Kicker = 24, Konqueror = 54, KCM = 33, cf. ).
+
* Run a combined AND search when two words have been entered unless the term is quoted (e.g. Hello World vs "Hello World")
+
+ Wildcards
+
=== Output ===
+
* Make the search result persistent. Users must not need to research after selecting or referencing an item.
+
* Follow the guidelines on [[Projects/Usability/HIG/ProgressIndicator|delayed operations]] if the search takes longer.
+
* Provide paging/scrolling of results.
+
* Provide auto complete feature to the input based on previous operations.
+
* Show the search pattern at the header of the result list (e.g. "Search results for: <Hello World>")
+
== Appearance ==
+
{| class="wikitable collapsible collapsed"
+
 
! Use case for filter vs. search
 
! Use case for filter vs. search
 
|-
 
|-
| Jane has Dolphin open in her Documents folder. Let's say Jane has ~100 miscellaneous files there that have built up over the years. Jane also has under Documents several more structured folders with oodles of files as well for different projects over the years, travel expense reports and receipts.
+
| Jane has Dolphin open in her Documents folder. Let's say Jane has ~100 miscellaneous files there that have built up over the years. Jane also has under Documents several more structured folders with oodles of files as well for different projects over the years, travel expense reports and receipts. Jane thinks that the file she's looking for is one of those ~100 miscellaneous files because that where she typically put documents that aren't project or travel expense related. She thinks the filename starts with "sta"  but isn't sure. So she opens the filter function on Dolphin and types "sta". What she expects is that out of ~100 files Dolphin shows in the Documents folder, some subset will be displayed with filenames starting with or containing "sta". She just wants to reduce the set of data that was already *visible* in Dolphin. She chose filter instead of search because she doesn't care about the 200 or so files in the Documents/Littlesburg Train Station project folder and its subfolders with "sta" in their filename.
Jane thinks that the file she's looking for is one of those ~100 miscellaneous files because that where she typically put documents that aren't project or travel expense related. She thinks the filename starts with "sta"  but isn't sure. So she opens the filter function on Dolphin and types "sta". What she expects is that out of ~100 files Dolphin shows in the Documents folder, some subset will be displayed with filenames starting with or containing "sta". She just wants to reduce the set of data that was already *visible* in Dolphin. She chose filter instead of search because she doesn't care about the 200 or so files in the Documents/Littlesburg Train Station project folder and its subfolders with "sta" in their filename, .
+
 
She's essentially just restricting her search to what is currently *visible* and not trying to recursively search the contents of the currently displayed Documents folder. She's still conceptually searching. But how she's searching, even in the current folder, is quite different.
 
She's essentially just restricting her search to what is currently *visible* and not trying to recursively search the contents of the currently displayed Documents folder. She's still conceptually searching. But how she's searching, even in the current folder, is quite different.
 
|}
 
|}
 +
== Example ==
 +
The 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. [[Projects/Usability/HIG/Combo_Box| Combo boxes]] are enhanced by a checkbox list together with a caption that shows the selected items or, in case of not enough space, the number of selected items (this pattern needs a separate guideline). The [[Projects/Usability/HIG/Tooltip | tooltipp]] lists all selections.
 +
 +
The 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.
 +
 +
[[Image:KDE-Search_KMail.png|300px]]
 +
 +
== Search ==
 +
* Use a search function to generate results based on various sources with sufficient options.
 +
* Always provide search function via extra secondary dialog.
 +
* Use advanced query parser to show the pattern on the one hand and to enter or modify the query directly.
 +
 +
=== Behavior ===
 +
* Do not abuse a filter for search operations. In particular do not use filter short-cuts to start the search.
 +
* Do not use search as the primary interaction method.
 +
* Show search results with a new reference (e.g. folder), like 'Last search'.
 +
* Allow users to save and reload queries.
 +
 +
* Show the query on ctrl+H.
 +
* Close the query on escape or via close icon.
 +
* Focus the query on alt+H (localization dependend) and on ctrl+H.
 +
* Empty the query on context change but apply the new filter in case of a search reference (e.g. folder).
 +
 +
* Follow the guidelines on delayed operations if the search takes longer.
 +
 +
=== Appearance ===
 +
* Label the query with 'Search'.
 +
* Place the input query above the result list.
 +
[[Image:KDE-Search_Search.png]]
 +
 +
* (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.
 +
* Use a static filter for functions related to the navigation (e.g. if finding an item out of a large list is the regular operation).
 +
* Use a dynamic filter when the operation is part of the workflow (e.g. to just have fast access to an item).
 +
 +
=== Behavior ===
 +
* Make the operation as simple as possible. For instance, do not apply multi-dimensional filtering or do not use logical operators for input.
 +
* Perform filter operations always instantaneously.
 +
* Run operation case insensitive, unless it is important.
 +
* Make input control large enough to show at least 20 characters.
 +
* Consider to provide auto complete feature to the input based on previous operations.
 +
* Do not mix static and dynamic filters in one dialog.
 +
 +
==== Static filter ====
 +
* Do not apply  a short-cut to open or close the input. Consider to have an option in the menu under 'view' or the configuration.
 +
* Do not clear the filter on context change.
 +
* If a Plasmoid or Plasma dialog has a filter capability, always use a static filter since there is no menu to show or hide it.
 +
 +
==== Dynamic filter ====
 +
* Show the filter input on short-cut ctrl+I
 +
* Hide the filter on escape or via close icon.
 +
* Focus the input on alt+I (localization dependent) and on ctrl+I.
 +
* 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.
 +
* If necessary, provide a combo box for multiple selection with at least the option to a) run the filter case-sensitive and b) to highlight all.
 +
 +
=== Appearance ===
 +
* Label the input with 'Filter'.
 +
* Show the static filter input above the list of items  but the dynamic filter input below the list of items to avoid jumping content.
 +
[[Image:KDE-Search_StaticFilter.png]] [[Image:KDE-Search_DynamicFilter.png]]
 +
 +
* (Yet to be defined by the VDG)
 +
 +
=== Implementation ===
 +
* (To be defined by devs)
 +
 +
== Highlight ==
 +
* Provide a 'highlight search' for text content. It highlights occurrences of the specified string in the text.
  
=== Input ===
+
=== Behavior ===  
* Discriminate instant search from search that needs to be started explicitly by
+
* Perform highlight operations always instantaneously.
** a special decorator of a common icon. Use version a) for the first option, and b) for second one.
+
* Make the operation as simple as possible.
** adding ellipsis to the inline text: 'Search...' instead of 'Search'
+
* Always add the Next/Previous buttons.
* Search input consists of an icon, a line input to enter the search pattern, and a button to start the search. (VDG made a proposal how it looks nice; Actually, icon is not standard currently but makes sense; Make sure search icon is not mixed-up with zoom!; Omit icon because of lightweight appearance)
+
* Run operation case insensitive by default.
 +
* Make input control large enough to show at least 20 characters.
 +
* Consider to provide auto complete feature to the input based on previous operations.
 +
* Provide a combo box for multiple selection with at least the options to a) run the filter case-sensitive and b) to highlight all.
  
* ''Placement'' (Presuming the app contains of a ''navigation area'' (or ''category selection'') left hand with ~1/3 of screen real estate, and a ''content area'' for the remaining space.)
+
* Show the highlighter input on short-cut ctrl+F.
** Start search at the upper right area of your dialog (KCM and input for web browser's search engine).
+
* Hide the highlighter input on escape or via close icon.
** Start above the content area (Search in Dolphin, KMail - search within current mail, KSystemLog)
+
* Focus the input on alt+F (localization dependent) and on ctrl+F.
** Start below the content area (Filter in Dolphin, Konqueror / Rekonq / Browser search within current page in general, KWrite, Konsole, Okular). (Most might be understood in terms of a filter since it don't generate something but jump to the right position!)
+
* Provide the [[Projects/Usability/HIG/Keyboard_Shortcuts | standard short-cuts]] F3/shift+F3 to go to the next/previous item.
** Start above or below depending on the layout (Kicker, if started from a top- or bottom-aligned band).
+
** Make search floating (KRunner style).
+
** Use an extra (modal) dialog (KMail search for mails, Krusader).
+
** Start above the navigation area/category selection to clean the content on-the-fly (Bangarang).
+
  
<cite="Thomas Pfeiffer">Above the content appears to be the common position for search bars that are always visible (like KMail or System Settings) while bottom seems to be the common position for search bars that only appear when a search is initiated (via the menu or Ctrl-F). </cite>
+
=== Appearance ===
 +
* Place the input control below the content area.
 +
* Label the input with 'Find'.
 +
[[Image:KDE-Search_Highlighter.png]]
  
* ''To show or not to show:''
+
* (Yet to be defined by the VDG)
** Always show search input. Do not hide the availability from users.
+
** Show input control only when users start the search.
+
** Hide the control in case the search is not the primary function of the app, but show a small button which indicates clearly the availability of the function.
+
** Active the control and focus it on Ctrl+F or when user clicks the icon.
+
** Do not use search icon anywhere else.
+
  
=== Output ===
+
=== Implementation ===
* ''How to present results'' (Depends on use case?)
+
* (To be defined by devs)
** Highlight search results (KCM mode).
+
** Hide non-matching results (Kicker mode).
+
** Generate a new list that matches the search pattern  (KRunner mode).
+
  
== Best Practice ==
+
== Legacy references ==
 +
* [http://i.imgur.com/eL7mi4K.png Example 1]
 +
* [http://wstaw.org/m/2014/03/26/Category_search_pattern.png Example 2]
  
 
[[Category:Usability]][[Category:Structure]][[Category:Organizational_Model]]
 
[[Category:Usability]][[Category:Structure]][[Category:Organizational_Model]]

Latest revision as of 17:57, 1 August 2014


[edit] 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. Often search results needs further refinement by a filter.

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. It makes sense to discriminate between a static filter that is part of the navigation and always shown, and a dynamic filter used for the current 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.

[edit] Example

The 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. Combo boxes are enhanced by a checkbox list together with a caption that shows the selected items or, in case of not enough space, the number of selected items (this pattern needs a separate guideline). The tooltipp lists all selections.

The 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.

KDE-Search KMail.png

[edit] Search

  • Use a search function to generate results based on various sources with sufficient options.
  • Always provide search function via extra secondary dialog.
  • Use advanced query parser to show the pattern on the one hand and to enter or modify the query directly.

[edit] Behavior

  • Do not abuse a filter for search operations. In particular do not use filter short-cuts to start the search.
  • Do not use search as the primary interaction method.
  • Show search results with a new reference (e.g. folder), like 'Last search'.
  • Allow users to save and reload queries.
  • Show the query on ctrl+H.
  • Close the query on escape or via close icon.
  • Focus the query on alt+H (localization dependend) and on ctrl+H.
  • Empty the query on context change but apply the new filter in case of a search reference (e.g. folder).
  • Follow the guidelines on delayed operations if the search takes longer.

[edit] Appearance

  • Label the query with 'Search'.
  • Place the input query above the result list.

KDE-Search Search.png

  • (Yet to be defined by the VDG)

[edit] Implementation

  • (To be defined by devs)

[edit] Filter

  • Apply filter to restrict the number of items of a list.
  • Use a static filter for functions related to the navigation (e.g. if finding an item out of a large list is the regular operation).
  • Use a dynamic filter when the operation is part of the workflow (e.g. to just have fast access to an item).

[edit] Behavior

  • Make the operation as simple as possible. For instance, do not apply multi-dimensional filtering or do not use logical operators for input.
  • Perform filter operations always instantaneously.
  • Run operation case insensitive, unless it is important.
  • Make input control large enough to show at least 20 characters.
  • Consider to provide auto complete feature to the input based on previous operations.
  • Do not mix static and dynamic filters in one dialog.

[edit] Static filter

  • Do not apply a short-cut to open or close the input. Consider to have an option in the menu under 'view' or the configuration.
  • Do not clear the filter on context change.
  • If a Plasmoid or Plasma dialog has a filter capability, always use a static filter since there is no menu to show or hide it.

[edit] Dynamic filter

  • Show the filter input on short-cut ctrl+I
  • Hide the filter on escape or via close icon.
  • Focus the input on alt+I (localization dependent) and on ctrl+I.
  • 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.
  • If necessary, provide a combo box for multiple selection with at least the option to a) run the filter case-sensitive and b) to highlight all.

[edit] Appearance

  • Label the input with 'Filter'.
  • Show the static filter input above the list of items but the dynamic filter input below the list of items to avoid jumping content.

KDE-Search StaticFilter.png KDE-Search DynamicFilter.png

  • (Yet to be defined by the VDG)

[edit] Implementation

  • (To be defined by devs)

[edit] Highlight

  • Provide a 'highlight search' for text content. It highlights occurrences of the specified string in the text.

[edit] Behavior

  • Perform highlight operations always instantaneously.
  • Make the operation as simple as possible.
  • Always add the Next/Previous buttons.
  • Run operation case insensitive by default.
  • Make input control large enough to show at least 20 characters.
  • Consider to provide auto complete feature to the input based on previous operations.
  • Provide a combo box for multiple selection with at least the options to a) run the filter case-sensitive and b) to highlight all.
  • Show the highlighter input on short-cut ctrl+F.
  • Hide the highlighter input on escape or via close icon.
  • Focus the input on alt+F (localization dependent) and on ctrl+F.
  • Provide the standard short-cuts F3/shift+F3 to go to the next/previous item.

[edit] Appearance

  • Place the input control below the content area.
  • Label the input with 'Find'.

KDE-Search Highlighter.png

  • (Yet to be defined by the VDG)

[edit] Implementation

  • (To be defined by devs)

[edit] Legacy references


This page was last modified on 1 August 2014, at 17:57. This page has been accessed 3,323 times. Content is available under Creative Commons License SA 3.0 as well as the GNU Free Documentation License 1.2.
KDE® and the K Desktop Environment® logo are registered trademarks of KDE e.V.Legal