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

[Philipp Stefan]

On 30.03.2014 00:18, Heiko Tietze wrote:
> On Tuesday 25 March 2014, 20:38:05 Andrew Lake wrote:
>> http://wstaw.org/m/2014/03/26/Category_search_pattern.png
> I think the position is good in case of some preselection is done left-hand.
> But if we have navigational content it absolutely makes no sense to place a
> search field there that affects the content only. For instance a file browser
> with folders on the left and files at the client area.
>
> All else looks nice to me except the missing main menu and the missing
> scrollbar arrows. :-)
> _______________________________________________
> kde-guidelines mailing list
> kde-guidelines at kde.org
> https://mail.kde.org/mailman/listinfo/kde-guidelines
I think so, too. I think the search field should be placed in the menu 
bar when the search will be performed in a global manner / lots of 
different directories that can't be accessed via the sidebar. Dolphin 
and I guess  Kmail would also fit in this category.
Apps that use the sidebar to navigate the applications/ between 
different grouping options of the data should place the search field in 
the sidebar. A music player or a social media application would fall 
into this second category.

In these second applications the search function is just a simple filter 
functions. And based on that I'm going to claim that the difference 
between search and filter is actually pretty meaningless in most use cases.

Let's imagine a music player:

    The applications currently is displays the album view. The user
    opens the search dialogue and attempts to search for a specific
    song, because the search function actually is filter here the
    application will display the album which contains the target song.
    The user now has two choices:
    1) Click on the album and then navigate the the song
    2) Click on "songs" in the sidebar and then directly navigate to the
    song in question
    This way no additional options for the search is needed - the
    different options in the sidebar become the search controls.

Let's imagine a application with a complicated structure like a file 
browser:

    1)The application currently displays a random directory. The user
    wants to find a file and has no idea where it resides. He calls the
    search function and the search field appear in the menu bar along
    with the option to display more settings. The search then returns
    the wished results and the user will proceed with whatever they had
    in mind.

    2)The user currently navigates a directory with lets say over 100
    files. The user then calls the filter function via a shortcut or a
    menu entry. The search field appears in the menu bar along with a
    option to display more settings. In these setting the option to only
    search the current directory is toggled. The filter will return the
    desired results and the user continues with what they were doing.

With this in mind I propose to always demand an instant search. If the 
search takes a bit longer an indicator that the query is still being 
processed can be shown. We can also get rid of the difference between 
the filter and the search functionality. The search field and the filter 
field are the same entity with the different predefined settings. They 
reside in the same area and use the same label and icon.

The different shortcuts will then only be a quick way to change between 
different parameters of the search function.

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. I think the user generally doesn't really care about the 
technical differences, and those who do can simply change them in the 
search settings.

What do you think?

Phil


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