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

[Thomas Pfeiffer]

On Monday 07 April 2014 11:14:25 Philipp Stefan wrote:
> Hmm, I send this mail a few days ago, but it doesn't seem to have
> arrived. My apologies for the late reply.
> 
> On 01.04.2014 21:22, Thomas Pfeiffer wrote:
> > Oh sure, absolutely. I don't know what Philipp had in mind, but I was
> > always thinking about "search in the current folder only" when I talked
> > about a search that was the same as filtering for the user. That's
> > currently not available in Dolphin's Search (presumably because it would
> > be redundant with the filter function), but it could be.
> 
> Yes you are correct. I should have made this clearer. Right now Dolphin
> has a "From here (FOLDER)" and a "Everywhere" option when calling the
> search function. My idea was to add a "Only here (FOLDER)" option, which
> would be toggled when calling the "filter" function.
> 
> >> Separately, perhaps it might be worth distinguishing this pattern from a
> >> word/item-highlight search where the content isn't altered but the found
> >> items are simply highlighted and you can walk through each search "hit".
> > 
> > Absolutely. Usually you'll find a search which returns a list of items as
> > a
> > result in applications which allow you to browse through something.
> > Word highlight is usually found in applications where you either read or
> > write text. And yes, they need different UIs
> > The third thing is a search for items which can also highlight the search
> > term within the results (Kate's "Search and Replace" comes to mind),
> > which should also be considered.
> 
> I see that this gets more and more complicated (at least from my point
> of view). I think we shouldn't concern us too much with fringe cases and
> only outline some general guidelines. If we have common behaviour like,
> where the search field appears, what information it displays and how to
> deal with the search results. I think this should be enough. I trust the
> developers that they don't suddenly violate the guidelines horribly only
> because they need two more button to realise a highlighting filter like
> Andrew talked about. IMHO a bit more subsidiarity will both make the HIG
> lighter and more comprehensible.

Sure, although I think that distinguishing at least between a search for items 
and a search within a document (the highlighting thing) would make sense, 
because they are really quite different, even with regard to placement: For 
the highlighting search, placing the search field below the document view has 
become pretty much the de facto standard, whereas for item search it's still 
above the item view.

> >> P.S. I do think we should consider my sidebar search suggestion as a
> >> separate, maybe experimental, pattern to revisit at a later date after
> >> we've sorted out this basic search pattern.
> > 
> > A few days ago I head meant to write an email to this list (or maybe I
> > have
> > but can't find it anymore?) suggesting that we should split our ideas into
> > both a search HIG and a pattern.
> > The search HIG would contain everything that we want to standardize,
> > whereas the pattern would be more like an idea for how we think a good
> > search feature could be implemented. So in my terms, your suggestion
> > would be "work on the HIG first, then on the pattern later".
> 
> This sounds like a good idea. Please excuse this one stupid question
> though: What's the difference between a "search pattern" and the "search
> HIG"?

There is no such thing as stupid questions ;)
For me, an HIG is a set of rules/guidelines for a specific UI element or 
characteristic of UI design such as text or help. They are centered on 
describing a specific solution further.
Patterns, on the other hand, start with a problem and offer a solution for the 
problem. They are not so much focused on detailed guidelines, but rather on 
introducing concepts that work for solving the problem.
See 
http://techbase.kde.org/Projects/Usability/HIG/SOU_Workspace#Design_Patterns 
for examples.

Cheers,
Thomas