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

[Philipp Stefan]

On 24.03.2014 16:16, Heiko Tietze wrote:
>
> 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]
>
>     [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.
>
>     [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?
>
>     [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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-guidelines/attachments/20140324/b3cf66fc/attachment.html>