<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 30.03.2014 00:18, Heiko Tietze
wrote:<br>
</div>
<blockquote cite="mid:1989760.06ANyFACf8@sonne" type="cite">
<pre wrap="">On Tuesday 25 March 2014, 20:38:05 Andrew Lake wrote:
</pre>
<blockquote type="cite">
<pre wrap=""><a class="moz-txt-link-freetext" href="http://wstaw.org/m/2014/03/26/Category_search_pattern.png">http://wstaw.org/m/2014/03/26/Category_search_pattern.png</a>
</pre>
</blockquote>
<pre wrap="">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
<a class="moz-txt-link-abbreviated" href="mailto:kde-guidelines@kde.org">kde-guidelines@kde.org</a>
<a class="moz-txt-link-freetext" href="https://mail.kde.org/mailman/listinfo/kde-guidelines">https://mail.kde.org/mailman/listinfo/kde-guidelines</a>
</pre>
</blockquote>
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.<br>
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.<br>
<br>
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.<br>
<br>
Let's imagine a music player:<br>
<blockquote>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:<br>
1) Click on the album and then navigate the the song<br>
2) Click on "songs" in the sidebar and then directly navigate to
the song in question<br>
This way no additional options for the search is needed - the
different options in the sidebar become the search controls.<br>
<br>
</blockquote>
Let's imagine a application with a complicated structure like a file
browser:<br>
<blockquote>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.<br>
<br>
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.<br>
<br>
</blockquote>
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. <br>
<br>
The different shortcuts will then only be a quick way to change
between different parameters of the search function.<br>
<br>
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.<br>
<br>
What do you think?<br>
<br>
Phil<br>
<br>
<br>
</body>
</html>