The new find bar shifting down content

[Robert Strong]

Every change has the potential to push away users and when a feature is 
implemented over more than one release it provides additional chances to 
push users away from using Firefox when a user gets used to one change 
and another change to the same feature happens in the release or two. I 
know it can be difficult to implement features in this manner but I 
think it is important to call this out especially given the additional 
changes outlined below. Does anyone disagree that there is value in 
releasing changes to a feature that are very noticeable to Firefox users 
in the same release from a user retention perspective?

Robert

On 8/20/2013 2:25 PM, Madhava Enros wrote:
> Hi all -
>
> I think there are a few different discussions happening in this thread 
> -- I wanted to pipe up with a bit of the context that may be lacking 
> about rationale, etc.
>
> *1. Why at the top?*
> If we were from starting from scratch and designing a findbar, we'd 
> put it at the top because
> (a) that connects it to where we put all the rest of the Firefox 
> chrome -- we'd expect that that's where most users would expect to 
> look for it
> (b) it conforms to a general design pattern that UI should 
> structurally "precede" the stuff that it affects or controls -- i.e., 
> changes, affected areas, etc. are "downstream" of the control -- 
> whether this is top-to-bottom or left-to-right (assuming LTR locale).
>
> We have the sense, anecdotally, that a lot of people don't notice the 
> currently shipping find bar down at the bottom. I know this will seem 
> unlikely to many of us to have already habituated to it's currently 
> shipping location. I'm not sure what, if any, data we have on this, 
> but you'll note that on new profiles we flash the bar yellow the first 
> time just to get people's attention. We should try to not find 
> ourselves in a situation that requires this in the first place.
>
> *2. Why shift everything down?*
> Indeed, why? My preference, and I think this is the intent behind the 
> current implementation in nightlies, is that we should _overlay_ the 
> bar when you hit Accel-F (animating it in, so that it's itself 
> noticeable). If the first match should be underneath the findbar, we 
> should scroll content down to reveal it. And, of course, a user can 
> scroll content down manually as well.
>
> *3. Why the full width of the screen?*
> I think it's this way right now because this was a "minimal improving 
> change" from the currently shipping findbar experience. Certainly, in 
> the mists of time when this design work was started, I think we were 
> told that a more minimal Chrome-style find box was Very Difficult to 
> implement for us. I think we can/should pursue this, but I'm not sure 
> it needs to be in the first rev.
> *
> *
> *4. Is this the platonic ideal of findbar experience*
> No - almost certainly not. In fact, we have further designs wrt 
> highlighting not just the matching string but the surrounding context. 
> That's for a future iteration, I think.
>
> I hope this helps!
>
> Madhava
>
> -- 
> Madhava Enros
> Firefox User Experience
> mozilla.org/firefox
>
> On Tuesday, August 20, 2013 at 5:02 PM, Markus Stange wrote:
>
>>
>> On Tue, Aug 20, 2013 at 10:35 PM, Ehsan Akhgari 
>> <ehsan.akhgari at gmail.com <mailto:ehsan.akhgari at gmail.com>> wrote:
>>
>>
>>     However, I would feel a lot better if somebody came up with
>>     reasons why shifting the content up/down is actually desired.
>>
>>
>> I don't think it's desired, ever.
>>
>>       The only reasoning in favor of the current behavior that I've
>>     seen is <https://bugzilla.mozilla.org/show_bug.cgi?id=893446#c14>
>>     (the first paragraph),
>>
>>
>> This makes no sense to me. Attention is drawn towards things that 
>> move and drawn away from the things that stay fixed. If everything is 
>> moving, attention is drawn everywhere it once, which can't work.
>>
>>     but based on the later discussion in the bug, it seems to me that
>>     this behavior is generally not desired, which caused us to come
>>     up with a solution which works some of the time but not all of
>>     the time, and will break on some popular websites such as Gmail. 
>>     And it's not clear at all why this half-working solution was
>>     implemented instead of other proposals which will give at least a
>>     consistent, if not superior, experience all the time.
>>
>>
>> Which other proposals are you referring to? The only other consistent 
>> proposal I know of was adapting Chrome's solution. I implemented the 
>> half-working solution because I overestimated the percentage of pages 
>> which it work on, because Mike gave positive feedback on it, and 
>> because I did not have the time and energy for a Chrome-like full 
>> reimplementation.
>>
>> -Markus
>> _______________________________________________
>> firefox-dev mailing list
>> firefox-dev at mozilla.org <mailto: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/20130820/228ca244/attachment.html>