1192075 - Change copy in Settings for Zoomed View/ magnifying glass preference

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

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

In bug 1189971 we added a pref for the Zoomed View feature. 

But the language as well as interaction there is inconsistent with the rest of our settings. 

Let's clean this up

Comment 1

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

Karen, do we have any word on how we want to talk about this feature? 

Currently:
Disable magnifying glass
Prevent magnifying glass for use in resolving ambiguous screen touches

(checkbox)


We've referred to it internally as "zoomed view", "magnifying glass", and "area of clustered links thing". I just want to make sure that we're on the same page here. Especially if there's some sort of messaging we want to put out around this feature.

Said feature name would also likely be the title of this settings preference that's currently under "Display". That would keep it more consistent with the rest of our settings.

Comment 2

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Note that this should land before merge, we should backout the setting, or we have to notify l10n about a string uplift.

Do we anticipate this setting landing with the feature? I figured it might be a temporary solution to it not working as expected. I'd also prefer to keep configurability (and thus code paths to test) to a minimum, when possible. NI antlam on whether this setting is necessary, or if that's something we should decide later when the algorithm is more intuitive.

(In reply to Anthony Lam (:antlam) from comment #1)
> We've referred to it internally as "zoomed view", "magnifying glass", and
> "area of clustered links thing".

I agree that we should decide on a name here – it causes confusion in Bugzilla too. I think the people working on it are accepting "zoomed view" but "magnifying glass" seems to pop up as the intuitive name for people not working on it (e.g. filing bugs).

Comment 3

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

(In reply to Michael Comella (:mcomella) from comment #2)
> Note that this should land before merge, we should backout the setting, or
> we have to notify l10n about a string uplift.
> 
> Do we anticipate this setting landing with the feature? I figured it might
> be a temporary solution to it not working as expected. I'd also prefer to
> keep configurability (and thus code paths to test) to a minimum, when
> possible. NI antlam on whether this setting is necessary, or if that's
> something we should decide later when the algorithm is more intuitive.

Ideally, if this works properly, we don't need the setting. But seeing as how there's still no end in sight right now in bugs like bug 1186738, bug 1135369, and bug 1191277... I think it needs to launch with a Setting.

> (In reply to Anthony Lam (:antlam) from comment #1)
> > We've referred to it internally as "zoomed view", "magnifying glass", and
> > "area of clustered links thing".
> 
> I agree that we should decide on a name here – it causes confusion in
> Bugzilla too. I think the people working on it are accepting "zoomed view"
> but "magnifying glass" seems to pop up as the intuitive name for people not
> working on it (e.g. filing bugs).

Holding off for Karen here.

Comment 4

[Dominique Vincent [:domivinc]]

(In reply to Anthony Lam (:antlam) from comment #3)
> 
> Ideally, if this works properly, we don't need the setting. But seeing as
> how there's still no end in sight right now in bugs like bug 1186738, bug
> 1135369, and bug 1191277... I think it needs to launch with a Setting.
> 

I totally agree with you Anthony, the minimum is a Setting. And I would also suggest to land the functionality deactivated by default. Each user will be able to opt-in with the Setting menu to see if it’s something that they need. We will keep the capability to set the zoomed view activated by default in a future release when we are more confident about the woomed view (design and potential bugs).


From a more general point of view, I think there are 3 importants things that are missing here:

1- To definitively make design choices regarding when and how the zoomed view must appear or not (the default sensibility using pref ui.touch.radius or an option in a menu / tool bar - bug 1180821).

2- To make functional tests; bugs 1191277 and bug 1190332 are not “new” bugs, they are visible since the first day in nightly (several months ago). I’m not familiar with Mozilla organisation, who is in charge of the functional testings to get a green light before landing in production?

3- To add test cases specific to the zoomed view (a few tests already exist because the cluster detection code is shared with another functionality: the closest link highlight functionality. But we should probably develop specific tests for the zoomed view. The functional tests done in point 2 should be a good starting point to implement the test cases.

If you really want to skip the 3 previous points and take minimal risk, I really think that the opt-in option with the functionality deactivated by default is the good path.

Comment 5

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

(In reply to Dominique Vincent [:domivinc] from comment #4)
> I’m not familiar with Mozilla organisation, who is in charge of the
> functional testings to get a green light before landing in production?

Honestly, for our team it's fairly organic and hard to pinpoint - whoever feels strongly about a particular feature can champion it and make a lot of executive decisions, but if others have interests in it, it can become a group decision (and because we are a small team, consensus can generally be reached). Engineering generally drives features forward and calls out to UX or Product for advice, particularly on features that originated in UX or Product.

On this particular feature, I've been guiding your development work (great work so far! :) and reaching out to Anthony (:antlam) for UX decisions, while Anthony occasionally reaches out to Product (Karen, or :kar) for more big-picture UX decisions.

> But we should probably develop
> specific tests for the zoomed view.

Sounds like a good plan - we don't have a strong testing culture (though, we really should :( ) so I wouldn't mind the feature landing in a version or two before the tests.

Comment 6

[Karen Rudnitski [:kar]]

> > I agree that we should decide on a name here – it causes confusion in
> > Bugzilla too. I think the people working on it are accepting "zoomed view"
> > but "magnifying glass" seems to pop up as the intuitive name for people not
> > working on it (e.g. filing bugs).
> 
> Holding off for Karen here.

I think people are calling it a magnifying glass because that's often the paradigm they've been presented. I kind of think that it should *look* like a magnifying glass if it's called that, and ours doesn't (which is fine!).

My concern is 'zoomed view' is how is that actually referred to as a feature in marketing or PR copy. Things like 'To enable Zoomed View...' doesn't quite feel right either. I'm going to loop in Matej for his thoughts since he typically has some decent intuition here. Even if it's just tweaked it a bit and calling it 'Zoom View' or maybe 'Magnifying Window' or.... I don't think 'lens' is right but trying to think how this feature name stands up to the other features in 'settings' and how it would be described.

Comment 7

[Matej Novak [:matej]]

(In reply to Karen Rudnitski [:kar] from comment #6)
> > > I agree that we should decide on a name here – it causes confusion in
> > > Bugzilla too. I think the people working on it are accepting "zoomed view"
> > > but "magnifying glass" seems to pop up as the intuitive name for people not
> > > working on it (e.g. filing bugs).
> > 
> > Holding off for Karen here.
> 
> I think people are calling it a magnifying glass because that's often the
> paradigm they've been presented. I kind of think that it should *look* like
> a magnifying glass if it's called that, and ours doesn't (which is fine!).
> 
> My concern is 'zoomed view' is how is that actually referred to as a feature
> in marketing or PR copy. Things like 'To enable Zoomed View...' doesn't
> quite feel right either. I'm going to loop in Matej for his thoughts since
> he typically has some decent intuition here. Even if it's just tweaked it a
> bit and calling it 'Zoom View' or maybe 'Magnifying Window' or.... I don't
> think 'lens' is right but trying to think how this feature name stands up to
> the other features in 'settings' and how it would be described.

Is there somewhere I could see how this looks in product and learn more about what it does?

It's hard to say without that, but I'm wondering if "view" is like "mode." Maybe if we land on the right description, it doesn't have to say "view" (or similar).

Words like "enlarged" or "detailed" are coming to mind, but again, hard to say without more details.

Comment 8

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

(In reply to Matej Novak [:matej] from comment #7)
> Is there somewhere I could see how this looks in product and learn more
> about what it does?

If you download the latest Nightly, go to a page with small text (e.g. I use reddit.com), and click in-between two, small text, close-together links (e.g. I use the various headers on reddit), the zoomed view will appear. Note that it's hard to get it to appear when expected – we're working on this in bug 1135369.

Comment 9

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

(In reply to Matej Novak [:matej] from comment #7)
> Is there somewhere I could see how this looks in product and learn more
> about what it does?
> 
> It's hard to say without that, but I'm wondering if "view" is like "mode."
> Maybe if we land on the right description, it doesn't have to say "view" (or
> similar).
> 
> Words like "enlarged" or "detailed" are coming to mind, but again, hard to
> say without more details.

This is generally the idea: https://dribbble.com/shots/2082036-Zoom-in

Comment 10

[Matej Novak [:matej]]

Thanks so much.

As a pref, I think something like "Magnify links" or "Magnify small links" could work.

If we want to use "zoom," I would recommend "Zoom in" or "Zoom in on links" ("zoom" on its own feels ambiguous here).

I was also thinking about describing the benefit rather than how it works. I was playing with things like "Easy links" or "Perfect click," but I could come up with anything that sounds right.

Does that help?

Comment 11

[Dominique Vincent [:domivinc]]

The zoomed view is designed to work for links but also for any small elements (form elements, a picture, ...).

To get a correct idea of all the cases you have the original design available here:
https://bug663803.bmoattachments.org/attachment.cgi?id=8394971

Could we define a description that is not only "links" oriented?

Comment 12

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

Thanks Matej!

I think thats a great place to start. "Magnify links" in particular appeals to me. But Domivinc brings up a point about form fields. Do you think this could be an issue? Though, I can see how those might not actually be that separate in the user's eyes.

Domivinc, please note that with a feature like this, we're constantly iterating, adjusting, and improving. While that spec is pretty comprehensive and it's where we started, we've made adjustments. We've had multiple discussions since then and things like "pictures" for example are no longer one of the primary use cases here.

Comment 13

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

Matej,

I also remember that we'll need a description too. Do you have any thoughts on this? Ideally, we would start keeping these title to description relationships for our settings items fairly consistent and since we've done some work on these Settings strings recently I figured you might want a crack at that too :)

Thanks!

Comment 14

[Dominique Vincent [:domivinc]]

(In reply to Anthony Lam (:antlam) from comment #12)
> I think thats a great place to start. "Magnify links" in particular appeals
> to me. But Domivinc brings up a point about form fields. Do you think this
> could be an issue? Though, I can see how those might not actually be that
> separate in the user's eyes.

Another term used by Gemma in the user research study to evaluate the zoomed view was: “Magnify tool” or something like that. Gemma, do you know if the participants to your study had a specific term in mind for this feature?

> 
> Domivinc, please note that with a feature like this, we're constantly
> iterating, adjusting, and improving. While that spec is pretty comprehensive
> and it's where we started, we've made adjustments. We've had multiple
> discussions since then and things like "pictures" for example are no longer
> one of the primary use cases here.

Yes Antony, we already discussed about your desire to limit (or improve ?) the “magnify tool” to links only. It will be hard to implement: you can have a picture in a link! You can have text elements with touch event that are not links ...

Comment 15

[Matej Novak [:matej]]

In general, I'd prefer to avoid terms like "mode" and "view" and "tool" whenever possible. That's what these things are, so if we describe or name them correctly, those labels shouldn't be necessary.

The fact that we need a description actually simplifies things since we don't have to communicate everything in the name.

Another idea I had was to call this a "loupe" and the pref could be "Use loupe."

I also thought of calling it a "pane" — something like "Smart pane" or "Enhanced pane" — but that somewhat goes against what I said at the beginning of this comment and isn't my favorite solution.

Either way, it could go with a description like one of the following:

Enlarge small links and form fields to make selecting them easier

Magnify small areas to make clicking on links and forms easier

Comment 16

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

Thanks Matej!

I think this is looking good. But we don't typically have a value proposition in the description. Do you think that's necessary considering our other copy in Settings? We also sometimes mention "when" like "scrolling  down a page" or " after quitting Nightly". I think that might be valuable here.

For example, how does this read? from my simple copy writing mind :)

Magnify links
Enlarge area when tapping near small links and form fields

Comment 17

[Matej Novak [:matej]]

(In reply to Anthony Lam (:antlam) from comment #16)
> Thanks Matej!
> 
> I think this is looking good. But we don't typically have a value
> proposition in the description. Do you think that's necessary considering
> our other copy in Settings? We also sometimes mention "when" like "scrolling
> down a page" or " after quitting Nightly". I think that might be valuable
> here.
> 
> For example, how does this read? from my simple copy writing mind :)
> 
> Magnify links
> Enlarge area when tapping near small links and form fields

I would say "areas" instead of "area," but otherwise this looks good.

I'd also like to keeping thinking about the name. I'm not sure having "links" in there is the best idea. Does the "loupe" idea not work for you?

Comment 18

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

(In reply to Matej Novak [:matej] from comment #17)
> (In reply to Anthony Lam (:antlam) from comment #16)
> > Magnify links
> > Enlarge area when tapping near small links and form fields
> 
> I would say "areas" instead of "area," but otherwise this looks good.

Gotcha!

> I'd also like to keeping thinking about the name. I'm not sure having
> "links" in there is the best idea. Does the "loupe" idea not work for you?

I agree, if we can decouple "links" to be a more general term that might be nice.

"Loupe" works for me, I'm happy to follow your lead here I just don't know what it means... :D

Comment 19

[Matej Novak [:matej]]

(In reply to Anthony Lam (:antlam) from comment #18)
> (In reply to Matej Novak [:matej] from comment #17)
> 
> > I'd also like to keeping thinking about the name. I'm not sure having
> > "links" in there is the best idea. Does the "loupe" idea not work for you?
> 
> I agree, if we can decouple "links" to be a more general term that might be
> nice.
> 
> "Loupe" works for me, I'm happy to follow your lead here I just don't know
> what it means... :D

Maybe it's not as common a term as I think. A loupe is like a small magnifying glass, the kind a jeweler uses, but it's also the word that programs like Photoshop and Lightroom use for zooming in on or magnifying areas.

If not that, maybe we could use something like "Magnify details" or "Enlarge details"?

Comment 20

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

Monocle? :D

or perhaps we should focus on the action required to trigger rather than generally describing what it magnifies? if that makes sense.

I.e. "Magnify on-press".. but better, heh

Comment 21

[Gemma Petrie (she/her) [:gemma]]

(In reply to Dominique Vincent [:domivinc] from comment #14)
> (In reply to Anthony Lam (:antlam) from comment #12)
> > I think thats a great place to start. "Magnify links" in particular appeals
> > to me. But Domivinc brings up a point about form fields. Do you think this
> > could be an issue? Though, I can see how those might not actually be that
> > separate in the user's eyes.
> 
> Another term used by Gemma in the user research study to evaluate the zoomed
> view was: “Magnify tool” or something like that. Gemma, do you know if the
> participants to your study had a specific term in mind for this feature?
> 
> > 
> > Domivinc, please note that with a feature like this, we're constantly
> > iterating, adjusting, and improving. While that spec is pretty comprehensive
> > and it's where we started, we've made adjustments. We've had multiple
> > discussions since then and things like "pictures" for example are no longer
> > one of the primary use cases here.
> 
> Yes Antony, we already discussed about your desire to limit (or improve ?)
> the “magnify tool” to links only. It will be hard to implement: you can have
> a picture in a link! You can have text elements with touch event that are
> not links ...

Users referred to the action as "zooming" until I introduced the term "Magnifying Glass" at the end of the study. Once introduced, the term "magnifier" emerged. In general, users did not have a specific label associated with this action - but to be clear, learning if they did was not the goal of the test.

Comment 22

[Matej Novak [:matej]]

Circular embiggening area thing?

This is a tough nut to crack. Maybe we go back to "small areas" in the pref and edit the description:

Magnify small areas
Enlarge links and form fields when tapping near them

Comment 23

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

This works for me!

Comment 24

[Karen Rudnitski [:kar]]

I think we've finally got something we can work with! We can watch to see if there's any feedback or confusion on the feature and tweak later if required, but for now, I think we've got something to ship with :)

Comment 25

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

Domivinc, Mcomella, could you guys take a look at this?

Comment 26

[Dominique Vincent [:domivinc]]

Attachment: patch-18082015 1-Bug_1992075___Change_copy_in_Settings_for_Zoomed_View__magnifying_glass_preference__r_mcomella.patch

I updated the texts and replaced ui.zoomedview.disabled by ui.zoomedview.enabled.
I also changed the default value to false for ui.zoomedview.enabled (no zoomed view).

Comment 27

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Comment on attachment 8649160 [details] [diff] [review]
patch-18082015 1-Bug_1992075___Change_copy_in_Settings_for_Zoomed_View__magnifying_glass_preference__r_mcomella.patch

Review of attachment 8649160 [details] [diff] [review]:
-----------------------------------------------------------------

r+ if the comment is fix (or at least addressed).

::: mobile/android/app/mobile.js
@@ +413,5 @@
>  
>  // When true, zooming will be enabled on all sites, even ones that declare user-scalable=no.
>  pref("browser.ui.zoom.force-user-scalable", false);
>  
> +pref("ui.zoomedview.enabled", false);

Don't we want the zoomed view to stay enabled by default?

Comment 28

[Dominique Vincent [:domivinc]]

(In reply to Michael Comella (:mcomella) from comment #27)
> Comment on attachment 8649160 [details] [diff] [review]
> 
> Don't we want the zoomed view to stay enabled by default?

Anthony, do you want the zoomed view enabled or disabled by default?

Comment 29

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

Thank you for the NI Domivinc!

I think it's best preffed off ATM. 

We still need to work on getting some bugs worked out  (like bug 1135369) before I'm comfortable preffing it on by default

Comment 30

[Dominique Vincent [:domivinc]]

Attachment: patch-19082015 1-Bug_1992075___Change_copy_in_Settings_for_Zoomed_View__magnifying_glass_preference__r_mcomella.patch

Reading back the different comments, I just realized we are not always talking about exactly the same thing. For the current Nightly build, we should probably keep the zoomed view ON by default to get the maximum of feedbacks (Michael point of view). And for the first Aurora/Production builds, we will take the decision later (set the default to OFF to minimize the risk).

So I made the change for nightly here:
pref("ui.zoomedview.enabled", true);

The zoomed view is ON by default.

I also created Bug 1196146 in order to manage the different changes we will have to make in order to get the zoomed view on Aurora.

Comment 31

[Dominique Vincent [:domivinc]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=67a885ddf8d2

Comment 32

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/ada5ea1547a0

Comment 33

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/integration/fx-team/rev/ada5ea1547a0

Comment 34

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

The patch had the bug number incorrect.

Comment 35

[Dominique Vincent [:domivinc]]

Attachment: patch-20082015 1-Bug_1192075___Change_copy_in_Settings_for_Zoomed_View__magnifying_glass_preference__r_mcomella.patch

Same patch with the correct bug number.

Comment 36

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/ada5ea1547a0