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

[Andrew Lake]

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



On Mon, Mar 24, 2014 at 8:16 AM, Heiko Tietze
<heiko.tietze at user-prompt.com>wrote:

> Am 23.03.2014 16:25:08, schrieb Philipp Stefan:
>
> I have made some mockups concerning the placement of the search field.
>
> Great work! I like it all ;-)
>
> But why do you change the search icon (magnifier) into a yin-yang whatever
> arrow? Overloading a control is bad usability in most cases.
>
>
> [2/A] Here I tried to integrate the search field with the search button.
>
> Users might understand the search function to be related to the topics.
>
>
> [3/B] Placement on the upper right.
> [4/C] Top centred search field.
>
> 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).
>
>
> [5/D] Search field on the bottom.
>
> I think it's a no-go to open a small input on demand somewhere at the
> bottom.
>
>
>
> I would find [2/A] to be the most elegant solution, but the limited
> space makes it also impractical when searching for longer search terms.
> This could be of course the solved by scaling down the font used, but it
> would also introduce some visual inconsistency.
>
> Scaling the font is treated as crime in some circles :-).
>
> _______________________________________________
> kde-guidelines mailing list
> kde-guidelines at kde.org
> https://mail.kde.org/mailman/listinfo/kde-guidelines
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-guidelines/attachments/20140324/b5fb5278/attachment-0001.html>