<div dir="ltr">Oh sure Thomas, I should have thought of that. I'm always the one saying preach with the pixels not the words! Sorry. :-)<div><br></div><div>Bangarang:</div><div><a href="http://bangarangkde.files.wordpress.com/2010/11/app-korn.png?w=740&h=547">http://bangarangkde.files.wordpress.com/2010/11/app-korn.png?w=740&h=547</a></div>
<div><br></div><div>A couple mockups I shared with the VDG (in the mockup toolkit) for a file manager:</div><div><a href="http://wstaw.org/m/2014/03/24/fm.png">http://wstaw.org/m/2014/03/24/fm.png</a><br></div><div><br></div>
<div>and a music player:</div><div><a href="http://wstaw.org/m/2014/03/24/mp.png">http://wstaw.org/m/2014/03/24/mp.png</a><br></div><div><br></div><div>In these particular mockups, the search is exposed in the UI with a simple search icon rather than a text field, but that less important. The word "Search" could accompany the icon to make it a bit more discoverable. Search could also be the first entry in the list if it is more appropriate. But, the number of interaction steps would be exactly the same: </div>
<div>1. Click to focus/activate</div><div>2. Type</div><div>3. Enter (only necessary if the interaction pattern is search-on-enter vs search-as-you-type).</div><div><br></div><div>In all these cases, category selection (including search) is on the left and content corresponding to that selection is on the right. The behavioral model is consistent whether you select a category or search: Content on the right reflects actions taken on the left AND selections on the left are mutually exclusive.</div>
<div><br></div><div>I've also used this pattern in a few Android applications with good results. Of course, while this is a design pattern I've found quite useful in practice, there's always the possibility that you folks may identify some downsides with this approach. I certainly welcome the feedback. :-)</div>
<div><br></div><div>Hope this helps,</div><div>Andrew</div><div><br></div><div>P.S. In the case of Bangarang, *filtering* was exposed in the content window where the content corresponding to any category selection on the left, including search, could be filtered. </div>
<div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 24, 2014 at 12:45 PM, Thomas Pfeiffer <span dir="ltr"><<a href="mailto:colomar@autistici.org" target="_blank">colomar@autistici.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Monday 24 March 2014 12:22:10 Andrew Lake wrote:<br>
> I've followed this conversation to try to absrob the viewpoints so far,<br>
> before rudely jumping in and sharing my thoughts. :-)<br>
><br>
> Is it possible to distill our consideration of search into something a<br>
> little less exceptional? Should search always be treated differently than<br>
> any other content selection/alteration model?<br>
><br>
> In many cases where search is present there is often some other basic<br>
> content selection model. For a music player, there is a Artist, Album,<br>
> Genre content selection model. For system settings there is usually a<br>
> Hardware, Appearance, Admin, etc. content selection. For Kickoff there's<br>
> Favorites, Applications, Computer, etc. For some reason search is often<br>
> visually treated as a something completely different - usually by putting<br>
> the search field in a completely different location than the other content<br>
> selection mechanisms.<br>
><br>
> The consequence can sometimes get messy. If you have Artist selected and<br>
> you do a search that displays songs in the search result, the UI ends up in<br>
> this inconsistent state where the search field is highlighted and songs are<br>
> being displayed but Artist is still selected. If the designer is careful,<br>
> they'll deselect Artist (leaving a useless category selection pane with<br>
> nothing selected), or hide the category selection all-together (like<br>
> Kickoff does).<br>
><br>
> My question is why? If other forms of content selection are available, why<br>
> treat search as a completely different form of content selection? When you<br>
> select Artist in a music player, the content changes to show artists. When<br>
> you select your Document folder in the places panel in dolphin, the content<br>
> changes to show the files in your Documents folder. When you search, the<br>
> content changes to reflect what you're searching for. Why not use the same<br>
> space and interaction model in the UI for search as other category<br>
> selection mechanism? Sure you have to type but is that really the only<br>
> thing that really compels a completely different location for the search<br>
> field?<br>
><br>
> If I have a simple two panel layout with category selection on the left and<br>
> content on the right, then search goes on the left with all the other<br>
> categories. The upside being that it cleans up the UI because I didn't have<br>
> to find a whole other place to put search. I've had the opportunity to use<br>
> this in several application designs across several platforms and have not<br>
> observed any degradation in user search experience. I'm not saying there<br>
> are never good reasons to elevate the search field to a primary, distinct<br>
> point of focus for any UI design - Unity does it well I think. Rather, I<br>
> think it should be the exception rather than the rule/guideline.<br>
><br>
> *Filtering* of existing content, on the other hand, really should go into<br>
> the content view. The category selection doesn't change as a result of<br>
> filtering. And with search as just another form of category selection, you<br>
> can conceivably filter search results - very useful.<br>
><br>
> Sorry for rambling but I hope this is helpful!<br>
> Andrew<br>
<br>
</div></div>Hi Andrew,<br>
while this idea sounds reasonable on an abstract level, I must admit that I<br>
can't really picture how it works in practice. Could you point us to some<br>
screenshots/mockups of applications were this was/will be implemented? Maybe<br>
then we can judge whether it would work for the majority of cases.<br>
Thanks,<br>
Thomas<br>
<div class="HOEnZb"><div class="h5"><br>
<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>
</div></div></blockquote></div><br></div>