1113297 - Back out match case mode for find-in-page

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Richard Newman [:rnewman]]

+++ This bug was initially created as a clone of Bug #1113296 +++

Comment 1

[:Margaret Leibovic]

This feature has been on Nightly for a year!
http://hg.mozilla.org/mozilla-central/annotate/1d6155d7e6c9/mobile/android/base/FindInPageBar.java#l34

We should find a way to fix this, or back it out. I think we should back it out.

Comment 2

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Is this the "Aa" icon I see in Find in Page?

Right now, from a user's point of view, I'm not sure why this level of specificity would be required. It's also adding confusion because this icon is more or less the same as the one in Reader View.

That being said, I don't think we should have this as an option in the Find-in-page bar.

Comment 3

[Barbara Bermes [:barbara] - NI please!]

Sorry guys, need a bit more context here.

- Why was this even added in the first place?

- Do we have some numbers in UI telemetry that confirm the toggle of this feature? Do people care?

I'm fine with "simplicity" and dropping it, unless we had x number of people asking for it or any other good reason.

Comment 4

[Richard Newman [:rnewman]]

It was added in Bug 1050480 because it stops Find In Page being useless in some situations -- particularly looking for acronyms or names that are also normal words ("SEA" when looking for an airport code, "Tom" who shows up in stomach, tomorrow, …).

We have it on desktop and Android (Nightly). Chrome and Safari do not.

(I have seen situations on desktop where it's the difference between 800+ matches and 3. Big value there. Probably bigger on a small screen…)


We held it back in Nightly in Bug 1113296 because the iconography and highlight state wasn't what we wanted.


Personally I like the feature, I use it, and so I see it as a differentiator rather than something we should remove.

Comment 5

[Kevin Brosnan [Ex-Mozilla]]

I am still not a fan of the red color for the disabled state (bug 1112232). I am seeing that toggling the match state removes focus from the keyboard. That is a blocker in my opinion. Filing that bug right now.

Comment 6

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

I agree, it is a differentiation but it also comes at a cost. I'm just not that happy with the current UX and I'm afraid it could just cause confusion/frustration with our users if they can't figure out why it's behaving differently.

I think even iOS isn't shipping with this right away and I'd like to keep the experience consistent to start. 

We can definitely revisit this later if we have stronger reason to believe this feature is required I think. At which point, we should look at unifying the experiences on both platforms to accommodate this too.

Comment 7

[Barbara Bermes [:barbara] - NI please!]

(In reply to Anthony Lam (:antlam) from comment #6)
> I agree, it is a differentiation but it also comes at a cost. I'm just not
> that happy with the current UX and I'm afraid it could just cause
> confusion/frustration with our users if they can't figure out why it's
> behaving differently.

Would a word "Match case" work better instead of an Aa icon?

> We can definitely revisit this later if we have stronger reason to believe this feature is required I 
> think. At which point, we should look at unifying the experiences on both platforms to accommodate this too.

How would you define if this feature is required in comparison to other features we've shipped. What's holding this back from e.g. other small improvements we've made in the past. I'm worried that we spent time on things like that and then decide not to ship it. There must have been a reason why we decided to put resources on this to work on. If there was something horrible wrong with that feature, I agree it should stay behind a nightly flag and should be fixed, but I wonder what we are waiting for? I know Mark has requested some UI telemetry for Find in page, we could wait for that data to show up in Beta to revisit. 

Anthony, do you feel if we see a lot of people using "Find in page", it would be worth to ship it? Would this be a good indicator in your mind for it to be included?

I feel specific configurations (such as match case) for search are kind of assumed and understood by the user theses days, at least the ones who use "find in page". 

So I'm in favour of shipping it sooner than later.

Comment 8

[:Margaret Leibovic]

(In reply to Barbara Bermes [:barbara] from comment #7)
> (In reply to Anthony Lam (:antlam) from comment #6)
> > I agree, it is a differentiation but it also comes at a cost. I'm just not
> > that happy with the current UX and I'm afraid it could just cause
> > confusion/frustration with our users if they can't figure out why it's
> > behaving differently.
> 
> Would a word "Match case" work better instead of an Aa icon?

Unfortunately, there's not room for that in the UI

> > We can definitely revisit this later if we have stronger reason to believe this feature is required I 
> > think. At which point, we should look at unifying the experiences on both platforms to accommodate this too.
> 
> How would you define if this feature is required in comparison to other
> features we've shipped. What's holding this back from e.g. other small
> improvements we've made in the past. I'm worried that we spent time on
> things like that and then decide not to ship it. There must have been a
> reason why we decided to put resources on this to work on. If there was
> something horrible wrong with that feature, I agree it should stay behind a
> nightly flag and should be fixed, but I wonder what we are waiting for? I
> know Mark has requested some UI telemetry for Find in page, we could wait
> for that data to show up in Beta to revisit. 

What's holding this back is that we're not happy with the UX. We do have telemetry about the find in page button, and we found they're not used often:
https://www.dropbox.com/s/y0dcwqpo5squ0f7/Screenshot%202015-12-23%2011.18.48.PNG?dl=0

Although there may be something wrong with those probes, since the find in page menu item is one of the more frequently used probes.

> Anthony, do you feel if we see a lot of people using "Find in page", it
> would be worth to ship it? Would this be a good indicator in your mind for
> it to be included?
> 
> I feel specific configurations (such as match case) for search are kind of
> assumed and understood by the user theses days, at least the ones who use
> "find in page". 
> 
> So I'm in favour of shipping it sooner than later.

I'm also in favor of shipping this, but we need a better icon. I think the main problem is that the red color does not indicate enabled/disabled (bug 1112232). Maybe we need some sort of pressed button state?

Alternately, we could look at fixing bug 1050479, but that would be a lot more work.

Comment 9

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to :Margaret Leibovic from comment #8)
> (In reply to Barbara Bermes [:barbara] from comment #7)
> > (In reply to Anthony Lam (:antlam) from comment #6)
> > > I agree, it is a differentiation but it also comes at a cost. I'm just not
> > > that happy with the current UX and I'm afraid it could just cause
> > > confusion/frustration with our users if they can't figure out why it's
> > > behaving differently.
> > 
> > Would a word "Match case" work better instead of an Aa icon?
> 
> Unfortunately, there's not room for that in the UI
> 
> > > We can definitely revisit this later if we have stronger reason to believe this feature is required I 
> > > think. At which point, we should look at unifying the experiences on both platforms to accommodate this too.
> > 
> > How would you define if this feature is required in comparison to other
> > features we've shipped. What's holding this back from e.g. other small
> > improvements we've made in the past. I'm worried that we spent time on
> > things like that and then decide not to ship it. There must have been a
> > reason why we decided to put resources on this to work on. If there was
> > something horrible wrong with that feature, I agree it should stay behind a
> > nightly flag and should be fixed, but I wonder what we are waiting for? I
> > know Mark has requested some UI telemetry for Find in page, we could wait
> > for that data to show up in Beta to revisit. 
> 
> What's holding this back is that we're not happy with the UX. We do have
> telemetry about the find in page button, and we found they're not used often:
> https://www.dropbox.com/s/y0dcwqpo5squ0f7/Screenshot%202015-12-23%2011.18.48.
> PNG?dl=0
> 
> Although there may be something wrong with those probes, since the find in
> page menu item is one of the more frequently used probes.

That screenshot is old. Current telemetry shows:

Method	Extras   	aurora	beta	nightly	release
menu	find_in_page	1742	70128	2627	130506
button	find_close	76		923	
button	find_in_page	108		918	
button	find_matchcase			40	
button	find_next	412		6352	
button	find_prev	120		3251

Comment 10

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

(In reply to Barbara Bermes [:barbara] from comment #7)
> (In reply to Anthony Lam (:antlam) from comment #6)
> > I agree, it is a differentiation but it also comes at a cost. I'm just not
> > that happy with the current UX and I'm afraid it could just cause
> > confusion/frustration with our users if they can't figure out why it's
> > behaving differently.
> 
> Would a word "Match case" work better instead of an Aa icon?

As Margaret mentioned, there's no room in the UI for this. But I also want to take a step back and look at other UX possibilities instead. I think we're focusing a bit too much on "fixing this UI".

If match case mode is so important, why did we not just always have it switched on? That way, this feature will literally highlight any text that matches what's _exactly_ in the input field. 

Conversely, do we think it's really a feature that makes our Find-in-page that much less valuable without it? Is it Great?

I've found that when using chrome's Find-in-page (that doesn't have match case), I am not really discovering a need for it - I can still find the same words without it. 

The benefit to not having this added feature is essentially clarity in our UX. It makes our product feel simple and easy to use. As a user, I just get how this feature works because there's not a lot of knobs and dials. I worry that we're adding complexity for a few people but confusing the experience for the majority that won't actually need this feature.

Comment 11

[:Margaret Leibovic]

After much discussion, we decided that we should just back out what we currently have, and open a separate bug for a more holistic approach to the find-in-page UX.

Comment 12

[:Margaret Leibovic]

Attachment: MozReview Request: Bug 1113297 - Back out match case mode for find-in-page. r=liuche

Review commit: https://reviewboard.mozilla.org/r/33479/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/33479/

Comment 13

[Chenxia Liu [:liuche]]

Comment on attachment 8715481 [details]
MozReview Request: Bug 1113297 - Back out match case mode for find-in-page. r=liuche

https://reviewboard.mozilla.org/r/33479/#review30503

Comment 14

[:Margaret Leibovic]

https://hg.mozilla.org/integration/fx-team/rev/6fb55bcaf65d4d6d335eff3886e2efbf35b47e3f
Bug 1113297 - Back out match case mode for find-in-page. r=liuche

Comment 15

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/6fb55bcaf65d