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

[Thomas Pfeiffer]

Hi everyone,
David just pointed a change to the new Kickoff Plasmoid out to me which
- at least to me - makes it clear that we need an HIG for the
implementation of search functionality.
The change in this case was that the visible search/filter bar was
replaced by a hidden one, which only becomes visible as you type. This
is basically what GNOME/GTK apps do (e.g. Nautilus or Pidgin).
I think whether search/filter bars should be always visible or appear as
the user types is debatable (KDE apps currently go for always visible
and work fine with it, GTK apps work okay with hidden ones as well).
What is not debatable is one Plasmoid going against all the rest. While
I think convincing the Kickoff people to change it back should be easy
enough, this clearly shows to me that an HIG for search features is
necessary.
It should not only define whether search fields are always visible or
not, but also how search results should be presented, whether the search
be within or only from the beginning, etc.

Do you guys agree that such an HIG is necessary? If so, I think we
should first decide whether KDE should stick to always visible search
fields or switch to hidden ones, then I can start writing the guideline
(unless Heiko would like to step up to do it ;) ).

Cheers,
Thomas

[Heiko Tietze]

Post by Thomas Pfeiffer
Do you guys agree that such an HIG is necessary? If so, I think we
should first decide whether KDE should stick to always visible search
fields or switch to hidden ones, then I can start writing the guideline
(unless Heiko would like to step up to do it ;) ).

Yes, of course it is part of the HIG. Actually there are some placeholders
below organizational model yet: Central configuration, Notification mechanism,
Minimize to tray, Processing of passwords.

I would call this "search" a filter because the result list is completely known
and becomes limited by the operation. I use "search" in case of generating a
potentially huge list on ground of some strings or the like.

Visible or not can be extended to "highlighted" (as in the KCM), and sorted or
separated or selected, to be creative, Personally, I like the highlighting,
but it works not well for trees and hidden stuff like menus. Dolphin search
works like kickoff and switches from standard view to some result list, kmail
and konqueror selects the first occurrence on search. So an answer is not that
easy.

[Thomas Pfeiffer]

Post by Heiko Tietze

Post by Thomas Pfeiffer
Do you guys agree that such an HIG is necessary? If so, I think we
should first decide whether KDE should stick to always visible search
fields or switch to hidden ones, then I can start writing the guideline
(unless Heiko would like to step up to do it ;) ).

Yes, of course it is part of the HIG. Actually there are some placeholders
below organizational model yet: Central configuration, Notification
mechanism, Minimize to tray, Processing of passwords.

Okay :)

Post by Heiko Tietze
I would call this "search" a filter because the result list is completely
known and becomes limited by the operation. I use "search" in case of
generating a potentially huge list on ground of some strings or the like.

Actually in the new Kickoff, the search uses KRunner underneath, so it does
indeed more than just filter the application list, so search makes sense in
this case.

Post by Heiko Tietze
Visible or not can be extended to "highlighted" (as in the KCM), and sorted
or separated or selected, to be creative, Personally, I like the
highlighting, but it works not well for trees and hidden stuff like menus.
Dolphin search works like kickoff and switches from standard view to some
result list, kmail and konqueror selects the first occurrence on search. So
an answer is not that easy.

Yes, the way the results are presented is another aspect that should be
covered in the guidelines.
However, while the presentation of results can be different depending on the
usecase, I think the visibility of the search field itself should be
consistent. I'd say either we make search/filter fields everywhere always
visible, or we hide them by default and only show them when users start
typing. What's your take on this?

[Heiko Tietze]

Post by Thomas Pfeiffer
Yes, the way the results are presented is another aspect that should be
covered in the guidelines.
However, while the presentation of results can be different depending on the
usecase, I think the visibility of the search field itself should be
consistent. I'd say either we make search/filter fields everywhere always
visible, or we hide them by default and only show them when users start
typing. What's your take on this?

My personal opinion is beyond any importance. I'd suggest to prepare a blog
post which outlines the possible HIGs and let decide the community.

[Heiko Tietze]

Post by Thomas Pfeiffer
Do you guys agree that such an HIG is necessary? If so, I think we
should first decide whether KDE should stick to always visible search
fields or switch to hidden ones, then I can start writing the guideline
(unless Heiko would like to step up to do it ;) ).

Let's start: http://techbase.kde.org/Projects/Usability/HIG/SearchPattern

PS: It's a pity that usability gets less attention in the last time. So to all
readers of this mailing list: Please join the discussion! A simple go ahead
would be nice at least... ;-)

[Thomas Pfeiffer]

Post by Heiko Tietze

Post by Thomas Pfeiffer
Do you guys agree that such an HIG is necessary? If so, I think we
should first decide whether KDE should stick to always visible search
fields or switch to hidden ones, then I can start writing the guideline
(unless Heiko would like to step up to do it ;) ).

Let's start: http://techbase.kde.org/Projects/Usability/HIG/SearchPattern

Thank you for getting things started!
Here are a few points that I'd like to discuss:

- "Start the search process via button or when the user pressed enter."
This would exclude all "search as you type" functionality (which the
currently many of search features in KDE offer). Suggestion:
"If the search can be performed quickly and with low resource usage,
start searching as the user types. If the search requires more resources
(such as computationally intensive search, reading lots of data from
disk or transferring lots of data over the network), start searching
only when the user presses enter or clicks the search button"
I think it may make sense to show in the UI whether it will sesarch
instantly or only after pressing enter or a button. Not sure yet how to
show it, though.

- Do we really need the icon next to the line input? It seems that the
majority of applications/websites/OSes just a line input which is
"pre-filled" (I don't know the correct term for this) with "Search" or
"Filter" with an icon to start the search, and I think that looks much
leaner while remaining recognizeable.

- On the "Appearance" section, do you mean that all these things would
be "allowed"? If so: I'm not sure if we should allow both "always show"
and "show only when users start to search" or recommend only one for the
sake of consistency. I fear that a small icon may not be enough to make
it clear to users that there is a hidden search function if the search
control is always visible in other places.

What do you think?

[Heiko Tietze]

I'd suggest to move usability or rather HIG related discussions into the
guidelines ML. I'll cross post for now.

- "Start the search process via button or when the user pressed enter." This

would exclude all "search as you type" functionality (which the currently many

"If the search can be performed quickly and with low resource usage, start

searching as the user types. If the search requires more resources (such as
computationally intensive search, reading lots of data from disk or
transferring lots of data over the network), start searching only when the
user presses enter or clicks the search button"

Search vs. filter makes a big difference like Ctrl+I/F in Dolphin (as franku
pointed out). My attempt for discrimination: A search takes all items and
increases the result list based the query pattern; a filter reduces the result
list based of the (limited) input list. That might be the user's picture
because technically both do very similar operations.

"Search as you type" would be still a core functionality for filters. I
understand it in terms of the auto-complete feature of
[url=http://techbase.kde.org/Projects/Usability/HIG/DropDown]drop down
lists[/url]. A guideline based on technical limitation (quickly, resources..)
would be okay as well but less descriptive.

-Do we really need the icon next to the line input?

Well, actually we do have an icon there (in most cases). And I like the idea
of easy identification.

- On the "Appearance" section, do you mean that all these things would be

"allowed"?
The sub items are exclusive. If we define a more or less new guideline we
should ask what users want.

|Sogatori at the forum: Most OSes and webpages seems to favour a magnifying
glass
I agree. The magnifier is IMHO less obtrusive compared to the actual spy glass.

[Thomas Pfeiffer]

Post by Heiko Tietze
I'd suggest to move usability or rather HIG related discussions into the
guidelines ML. I'll cross post for now.

- "Start the search process via button or when the user pressed enter." This

would exclude all "search as you type" functionality (which the currently many

"If the search can be performed quickly and with low resource usage, start

searching as the user types. If the search requires more resources (such as
computationally intensive search, reading lots of data from disk or
transferring lots of data over the network), start searching only when the
user presses enter or clicks the search button"
Search vs. filter makes a big difference like Ctrl+I/F in Dolphin (as franku
pointed out). My attempt for discrimination: A search takes all items and
increases the result list based the query pattern; a filter reduces the
result list based of the (limited) input list. That might be the user's
picture because technically both do very similar operations.
"Search as you type" would be still a core functionality for filters. I
understand it in terms of the auto-complete feature of
[url=http://techbase.kde.org/Projects/Usability/HIG/DropDown]drop down
lists[/url]. A guideline based on technical limitation (quickly,
resources..) would be okay as well but less descriptive.

I see filter vs. search and instant vs. on enter/button as orthogonal. Okay,
filtering should usually be fast enough to work as you type, but search as you
type with an actual search is well possible, too. See Dolphin's search feature
or KRunner, for example. They both perform actual searches, but still works
instantly. And from all I've heard, it will work even better with baloo.
Why would we have users click a button first if we can effortlessly search as
they type as well?

Post by Heiko Tietze

-Do we really need the icon next to the line input?

Well, actually we do have an icon there (in most cases). And I like the idea
of easy identification.

Hm, it seems like we're talking about different thins. I thought the icon in
"Search input consists of an icon, a line input to enter the search pattern,
and a button to start the search." was referring to the binoculars next to the
inout in Kickoff, for example. And I've not seen that combination anywhere
else. Neither in Dolphin nor in KMail nor anywhere else I looked. If you did
mean that icon: Where else did you see it? If not: Which one did you mean?

Post by Heiko Tietze

- On the "Appearance" section, do you mean that all these things would be

"allowed"?
The sub items are exclusive. If we define a more or less new guideline we
should ask what users want.

Ah okay, so these are meant as proposals on which we ask for feedback from the
HIG users? Makes sense to me!

Post by Heiko Tietze
|Sogatori at the forum: Most OSes and webpages seems to favour a magnifying
glass
I agree. The magnifier is IMHO less obtrusive compared to the actual spy glass.

The advantage of the spyglass is certainly that it cannot be confused with
zoom, but magnifying glasses are so more common for search as well that I'd go
with that one, too.

[Heiko Tietze]

Post by Thomas Pfeiffer
I see filter vs. search and instant vs. on enter/button as orthogonal. Okay,
filtering should usually be fast enough to work as you type, but search as
you type with an actual search is well possible, too. See Dolphin's search
feature or KRunner, for example. They both perform actual searches, but
still works instantly. And from all I've heard, it will work even better
with baloo. Why would we have users click a button first if we can
effortlessly search as they type as well?

Is it really consistent if you have an instant search at on time and a
'classic' later? Even if we apply philiphorger's nice idea with different icons
[1] it would be something new. But I'm open for all approaches.

Post by Thomas Pfeiffer
Hm, it seems like we're talking about different thins. I thought the icon in
"Search input consists of an icon, a line input to enter the search
pattern, and a button to start the search." was referring to the binoculars
next to the inout in Kickoff, for example. And I've not seen that
combination anywhere else. Neither in Dolphin nor in KMail nor anywhere
else I looked. If you did mean that icon: Where else did you see it? If
not: Which one did you mean?

You are right, there is no icon. And I don't remember where I spotted them.
Anyway, I believe it is a good idea to identify 'search bars'. And the best
way to do so is IMHO an icon.

[1] http://forum.kde.org/viewtopic.php?f=285&t=120079#p304953

[Thomas Pfeiffer]

Post by Heiko Tietze

Post by Thomas Pfeiffer
I see filter vs. search and instant vs. on enter/button as orthogonal.
Okay, filtering should usually be fast enough to work as you type, but
search as you type with an actual search is well possible, too. See
Dolphin's search feature or KRunner, for example. They both perform
actual searches, but still works instantly. And from all I've heard, it
will work even better with baloo. Why would we have users click a button
first if we can effortlessly search as they type as well?

Is it really consistent if you have an instant search at on time and a
'classic' later? Even if we apply philiphorger's nice idea with different
icons [1] it would be something new. But I'm open for all approaches.

No, they would always be instant (maybe with a slight delay if the query is
too complex). Just like they are now. Everything that is Semantic Search (aka
Nepomuk/baloo)-powered has always been instant. What would be inconsistent?

I like the idea in the forum, too, but I don't think the different icons
should indicate different "states" of the same search function. Either a
search function is based on very fast and resource-efficient search engine so
that it can be always instant, or it isn't and thus has to be always "search
on click/enter".

Post by Heiko Tietze

Post by Thomas Pfeiffer
Hm, it seems like we're talking about different thins. I thought the icon
in "Search input consists of an icon, a line input to enter the search
pattern, and a button to start the search." was referring to the
binoculars next to the inout in Kickoff, for example. And I've not seen
that
combination anywhere else. Neither in Dolphin nor in KMail nor anywhere
else I looked. If you did mean that icon: Where else did you see it? If
not: Which one did you mean?

You are right, there is no icon. And I don't remember where I spotted them.
Anyway, I believe it is a good idea to identify 'search bars'. And the best
way to do so is IMHO an icon.

An icon certainly makes it most obvious, yes, but I think putting "Search"
into the empty search field works well enough (it seems to be the de facto
standard, at least) and looks more lightweight.

[Philipp Stefan]

Hello everyone,

my name is Philipp Stefan, I'm the guy from the VDG Forum who made the
lengthy post about the search functionality.

Post by Thomas Pfeiffer

Post by Heiko Tietze

Post by Thomas Pfeiffer
I see filter vs. search and instant vs. on enter/button as orthogonal.
Okay, filtering should usually be fast enough to work as you type, but
search as you type with an actual search is well possible, too. See
Dolphin's search feature or KRunner, for example. They both perform
actual searches, but still works instantly. And from all I've heard, it
will work even better with baloo. Why would we have users click a button
first if we can effortlessly search as they type as well?

Is it really consistent if you have an instant search at on time and a
'classic' later? Even if we apply philiphorger's nice idea with different
icons [1] it would be something new. But I'm open for all approaches.

No, they would always be instant (maybe with a slight delay if the query is
too complex). Just like they are now. Everything that is Semantic Search (aka
Nepomuk/baloo)-powered has always been instant. What would be inconsistent?
I like the idea in the forum, too, but I don't think the different icons
should indicate different "states" of the same search function. Either a
search function is based on very fast and resource-efficient search engine so
that it can be always instant, or it isn't and thus has to be always "search
on click/enter".

I agree. I think that the search functionality has been proven to be
fast enough to be "instant". On the other hand, does every application
use Nepomuk/baloo for its search functionality? I know that Dolphin
doesn't use it always e.g. when searching the root directory.

Post by Thomas Pfeiffer

Post by Heiko Tietze

Post by Thomas Pfeiffer
Hm, it seems like we're talking about different thins. I thought the icon
in "Search input consists of an icon, a line input to enter the search
pattern, and a button to start the search." was referring to the
binoculars next to the inout in Kickoff, for example. And I've not seen
that
combination anywhere else. Neither in Dolphin nor in KMail nor anywhere
else I looked. If you did mean that icon: Where else did you see it? If
not: Which one did you mean?

You are right, there is no icon. And I don't remember where I spotted them.
Anyway, I believe it is a good idea to identify 'search bars'. And the best
way to do so is IMHO an icon.

An icon certainly makes it most obvious, yes, but I think putting "Search"
into the empty search field works well enough (it seems to be the de facto
standard, at least) and looks more lightweight.

I'd agree that an icon is the best way to make the search functionality
easily identifiable. Like I have stated in my forum post before: I
really like the elementary HIG [1] in this regard. In the case of
Kickoff it would also help to state that the search will also work for
finding files. I find the label "Search Applications and Files" way more
telling than "Search..." On the other hand we'll have to consider that
such a phrase can balloon up easily when translated.
If we follow the elementary OS/GNOME 3 style, then it would also be
feasible to change the magnifying glass to a spinning circle if the
search operation takes a bit longer, to indicate that the program is
still doing something.

Have you already discussed the placement of the "search bar"? I'd prefer
a placement above the content (view), mostly because the "Search/Filter"
button currently resides on top of the application(s). I was also about
to make some new mock-ups, when I saw Andrew's post in the forum [2]
that the mockup toolkit is now available. The example mockups shown in
the toolkit place the "search" button on the left side of the
application. I don't know weather that'll be the direction the VDG wants
to go or not, I'll ask them shortly.
I guess any placement will be Ok, as long as it's consistent. The
"filter" and "search" functionality should appear at the same place though.

Something more mailing list related:
How is a conclusion reached? Is there normally some kind of vote, or
will the one who edits the wikipage first the one who decides what's
being used? Also, is there some kind of place where the current "draft"
is saved, or does the current HIG wikipage function like that? I ask,
because I have a horrible memory and forget easily. Something along the
lines of "Issue | Decision" would be wonderful. I can, of course, also
make such a list only for myself :)

Cheers

Phil


[1] http://elementaryos.org/docs/human-interface-guidelines/search-fields
[2] http://forum.kde.org/viewtopic.php?f=285&t=120225

[Thomas Pfeiffer]

Post by Philipp Stefan
Hello everyone,

Hi Phil,
welcome to the HIG team!

Post by Philipp Stefan
How is a conclusion reached? Is there normally some kind of vote, or
will the one who edits the wikipage first the one who decides what's
being used? Also, is there some kind of place where the current "draft"
is saved, or does the current HIG wikipage function like that? I ask,
because I have a horrible memory and forget easily. Something along the
lines of "Issue | Decision" would be wonderful. I can, of course, also
make such a list only for myself :)

So far, the process has been
1. Someone (so far usually Heiko) writes a first draft and puts it either on
the wiki or the mailing list (usually both)
2a. We discuss the draft on the mailing list until all issues have been sorted
out
2b. If others find small issues that don't need discussion (like misspellings
or language imperfections), they directly edit the wiki
3. Changes are applied to the Wiki and we consider the guideline "released"

So far we've been able to reach consensus on all matters without needing a
vote (a vote doesn't make much sense with so few people, recently in fact only
Heiko and me have been active on this list unless I dragged David Edmundson in
to give some technical feedback).

Cheers,
Thomas

[Heiko Tietze]

Post by Thomas Pfeiffer
So far we've been able to reach consensus on all matters without needing a
vote (a vote doesn't make much sense with so few people, recently in fact
only Heiko and me have been active on this list unless I dragged David
Edmundson in to give some technical feedback).

I planned to run a survey about the appearance questions. But if we decide
that some of the alternatives aren't working at all we can prepare the
guideline and present it to the community for an open discussion. My
preferences: Placement: #1, Show: #3 (plus global short-cut), Results:
depending on context #1 or #3.
Anyway, it would be great to add mockups for the most important aspects.

[Philipp Stefan]

Post by Heiko Tietze

Post by Thomas Pfeiffer
So far we've been able to reach consensus on all matters without needing a
vote (a vote doesn't make much sense with so few people, recently in fact
only Heiko and me have been active on this list unless I dragged David
Edmundson in to give some technical feedback).

I planned to run a survey about the appearance questions. But if we decide
that some of the alternatives aren't working at all we can prepare the
guideline and present it to the community for an open discussion. My
depending on context #1 or #3.
Anyway, it would be great to add mockups for the most important aspects.
_______________________________________________
kde-guidelines mailing list
https://mail.kde.org/mailman/listinfo/kde-guidelines

I have made some mockups concerning the placement of the search field. I
used the very simple example application found in the Mockup Toolkit and
modified it a bit. It is important to notice though that this mockup
only explores the possibilities with the "new" sidebars as seen in the
Mockup Toolkit. If the VDG descides to not use them then this mockup
become irrelevant.

For this example I assumed that the search field is hidden by default,
but a search button is displayed on the sidebar. For the sake of seeing
the different states of the search field I made it so, that the search
fields are not focused by default.

[1] The example application found in the Mockup Toolkit
[2/A] Here I tried to integrate the search field with the search button.
The space is very limited, but then, the application is also rather small.
[3/B] Placement on the upper right.
[4/C] Top centred search field.
[5/D] Search field on the bottom. I adapted its width to the content
view, because it looked pretty silly when it's only aligned to the
bottom right. If you want it any ways I can make another mockup with a
search field centred on the bottom right. :)

If you don't want to deal with all the images then have this one [6], it
is an overview of all. The picture is huge though, so be warned!

I would find [2/A] to be the most elegant solution, but the limited
space makes it also impractical when searching for longer search terms.
This could be of course the solved by scaling down the font used, but it
would also introduce some visual inconsistency.

[3/B] I find impractical as well. I observed that older people tend to
drag their mouse to the search field and click it, even though it was
already focused. The placement on the upper right introduces a longer
way than necessary.

[4/C] is more acceptable than [3/B] in my opinion, as the path from the
search button to the actual search field is a bit shorter than in [3/B].

[5/D] is as good as [4/C], if not better. The search button in the
Mockup Toolkit can always be found as the last item of the side bar, so
naturally the way from the search button to the search field will be
shorter to [5/D] than to [4/C].

I hope this is not too confusing. Any way, I hope that this will maybe
help a bit. If you have some input regarding the mockups, please share
it! :)

Cheers,

Phil

[1]Loading Image...
[2]Loading Image...
[3]Loading Image...
[4]Loading Image...
[5]Loading Image...
[6]Loading Image...

[Heiko Tietze]

Post by Philipp Stefan
I have made some mockups concerning the placement of the search field.

Great work! I like it all ;-)
But why do you change the search icon (magnifier) into a yin-yang whatever arrow? Overloading a control is bad usability in most cases.

Post by Philipp Stefan
[2/A] Here I tried to integrate the search field with the search button.

Users might understand the search function to be related to the topics. 

Post by Philipp Stefan
[3/B] Placement on the upper right.
[4/C] Top centred search field.

My aesthetic appreciation prefers 4/C. But all mockups replace the original header line. This is a problem when the content jumps down on search, that means when a further search bar is opened. Can't we integrate them? Perhaps right hand of the address line (> cool wallpapers).

Post by Philipp Stefan
[5/D] Search field on the bottom.

I think it's a no-go to open a small input on demand somewhere at the bottom.
 > I would find [2/A] to be the most elegant solution, but the limited

Post by Philipp Stefan
space makes it also impractical when searching for longer search terms.
This could be of course the solved by scaling down the font used, but it
would also introduce some visual inconsistency.

Scaling the font is treated as crime in some circles :-).

[Philipp Stefan]

Post by Heiko Tietze
Great work! I like it all ;-)
But why do you change the search icon (magnifier) into a yin-yang
whatever arrow? Overloading a control is bad usability in most cases.

Oh, that's the indicator that the search is still ongoing. I didn't
include the "search finished" state in the mockups because I got lazy ._.
I send a mockup off all the possibilities (read: that I found
acceptable) in a reply mail to Thomas Pfeiffer. I guess this got lost
somehow. How should I post mails to the list in future to prevent this
from happening?
Anyway, here's the picture of the "idle" and "busy" state of the search
field [1]

Post by Heiko Tietze
[2/A] Here I tried to integrate the search field with the search button.
Users might understand the search function to be related to the topics.

Right, I didn't consider this.

Post by Heiko Tietze
[3/B] Placement on the upper right.
[4/C] Top centred search field.
My aesthetic appreciation prefers 4/C. But all mockups replace the
original header line. This is a problem when the content jumps down on
search, that means when a further search bar is opened. Can't we
integrate them? Perhaps right hand of the address line (> cool
wallpapers).

I don't think we can prevent the jumping, only lessen it. If you compare
the hight of the search field and the available space between the
content view and the window controls on the right sight then you'll
notice that the search field doesn't fit in, even less so with padding.
I can of course solve this by shrinking the input field a bit, but I'm
not sure that's a wise thing to do. I find the input fields quite big in
general though, that's maybe something to add to the feedback for the VDG.

Also, if the search field would be to the right of the address field
wouldn't the user assume that the search only affects the current
directory? I think this might be better for the filter functionality.
Dolphin also hides the address line when the search functionality is called.

I can make to mockups, one with the shrunken search field and one with
the reduced jumping. Some ideas what to add to the list?

Post by Heiko Tietze
[5/D] Search field on the bottom.
I think it's a no-go to open a small input on demand somewhere at the bottom.

If Thomas agrees we can at least agree that the input should be always
on top (of the content) :)

Cheers,

Phil

[1] http://i.imgur.com/NC8r0ii.png

[Heiko Tietze]

Post by Philipp Stefan
Oh, that's the indicator that the search is still ongoing. I didn't
include the "search finished" state in the mockups because I got lazy ._.
I send a mockup off all the possibilities (read: that I found
acceptable) in a reply mail to Thomas Pfeiffer. I guess this got lost
somehow. How should I post mails to the list in future to prevent this
from happening?
Anyway, here's the picture of the "idle" and "busy" state of the search
field [1]

I have seen this mockup too but forgot it. Anyway, I don't like it because
search is ongoing is less informative and does not need an extra icon. What do
you think about a decorator of the magnifier? Just add your arrows to the right
bottom during the search - and animate it if necessary.

Post by Philipp Stefan
I don't think we can prevent the jumping, only lessen it. If you compare
the hight of the search field and the available space between the
content view and the window controls on the right sight then you'll
notice that the search field doesn't fit in, even less so with padding.

We could extend the height of the address line...

Post by Philipp Stefan
Also, if the search field would be to the right of the address field
wouldn't the user assume that the search only affects the current
directory? I think this might be better for the filter functionality.
Dolphin also hides the address line when the search functionality is called.

Touche. Go with the replacement option, but have the search icon at the same
position in any condition. I.e. do not make it vertically jumping and have
something static at the horizontal line.

[Thomas Pfeiffer]

Post by Philipp Stefan

Post by Philipp Stefan
[5/D] Search field on the bottom.
I think it's a no-go to open a small input on demand somewhere at the bottom.

If Thomas agrees we can at least agree that the input should be always
on top (of the content) :)

I don't know. I just did a quick scan of some KDE applications and actually
found a searchbar at the bottom to be a very common pattern (if not the
prevalent one). Examples:
- Filter in Dolphin
- Konqueror / Rekonq
- Kate
- Konsole

Above the content appears to be the common position for search bars that are
always visible (like KMail or System Settings) while bottom seems to be the
common position for search bars that only appear when a search is initiated
(via the menu or Ctrl-F).
Would it makes sense to put it like that in the HIG or should we force all
applications which put it on the bottom to change it? I assume the pattern of
"make a search bar appear at the bottom when user starts searching" was
inspired in browsers by Firefox and then spread to other applications.

[Andrew Lake]

I've followed this conversation to try to absrob the viewpoints so far,
before rudely jumping in and sharing my thoughts. :-)

Is it possible to distill our consideration of search into something a
little less exceptional? Should search always be treated differently than
any other content selection/alteration model?

In many cases where search is present there is often some other basic
content selection model. For a music player, there is a Artist, Album,
Genre content selection model. For system settings there is usually a
Hardware, Appearance, Admin, etc. content selection. For Kickoff there's
Favorites, Applications, Computer, etc. For some reason search is often
visually treated as a something completely different - usually by putting
the search field in a completely different location than the other content
selection mechanisms.

The consequence can sometimes get messy. If you have Artist selected and
you do a search that displays songs in the search result, the UI ends up in
this inconsistent state where the search field is highlighted and songs are
being displayed but Artist is still selected. If the designer is careful,
they'll deselect Artist (leaving a useless category selection pane with
nothing selected), or hide the category selection all-together (like
Kickoff does).

My question is why? If other forms of content selection are available, why
treat search as a completely different form of content selection? When you
select Artist in a music player, the content changes to show artists. When
you select your Document folder in the places panel in dolphin, the content
changes to show the files in your Documents folder. When you search, the
content changes to reflect what you're searching for. Why not use the same
space and interaction model in the UI for search as other category
selection mechanism? Sure you have to type but is that really the only
thing that really compels a completely different location for the search
field?

If I have a simple two panel layout with category selection on the left and
content on the right, then search goes on the left with all the other
categories. The upside being that it cleans up the UI because I didn't have
to find a whole other place to put search. I've had the opportunity to use
this in several application designs across several platforms and have not
observed any degradation in user search experience. I'm not saying there
are never good reasons to elevate the search field to a primary, distinct
point of focus for any UI design - Unity does it well I think. Rather, I
think it should be the exception rather than the rule/guideline.

*Filtering* of existing content, on the other hand, really should go into
the content view. The category selection doesn't change as a result of
filtering. And with search as just another form of category selection, you
can conceivably filter search results - very useful.

Sorry for rambling but I hope this is helpful!
Andrew



On Mon, Mar 24, 2014 at 8:16 AM, Heiko Tietze

Post by Philipp Stefan
I have made some mockups concerning the placement of the search field.
Great work! I like it all ;-)
But why do you change the search icon (magnifier) into a yin-yang whatever
arrow? Overloading a control is bad usability in most cases.
[2/A] Here I tried to integrate the search field with the search button.
Users might understand the search function to be related to the topics.
[3/B] Placement on the upper right.
[4/C] Top centred search field.
My aesthetic appreciation prefers 4/C. But all mockups replace the
original header line. This is a problem when the content jumps down on
search, that means when a further search bar is opened. Can't we integrate
them? Perhaps right hand of the address line (> cool wallpapers).
[5/D] Search field on the bottom.
I think it's a no-go to open a small input on demand somewhere at the bottom.
I would find [2/A] to be the most elegant solution, but the limited
space makes it also impractical when searching for longer search terms.
This could be of course the solved by scaling down the font used, but it
would also introduce some visual inconsistency.
Scaling the font is treated as crime in some circles :-).
_______________________________________________
kde-guidelines mailing list
https://mail.kde.org/mailman/listinfo/kde-guidelines

[Thomas Pfeiffer]

Post by Andrew Lake
I've followed this conversation to try to absrob the viewpoints so far,
before rudely jumping in and sharing my thoughts. :-)
Is it possible to distill our consideration of search into something a
little less exceptional? Should search always be treated differently than
any other content selection/alteration model?
In many cases where search is present there is often some other basic
content selection model. For a music player, there is a Artist, Album,
Genre content selection model. For system settings there is usually a
Hardware, Appearance, Admin, etc. content selection. For Kickoff there's
Favorites, Applications, Computer, etc. For some reason search is often
visually treated as a something completely different - usually by putting
the search field in a completely different location than the other content
selection mechanisms.
The consequence can sometimes get messy. If you have Artist selected and
you do a search that displays songs in the search result, the UI ends up in
this inconsistent state where the search field is highlighted and songs are
being displayed but Artist is still selected. If the designer is careful,
they'll deselect Artist (leaving a useless category selection pane with
nothing selected), or hide the category selection all-together (like
Kickoff does).
My question is why? If other forms of content selection are available, why
treat search as a completely different form of content selection? When you
select Artist in a music player, the content changes to show artists. When
you select your Document folder in the places panel in dolphin, the content
changes to show the files in your Documents folder. When you search, the
content changes to reflect what you're searching for. Why not use the same
space and interaction model in the UI for search as other category
selection mechanism? Sure you have to type but is that really the only
thing that really compels a completely different location for the search
field?
If I have a simple two panel layout with category selection on the left and
content on the right, then search goes on the left with all the other
categories. The upside being that it cleans up the UI because I didn't have
to find a whole other place to put search. I've had the opportunity to use
this in several application designs across several platforms and have not
observed any degradation in user search experience. I'm not saying there
are never good reasons to elevate the search field to a primary, distinct
point of focus for any UI design - Unity does it well I think. Rather, I
think it should be the exception rather than the rule/guideline.
*Filtering* of existing content, on the other hand, really should go into
the content view. The category selection doesn't change as a result of
filtering. And with search as just another form of category selection, you
can conceivably filter search results - very useful.
Sorry for rambling but I hope this is helpful!
Andrew

Hi Andrew,
while this idea sounds reasonable on an abstract level, I must admit that I
can't really picture how it works in practice. Could you point us to some
screenshots/mockups of applications were this was/will be implemented? Maybe
then we can judge whether it would work for the majority of cases.
Thanks,
Thomas

[Andrew Lake]

Oh sure Thomas, I should have thought of that. I'm always the one saying
preach with the pixels not the words! Sorry. :-)

Bangarang:
Loading Image...

A couple mockups I shared with the VDG (in the mockup toolkit) for a file
manager:
Loading Image...

and a music player:
Loading Image...

In these particular mockups, the search is exposed in the UI with a simple
search icon rather than a text field, but that less important. The word
"Search" could accompany the icon to make it a bit more
discoverable. Search could also be the first entry in the list if it is
more appropriate. But, the number of interaction steps would be exactly the
same:
1. Click to focus/activate
2. Type
3. Enter (only necessary if the interaction pattern is search-on-enter vs
search-as-you-type).

In all these cases, category selection (including search) is on the left
and content corresponding to that selection is on the right. The behavioral
model is consistent whether you select a category or search: Content on the
right reflects actions taken on the left AND selections on the left are
mutually exclusive.

I've also used this pattern in a few Android applications with good
results. Of course, while this is a design pattern I've found quite useful
in practice, there's always the possibility that you folks may identify
some downsides with this approach. I certainly welcome the feedback. :-)

Hope this helps,
Andrew

P.S. In the case of Bangarang, *filtering* was exposed in the content
window where the content corresponding to any category selection on the
left, including search, could be filtered.

Post by Philipp Stefan

Post by Andrew Lake
I've followed this conversation to try to absrob the viewpoints so far,
before rudely jumping in and sharing my thoughts. :-)
Is it possible to distill our consideration of search into something a
little less exceptional? Should search always be treated differently than
any other content selection/alteration model?
In many cases where search is present there is often some other basic
content selection model. For a music player, there is a Artist, Album,
Genre content selection model. For system settings there is usually a
Hardware, Appearance, Admin, etc. content selection. For Kickoff there's
Favorites, Applications, Computer, etc. For some reason search is often
visually treated as a something completely different - usually by putting
the search field in a completely different location than the other

content

Post by Andrew Lake
selection mechanisms.
The consequence can sometimes get messy. If you have Artist selected and
you do a search that displays songs in the search result, the UI ends up

in

Post by Andrew Lake
this inconsistent state where the search field is highlighted and songs

are

Post by Andrew Lake
being displayed but Artist is still selected. If the designer is careful,
they'll deselect Artist (leaving a useless category selection pane with
nothing selected), or hide the category selection all-together (like
Kickoff does).
My question is why? If other forms of content selection are available,

why

Post by Andrew Lake
treat search as a completely different form of content selection? When

you

Post by Andrew Lake
select Artist in a music player, the content changes to show artists.

When

Post by Andrew Lake
you select your Document folder in the places panel in dolphin, the

content

Post by Andrew Lake
changes to show the files in your Documents folder. When you search, the
content changes to reflect what you're searching for. Why not use the

same

Post by Andrew Lake
space and interaction model in the UI for search as other category
selection mechanism? Sure you have to type but is that really the only
thing that really compels a completely different location for the search
field?
If I have a simple two panel layout with category selection on the left

and

Post by Andrew Lake
content on the right, then search goes on the left with all the other
categories. The upside being that it cleans up the UI because I didn't

have

Post by Andrew Lake
to find a whole other place to put search. I've had the opportunity to

use

Post by Andrew Lake
this in several application designs across several platforms and have not
observed any degradation in user search experience. I'm not saying there
are never good reasons to elevate the search field to a primary, distinct
point of focus for any UI design - Unity does it well I think. Rather, I
think it should be the exception rather than the rule/guideline.
*Filtering* of existing content, on the other hand, really should go into
the content view. The category selection doesn't change as a result of
filtering. And with search as just another form of category selection,

you

Post by Andrew Lake
can conceivably filter search results - very useful.
Sorry for rambling but I hope this is helpful!
Andrew

Hi Andrew,
while this idea sounds reasonable on an abstract level, I must admit that I
can't really picture how it works in practice. Could you point us to some
screenshots/mockups of applications were this was/will be implemented? Maybe
then we can judge whether it would work for the majority of cases.
Thanks,
Thomas
_______________________________________________
kde-guidelines mailing list
https://mail.kde.org/mailman/listinfo/kde-guidelines

[Philipp Stefan]

Post by Andrew Lake
Oh sure Thomas, I should have thought of that. I'm always the one
saying preach with the pixels not the words! Sorry. :-)
http://bangarangkde.files.wordpress.com/2010/11/app-korn.png?w=740&h=547
A couple mockups I shared with the VDG (in the mockup toolkit) for a
http://wstaw.org/m/2014/03/24/fm.png
http://wstaw.org/m/2014/03/24/mp.png
In these particular mockups, the search is exposed in the UI with a
simple search icon rather than a text field, but that less
important. The word "Search" could accompany the icon to make it a bit
more discoverable. Search could also be the first entry in the list if
it is more appropriate. But, the number of interaction steps would be
1. Click to focus/activate
2. Type
3. Enter (only necessary if the interaction pattern is search-on-enter
vs search-as-you-type).
In all these cases, category selection (including search) is on the
left and content corresponding to that selection is on the right. The
behavioral model is consistent whether you select a category or
search: Content on the right reflects actions taken on the left AND
selections on the left are mutually exclusive.
I've also used this pattern in a few Android applications with good
results. Of course, while this is a design pattern I've found quite
useful in practice, there's always the possibility that you folks may
identify some downsides with this approach. I certainly welcome the
feedback. :-)
Hope this helps,
Andrew
P.S. In the case of Bangarang, *filtering* was exposed in the content
window where the content corresponding to any category selection on
the left, including search, could be filtered.

Hi Andrew,

I have to say that I like the idea, but I think it only works in
applications which can present the same information in different ways
i.e. a music player or a chat app. You said it yourself already.
I always thought that the file manager was the "norm" application, but
now that I really think about it it seems that most applications don't
behave this way at all.
So maybe we really should focus on the filter functionality first,
because the only application that performs an actual search are the file
manager and KRunner/Kickoff.

You want to integrate the search in the "button" on the left side as
well. Have you read the e-mails between me and Heiko Tietze[1]? I
noticed that if we use a standard text field so build the search field
then the space is very restricted with the current size of the text
field and the typeface. Does the VDG intent to make a dedicated search
widget?

Cheers,

Phil

[1] http://mail.kde.org/pipermail/kde-guidelines/2014-March/000760.html
; http://mail.kde.org/pipermail/kde-guidelines/2014-March/000761.html ;
http://mail.kde.org/pipermail/kde-guidelines/2014-March/000762.html

[Andrew Lake]

Oh yeah,

I totally agree that only when there is already another way to browse
through the information at the top level should search share that
interaction pattern. For the moment I see that pattern in file managers,
media players with libraries, kickoff style menus and the like. For me that
covers quite a few applications that traditionally use search.

Taking a stab a filter functionality makes great sense to me.

Regarding the size of the search field on the left, there are couple ways
I've dealt with that in my applications:
1. Wherever the search field is placed, on the left or not, some decision
has to be made about a reasonable size.
2. I've found that space for about 25 characters seem to serve vast
majority of search needs. That's my anecdotal experience developing my
apps, but a simple user study can validate an reasonable number. (Also
search fields for Apple's iTunes and spotlight and Microsoft's Windows 8
search panel and several apps aren't a great deal bigger.)
3. When more space is needed, make the left panel size resizable with a
minimum size corresponding to the minimum size of the search field (~20
characters) and have the search field always fill the width of the panel.
It is exactly the same interaction model the user employs to see more
characters in any of the other non-search categories in the left pane -
resize the pane.

I confess the mockups could probably use more space in the left pane
following these steps, but not insurmountable I don't think. The Bangarang
screenshot shows how these steps can actually solve that problem.

Regarding a dedicated search widget, my personal opinion as just one member
of the VDG (so not speaking for the group) is that we have all the tools we
need to solve UI problems elegantly and beautifully with existing widgets
(they are amazingly flexible and powerful). What's really needed are some
clear and helpful design patterns (specific widget arrangements) to help
app developers understand how to put the widgets together in the right way
to solve a particular information/interaction problem.

With the thought you folks here are already putting into this, I'm excited
to see what great design patterns we come up with for search and filtering

Hope this helps!
Andrew

Post by Philipp Stefan
I have to say that I like the idea, but I think it only works in
applications which can present the same information in different ways i.e.
a music player or a chat app. You said it yourself already.
I always thought that the file manager was the "norm" application, but now
that I really think about it it seems that most applications don't behave
this way at all.
So maybe we really should focus on the filter functionality first, because
the only application that performs an actual search are the file manager
and KRunner/Kickoff.
You want to integrate the search in the "button" on the left side as well.
Have you read the e-mails between me and Heiko Tietze[1]? I noticed that if
we use a standard text field so build the search field then the space is
very restricted with the current size of the text field and the typeface.
Does the VDG intent to make a dedicated search widget?
Cheers,
Phil
[1] http://mail.kde.org/pipermail/kde-guidelines/2014-March/000760.html ;
http://mail.kde.org/pipermail/kde-guidelines/2014-March/000761.html ;
http://mail.kde.org/pipermail/kde-guidelines/2014-March/000762.html
_______________________________________________
kde-guidelines mailing list
https://mail.kde.org/mailman/listinfo/kde-guidelines

[Thomas Pfeiffer]

Post by Andrew Lake
Oh yeah,
I totally agree that only when there is already another way to browse
through the information at the top level should search share that
interaction pattern. For the moment I see that pattern in file managers,
media players with libraries, kickoff style menus and the like. For me
that covers quite a few applications that traditionally use search.

For file managers, putting the search in the Places panel works for
simple search (though I'd put it at the top, because the list of places
can get longer than the container's height and you'd have to scroll to
get to the search) but what about all the search options that e.g.
Dolphin offers? That wouldn't fit in the panel...

Plus, we have to keep in mind that the places panel in Dolphin is
optional, so users might not even have it visible but still want to search.

Actually, the "search" in media players is a filter, not a search. If we
say that a filter should always be placed on top of the thing it
filters, that would work for media players (Amarok already does it that
way, too) and file managers as well.

Post by Andrew Lake
Taking a stab a filter functionality makes great sense to me.
Regarding the size of the search field on the left, there are couple
1. Wherever the search field is placed, on the left or not, some
decision has to be made about a reasonable size.
2. I've found that space for about 25 characters seem to serve vast
majority of search needs. That's my anecdotal experience developing my
apps, but a simple user study can validate an reasonable number. (Also
search fields for Apple's iTunes and spotlight and Microsoft's Windows 8
search panel and several apps aren't a great deal bigger.)
3. When more space is needed, make the left panel size resizable with a
minimum size corresponding to the minimum size of the search field (~20
characters) and have the search field always fill the width of the
panel. It is exactly the same interaction model the user employs to see
more characters in any of the other non-search categories in the left
pane - resize the pane.

I agree, though, as mentioned before, this only works for a simple
search with no options. If we have options, they could only be put in a
popup called from a button in the search field.

Post by Andrew Lake
I confess the mockups could probably use more space in the left pane
following these steps, but not insurmountable I don't think. The
Bangarang screenshot shows how these steps can actually solve that problem.
Regarding a dedicated search widget, my personal opinion as just one
member of the VDG (so not speaking for the group) is that we have all
the tools we need to solve UI problems elegantly and beautifully with
existing widgets (they are amazingly flexible and powerful). What's
really needed are some clear and helpful design patterns (specific
widget arrangements) to help app developers understand how to put the
widgets together in the right way to solve a particular
information/interaction problem.
With the thought you folks here are already putting into this, I'm
excited to see what great design patterns we come up with for search and
filtering
Hope this helps!
Andrew

The thing is: Our general approach is to use the HIG to try to
standardize on what's already there (take the best approach we currently
see and make that the standard across all KDE software) instead of
coming up with completely new things.
The reason behind that is a practical one: If we standardize on
something that is already implemented in many applications, chances are
that other applications currently doing it differently may switch to it
for the sake of consistency. If we introduce something completely new,
the risk is high that no application will implement it, and an HIG that
isn't implemented anywhere doesn't have a high chance of being respected
in future applications.
The exception to that is, of course, if we don't think any of the
existing implementations is good enough to become the new standard. In
that case we have to introduce something new and try to get at least one
prominent application to implement it, hoping that others will follow
the good example.

So with all the brainstorming we are currently doing (which is great),
let's keep in mind that we should preferably use things that are already
present in some KDE applications.

Cheers,
Thomas

[Andrew Lake]

For file managers, putting the search in the Places panel works for simple
search (though I'd put it at the top, because the list of places can get
longer than the container's height and you'd have to scroll to get to the
search) but what about all the search options that e.g. Dolphin offers?
That wouldn't fit in the panel...

This is relatively easily addressed by a collapsible Options section under
Search that is exposed, or made available to be exposed, when search is
active. In practice, I've found this works quite well.

Plus, we have to keep in mind that the places panel in Dolphin is
optional, so users might not even have it visible but still want to search.

Fair point. For clarity though, this is proposed as a design pattern that
might be helpful when category/content selection is already available in
your interface design. I (already) fully acknowledge that there will be
times when that is not applicable. And even if it is applicable, I fully
acknowledge that it simply may not fit with the desired visual design for
the application. That's fine too I think.

Actually, the "search" in media players is a filter, not a search. If we
say that a filter should always be placed on top of the thing it filters,
that would work for media players (Amarok already does it that way, too)
and file managers as well.

Filters filter already presented content. The pattern works for Amarok's
library because Amarok presents in its entire library in a tree view. Not
all media players do this. In fact very few do. Most have a
category/content selection in a separate pane that is not restricted to
just categories of the music library (e.g. playlists, radio stations,
etc.). The filter pattern is certainly a good solution for Amarok's music
library given the way it is presented.

I agree, though, as mentioned before, this only works for a simple search

with no options. If we have options, they could only be put in a popup
called from a button in the search field.

As mentioned above, collapsible options exposed when search is active is
another way to address advanced search.

The thing is: Our general approach is to use the HIG to try to standardize

on what's already there (take the best approach we currently see and make
that the standard across all KDE software) instead of coming up with
completely new things.
The reason behind that is a practical one: If we standardize on something
that is already implemented in many applications, chances are that other
applications currently doing it differently may switch to it for the sake
of consistency. If we introduce something completely new, the risk is high
that no application will implement it, and an HIG that isn't implemented
anywhere doesn't have a high chance of being respected in future
applications.

That's fine by me. I do think though that that approach rather compels UI
designers to abandon the guidelines when a potentially better approach is
discovered. It also means it's more likely that new/better approaches will
inevitably be discovered outside of the KDE community, used by UI designers
in conflict with the guidelines and then only adopted by the guidelines
when enough UI designers break the guidelines to use the new approach.

For clarity, I'm not saying my proposal is necessarily better - I was just
proposing it to see if folks here might find it useful, as I have in
practice. I mean this sincerely: I do *not* take any offence if you all
prefer to continue in the direction you were before I popped in. Whatever
you folks come up with will certainly be better than anything we've had
before, so I welcome it! More importantly, if anything I've offered so far
has been found with discomfort or offence, I sincerely apologize. :-)

<offtopic>
I originally had some text here describing my intent to contribute to
putting together a design pattern library. However, rather than derail this
topic any more than I already have, feel free to contact me on via G+, via
email, or on the VDG forum if you're interested in that topic.
</offtopic>

Thanks much for taking the time to consider what I've offered, and please
don't be shy about moving in the direction you originally had planned,

Much respect,
Andrew Lake

[Thomas Pfeiffer]

On Tue, Mar 25, 2014 at 2:47 AM, Thomas Pfeiffer

For file managers, putting the search in the Places panel works for simple
search (though I'd put it at the top, because the list of places can get
longer than the container's height and you'd have to scroll to get to the
search) but what about all the search options that e.g. Dolphin offers?
That wouldn't fit in the panel...

This is relatively easily addressed by a collapsible Options section under
Search that is exposed, or made available to be exposed, when search is
active. In practice, I've found this works quite well.

Picture, please ;) I guess I understand what you mean on an abstract level,
but would like to see it "in action"

Plus, we have to keep in mind that the places panel in Dolphin is
optional, so users might not even have it visible but still want to search.

Fair point. For clarity though, this is proposed as a design pattern that
might be helpful when category/content selection is already available in
your interface design. I (already) fully acknowledge that there will be
times when that is not applicable. And even if it is applicable, I fully
acknowledge that it simply may not fit with the desired visual design for
the application. That's fine too I think.

That was not meant as an argument against the pattern as such, just to point
out a potential pitfall with flexible UIs.

Actually, the "search" in media players is a filter, not a search. If we
say that a filter should always be placed on top of the thing it filters,
that would work for media players (Amarok already does it that way, too)
and file managers as well.

Filters filter already presented content. The pattern works for Amarok's
library because Amarok presents in its entire library in a tree view. Not
all media players do this. In fact very few do. Most have a
category/content selection in a separate pane that is not restricted to
just categories of the music library (e.g. playlists, radio stations,
etc.). The filter pattern is certainly a good solution for Amarok's music
library given the way it is presented.

We could still place the search/filter field above the other categories even
if it's a "real" search, couldn't we?

I agree, though, as mentioned before, this only works for a simple search

with no options. If we have options, they could only be put in a popup
called from a button in the search field.

As mentioned above, collapsible options exposed when search is active is
another way to address advanced search.
The thing is: Our general approach is to use the HIG to try to standardize

on what's already there (take the best approach we currently see and make
that the standard across all KDE software) instead of coming up with
completely new things.
The reason behind that is a practical one: If we standardize on something
that is already implemented in many applications, chances are that other
applications currently doing it differently may switch to it for the sake
of consistency. If we introduce something completely new, the risk is high
that no application will implement it, and an HIG that isn't implemented
anywhere doesn't have a high chance of being respected in future
applications.

That's fine by me. I do think though that that approach rather compels UI
designers to abandon the guidelines when a potentially better approach is
discovered. It also means it's more likely that new/better approaches will
inevitably be discovered outside of the KDE community, used by UI designers
in conflict with the guidelines and then only adopted by the guidelines
when enough UI designers break the guidelines to use the new approach.

I didn't mean we cannot introduce something new via the HIG. It's just that if
we do, we have to make such a convincing case for it that we can convince some
developers to implement it soon after the HIG is released, so that people can
see it in action.

For clarity, I'm not saying my proposal is necessarily better - I was just
proposing it to see if folks here might find it useful, as I have in
practice. I mean this sincerely: I do *not* take any offence if you all
prefer to continue in the direction you were before I popped in. Whatever
you folks come up with will certainly be better than anything we've had
before, so I welcome it! More importantly, if anything I've offered so far
has been found with discomfort or offence, I sincerely apologize. :-)

It seems like my previous email came off too harsh. Sorry for that. I tend to
focus on pointing out potential problems with new ideas. I only mean to be
cautious so ideas won't fail just because some aspect hasn't been given enough
thought, but it seems like often end up discouraging people which are excited
about new ideas.

If I point out potential problems with an idea, it usually means that I like
the idea in general. If I don't I usually just quietly hope that it will lose
momentum and fade away without me having to fight it ;)

<offtopic>
I originally had some text here describing my intent to contribute to
putting together a design pattern library. However, rather than derail this
topic any more than I already have, feel free to contact me on via G+, via
email, or on the VDG forum if you're interested in that topic.
</offtopic>

Actually, one part of the project that got me involved with KDE more than five
years ago (damn, time flies!) was exactly that, and its results can still be
seen here:
http://techbase.kde.org/Projects/Usability/HIG/SOU_Workspace#Design_Patterns
Sadly it hasn't really taken off (yet), but I'd love to revive that project
together with you and anyone else interested!

Thanks much for taking the time to consider what I've offered, and please
don't be shy about moving in the direction you originally had planned,

Sorry again if I discouraged you. You input is greatly appreciated, and
nothing has been decided yet!

[Andrew Lake]

Post by Thomas Pfeiffer

Post by Andrew Lake
This is relatively easily addressed by a collapsible Options section

under

Post by Andrew Lake
Search that is exposed, or made available to be exposed, when search is
active. In practice, I've found this works quite well.

Picture, please ;) I guess I understand what you mean on an abstract level,
but would like to see it "in action"

I did it again! What was I thinking? Haha, no problem. When I got home
after work I did a quick mockup showing what the progression looks like for
the fake file manager:
Loading Image...

I'm pretty sure I'm violating some HIG alignment guidelines somewhere
there, but I hope you get the idea - progressively reveal more
functionality as the user needs it.

Post by Thomas Pfeiffer
We could still place the search/filter field above the other categories even
if it's a "real" search, couldn't we?

Oh yeah, I think that'd be totally fine. Maybe consider the pattern I''m
offering here could be another option for UI designs that already have a
category/content selection pane controlling a separate content pane. I
definitely don't think the other pattern has to be wrong for this to be an
option.

Post by Thomas Pfeiffer
Actually, one part of the project that got me involved with KDE more than five

years ago (damn, time flies!) was exactly that, and its results can still be

Post by Thomas Pfeiffer
http://techbase.kde.org/Projects/Usability/HIG/SOU_Workspace#Design_Patterns
Sadly it hasn't really taken off (yet), but I'd love to revive that project
together with you and anyone else interested!

So excited about this! Totally in the wheelhouse of contributions I'd very
much like to make as VDG member.

Post by Thomas Pfeiffer
... Please stay with us and suggest new
stuff for the HIG.

Oh no no, please don't take my previous mail to mean I'm taking my stuff
and heading home! I'm totally sticking around to drive you all nuts! jk I'm
immensely grateful for the welcoming feeling I've gotten here. Like I said,
no matter the outcome in this particular case, I'm confident it'll be a win
for a community in the end. :-)

Much respect,
Andrew

[Jens Reuterberg]

Post by Andrew Lake
http://wstaw.org/m/2014/03/26/Category_search_pattern.png

Sry I'm just here to say :O I wantz that! So badly!

[Philipp Stefan]

Post by Andrew Lake
I did it again! What was I thinking? Haha, no problem. When I got home
after work I did a quick mockup showing what the progression looks
http://wstaw.org/m/2014/03/26/Category_search_pattern.png
I'm pretty sure I'm violating some HIG alignment guidelines somewhere
there, but I hope you get the idea - progressively reveal more
functionality as the user needs it.

This looks very good. My only problem is that we could run into
situations where the search field is too short/the side bar is too big.
It obviously looks good when the search field is shown, but when it's
hidden the sidebar looks rather funky.
Of course the content view could just be shrunk to make place for a
bigger side bar when the search is called, but then the content would
also jump. IIRC Heiko did/does want to prevent this from happening.

On another note: I'm currently trying to get into the Wiki stuff, to
"fork" the HIG parts that I like contributing to, like Andrew did. I
didn't think it's that complicated :D

Cheers,

Phil

[Thomas Pfeiffer]

Post by Philipp Stefan

Post by Andrew Lake
I did it again! What was I thinking? Haha, no problem. When I got home
after work I did a quick mockup showing what the progression looks
http://wstaw.org/m/2014/03/26/Category_search_pattern.png
I'm pretty sure I'm violating some HIG alignment guidelines somewhere
there, but I hope you get the idea - progressively reveal more
functionality as the user needs it.

This looks very good. My only problem is that we could run into
situations where the search field is too short/the side bar is too big.
It obviously looks good when the search field is shown, but when it's
hidden the sidebar looks rather funky.
Of course the content view could just be shrunk to make place for a
bigger side bar when the search is called, but then the content would
also jump. IIRC Heiko did/does want to prevent this from happening.

Agreed: The sidebar shouldn't auto-expand when the options are expanded. It
could make all the icons in the main part rearrange, which would be quite
confusing.
If we can avoid that, I'm fine with the idea :)

Post by Philipp Stefan
On another note: I'm currently trying to get into the Wiki stuff, to
"fork" the HIG parts that I like contributing to, like Andrew did. I
didn't think it's that complicated :D

No need to "fork" anything. You can just edit a page with a suggestion, we can
still revert it easily if we decide that the suggestion is not the way to go.

[Heiko Tietze]

Post by Andrew Lake
http://wstaw.org/m/2014/03/26/Category_search_pattern.png

I think the position is good in case of some preselection is done left-hand.
But if we have navigational content it absolutely makes no sense to place a
search field there that affects the content only. For instance a file browser
with folders on the left and files at the client area.

All else looks nice to me except the missing main menu and the missing
scrollbar arrows. :-)

[Philipp Stefan]

Post by Heiko Tietze

Post by Andrew Lake
http://wstaw.org/m/2014/03/26/Category_search_pattern.png

I think the position is good in case of some preselection is done left-hand.
But if we have navigational content it absolutely makes no sense to place a
search field there that affects the content only. For instance a file browser
with folders on the left and files at the client area.
All else looks nice to me except the missing main menu and the missing
scrollbar arrows. :-)
_______________________________________________
kde-guidelines mailing list
https://mail.kde.org/mailman/listinfo/kde-guidelines

I think so, too. I think the search field should be placed in the menu
bar when the search will be performed in a global manner / lots of
different directories that can't be accessed via the sidebar. Dolphin
and I guess Kmail would also fit in this category.
Apps that use the sidebar to navigate the applications/ between
different grouping options of the data should place the search field in
the sidebar. A music player or a social media application would fall
into this second category.

In these second applications the search function is just a simple filter
functions. And based on that I'm going to claim that the difference
between search and filter is actually pretty meaningless in most use cases.

Let's imagine a music player:

The applications currently is displays the album view. The user
opens the search dialogue and attempts to search for a specific
song, because the search function actually is filter here the
application will display the album which contains the target song.
The user now has two choices:
1) Click on the album and then navigate the the song
2) Click on "songs" in the sidebar and then directly navigate to the
song in question
This way no additional options for the search is needed - the
different options in the sidebar become the search controls.

Let's imagine a application with a complicated structure like a file
browser:

1)The application currently displays a random directory. The user
wants to find a file and has no idea where it resides. He calls the
search function and the search field appear in the menu bar along
with the option to display more settings. The search then returns
the wished results and the user will proceed with whatever they had
in mind.

2)The user currently navigates a directory with lets say over 100
files. The user then calls the filter function via a shortcut or a
menu entry. The search field appears in the menu bar along with a
option to display more settings. In these setting the option to only
search the current directory is toggled. The filter will return the
desired results and the user continues with what they were doing.

With this in mind I propose to always demand an instant search. If the
search takes a bit longer an indicator that the query is still being
processed can be shown. We can also get rid of the difference between
the filter and the search functionality. The search field and the filter
field are the same entity with the different predefined settings. They
reside in the same area and use the same label and icon.

The different shortcuts will then only be a quick way to change between
different parameters of the search function.

I think this way the guidelines can be simplified greatly and I think
the behaviour of the whole function become clearer/more consistent to
the user. I think the user generally doesn't really care about the
technical differences, and those who do can simply change them in the
search settings.

What do you think?

Phil

[Thomas Pfeiffer]

Post by Philipp Stefan

Post by Heiko Tietze

Post by Andrew Lake
http://wstaw.org/m/2014/03/26/Category_search_pattern.png

I think the position is good in case of some preselection is done
left-hand. But if we have navigational content it absolutely makes no
sense to place a search field there that affects the content only. For
instance a file browser with folders on the left and files at the client
area.
All else looks nice to me except the missing main menu and the missing
scrollbar arrows. :-)
_______________________________________________
kde-guidelines mailing list
https://mail.kde.org/mailman/listinfo/kde-guidelines

I think so, too. I think the search field should be placed in the menu
bar when the search will be performed in a global manner / lots of
different directories that can't be accessed via the sidebar. Dolphin
and I guess Kmail would also fit in this category.
Apps that use the sidebar to navigate the applications/ between
different grouping options of the data should place the search field in
the sidebar. A music player or a social media application would fall
into this second category.
In these second applications the search function is just a simple filter
functions. And based on that I'm going to claim that the difference
between search and filter is actually pretty meaningless in most use cases.
The applications currently is displays the album view. The user
opens the search dialogue and attempts to search for a specific
song, because the search function actually is filter here the
application will display the album which contains the target song.
1) Click on the album and then navigate the the song
2) Click on "songs" in the sidebar and then directly navigate to the
song in question
This way no additional options for the search is needed - the
different options in the sidebar become the search controls.
Let's imagine a application with a complicated structure like a file
1)The application currently displays a random directory. The user
wants to find a file and has no idea where it resides. He calls the
search function and the search field appear in the menu bar along
with the option to display more settings. The search then returns
the wished results and the user will proceed with whatever they had
in mind.
2)The user currently navigates a directory with lets say over 100
files. The user then calls the filter function via a shortcut or a
menu entry. The search field appears in the menu bar along with a
option to display more settings. In these setting the option to only
search the current directory is toggled. The filter will return the
desired results and the user continues with what they were doing.
With this in mind I propose to always demand an instant search. If the
search takes a bit longer an indicator that the query is still being
processed can be shown. We can also get rid of the difference between
the filter and the search functionality. The search field and the filter
field are the same entity with the different predefined settings. They
reside in the same area and use the same label and icon.
The different shortcuts will then only be a quick way to change between
different parameters of the search function.
I think this way the guidelines can be simplified greatly and I think
the behaviour of the whole function become clearer/more consistent to
the user. I think the user generally doesn't really care about the
technical differences, and those who do can simply change them in the
search settings.
What do you think?
Phil

I think unifying search and filter mechanism makes a lot of sense from a user
perspective. It might be difficult to convince developers because they seem to
usually prefer to present things in a technically precise manner (Jens'
"precise vs. correct" comes to mind once again), but for users a filter and a
search in the current folder is presumable the same.

[Philipp Stefan]

Post by Thomas Pfeiffer
I think unifying search and filter mechanism makes a lot of sense from a user
perspective. It might be difficult to convince developers because they seem to
usually prefer to present things in a technically precise manner (Jens'
"precise vs. correct" comes to mind once again), but for users a filter and a
search in the current folder is presumable the same.

That's of course a problem, but not one that can't be solved. I'd expect
the developers to be rational and be open for our arguments (and vice
versa of course). I think in this case we have good arguments at our hands.
It's worth a try at least, or so I think. Where can we reach out to the
developers or get them to come here and give us some feedback on this?

Phil

[Andrew Lake]

[Thomas Pfeiffer]

On Tuesday 01 April 2014 09:47:36 Andrew Lake wrote:

[Philipp Stefan]

Hmm, I send this mail a few days ago, but it doesn't seem to have
arrived. My apologies for the late reply.

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 "

[Thomas Pfeiffer]

Post by Philipp Stefan
Hmm, I send this mail a few days ago, but it doesn't seem to have
arrived. My apologies for the late reply.

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 "

[Heiko Tietze]

Am 30.03.2014 19:36:30, schrieb Philipp Stefan:
I think this way the guidelines can be simplified greatly and I
think the behaviour of the whole function become clearer/more
consistent to the user.

Yes!

I was thinking about a better HIG for a while. We have discussed a lot of options, especially about the position of the control. Reviewing the current layout I get these results:

** Start search at the upper right area of your dialog (KCM and input for web browser's search engine).
** Start above the content area (Search in Dolphin, KMail - search within current mail, KSystemLog)
** Start below the content area (Filter in Dolphin, Konqueror / Rekonq / Browser search within current page in general, KWrite, Konsole, Okular).
** Start above or below depending on the layout (Kicker, if started from a top- or bottom-aligned band).
** Make search floating (KRunner style).
** Use an extra (modal) dialog (KMail search for mails, Krusader).
** Start above the navigation area/category selection to clean the content on-the-fly (Bangarang).

I started with this consideration but most of these operations might be understood in terms of a filter since it don't generate something new but jump to the right position! So what's about the simple advice to use a standard 'filter' and search per extra dialog. This would affect only Dolphin, but solves the strange "from here" issue by the way.

Therefore I stripped all discussion from the HIG and applied a different structure (please understand it as proposal not solution; all changes can be reverted).
http://techbase.kde.org/Projects/Usability/HIG/SearchPattern
--------------------------------
Purpose
A search function allows to generate a subset out of a big
number of items on ground of a user defined pattern. The function is
essential to find matching items in case of a extended list or if the
position of target(s) is unknown, as well as when bulk operations should
be executed to a subset. A search operation interrupts the 'predefined
workflow' and bypass core functions to a user-defined data set.
Supplemental to search is the filter function which rather reduces a given number of items than generating an output. Filtering should be always instantaneous.

[show] Use case for filter vs. search
Guidelines
Provide filter function to shown content by default. Apply search using an extra dialog.
Filter
Input
Perform filter operations always instantaneously.
Make the operation as simple as possible. For instance, do not
apply multi-dimensional filtering or do not use logical operators for
input.
Run operation case insensitive, unless it is important.
Make input control large enough to show at least 20 characters.
Output
Make the filter result persistent until it is cleared
explicitly. Users must not need to research after selecting or
referencing an item.
Provide auto complete feature to the input based on previous operations.
Highlight matching results and jump to the first occurrence.
Appearance
Hide input control until users start the search.






 
NoteI'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.

Search
Input
Do not inherit artificial intelligence from users. Search operations have always be clear and comprehensible to users.
Show hints on how to use the search effectively.
Do fuzzy search by default, if applicable. That means extend the results by adding a wildcard to the item.
Run a combined AND search when two words have been entered unless the term is quoted (e.g. Hello World vs "Hello World")
Output
Show the search pattern at the header of the result list (e.g. "Search results for: <Hello World>")
Follow the guidelines on delayed operations if the search takes longer.
Provide paging/scrolling of results.
Appearance
Run search operation within an extra, modal dialog.
Best Practice
Example 1
Example 2

--------------------------------
For now, most apps places the filter bar below the content. That should be used as the state of the art for the HIG but might be as well a good starting point to improve the layout with Plasma Next. Because a mailing list is not so good for discussions I vote for moving back to the forum with all advanced ideas and to keep the legacy stuff here. (I know it was me who moved the discussion first to the ML, sorry.)

[Philipp Stefan]

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?

Post by Philipp Stefan
I think this way the guidelines can be simplified greatly and I
think the behaviour of the whole function become clearer/more
consistent to the user.
Yes!
I was thinking about a better HIG for a while. We have discussed a lot
of options, especially about the position of the control. Reviewing
** Start search at the upper right area of your dialog (KCM and input
for web browser's search engine).
** Start above the content area (Search in Dolphin, KMail - search
within current mail, KSystemLog)
** Start below the content area (Filter in Dolphin, Konqueror / Rekonq
/ Browser search within current page in general, KWrite, Konsole, Okular).
** Start above or below depending on the layout (Kicker, if started
from a top- or bottom-aligned band).
** Make search floating (KRunner style).
** Use an extra (modal) dialog (KMail search for mails, Krusader).
** Start above the navigation area/category selection to clean the
content on-the-fly (Bangarang).
I started with this consideration but most of these operations might
be understood in terms of a filter since it don't generate something
new but jump to the right position! So what's about the simple advice
to use a standard 'filter' and search per extra dialog. This would
affect only Dolphin, but solves the strange "from here" issue by the way.
Therefore I stripped all discussion from the HIG and applied a
different structure (please understand it as proposal not solution;
all changes can be reverted).
http://techbase.kde.org/Projects/Usability/HIG/SearchPattern
--------------------------------
Purpose
A /search function/ allows to generate a subset out of a big number of
items on ground of a user defined pattern. The function is essential
to find matching items in case of a extended list or if the position
of target(s) is unknown, as well as when bulk operations should be
executed to a subset. A search operation interrupts the 'predefined
workflow' and bypass core functions to a user-defined data set.
Supplemental to search is the /filter function/ which rather reduces a
given number of items than generating an output. Filtering should be
always instantaneous.
[show] Use case for filter vs. search
Guidelines
* Provide filter function to shown content by default. Apply search
using an extra dialog.
Filter
------------------------------------------------------------------------
Input
* Perform filter operations always instantaneously.
* Make the operation as simple as possible. For instance, do not
apply multi-dimensional filtering or do not use logical operators
for input.
* Run operation case insensitive, unless it is important.
* Make input control large enough to show at least 20 characters.
Output
* Make the filter result persistent until it is cleared explicitly.
Users must not need to research after selecting or referencing an
item.
* Provide auto complete feature to the input based on previous
operations.
* Highlight matching results and jump to the first occurrence.
Appearance
* Hide input control until users start the search.
noframe <Loading Image...>
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.
Search
------------------------------------------------------------------------
Input
* Do not inherit artificial intelligence from users. Search
operations have always be clear and comprehensible to users.
* Show hints on how to use the search effectively.
* Do fuzzy search by default, if applicable. That means extend the
results by adding a wildcard to the item.
* Run a combined AND search when two words have been entered unless
the term is quoted (e.g. Hello World vs "Hello World")
Output
* Show the search pattern at the header of the result list (e.g.
"Search results for: <Hello World>")
* Follow the guidelines on delayed operations
<http://techbase.kde.org/Projects/Usability/HIG/ProgressIndicator>
if the search takes longer.
* Provide paging/scrolling of results.
Appearance
* Run search operation within an extra, modal dialog.
Best Practice
* Example 1 <http://i.imgur.com/eL7mi4K.png>
* Example 2 <http://wstaw.org/m/2014/03/26/Category_search_pattern.png>
--------------------------------
For now, most apps places the filter bar below the content. That
should be used as the state of the art for the HIG but might be as
well a good starting point to improve the layout with Plasma Next.
Because a mailing list is not so good for discussions I vote for
moving back to the forum with all advanced ideas and to keep the
legacy stuff here. (I know it was me who moved the discussion first to
the ML, sorry.)
_______________________________________________
kde-guidelines mailing list
https://mail.kde.org/mailman/listinfo/kde-guidelines

[Heiko Tietze]

Post by Philipp Stefan
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 ;-).

[Thomas Pfeiffer]

Post by Heiko Tietze

Post by Philipp Stefan
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"

Post by Heiko Tietze
== 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?

Post by Heiko Tietze
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).

Post by Heiko Tietze
|
| 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!

Post by Heiko Tietze
== 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.

Post by Heiko Tietze
=== 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).

Post by Heiko Tietze
==== 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.

Post by Heiko Tietze
=== 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?

Post by Heiko Tietze
==== Appearance ====
* Run search operation within an extra, modal dialog.

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

Post by Heiko Tietze
== 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

[Heiko Tietze]

Post by Thomas Pfeiffer

Post by Heiko Tietze
== 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

[Thomas Pfeiffer]

Post by Thomas Pfeiffer

Post by Heiko Tietze
== 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?

[Heiko Tietze]

Why can't we just call it Search?

Do you agree to separate the filter (or whatever we call it) function from
search?

(This question is not related to your concerns about the word pattern but to
all other discussion.)

[Thomas Pfeiffer]

Post by Heiko Tietze

Why can't we just call it Search?

Do you agree to separate the filter (or whatever we call it) function from
search?

As stated before, I see three different things (filter a list, search anywhere
and highlight within opened document), and in order to keep HIGs short, we
should in fact create one HIG for each, and interlink them.
I'd focus on the filtering first, since this is what the current draft mostly
talks about.

[Heiko Tietze]

Post by Thomas Pfeiffer
As stated before, I see three different things (filter a list, search
anywhere and highlight within opened document), and in order to keep HIGs
short, we should in fact create one HIG for each, and interlink them.
I'd focus on the filtering first, since this is what the current draft
mostly talks about.

I cannot follow you. First, those three aspects are apples and oranges to me -
filter/search are two different work-flow (which I want to separate) and
highlighting is one way to show the output. You argue with filter and search.
For instance:

|What about
|a) Search within active document
|b) Filter of currently visible list of elements
|c) Search for elements not currently visible
or
|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.

|KMail has all three (as described above)
|Kate has a) via Ctrl-F or "Edit -> Find..." as well as c) via "Search...
|Kickoff looks like it only has b),

I'm afraid of a mix-up and of unclear advice. I tried to write up a HIG for
all aspects we discussed, similar to your list, but it felt bad. Therefore I
want to get rid of all search except the content filter via ctrl+F - which is
what almost all application provide (in a similar way below the content).

If we follow your proposal with a), b), and c) we have to define when to use
what option. And we have to find a different name for c) as 'search'.
Additionally I have no idea what we add to the second HIG if all questions are
answered in this one.

[Heiko Tietze]

Post by Thomas Pfeiffer
As stated before, I see three different things (filter a list, search
anywhere and highlight within opened document), and in order to keep HIGs
short, we should in fact create one HIG for each, and interlink them.
I'd focus on the filtering first, since this is what the current draft
mostly talks about.

After talking with Thomas we agreed on having three types of search for
different use cases. The HIG proposal is now as following:

== Purpose ==
A ''search'' function allows to generate a subset out of a big number of items
on ground of a user defined pattern. It usually can be applied to various
sources and has several options for fine-tuning.

Supplemental to search the ''filter'' function reduces the number of items.
This operation works on the current list only and does not generate a new
output. Filtering should be always instantaneous and must not interrupt the
workflow.

Similar to filtering the operation might be used to ''highlight'' information.
This preselection is a common feature in text processing and used to locate a
particular piece of information without concealing the surrounding.

(Use case)

== Search ==
* Use a search function to generate results based on various sources with
sufficient options.
* Always provide search function via extra secondary dialog.

=== Behavior ===
* Do not inherit artificial intelligence from users. Search operations have
always be clear and comprehensible to users.
* Show hints on how to use the search effectively.
* Run a combined AND search when two words have been entered unless the term
is quoted (e.g. Hello World vs "Hello World")
* Follow the guidelines on delayed operations if the search takes longer.

=== Appearance ===
* (Yet to be defined by the VDG)

=== Implementation ===
* (To be defined by devs)

== Filter ==
* Apply filter to restrict the number of items of a list.
* Do not overload the simple filter function by options. If necessary, provide
an additional search.

=== Behavior ===
* Perform filter operations always instantaneously.
* Make the operation as simple as possible. For instance, do not apply multi-
dimensional filtering or do not use logical operators for input.
* Run operation case insensitive, unless it is important.
* Make input control large enough to show at least 20 characters.
* By default clear the filter input when the content is changed. But consider
to provide a sticky function and keep the filter until it is cleared
explicitly. With this option users do not need to research after selecting or
referencing an item.
* Consider to provide auto complete feature to the input based on previous
operations.

=== Appearance ===
* Show the filter pattern above the list of items.
* Use Ctrl+H to show/hide the input.
* Do not hide the input if the filter is an essential part of the application,
i.e. when the list of items usually is large.
* Show 'Search...' as place holder unless the control is focused. Do not use
'filter' or other labels.

=== Implementation ===
* (To be defined by devs)

== Highlight ==
* Provide 'highlight search' when the content is relevant.
* Do not overload the simple highlight function by options. If necessary,
provide an additional search.

=== Behavior ===
* Perform highlight operations always instantaneously.
* Make the operation as simple as possible. Do not add options.
* Run operation case insensitive.
* Make input control large enough to show at least 20 characters.
* Consider to provide auto complete feature to the input based on previous
operations.

=== Appearance ===
* Place the input control at the bottom of the content area.
* Hide the input by default.
* Active the control and focus it on ctrl+F.

=== Implementation ===
* (To be defined by devs)

[Heiko Tietze]

We updated the search guidelines according the discussion on the forums. At least placement of and access (short-cuts) to controls should be final now. The search dialog itself is still in discussion: Thomas prefers the Amarok style (drag 'n drop) and I favor the dual-list pattern for simplicity and accessibility reason.

http://techbase.kde.org/Projects/Usability/HIG/SearchPattern

[Heiko Tietze]

The search dialog itself is still in discussion: Thomas prefers the Amarok style (drag 'n drop) and I > favor the dual-list pattern for simplicity and accessibility reason.

Thomas convinced me to favor the Amarok style. The telling argument to me is to not alter the simple dual-list pattern. And we can reuse existing code and improve it "upstrem". A blog post is almost ready for publication which outlines the final HIG for a broader audience.

[Heiko Tietze]

On Tuesday 25 March 2014, 09:51:44 Andrew Lake wrote:
<ontopic>

Post by Andrew Lake
<offtopic>
I originally had some text here describing my intent to contribute to
putting together a design pattern library. However, rather than derail this
topic any more than I already have, feel free to contact me on via G+, via
email, or on the VDG forum if you're interested in that topic.
</offtopic>

Don't we discuss design pattern right now? Please stay with us and suggest new
stuff for the HIG (but a new thread would be nice *g*).

I suggested to run a user survey as we started to discuss this issue. Assuming
we all agree on one solution it wouldn't make sense. But if we have two or
more ideas, all well proofed by arguments, we should offer these options to the
community. If I find some spare time tomorrow or so, I'll try to outline a
conclusion.

[Philipp Stefan]

Post by Thomas Pfeiffer

Post by Philipp Stefan
Hello everyone,

Hi Phil,
welcome to the HIG team!

Post by Philipp Stefan
How is a conclusion reached? Is there normally some kind of vote, or
will the one who edits the wikipage first the one who decides what's
being used? Also, is there some kind of place where the current "draft"
is saved, or does the current HIG wikipage function like that? I ask,
because I have a horrible memory and forget easily. Something along the
lines of "Issue | Decision" would be wonderful. I can, of course, also
make such a list only for myself :)

So far, the process has been
1. Someone (so far usually Heiko) writes a first draft and puts it either on
the wiki or the mailing list (usually both)
2a. We discuss the draft on the mailing list until all issues have been sorted
out
2b. If others find small issues that don't need discussion (like misspellings
or language imperfections), they directly edit the wiki
3. Changes are applied to the Wiki and we consider the guideline "released"
So far we've been able to reach consensus on all matters without needing a
vote (a vote doesn't make much sense with so few people, recently in fact only
Heiko and me have been active on this list unless I dragged David Edmundson in
to give some technical feedback).
Cheers,
Thomas
_______________________________________________
kde-guidelines mailing list
https://mail.kde.org/mailman/listinfo/kde-guidelines

Thank you for clearing that up! Sounds simple enough, simple enough for
me, which is always good. :)

I made a quick mockup of all the possible default styles/layouts of the
search field [1]. On the left one can see all the possible styles for
the unfocused search field that we've discussed so far.
1) Is just an entry field with the label "Search" (or "Filter"
respectively).
2) Is the same except that it follows elementary's HIG for the labeling [2].
3) Just a symbol without any label.
4) A symbol and a simple label ("Search" / "Filter")
5) A symbol and a label that follows elementary's HIG [2]

I made the "Busy" section on the left under the assumption that we'd
have choose to recommend "instant" search. If a query would take longer
a spinning (in this example blue) circle would appear. If we want to
explore philiphorger's [3] idea more, I can make a second overview.

I hope that'll help to settle for one version. :)

Cheers,

Phil

[1] Loading Image...
[2] http://elementaryos.org/docs/human-interface-guidelines/search-fields
[3] http://forum.kde.org/viewtopic.php?f=285&t=120079#p304953

[Thomas Pfeiffer]

Post by Heiko Tietze

Post by Thomas Pfeiffer
Do you guys agree that such an HIG is necessary? If so, I think we
should first decide whether KDE should stick to always visible search
fields or switch to hidden ones, then I can start writing the guideline
(unless Heiko would like to step up to do it ;) ).

Let's start: http://techbase.kde.org/Projects/Usability/HIG/SearchPattern
PS: It's a pity that usability gets less attention in the last time. So to all
readers of this mailing list: Please join the discussion! A simple go ahead
would be nice at least... ;-)

In a very curious coincidence, just today someone started a thread in
the VDG forum to discuss his ideas for a Search HIG [1]! He found your
draft, but after reading the title "Search Pattern" he thought that it
did not concern search fields in the UI. This may point to a need to
change the title, but that's just a small thing.

What's more important is that he already put a lot of thought into this
and even created mockups. In order not to put him (and others who might
be interested in this) off by tellin them to subscribe to a mailing
list, I'd like to move the discussion to the forum thread and work on
this HIG there.
Therefore I'd like to invite you, Heiko, and anyone else who is
interested to join the discussion in the forum:

[1] http://forum.kde.org/viewtopic.php?f=285&t=120079

Thanks,
Thomas