The new find bar shifting down content

Ehsan Akhgari ehsan.akhgari at gmail.com
Wed Aug 21 15:57:43 UTC 2013


Sure, but my point was that your proposal, while interesting, is probably
going to be a lot trickier to get to work than just adopting Chrome's
solution, and it's not obviously better than what Chrome does, IMO.  Also,
I've heard bad things about UI elements which change their function based
on modal information, but I'm not a UX expert.  :-)

--
Ehsan
<http://ehsanakhgari.org/>


On Wed, Aug 21, 2013 at 11:50 AM, Rob Campbell <rcampbell at mozilla.com>wrote:

> Chrome doesn't have a dedicated search field. Imagine taking their little
> find widget and instead of intruding into content, you put it next to the
> omnibar. Then you'd have a search box that looked like our own with a
> couple of extra buttons for next and previous.
>
> On 2013-08-21, at 11:32 , Ehsan Akhgari <ehsan.akhgari at gmail.com> wrote:
>
> While this idea is neat and all, and we could make it work perhaps, is
> there any reason why we wouldn't want to solve this problem the way that
> Chrome has?
>
> --
> Ehsan
> <http://ehsanakhgari.org/>
>
>
> On Wed, Aug 21, 2013 at 11:29 AM, Rob Campbell <rcampbell at mozilla.com>wrote:
>
>>
>> On 2013-08-21, at 11:19 , Mike Connor <mconnor at mozilla.com> wrote:
>>
>> >
>> > On 2013-08-21, at 9:57 AM, Rob Campbell <rcampbell at mozilla.com> wrote:
>> >
>> >> Add me to the list of people not happy with this change. I'd like to
>> see it reverted until we come up with a better solution (I have one below).
>> >
>> > I'd say that (as I believe Gavin suggested on IRC yesterday) the right
>> thing to do is not let this change ride the trains, but continue to iterate
>> on it in Nightly (at least if we think it's the right thing to be working
>> on right now).
>>
>> yeah for sure.
>>
>> >> There are too many absolute positioned elements on the web. The
>> shifting is eye-grabbing and distracting. Many pages are going to have
>> something shifting around with this solution unless we make the toolbar not
>> affect the content's dimensions. This runs the risk of overlaying something
>> useful which is a separate difficult problem.
>> >>
>> >> Also, the animating Find bar draws my eye to it and forces me to look
>> at the awkward animation. I'm sure that's a fixable problem, but the
>> content shifting is going to be trickier unless we redesign the findbar
>> entirely.
>> >
>> > I'm not finding the animation awkward.  I'd assert that the user's eye
>> being drawn to the UI they're going to interact with is a Good Thing,
>> though I'll admit that I often don't look at the find bar when I'm using it.
>>
>> My issue with the animation is that it's appearing over existing toolbars
>> and chrome. It's coming in from "somewhere" but it's not really clear
>> where. It looks strange.
>>
>> I kind of agree that it's good that it's now more visible. As Madhava
>> said (and I can backup from personal experience) it's hard to see it when
>> it appears at the bottom of the page.
>>
>> >> Alternative:
>> >>
>> >> Could we repurpose our Web Search input field for Find in Page? People
>> already use it for "Searching". It's persistent and never moves, and our
>> existing hotkeys could update the current Search Engine to a new Find in
>> Page search engine that would drive the searches.
>> >
>> > Main concern here is that the mode switch would probably suck for
>> mouse-driven users.  If we're relying on keyboard shortcuts, this would be
>> fine.  For mouse-driven users, we'd break "click in search field and type
>> to search" as a use case if they'd previously been in find mode (and
>> clicking could be ".  In general it's difficult to make one UI element
>> serve two masters.
>>
>> We might need to rethink that UI element a bit to make it fit. I don't
>> know what would happen to the Previous / Next buttons we have on the find
>> bar currently. For quicksearch, it seems pretty straightforward.
>>
>> As for breaking mouse users, they still get to click in an element and
>> start typing, same as before. (especially in the case mentioned below).
>>
>> > (From the "everything old is new again" files: this was actually a
>> feature in… 0.6 or so?  It was pretty awkward and no one would admit to
>> using it, so we removed it before 1.0.)
>>
>> Maybe it was a poor implementation. I'd have to how 0.6 worked.
>>
>> I'll use this as proof that it's a brilliant idea and we should explore
>> it. ;)
>>
>> >> Entering a term in the Web Search field could also provide
>> auto-suggestions from within the page.
>> >> 3
>> >> Your currently-selected search engine would return when you're done
>> searching (after an ESC).
>> >>
>> >> For a not super great of this, see Safari Mobile on iPad. When you
>> focus their search field, a separate Find on Page toolbar appears at the
>> bottom of the screen.
>> >
>> > Sadly, most variants I've seen of this concept end up in "not super
>> great" end states.  It's possible there's a path that works, but I'm not
>> smart enough to figure one out.
>>
>> I haven't spent any time thinking about it beyond what I posted here.
>> I'll leave that for the UX experts. :)
>>
>> ~ rob
>> _______________________________________________
>> firefox-dev mailing list
>> firefox-dev at mozilla.org
>> https://mail.mozilla.org/listinfo/firefox-dev
>>
>
> _______________________________________________
> firefox-dev mailing list
> firefox-dev at mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20130821/061b15b5/attachment.html>


More information about the firefox-dev mailing list