As proposed in another thread it makes sense to harmonize search, filter, and highlight functions. KMail is one candidate to prove the concept, actually it is the worst-case scenario.

To start with the highlighter below the message content, the current way of presentation is the state of the art in KDE. The only addition from the UX perspective would be to show the options in the drop down menu. The caption remains 'Options' if nothing is set but is changed to 'Case sensitive' if only this one has been checked or 'Case sen... +1' if more were chosen (note the ellipsis and +1 for one more checked option). All actual options are shown in the tooltip.

As suggested by Hans, Filter can be static, i.e. always visible, and dynamic (as right now per ctrl+H). To illustrate the difference I useD a filter for folders instead of the current favorits. It is placed above the control it filters. To focus the line edit one has to use alt+hotkey. The dynamic filter should be opened and re-focused by ctrl+I, closed on escape or via icon left hand. It is located below the control to avoid jumping content. A 'lock' keeps the filter active even when the content changes. In respect to kmail the new quick filter available by toggle buttons via 'more' should be moved to a check list box, similar as for the highlighter options.

Search is available as a simple function, looking in all field for the pattern. Or as advanced feature using either a wizard for generating the query or this query is entered directly into the control. The idea is to use Steckdenis' query parser. A search creates a folder with the name ('Last search' or 'All unread messages') which stores and reactivates the query. This folder should get active on search instead of keeping the current selection.



In short:

Highlighter for mail content
* Show: Ctrl+F
* Hide: Esc, Icon left-hand
* Focus: Alt+F (l10 dependent) and Ctrl+F
* Remark: Preview selected options in tooltip, change the label 'Options' to selected items

Static Filter to mail folders (example instead of current favorits)
* Stays open until closed explicitly via menu/configuration

Dynamic Filter of mails
* Show: Ctrl+I
* Hide: Esc, Icon left-hand
* Focus: Alt+I (l10n dependent) and Ctrl+I
* On context change: empty if not locked (right hand icon)

Search (Query parser with direct input or per wizard dialog)
* Show: Ctrl+H
* Hide: Esc, Icon left.hand
* Focus: Alt+H (l10n dep.) and Ctrl+H
* On context change: Empty line edit or apply query in case of a search folder

Search dialog
* No short-cut
* Result is input for query parser ("search" control)

Are those changes feasible?

PS: 50% of kudos go to colomar. Thanks for hours of discussion!

Just adding to make it absolutely clear: We just picked KMail as an example to demonstrate our general ideas, because it's one of the rare applications that has all three: Search, filter and highlighter, all in the same window.
We don't expect it to get implemented in KMail any time soon, since their resources are scarce and their priorities are on other things at the moment, but if we agree on the design and it's technically feasible in general, that should become the default for all KDE applications (from which specific applications could deviate if it doesn't work for them, of course).

This sounds. I only have some very few nitpicks that might not even be relevant:
1. You wrote that the filter goes above the control it filters in the mock up, however, it went below this control (I know it's just a mockup, but I just want to make sure)
2. Why does the search function not get a short cut, too?
3. I know that we can change it whenever we want, but why do we put "Filter:", "Search:" etc. next to the text field and not in the text field? Wouldn't this be much more space efficient?
4. +2 for using Stackdenis' query parser
5. I'm not sure if I'm a fan of the drop down for the highlighter with the ellipsis and the +1. I don't have a better idea though, so it's good. I'd like to propose a mandatory "unchecked all" option in the drop down, though, depending on how many options go in there (I don't know, really).

Other than that, it looks and sounds good.

Thanks for the feedback! Here are some replies:

Sogatori wrote:1. You wrote that the filter goes above the control it filters in the mock up, however, it went below this control (I know it's just a mockup, but I just want to make sure)

Here the difference between "static" and "dynamic" filters come into play. The one above the folder list is a static one (can only be switched on or off via the menu), the one below the list of emails is a dynamic one (switched on or off by shortcut or esc, is not shown by default). The distinction is a bit tricky, but we felt it's necessary to accommodate applications that have both search and filter bar.

2. Why does the search function not get a short cut, too?

The search field does get one, the button for the dialog doesn't. The point behind it is that the dialog doesn't work well without the mouse anyway, so people either click on the button and use the dialog with the mouse, or they press Ctrl+H to get to the search field and enter their query directly in there.

3. I know that we can change it whenever we want, but why do we put "Filter:", "Search:" etc. next to the text field and not in the text field? Wouldn't this be much more space efficient?

That's mostly a matter of taste. Heiko prefers labels next to fields, I prefer them inside, like you do. We just put one suggestion there to start a discussion about what people prefer.

5. I'm not sure if I'm a fan of the drop down for the highlighter with the ellipsis and the +1. I don't have a better idea though, so it's good. I'd like to propose a mandatory "unchecked all" option in the drop down, though, depending on how many options go in there (I don't know, really).

We don't think it's perfect, but we couldn't come up with something better, either. We're hoping for this community to come up with better ideas

colomar wrote:Why do we put [captions] next to the text field: That's mostly a matter of taste. Heiko prefers labels next to fields...

...because you get an access key for free. Ctrl+shortcut is a more generic (and limited) feature, like ctrl+S which should always save the current document. Alt+S could be used as you want, however. An example is Firefox (or maybe other browsers too): How do you focus the navbar/awesomebar? Easy to answer if it was labeled with "Address:" but hard to figure out at present (it is ctrl+L).
PS: And caption left to the input is standard in KDE apps.

Heiko Tietze wrote:PS: And caption left to the input is standard in KDE apps.

It's standard for forms, not for search/filter fields

colomar wrote:Thanks for the feedback! Here are some replies:

Sogatori wrote:1. You wrote that the filter goes above the control it filters in the mock up, however, it went below this control (I know it's just a mockup, but I just want to make sure)

Here the difference between "static" and "dynamic" filters come into play. The one above the folder list is a static one (can only be switched on or off via the menu), the one below the list of emails is a dynamic one (switched on or off by shortcut or esc, is not shown by default). The distinction is a bit tricky, but we felt it's necessary to accommodate applications that have both search and filter bar.

Hmm, I don't know if I like that. The original goal was to make Search, Filter, Highlight more consisted and predictable across the KDE applications. I wonder if the users care/notice the difference between static and dynamic filters enough to justify the appearing in different places. Especially from the standpoint of distinguishing which control it filters. Some applications have search and filter bars, that's true, but don't we include a "Search" or "Filter" label any way? Personally I think that's enough of an distinction while keeping the placement of these controls consistent, especially when one calls a "dynamic" filter that appears below a "static" search field.

Sogatori wrote:I don't know if I like that. The original goal was to make Search, Filter, Highlight more consisted and predictable across the KDE applications.

How is about an advice to have only static or dynamic filter at once? The dynamic filter would look and feel similar to the highlighter, and static filters are rather an integral part of the application.

Heiko Tietze wrote:

Sogatori wrote:I don't know if I like that. The original goal was to make Search, Filter, Highlight more consisted and predictable across the KDE applications.

How is about an advice to have only static or dynamic filter at once? The dynamic filter would look and feel similar to the highlighter, and static filters are rather an integral part of the application.

I think that's a sound idea.