The new find bar shifting down content

Ehsan Akhgari ehsan.akhgari at gmail.com
Wed Aug 21 15:49:32 UTC 2013


FWIW that would be the second place in our primary UI where we shift a
piece of our chrome based on content.  We already do this for the link
target mini-statusbar.

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


On Wed, Aug 21, 2013 at 11:45 AM, Mike Connor <mconnor at mozilla.com> wrote:

> The one thing I've seen cited that makes it not optimal is the horizontal
> shifting if the result is under the bit extending from the toolbar.  It's a
> literal edge case, but something worth keeping in mind.  I think the main
> other issue is whether we'd kill match case/highlight all, or just have
> minimal icons for those features.  I'll let UX chime in on whether they'd
> prefer this sort of solution.
>
> -- Mike
>
> On 2013-08-21, at 11:32 AM, 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
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20130821/b5afeaab/attachment.html>


More information about the firefox-dev mailing list