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

[Heiko Tietze]

Am 30.03.2014 19:36:30, schrieb Philipp Stefan:
> 
    I think this way the guidelines can be simplified greatly and I
    think the behaviour of the whole function become clearer/more
    consistent to the user.

Yes!

I was thinking about a better HIG for a while. We have discussed a lot of options, especially about the position of the control. Reviewing the current layout I get these results:

** Start search at the upper right area of your dialog (KCM and input for web browser's search engine).
** Start above the content area (Search in Dolphin, KMail - search within current mail, KSystemLog)
** Start below the content area (Filter in Dolphin, Konqueror / Rekonq / Browser search within current page in general, KWrite, Konsole, Okular).
** 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).

I started with this consideration but most of these operations might be understood in terms of a filter since it don't generate something new but jump to the right position! So what's about the simple advice to use a standard 'filter' and search per extra dialog. This would affect only Dolphin, but solves the strange "from here" issue by the way.

Therefore I stripped all discussion from the HIG and applied a different structure (please understand it as proposal not solution; all changes can be reverted).
http://techbase.kde.org/Projects/Usability/HIG/SearchPattern
--------------------------------
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.

[show] Use case for filter vs. search
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.






 
NoteI'd prefer to show it always but actually that's not the current behaviour in general.
 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. 
Best Practice 
 Example 1
 Example 2

--------------------------------
For now, most apps places the filter bar below the content. That should be used as the state of the art for the HIG but might be as well a good starting point to improve the layout with Plasma Next. Because a mailing list is not so good for discussions I vote for moving back to the forum with all advanced ideas and to keep the legacy stuff here. (I know it was me who moved the discussion first to the ML, sorry.)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-guidelines/attachments/20140408/40cc696f/attachment.html>