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

[Thomas Pfeiffer]

On Tuesday 25 March 2014 09:51:44 Andrew Lake wrote:
> 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.

Picture, please ;) I guess I understand what you mean on an abstract level, 
but would like to see it "in action"

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

That was not meant as an argument against the pattern as such, just to point 
out a potential pitfall with flexible UIs.

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

We could still place the search/filter field above the other categories even 
if it's a "real" search, couldn't we?

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

I didn't mean we cannot introduce something new via the HIG. It's just that if 
we do, we have to make such a convincing case for it that we can convince some 
developers to implement it soon after the HIG is released, so that people can 
see it in action.

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

It seems like my previous email came off too harsh. Sorry for that. I tend to 
focus on pointing out potential problems with new ideas. I only mean to be 
cautious so ideas won't fail just because some aspect hasn't been given enough 
thought, but it seems like often end up discouraging people which are excited 
about new ideas.

If I point out potential problems with an idea, it usually means that I like 
the idea in general. If I don't I usually just quietly hope that it will lose 
momentum and fade away without me having to fight it ;)

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

Actually, one part of the project that got me involved with KDE more than five 
years ago (damn, time flies!) was exactly that, and its results can still be 
seen here: 
http://techbase.kde.org/Projects/Usability/HIG/SOU_Workspace#Design_Patterns
Sadly it hasn't really taken off (yet), but I'd love to revive that project 
together with you and anyone else interested!

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

Sorry again if I discouraged you. You input is greatly appreciated, and 
nothing has been decided yet!