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

[Thomas Pfeiffer]

On Sunday 30 March 2014 19:36:30 Philipp Stefan wrote:
> 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

I think unifying search and filter mechanism makes a lot of sense from a user 
perspective. It might be difficult to convince developers because they seem to 
usually prefer to present things in a technically precise manner (Jens' 
"precise vs. correct" comes to mind once again), but for users a filter and a 
search in the current folder is presumable the same.