Re: [Usability] Find bar variants

[Daniel Borgmann <spark-mailinglists web de>]

I'm currently using a rather non-standard version of the findbar (no
next and previous buttons) in my text editor (Scratchpad) and the entire
application is a bit non-standard, but I'd still like to comment on
this. :)

On Wed, 2005-02-16 at 12:44 -0500, Bryan Clark wrote:
>>- Should they have a Close button ?
>
>I think we're going to try not having one soon.  So I'd say no assuming
>we get some feedback that is pretty positive about this.

I am also using no close button, the bar disappears after unfocusing or
pressing escape. In case you want to keep the bar around, I have a View
-> Searchbar item.

>>- Next, Prev of Prev, Next button order?
>
>We played with ours for a while and found the [< Previous] [> Next]
>seemed most rational.  I'd recommend going with that, someone tried to
>point out a Fitt's law argument here where the Next is the most used and
>should be closer to the text entry.  I don't think the Fitt's law
>argument is valid.  The order choice was because having the buttons
>point at each other looked weird. :-)

If I'd use those buttons, I'd definitely use the [< Previous] [> Next]
order, but that seems to be rough consensus already. :)

>>- Is case sensitivity common enough to warrant a checkbox in the find
>>bar?
>
>Like I said, probably not, but we weren't tight on space.

I'm not sure on it either, but I assume it can be important for a text
editor (personally I've never used it). However, the solution to
automatically search case sensitive when capital letters are entered
sounds great to me. I'll look into this.

>My questions for others is: Are you supporting '/' as an alternative
>Ctrl-F keybinding to bring up the find bar?  I'm thinking about saying
>yes for Evince.  Just to keep those *nix weirdos happy ;-)

I love vi and would love to support this handy keybinding, but it really
doesn't make sense for a text editor or in any other case where an entry
widget is likely to be focused. For this reason I'd suggest not to
support it to avoid confusion.

-- 
Daniel Borgmann <spark mayl de>