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

[Thomas Pfeiffer]

On 25.03.2014 00:38, Andrew Lake wrote:
> 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.

For file managers, putting the search in the Places panel works for 
simple search (though I'd put it at the top, because the list of places 
can get longer than the container's height and you'd have to scroll to 
get to the search) but what about all the search options that e.g. 
Dolphin offers? That wouldn't fit in the panel...

Plus, we have to keep in mind that the places panel in Dolphin is 
optional, so users might not even have it visible but still want to search.

Actually, the "search" in media players is a filter, not a search. If we 
say that a filter should always be placed on top of the thing it 
filters, that would work for media players (Amarok already does it that 
way, too) and file managers as well.

> 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 agree, though, as mentioned before, this only works for a simple 
search with no options. If we have options, they could only be put in a 
popup called from a button in the search field.

> 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

The thing is: Our general approach is to use the HIG to try to 
standardize on what's already there (take the best approach we currently 
see and make that the standard across all KDE software) instead of 
coming up with completely new things.
The reason behind that is a practical one: If we standardize on 
something that is already implemented in many applications, chances are 
that other applications currently doing it differently may switch to it 
for the sake of consistency. If we introduce something completely new, 
the risk is high that no application will implement it, and an HIG that 
isn't implemented anywhere doesn't have a high chance of being respected 
in future applications.
The exception to that is, of course, if we don't think any of the 
existing implementations is good enough to become the new standard. In 
that case we have to introduce something new and try to get at least one 
prominent application to implement it, hoping that others will follow 
the good example.

So with all the brainstorming we are currently doing (which is great), 
let's keep in mind that we should preferably use things that are already 
present in some KDE applications.

Cheers,
Thomas