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

[Thomas Pfeiffer]

On Monday 24 March 2014 12:22:10 Andrew Lake wrote:
> I've followed this conversation to try to absrob the viewpoints so far,
> before rudely jumping in and sharing my thoughts. :-)
> 
> 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?
> 
> 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.
> 
> 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).
> 
> 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?
> 
> 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.
> 
> *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.
> 
> Sorry for rambling but I hope this is helpful!
> Andrew

Hi Andrew,
while this idea sounds reasonable on an abstract level, I must admit that I 
can't really picture how it works in practice. Could you point us to some 
screenshots/mockups of applications were this was/will be implemented? Maybe 
then we can judge whether it would work for the majority of cases.
Thanks,
Thomas