<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 24.03.2014 16:16, Heiko Tietze wrote:<br>
<blockquote
cite="mid:85dd9022b4b0d6882860523496477f3e9c5a524d@user-prompt.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<title></title>
<style type="text/css">.felamimail-body-blockquote {margin: 5px 10px 0 3px;padding-left: 10px;border-left: 2px solid #000088;} </style>
<p>Great work! I like it all ;-)<br>
</p>
<p>But why do you change the search icon (magnifier) into a
yin-yang whatever arrow? Overloading a control is bad usability
in most cases.<br>
</p>
</blockquote>
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 ._.<br>
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?<br>
Anyway, here's the picture of the "idle" and "busy" state of the
search field [1]<br>
<blockquote
cite="mid:85dd9022b4b0d6882860523496477f3e9c5a524d@user-prompt.com"
type="cite">
<blockquote class="felamimail-body-blockquote">[2/A] Here I tried
to integrate the search field with the search button. <br>
</blockquote>
<p>Users might understand the search function to be related to the
topics. <br>
</p>
</blockquote>
Right, I didn't consider this.<br>
<blockquote
cite="mid:85dd9022b4b0d6882860523496477f3e9c5a524d@user-prompt.com"
type="cite">
<blockquote class="felamimail-body-blockquote">[3/B] Placement on
the upper right.<br>
[4/C] Top centred search field. <br>
</blockquote>
<p>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).<br>
</p>
</blockquote>
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.<br>
<br>
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.<br>
Dolphin also hides the address line when the search functionality is
called.<br>
<br>
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?<br>
<blockquote
cite="mid:85dd9022b4b0d6882860523496477f3e9c5a524d@user-prompt.com"
type="cite">
<blockquote class="felamimail-body-blockquote">[5/D] Search field
on the bottom.<br>
</blockquote>
<p>I think it's a no-go to open a small input on demand somewhere
at the bottom. <br>
</p>
</blockquote>
If Thomas agrees we can at least agree that the input should be
always on top (of the content) :) <br>
<br>
Cheers, <br>
<br>
Phil<br>
<br>
[1] <a class="moz-txt-link-freetext" href="http://i.imgur.com/NC8r0ii.png">http://i.imgur.com/NC8r0ii.png</a><br>
</body>
</html>