Projects/Usability/HIG/SearchPattern
| Under Construction |
|---|
| This is a new page, currently under construction! |
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.
Supplemental to search is the filter function which rather reduces a given number of items than generating an output. Filtering should be always instantaneous.
| 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 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. |
Guidelines
- Provide filter function to shown content by default. Apply search using an extra dialog.
Filter
Input
- 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.
Output
- Make the filter result persistent until it is cleared explicitly. Users must not need to research after selecting or referencing an item.
- Provide auto complete feature to the input based on previous operations.
- Highlight matching results and jump to the first occurrence.
Appearance
- Hide input control until users start the search.
- Hide the input control in case the filter 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.
- Place the input control at the bottom of the content area.
Search
Input
- 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.
- Do fuzzy search by default, if applicable. That means extend the results by adding a wildcard to the item.
- Run a combined AND search when two words have been entered unless the term is quoted (e.g. Hello World vs "Hello World")
Output
- Show the search pattern at the header of the result list (e.g. "Search results for: <Hello World>")
- Follow the guidelines on delayed operations if the search takes longer.
- Provide paging/scrolling of results.
Appearance
- Run search operation within an extra, modal dialog.
