I'm actually pretty ok with using a slider for discrete zoom factors. Like buttons or droplists, I think they would work well enough if the only kind of zooming being used in a particular application design are discrete zoom factors. I'm just not entirely convinced that there is no credible use-case for precise zoom factors.

Thomas is right in that sometimes folks do get their calculators out to figure out the precise zoom factor setting at which to preview, for example, an image they're working on. Sometimes the calculation is not so complicated that it needs a calculator though. Sometimes I need that 800% or the 25% (or the 1200%, 400%, 150%, 10%, 20%, 2000%, and on). Trying to account for all the possible useful discrete zoom factors at design-time may be possible with many applications. With other applications though, I'm not quite so sure it is possible or practical. If Inkscape or GIMP or Photoshop switched to only discrete zoom factors + arbitrary non-precise zoom, they'd end up with a super-long slider or droplist to account for all of the potential discrete zoom factors users find useful in their workflow at run-time. And I'm almost certain they'd miss some.

To be clear, I'm not suggesting that we should always have precise zoom factor control. Rather that we provide guidance on when not to use a precise zoom factor control and when to use it. The same goes for when to use a discrete zooming control or arbitrary (non-precise) zooming control and when not to. Different applications across our application spectrum will have different needs and, best I can tell, all three of these zoom behaviors are used and are useful. So I think providing guidelines appropriate for each need is most helpful in getting the consistency we seek without unnecessarily constraining functionality. So rather than saying "Only use this control/pattern", perhaps we say "if you need this [behavior], use this control/pattern" paired with "we recommend [behavior] and [behavior] and avoiding [behavior] where possible".

One clarification, I think the slider control implementations in Qt4, Qt5 and QtQuick can be set to use either continuous (arbitrary) or discrete steps - not both at the same time. So what I poorly attempted to communicate was that the slider would not actually work for applications that need both arbitrary and discrete zoom control (like Gwenview and Krita). Well... unless they got rid of one behavior or the other.... or unless they used two sliders.

Oh, I just saw I might have caused some confusion: I'm not saying precise zoom is never useful. I'm just suggesting that perhaps setting a precise zoom-factor might never be useful.
If I want to view that 96x96px icon at 32x32px, wouldn't it be more useful if I could set it to "Zoom out until the longer side is 22px on the screen" instead of "33%"? If I have precise information for which size I want to view the image in, it's in pixels, not in %, right? The percentage is only what I calculate (in my hand or using a calculator) from the original and target sizes.

colomar wrote:Oh, I just saw I might have caused some confusion: I'm not saying precise zoom is never useful. I'm just suggesting that perhaps setting a precise zoom-factor might never be useful.
If I want to view that 96x96px icon at 32x32px, wouldn't it be more useful if I could set it to "Zoom out until the longer side is 22px on the screen" instead of "33%"? If I have precise information for which size I want to view the image in, it's in pixels, not in %, right? The percentage is only what I calculate (in my hand or using a calculator) from the original and target sizes.

Ahh, the confusion may have been mine. It's kinda tricky isn't it. I certainly agree, in that icon zooming case, that the technical result of what the user wants is in pixels and that the task the user is trying to accomplish can be logically and successfully be expressed in pixels - "show me this 96x96 pixel image at 16x16 pixels". I confess though that it sounds and feels rather similar to a resize behavior than a zoom behavior. Maybe it's because I know the image already has a resolution property that is almost uniquely expressed the same way. So perhaps when I want to change the resolution then I think using the units of that property - pixels. When I want to see the image bigger/smaller without changing the image resolution property then I think of the current application zoom factor and use the units I associate with that property - %. That might be a bunch of post-rationalization for all I know. What you suggest may well be a fair way to address that particular case of precise zoom. Is it sufficient to cover instances where precise zoom factor might legitimately serve a need? I confess that I'm not sure. If I seem reluctant to conclude that there are no instances where precise zoom factors are ncecessary, it's probably because I am.

I don't have explicit usage data to support the use of precise zoom factor as a legitimate use-case. What we do have are the several applications across the platform spectrum that provide that behavior. Admittedly, that might be due to poor application design or it might be due to legitimate use-cases. Difficult to tell without explicit usage data. But it's enough to give me pause when considering whether or not it is essential functionality in some applications. In so far as I don't have the data to conclude it is essential functionality, I similarly don't have the data to conclude that it is not. In light of the data we do have (applications that provide it), however inadequate, I'm thinking we'd fare better accommodating the possibility that precise zoom factor does serve a legitimate use-case, even if we can find specific reasons to recommend other behavioral solutions most of the time.

Since I don't have any more data than you do, of course I wouldn't say "There is never a scenario where entering precise zoom percentages is the most useful thing to do".
"Never say never" and everything

What I want to avoid, though, is people implementing precise percentage zoom just because that's what others do or what they're used to. It should only be done if, after thinking about the different possibilities, the designer decides that for this specific application, allowing the user to set precise zoom percentages would be the best thing to do.
And I'd bet there are quite a few applications that implement precise percentage even though actually there is no valid usecase for them.

Then I think we're on the same page regarding accommodating precise zoom factor behavior and controls in the guidelines Thomas. I was simply reluctant to exclude them altogether.

alake wrote:Then I think we're on the same page regarding accommodating precise zoom factor behavior and controls in the guidelines Thomas. I was simply reluctant to exclude them altogether.

I don't think we should exclude them altogether, either.

Thomas or Andrew, could you please draft the guideline when to use precise vs. arbitrary zooming? I'm a little bit confuse now