Sogatori wrote:I'd be ok with joining the mailing list. I already subscribed to the mailing list, though now I am a bit clueless what to do next. I can't really quote anyone, because I don't have the past mails. Is there a way to get the mailing list to send me the old mails that are already there, so I can reply to them?

Okay, great that you've subscribed! I've just sent my reply to Heiko's last mail, so you can reply to that one.

Sogatori wrote:

philiphorger wrote:[…]
But what if the search requires heavy computation, pulling a lot of resources from disk or network, etc.?

Code: Select all

 [ how can mirrors be re|                                 ⏎ ]


NOW we have a symbol for either the return key, or a key in general. Pressing ENTER or clicking the icon will trigger a search. And the visual change as the user starts typing, draws attention to the on-completion nature of the search field.

Oh, I like the idea! I will try to incorporate it into the mockups I'm currently making based on the feedback. It helps me to express what I mean since I'm not great with words.

Cool! Glad the idea doesn't just sound good in my head, seeing it as a mockup would be awesome

Sogatori wrote:

colomar wrote:

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

I don't want to ditch the mailing list, but since we now have several people involved in this thread who are not subscribed to the mailing list, could we continue discussing this specific guideline here? Or would it be okay for the others in this thread to join the kde-guidelines mailing list?

I'd be ok with joining the mailing list. I already subscribed to the mailing list, though now I am a bit clueless what to do next. I can't really quote anyone, because I don't have the past mails. Is there a way to get the mailing list to send me the old mails that are already there, so I can reply to them?

Mailing lists usually have copies that are hosted by web services. It looks like the one for kde-guidelines is here: http://lists.kde.org/?l=kde-guidelines&r=1&w=2

Personally, I'd love for the thread to continue to be a valid avenue for this conversation, even if not exclusively. It's not too hard to maintain a rough sync between ML and forum, since you can post forum links in the ML and ML links in the forum, when you want to draw the audience's awareness to something interesting on the other side. But that does admittedly only work for a loose sort of synchronization - the tighter you try to bind the two together, the more work it is to write or read, and past some threshold it just gets obnoxious. For this, though, I think easy loose sync is probably all that's needed.

philiphorger wrote:Personally, I'd love for the thread to continue to be a valid avenue for this conversation, even if not exclusively. It's not too hard to maintain a rough sync between ML and forum, since you can post forum links in the ML and ML links in the forum, when you want to draw the audience's awareness to something interesting on the other side. But that does admittedly only work for a loose sort of synchronization - the tighter you try to bind the two together, the more work it is to write or read, and past some threshold it just gets obnoxious. For this, though, I think easy loose sync is probably all that's needed.

I'll still be reading this thread here, so if something important comes up, I'll post it on the mailing list. And yes, we can post important news from the ML thread here, too.

After some discussion on the mailing list we have come to an agreement. The outcome is added to the HIG [1] and proposed in a blog post [2]. In general we define three types search: a) filter (which restricts a list of items to the search pattern; input above the control and rather static), b) highlighter (the known 'ctrl+F feature' that is used to mark a pattern without hiding the surrounding; input below the content and on demand only), and c) the literally search which should be operated per extra window. Options a) and b) should be as simple as possible.
What we need, supposed we all agree on this solution, is a nice visual design that supports the different use cases.

[1] HIG page: http://techbase.kde.org/Projects/Usabil ... rchPattern
[2] Blog post: http://user-prompt.com/kde-hig-the-search-pattern/

Well, for the search dialog, the Amarok extended filter options is an interesting spin on traditional ones. It certainly gets the job done nicely, although it looks pretty unusual:



(sorry for the localisation, but you probably get the idea)

We currently have three places to discuss this HIG proposal (mailing list, forum, blog). I'm kind of lost about where to send my concerns.

I've commented on the blog post and I'm going to mirror that comment here, I've seen there are some comments here about the "search when typing" feature and I'd like to expose some of my thoughts about these guidelines as well.

(http://user-prompt.com/kde-hig-the-sear ... mment-3595)

I know I'm late to the party, but I find this whole search vs. filter thing counter-intuitive. Plus, there should be some additional guideline for the keyboard navigation. On Dolphin, when you Ctrl-F, you search for something, press ENTER and press the key down to select some result, but when you Ctrl-I, the filter is instantaneous but you have to remember pressing ENTER to get back to the list so you can select some result.

What you describe as being the highlight search is, IMHO, an improvement to the default Qt keyboardSearch() method (you start typing on Dolphin and if you're lucky, it will select the file/folder starting with the term you just typed). In every situation where the keyboardSearch() makes sense, the highlight search also makes perfect sense.

I find it very strange that I can type Ctrl-I then Ctrl-F and have both boxes open at the same time (Dolphin) and I think that a solution with just one box (and one shortcut) would be simpler than the proposed guideline.

But even with a two shortcuts solution being the final HIG for highlighting/filtering, I miss some more details about keyboard navigation, "search when typing" being the first thing that comes to my mind, but also some default way to actually get back to the results list: After the search/filter, what is the selected result? Where is the focus? How to get the focus back to the results list?

renatoatilio wrote:We currently have three places to discuss this HIG proposal (mailing list, forum, blog). I'm kind of lost about where to send my concerns.

I suggest to use this forum for new ideas. All 'description about the current state' belongs to the HIG, and the mailing list when it sticks to some point.

To add a thought to what I replied at the blog: The 'keyboard search', e.g. jump to the first occurrence, should be rather part of list views [1]. But it doesn't solve any generic search/filter/highlight issue - we cannot use this pattern in all applications - and it has more of a convenience feature that supports the filter operation. Take a look at Krusader: The feature is the same but you see what you are doing because a small filter bar opens. Isn't this idea very similar to the proposal?

[1] http://techbase.kde.org/Projects/Usability/HIG/ListView

Heiko Tietze wrote:To add a thought to what I replied at the blog: The 'keyboard search', e.g. jump to the first occurrence, should be rather part of list views [1]. But it doesn't solve any generic search/filter/highlight issue - we cannot use this pattern in all applications - and it has more of a convenience feature that supports the filter operation. Take a look at Krusader: The feature is the same but you see what you are doing because a small filter bar opens. Isn't this idea very similar to the proposal?

Just to be clear, I agree on the search/filter/highlight as a general solution. It is just that in most cases, where an implicit approach is possible, it should be endorsed by the guidelines, in my opinion. This is the Krusader case you described, and also the case of a patch I created for Telepathy [1] that delegates key typing on the tree view to the filter bar (you see what you are doing because you are actually using the filter bar - but that was created before these proposed guidelines).

In other words, the general way of searching/filtering/highlighting should also be there, but a default "convenience feature" supporting the filter (or the highlight, debatable) operation shouldn't also be described on the guidelines to create a standard convenience search?

[1] https://git.reviewboard.kde.org/r/117916/

Hmm, the GTK box that appears on typing is certainly an improvement. I think that filters should get more of a representation, though (search has a button, but filters are usually tucked away and I have no clue what keyboard shortcut would activate it in different programs). I have one directory full of files with the same prefix (which happens to have a number in it), and typing things in does absolutely nothing in that case. A filter would work perfectly there, but there's no button for it...

Just another thought about the highlight approach.

Searching with Ctrl+F is supposed to highlight the matching results, which is great.

But with the focus still on the search box, how do you navigate between the results?

Okular, for instance, has shortcuts for navigation (Alt+P and Alt+N). But pressing the UP and DOWN keys does absolutely nothing.

I don't know if it is in the scope of this HIG, but having the search navigation also conforming to some patterns would be great.

I already wrote about this here:
viewtopic.php?f=83&t=111514
And some things related to this here too:
viewtopic.php?f=83&t=96374

renatoatilio wrote:But with the focus still on the search box, how do you navigate between the results?

Okular, for instance, has shortcuts for navigation (Alt+P and Alt+N). But pressing the UP and DOWN keys does absolutely nothing.

I don't know if it is in the scope of this HIG, but having the search navigation also conforming to some patterns would be great.

The default shortcuts for "Find Next" and "Find Previous" are F3 and Shift-F3. This is more of a legacy thing because "that's how it's always been done". If we keep those shortcuts, people who already know them don't have to adapt, but they're less intuitive for newcomers.
Btw: In Kate, up and down arrow switch between recently used search strings.

And yes, we have to include shortcuts for find previous/next in the HIG. Good catch!

colomar wrote:And yes, we have to include shortcuts for find previous/next in the HIG. Good catch!

We have a special page on short-cuts with:
* Find Next |F3|Find the next match
* Find Previous|Shift+F3|Find previous match
However, a link to this page would be kind.

Heiko Tietze wrote:

colomar wrote:And yes, we have to include shortcuts for find previous/next in the HIG. Good catch!

We have a special page on short-cuts with:
* Find Next |F3|Find the next match
* Find Previous|Shift+F3|Find previous match
However, a link to this page would be kind.

Yes, cross-linking is important, especially since we do include the shortcut for starting the search as such in the search pattern HIG.

colomar wrote:Yes, cross-linking is important, especially since we do include the shortcut for starting the search as such in the search pattern HIG.

I just changed it to "Use Ctrl+H to show/hide the input, and F3/Shift+F3 for the next/previous item (cf. HIG about [http://techbase.kde.org/Projects/Usability/HIG/Keyboard_Shortcuts short-cuts])." but it makes no sense in case of the filter. So I added it only to the highlighter:

* Active the control and focus it on ctrl+F, and use F3/Shift+F3 to go to the next/previous item (cf. HIG about [http://techbase.kde.org/Projects/Usability/HIG/Keyboard_Shortcuts short-cuts]).