493500 - Consider decreasing the full content zoom increment (by half, at least)

Status: RESOLVED FIXED

(Camino Graveyard :: Page Layout, enhancement)

Description

[Lisa Thompson]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en; rv:1.9.0.11pre) Gecko/2009051600 Camino/2.0b3pre (like Firefox/3.0.11pre)
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en; rv:1.9.0.11pre) Gecko/2009051600 Camino/2.0b3pre (like Firefox/3.0.11pre)

It seems to me that the increment for full content zoom is set so high that it makes the feature less useful than it could be. 

The default zoom factors for Firefox (.3, .5, .67, .8, .9, 1, 1.1, 1.2, 1.33, 1.5, 1.7, 2, 2.4, 3) are about twice as fine-grained as Camino's are, if I understand correctly that Camino zooms in increments of 0.25.

The smaller increments make for a much nicer browsing experience in my opinion. I use the feature to make some websites more readable and usually one click is more than enough, sometimes too much; rather than "zooming", I'm basically picking between small, medium & large, and three sizes don't fit all. :-)

It goes without saying that my use (and my screen-size, 24") might not be typical, but I would also note that for users who want to zoom at .25, two mouse-clicks or keypresses instead of one, at the same location, doesn't seem like it would impose that much of a burden.

Thanks for your consideration.

for reference: Bug 389795

Reproducible: Always

Comment 1

[Stuart Morgan]

I hadn't really given it much thought, but now that you mention it the first bump up does seem kind of jarring. I'd be in favor of scaling that back somewhat.

Comment 2

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Perhaps that's part of what makes me find full content zoom so useless, too?

Comment 3

[8-bit]

Yes, scaling it back would definitely make it more useful - needs to be a "smoother transition" and not quite as big of a bump. I'm all for it.

Question: Currently the value is set at .25. Does that mean it is upscaling at 25% per level, or is that representative of something else. Any clarification would be greatly appreciated.

Comment 4

[Chris Lawson (gone)]

Something else to think about: do we want to respect a pref for this? Obviously leaving it hidden would be fine, since once we have a sensible default, this isn't something I'd expect a lot of people to be twiddling, but maybe we want to respect the toolkit.zoomManager.zoomValues pref?

http://kb.mozillazine.org/Toolkit.zoomManager.zoomValues

See also bug 401221, where the idea of just specifying a single interval (instead of a series of percentages) was briefly mentioned. I think that approach is much simpler and if we do want to do a pref, I think it might be a win to take such an approach at the expense of not having straight-up prefs compatibility. We've invented new prefs of our own in the past in similar situations.

Comment 5

[Stuart Morgan]

I'm not sure I really see the value in wiring up a pref here.

Comment 6

[Lisa Thompson]

Philippe made a build with the zoom increment changed to 0.20. I was looking at it and did some screenshots -- I thought they might be of interest if someone decides to work on this. (I think 0.20 is still too high.) I was wondering if you'd still get the same min and max zooms, albeit with more clicks, and apparently you do.

http://homepage.mac.com/lthompson.22/camino-zoom.html

I also noticed some weirdness at extreme zoom-in that got compounded in the 0.20 build -- relevant to a possible patch? or just because it's not an official build? -- but I thought I'd mention it:

With the official build (0.25) - you can zoom a page out 3 times and zoom in 15 times; you can actually choose the zoom-in menu item or click on the toolbar button a 16th time (before the toolbar button and menu item are dimmed), but it produces no change on the web page.

With the 0.20 build - you can zoom a page out 4 times and activate zoom-in 21 times, although the 16th, 18th, 20th and 21st clicks, or key-combo presses, produce no change on the page.

Comment 7

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Based on our current plans, fixing this is part of 2.0; pinch apparently suffers because of it, too.

Comment 8

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

We want this for b4 so that we can get additional feedback if needed.

Comment 9

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Per discussion last night and at the meeting, Stuart's going to check in a change to 0.15 tonight, and if Sean comes up with a tested increment before the rest of the b4 bugs are done, we'll land that for b4.

Otherwise, we know the current value is not what we want, so we'll ship b4 with a different value.

Comment 10

[Stuart Morgan]

Landed a change from 0.25 to 0.125 (I realized that 0.15 would make 0.5 and 2.0 impossible, which seemed like a bad idea) on trunk and CAMINO_2_0_BRANCH.

It's not great once you get up past 1.5 or so, since it feels slow, but it's better for the range that people are most likely to actually use. Leaving open for a smarter (accelerating) set of steps though.

(Taking off b4 blocker list, but we'll take a better approach for b4 if it's ready.)

Comment 11

[Stuart Morgan]

We decided to call this fixed; if we decide to investigate non-linear increments that can be a new bug.