<div dir="ltr">I've followed this conversation to try to absrob the viewpoints so far, before rudely jumping in and sharing my thoughts. :-)<div><br></div><div>Is it possible to distill our consideration of search into something a little less exceptional? Should search always be treated differently than any other content selection/alteration model?</div>
<div><br></div><div>In many cases where search is present there is often some other basic content selection model. For a music player, there is a Artist, Album, Genre content selection model. For system settings there is usually a Hardware, Appearance, Admin, etc. content selection. For Kickoff there's Favorites, Applications, Computer, etc. For some reason search is often visually treated as a something completely different - usually by putting the search field in a completely different location than the other content selection mechanisms.</div>
<div><br></div><div>The consequence can sometimes get messy. If you have Artist selected and you do a search that displays songs in the search result, the UI ends up in this inconsistent state where the search field is highlighted and songs are being displayed but Artist is still selected. If the designer is careful, they'll deselect Artist (leaving a useless category selection pane with nothing selected), or hide the category selection all-together (like Kickoff does). </div>
<div><br></div><div>My question is why? If other forms of content selection are available, why treat search as a completely different form of content selection? When you select Artist in a music player, the content changes to show artists. When you select your Document folder in the places panel in dolphin, the content changes to show the files in your Documents folder. When you search, the content changes to reflect what you're searching for. Why not use the same space and interaction model in the UI for search as other category selection mechanism? Sure you have to type but is that really the only thing that really compels a completely different location for the search field?</div>
<div><br></div><div>If I have a simple two panel layout with category selection on the left and content on the right, then search goes on the left with all the other categories. The upside being that it cleans up the UI because I didn't have to find a whole other place to put search. I've had the opportunity to use this in several application designs across several platforms and have not observed any degradation in user search experience. I'm not saying there are never good reasons to elevate the search field to a primary, distinct point of focus for any UI design - Unity does it well I think. Rather, I think it should be the exception rather than the rule/guideline.</div>
<div><br></div><div>*Filtering* of existing content, on the other hand, really should go into the content view. The category selection doesn't change as a result of filtering. And with search as just another form of category selection, you can conceivably filter search results - very useful.</div>
<div><br></div><div>Sorry for rambling but I hope this is helpful!</div><div>Andrew</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 24, 2014 at 8:16 AM, Heiko Tietze <span dir="ltr"><<a href="mailto:heiko.tietze@user-prompt.com" target="_blank">heiko.tietze@user-prompt.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Am 23.03.2014 16:25:08, schrieb Philipp Stefan:<div class=""><br><blockquote>I have made some mockups concerning the placement of the search field.<br>
</blockquote></div><p>Great work! I like it all ;-)<br></p><p>But why do you change the search icon (magnifier) into a yin-yang whatever arrow? Overloading a control is bad usability in most cases.<br></p><div class=""><p>
<br></p><blockquote>[2/A] Here I tried to integrate the search field with the search button. <br></blockquote></div><p>Users might understand the search function to be related to the topics. </p><div class=""><p><br></p>
<blockquote>
[3/B] Placement on the upper right.<br>[4/C] Top centred search field. <br></blockquote></div><p>My aesthetic appreciation prefers 4/C. But all mockups replace the original header line. This is a problem when the content jumps down on search, that means when a further search bar is opened. Can't we integrate them? Perhaps right hand of the address line (> cool wallpapers).<br>
</p><div class=""><p> <br></p><blockquote>[5/D] Search field on the bottom.<br></blockquote></div><p>I think it's a no-go to open a small input on demand somewhere at the bottom. <br></p><div class=""><p> </p><blockquote>
I would find [2/A] to be the most elegant solution, but the limited <br>space makes it also impractical when searching for longer search terms. <br>This could be of course the solved by scaling down the font used, but it <br>
would also introduce some visual inconsistency.<br></blockquote></div><p>Scaling the font is treated as crime in some circles :-).<br></p><span></span></div>
<br>_______________________________________________<br>
kde-guidelines mailing list<br>
<a href="mailto:kde-guidelines@kde.org">kde-guidelines@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kde-guidelines" target="_blank">https://mail.kde.org/mailman/listinfo/kde-guidelines</a><br>
<br></blockquote></div><br></div>