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

[Andrew Lake]

Oh yeah,

I totally agree that only when there is already another way to browse
through the information at the top level should search share that
interaction pattern. For the moment I see that pattern in file managers,
media players with libraries, kickoff style menus and the like. For me that
covers quite a few applications that traditionally use search.

Taking a stab a filter functionality makes great sense to me.

Regarding the size of the search field on the left, there are couple ways
I've dealt with that in my applications:
1. Wherever the search field is placed, on the left or not, some decision
has to be made about a reasonable size.
2. I've found that space for about 25 characters seem to serve vast
majority of search needs. That's my anecdotal experience developing my
apps, but a simple user study can validate an reasonable number. (Also
search fields for Apple's iTunes and spotlight and Microsoft's Windows 8
search panel and several apps aren't a great deal bigger.)
3. When more space is needed, make the left panel size resizable with a
minimum size corresponding to the minimum size of the search field (~20
characters) and have the search field always fill the width of the panel.
It is exactly the same interaction model the user employs to see more
characters in any of the other non-search categories in the left pane -
resize the pane.

I confess the mockups could probably use more space in the left pane
following these steps, but not insurmountable I don't think. The Bangarang
screenshot shows how these steps can actually solve that problem.

Regarding a dedicated search widget, my personal opinion as just one member
of the VDG (so not speaking for the group) is that we have all the tools we
need to solve UI problems elegantly and beautifully with existing widgets
(they are amazingly flexible and powerful). What's really needed are some
clear and helpful design patterns (specific widget arrangements) to help
app developers understand how to put the widgets together in the right way
to solve a particular information/interaction problem.

With the thought you folks here are already putting into this, I'm excited
to see what great design patterns we come up with for search and filtering

Hope this helps!
Andrew

On Mon, Mar 24, 2014 at 3:35 PM, Philipp Stefan <sogatori at gmail.com> wrote:

> I have to say that I like the idea, but I think it only works in
> applications which can present the same information in different ways i.e.
> a music player or a chat app. You said it yourself already.
> I always thought that the file manager was the "norm" application, but now
> that I really think about it it seems that most applications don't behave
> this way at all.
> So maybe we really should focus on the filter functionality first, because
> the only application that performs an actual search are the file manager
> and KRunner/Kickoff.
>
> You want to integrate the search in the "button" on the left side as well.
> Have you read the e-mails between me and Heiko Tietze[1]? I noticed that if
> we use a standard text field so build the search field then the space is
> very restricted with the current size of the text field and the typeface.
> Does the VDG intent to make a dedicated search widget?
>
> Cheers,
>
> Phil
>
> [1] http://mail.kde.org/pipermail/kde-guidelines/2014-March/000760.html ;
> http://mail.kde.org/pipermail/kde-guidelines/2014-March/000761.html ;
> http://mail.kde.org/pipermail/kde-guidelines/2014-March/000762.html
>
> _______________________________________________
> 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/333f41b1/attachment-0001.html>