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

[Thomas Pfeiffer]

On Wednesday 16 April 2014 08:59:08 Heiko Tietze wrote:
> Am 15.04.2014 21:56:21, schrieb Thomas Pfeiffer:
> > > == 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?
> 
> From wikipedia: "A design pattern is a general reusable solution to a
> commonly occurring problem within a given context in software design. ...
> Structural design patterns addressing concerns related to high-level
> structures of applications being developed."
> 
> Alternatives could be: model, norm, standard implementation, composition,
> principle. 

Why can't we just call it Search? What's fundamentally different from the 
other HIGs?

> > > 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).
> 
> Actually, the HIG describes the (current) 'filter' only and does not made
> any assumption of the search. So this part should start with "A filter
> function..." followed by the reference to the (upcoming) search page. Doing
> so we can postpone this issue. ;-) > > == Guidelines ==

*g* Sounds like a good idea to me to first push the Filter guideline out!

> > > * 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.
> 
> As I said in the accompanying mail I suggest to <describe> the current state
> as filter only. Most tools have a filter bar below the content and only a
> few do real search operations. KRunner is not an exception, Kicker might be
> one. I'm aware that it is not a good differentiation because the <filter>
> does not always limit shown information (and search doesn't generate
> complete new stuff).

If whether it opens a new dialog or not is our differentiation between filter 
and search, then I agree that we should call them differently.

> > > === 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).
> 
> The idea was based on Kate/Kmail, or the like, where you have the same
> 'filter bar' as in KCM, Kicker, and KRunner. In summary the filter/search
> operation highlights and does not reduce a list. But I can follow your
> argumentation that this function is understood in text processing not as
> filtering. What's about a different naming like active vs. passive search?
> The former is real search, the latter what I try to describe here with
> filter.

KMail has all three: 
- A feature to find and highlight a string in the currently opened mail 
(invoked via Ctrl-F)
- A filter bar to filter on the currently visible folder (which does not 
highlight, but indeed only shows the mails matching the search term), always 
visible above the list of mails
- A "proper" search over all folders with advanced criteria via an external 
dialog

KMail surely is the most extreme case, but it shows to me that we need to 
distinguish between all three in order to make clear which is which and how to 
design/implement each.

What about
a) Search within active document
b) Filter of currently visible list of elements
c) Search for elements not currently visible

KMail has all three (as described above)
Kate has a) via Ctrl-F or "Edit -> Find..." as well as c) via "Search and 
Replace" at the bottom or "Edit -> Search in Files" (holy f*ck, they named the 
same function differently on the button than in the menu!!!)

Kickoff looks like it only has b), but it turns out it's actually c) (without 
a separate dialog) since it finds files as well, which are not shown when 
browsing through the menu.

So the status quo is a hodgepodge of different stuff all over Plasma and 
Applications. They all do slightly different things and are invoked in a 
slightly different way.

> > > ==== 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.
> 
> I believe the standard right now is hidden by default and visible on
> Ctrl+F, or so. Whatever we do in future releases. (Its much easier to
> discuss changes based on the description of the current state.)

These applications all show the filter bar by default:
KMail, Amarok, JuK, System Settings, Kickoff (at least in Plasma Current),  
Okular shows the search within the text only when Ctrl-F is pressed, but the 
filter over Table of Contents/Thumbnails/Bookmarks is always visible. 

The pattern I see here is that views used for browsing (like the library in 
Amarok or Juk or the list of emails in KMail) seem usually to have the filter 
bar always visible (with the notable exception of Dolphin, but most people I 
talked to about it thought that this was a bad thing!), whereas search within 
the currently open document (like the one in KMail or Okular) are mostly 
invoked with Ctrl-F.

Therefore I suggest we distinguish between filtering a list of things and 
searching within the document, and do the former with an always visible filter 
bar and the latter with one invoked with Ctrl-F or a button.

> > 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.
> 
> IMHO a bad alternative, even when it is a good description, because it gives
> too much leeway. How should devs know what users expect to see in their
> app?

See above. Would the suggestion above make sense to you?

> > > ==== 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?
> 
> KDE is not Google. There should not be any magic behind the operation. On
> the other hand, it concerns only the search HIG - so again: postponed.

Okay, so you meant what I guessed you meant. I don't think "inherit artificial 
intelligence" is what expresses it clearly to people, though. I think "Search 
operations always have to be clear and comprehensible to users" stands for 
itself and doesn't need the first sentence, though.

> > > ==== Appearance ====
> > > * Run search operation within an extra, modal dialog.
> > 
> > See above. I don't think this is always necessarily the case.
> 
> That's the clue of the whole HIG. 

It is? Then I apparently have missed it. I thought it was about standardizing 
the different kinds of search/filter...

> > > == 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...
> 
>  HIG says: "Place the input control at the bottom of the content area.".
> Because its standard right now.

Ah yes, I missed that.
Actually, the standard for filter over a list actually seems to be above the 
list (again, with the notable exception of Dolphin, and again, I think they're 
doing it wrong, but see the other applications I mentioned) while the standard 
for searching within the currently active document is certainly below.

> > ... so I'd like this
> > to be as clear and well defined as possible.
> 
> Me too. Please go ahead and scrutinize all in detail.

I already did that ;)

I really have the impression that filtering a list of things and searching 
within the currently opened/active document are fundamentally different and 
each have their own de-facto standard in KDE, both in invocation and position 
of the search field.
The only application I found which does it differently is Dolphin, so I'd say 
Dolphin should change instead of dictating the standard for others.