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

[Thomas Pfeiffer]

On Monday 14 April 2014 12:57:40 Heiko Tietze wrote:
> On Monday 14 April 2014, 12:47:26 Philipp Stefan wrote:
> > I'm sorry, I forgot about this e-mail, Heiko.
> > 
> > I like your proposal and I agree that we should move this discussion
> > back into the forums to get more input. How do you want to do it? Just a
> > copy-pasta?
> 
> First, I like to get consensus on the draft of the HIG. Basically it states
> that only filtering is done "inline" and all search operation has to be
> moved to extra dialogs (which might be an overlay and have to be designed
> in future).
> 
> If we agree on the description what we currently have, I plan to outline all
> considerations along with this guideline for a blog post that might be as
> well good for the forum. Hopefully I do not miss any important idea ;-).

Thank you for writing up the results of our discussion so far! There are still 
some things I'd like to discuss further before putting them in the blog, so 
here are some detailed comments.
Regard everything I don't comment on as an implicit "+1"

> == Purpose ==

First of all: This document still does not exactly fit my understanding of 
"pattern". It's still more of a classic HIG to me, so I would suggest to 
remove "Pattern" from the name. What do the others think?

> bypass core functions to a user-defined data set.

That sounds a bit too "science-y" to me. Do we even need that phrase? I think 
it's clear to our users that usually functions/actions can be performed on the 
search results. And actually, there might even be searches where no actions 
can be performed on the result set (though I assume these would be the rare 
exception).

> |
> | Jane has Dolphin open in her Documents folder. Let's say Jane has ~100
> | miscellaneous files there that have built up over the years. Jane also
> | has under Documents several more structured folders with oodles of files
> | as well for different projects over the years, travel expense reports and
> | receipts. Jane thinks that the file she's looking for is one of those
> | ~100 miscellaneous files because that where she typically put documents
> | that aren't project or travel expense related. She thinks the filename
> | starts with "sta"  but isn't sure. So she opens the filter function on
> | Dolphin and types "sta". What she expects is that out of ~100 files
> | Dolphin shows in the Documents folder, some subset will be displayed with
> | filenames starting with or containing "sta". She just wants to reduce the
> | set of data that was already *visible* in Dolphin. She chose filter
> | instead of search because she doesn't care about the 200 or so files in
> | the Documents/Littlesburg Train Station project folder and its subfolders
> | with "sta" in their filename.> 
> She's essentially just restricting her search to what is currently *visible*
> and not trying to recursively search the contents of the currently
> displayed Documents folder. She's still conceptually searching. But how
> she's searching, even in the current folder, is quite different.> 
> |}

Yes, this makes it very clear!
 
> == Guidelines ==
> * Provide filter function to shown content by default. Apply search using an
> extra dialog.

Okay, this might need more discussion. I'm not sure why search would always 
need an extra dialog. Search via KRunner or launchers is certainly search, but 
it's done in a simple lineedit. Or would that count as "extra dialog" to you 
because it's not inside another application? If so, we should make the 
distinction more clear.

> === Filter ===
> Highlight matching results and jump to the first occurrence.

This seems to mix up a filter on a set of items with a search within a 
document (which I'd not call "filter", as it does only highlight). I'd say we 
either put search within a document in its own HIG or at least give it an 
extra section, as there clearly are differences.
A filter usually does not highlight results, but reduces the visible set of 
items to those matching the filter. The only case I know where matching items 
are only highlighted is System Settings, and we might change even that because 
in my opinion it does not work well right now (as a match might be on the 
second level which isn't visible when the filtering is performed, so an 
element might be highlighted which doesn't seem to match the filter, though in 
fact one of its children does).

> ==== Appearance ====
> * Hide input control until users start the search.
> {{Note|I'd prefer to show it always but actually that's not the current
> behaviour in general. * Hide the input control in case the filter is not
> the primary function of the app, but show a small button which indicates
> clearly the availability of the function.}} * Active the control and focus
> it on ctrl+F or when user clicks the icon. * Place the input control at the
> bottom of the content area.

Kickoff (the default application launcher) in Plasma Next currently has a 
hidden search field which becomes visible as soon as the user starts typing 
(like GTK/GNOME applications often do). This is a third way, which currently 
only the new Kickoff does.
Do we think this might be a pattern to be followed and should explicitly 
recommend it, or should we discourage it and ask sebas to change it? Having to 
click a button or pressing Ctrl-F to search in Kickoff does not sound like a 
good idea to me, as it would be too many steps. 

We certainly don't want three different ways (always visible, visible when 
typing and visible only when pressing button or shortcut), so we have to make 
sure where we see the future. Two ways would be okay with me, but then we'd 
have to explain when to use which (e.g. depending on how often users are 
expected to use the filter).

Suggestion:
If users are expected to use the filter regularly, make the search field 
always visible. If users are less likely to use it regularly so it would be 
more distracting than helpful if always visible, hide it by default until the 
user clicks a filter button or presses Ctrl-F.


> === Search ===
> <HR>
> ==== Input ====
> * Do not inherit artificial intelligence from users. Search operations have
> always be clear and comprehensible to users. 

"inherit artificial intelligence" again sounds too science-y to me, and might 
actually be incorrect. I could only guess what it means after reading the 
second sentence.
What exactly do you mean by this?

> ==== Appearance ====
> * Run search operation within an extra, modal dialog.

See above. I don't think this is always necessarily the case.

> == Best Practice ==
> * [http://i.imgur.com/eL7mi4K.png Example 1]
> * [http://wstaw.org/m/2014/03/26/Category_search_pattern.png Example 2]

Do you plan to ask the community about the placement in your blog post, or do 
you intend not to define it in the HIG? Because I think it should be defined 
for consistency's sake...

Sorry for asking for more clarification/discussion on quite a few parts of it, 
but I had quite a few occasions recently where I wished we had a Search HIG 
since people tend to implement search rather inconsistently, so I'd like this 
to be as clear and well defined as possible.

Thanks again for all the work on this,
Thomas