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

[Heiko Tietze]

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.
 > > 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 ==
> > * 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).
> > === 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.

> > ==== 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.)
> 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? 

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

> ... so I'd like this 
> to be as clear and well defined as possible.


Me too. Please go ahead and scrutinize all in detail.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-guidelines/attachments/20140416/faffd97b/attachment.html>