[kde-guidelines] HIG for search needed (?)
Philipp Stefan
sogatori at gmail.com
Mon Apr 14 10:47:26 UTC 2014
I'm sorry, I forgot about this e-mail, Heiko.
I like your proposal and I agree that we should move this discussion
back into the forums to get more input. How do you want to do it? Just a
copy-pasta?
On 08.04.2014 16:02, Heiko Tietze wrote:
> 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.
>
> noframe <http://techbase.kde.org/File:Note-box-icon.png>
> Note
> I'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
> <http://techbase.kde.org/Projects/Usability/HIG/ProgressIndicator>
> if the search takes longer.
> * Provide paging/scrolling of results.
>
>
> Appearance
>
> * Run search operation within an extra, modal dialog.
>
>
> Best Practice
>
> * Example 1 <http://i.imgur.com/eL7mi4K.png>
> * Example 2 <http://wstaw.org/m/2014/03/26/Category_search_pattern.png>
>
>
> --------------------------------
>
>
> 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.)
>
>
>
>
>
> _______________________________________________
> kde-guidelines mailing list
> kde-guidelines at kde.org
> https://mail.kde.org/mailman/listinfo/kde-guidelines
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-guidelines/attachments/20140414/41538222/attachment.html>
More information about the kde-guidelines
mailing list