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

[Andrew Lake]

On Tue, Mar 25, 2014 at 2:47 AM, Thomas Pfeiffer <colomar at autistici.org>wrote:

>
> 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...
>

This is relatively easily addressed by a collapsible Options section under
Search that is exposed, or made available to be exposed, when search is
active. In practice, I've found this works quite well.


> 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.
>

Fair point. For clarity though, this is proposed as a design pattern that
might be helpful when category/content selection is already available in
your interface design. I (already) fully acknowledge that there will be
times when that is not applicable. And even if it is applicable, I fully
acknowledge that it simply may not fit with the desired visual design for
the application. That's fine too I think.


> 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.


Filters filter already presented content. The pattern works for Amarok's
library because Amarok presents in its entire library in a tree view. Not
all media players do this. In fact very few do. Most have a
category/content selection in a separate pane that is not restricted to
just categories of the music library (e.g. playlists, radio stations,
etc.). The filter pattern is certainly a good solution for Amarok's music
library given the way it is presented.

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.


As mentioned above, collapsible options exposed when search is active is
another way to address advanced search.

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.
>
>
That's fine by me. I do think though that that approach rather compels UI
designers to abandon the guidelines when a potentially better approach is
discovered. It also means it's more likely that new/better approaches will
inevitably be discovered outside of the KDE community, used by UI designers
in conflict with the guidelines and then only adopted by the guidelines
when enough UI designers break the guidelines to use the new approach.

For clarity, I'm not saying my proposal is necessarily better - I was just
proposing it to see if folks here might find it useful, as I have in
practice. I mean this sincerely: I do *not* take any offence if you all
prefer to continue in the direction you were before I popped in. Whatever
you folks come up with will certainly be better than anything we've had
before, so I welcome it! More importantly, if anything I've offered so far
has been found with discomfort or offence, I sincerely apologize. :-)

<offtopic>
I originally had some text here describing my intent to contribute to
putting together a design pattern library. However, rather than derail this
topic any more than I already have, feel free to contact me on via G+, via
email, or on the VDG forum if you're interested in that topic.
</offtopic>

Thanks much for taking the time to consider what I've offered, and please
don't be shy about moving in the direction you originally had planned,

Much respect,
Andrew Lake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-guidelines/attachments/20140325/1c12b9fc/attachment.html>