Gnome published the first draft of their new HIG recently (the online pages seem to be more up-to-date that the offline docs). Two facts are remarkable, at least:

"As far as possible, applications should be designed in order to not require manual configuration. Generally, a well-designed interface does not require configuration and will operate effectively with no modification of preferences for both different use cases and users."

The other interesting thing is the guideline on zoom.

How does KDE handle zoom by default?

• Dolphin
  Access: mouse = ctrl+wheel, keyboard = ctrl + num +/-
  Reset to default: no
  Main menu: view > first two options = +/-
  Visualization: (hideable) slider at statusbar with no further label (except a tooltip when using the slider)
  Steps: pixels (16,22,32,48px..)
• Gwenview
  Access: mouse = ctrl+wheel, keyboard = ctrl + num +/-
  Reset to default: not per keyboard but via quick access button/function
  Main menu: view > somewhere in the middle of the menu = original size, fit to screen, and +/-
  Visualization: slider at statusbar labeled with the current size, plus quick access to fit to screen and 100%
  Steps: percent, non-linear (2/3, 100, 200%...)
• Calligra (Words)
  Access: mouse = ctrl+wheel, keyboard = ctrl + num +/-
  Reset to default: no
  Main menu: view > last section = +/- and a submenu with strange radio buttons (don't behave like rb, steps with decimals)
  Visualization: slider at statusbar labeled with the current size, plus quick access per dropdown to predefined steps or direct input
  Steps: percent, non-linear (25,33.3,66.7,100,141.4%...)
• KMail
  Access: mouse = ctrl+wheel, keyboard = ctrl + num +/-
  Reset to default: ctrl+num0
  Main menu: view > last section > scaling (submenu) = +/- and reset
  Visualization: no
  Steps: unknown (no visualization)
• Kdenlive
  Access: mouse = ctrl+wheel, keyboard = ctrl + num +/-
  Reset to default: ctrl+num0
  Main menu: timeline > last section = +/- and fit
  Visualization: slider at statusbar that shows a tooltip on zoom with the current size, plus +/-, and fit buttons
  Steps: x/13 (might depend on the clip)
• Okular
  Access: mouse = ctrl+wheel, keyboard = ctrl + num +/-
  Reset to default: only per menu
  Main menu: view > middle section = +/-, and width, page, auto
  Visualization: dropdown at toolbar showing clear text (whole page) or the current value (100%) with access to +/-, and other options via dropdown
  Steps: percent (12, 25,33,50,66,75,91.8=fit?,100,150,200%)

Putting all together
Zoom serves two different purposes in the current implementation: it supports accessibility (Dolphin, KMail, Calligra, etc.) by modifying the text size, and it offers the common modification of the level of detail (Gwenview, Kdenlive, etc.).

• Do we really need the first one, or isn't it better to change it at some system module? (Actually, I use it sometimes with Firefox to read a page in a leaned back position).
• Should we make it a default to have a slider at the status bar (with buttons and label, according the resp. HIG)? AFAIK, the status bar has been considered as bad style.
• The zoom icon equals often to search (magnifier glass) unless its decorated with +/-. Do we need and have better symbols?

I'm sure there are some more things to consider. So please comment the hell out of this thread

PS: Okular added

First of all: Yes, we do need a zoom HIG, of course, so thank you for kicking this off!
Actually, I'm positively surprised that even without a HIG, KDE achieved a relatively good level of consistency, but your examples also show that there is still room for improvement.

Now to your specific questions:

Do we really need the first one, or isn't it better to change it at some system module? (Actually, I use it sometimes with Firefox to read a page in a leaned back position).

Of course standard font sizes for UI text are set in the respective KCM, but it's still convenient to be able to zoom in or out on a specific view. If a zoom would indeed only change the font size of UI text, I'd consider it unnecessary, but in all the applications you mentioned, the whole content is zoomed, which usually contains things other than text as well; Or text which isn't UI text and therefore could have different initial values (e.g. in a document shown in Okular) and therefore isn't influenced by the standard font settings.
In Dolphin, zooming is relevant for example if one has activated thumbnails and needs bigger or smaller ones in a specific situation.
So yes, let's please keep the ability to zoom content in or out (and in Dolphin, I'd consider the view of the files in a folder "content" as well).

Should we make it a default to have a slider at the status bar (with buttons and label, according the resp. HIG)? AFAIK, the status bar has been considered as bad style.

That's a bit trickier: Yes, we say that status bars should only be used if they actually contain information and that they should not contain any controls. And I'd still stick with that as a general rule.
On the other hand, I've found the zoom controls in status bars to be quite convenient in e.g. Dolphin or Gwenview. Semantically, the zoom controls would clearly belong in the toolbar, though. The quesion is: Why don't some applications place them there? We should ask some developers that have put them in the status bar in their applications about the rationale behind that choice before telling them to change it.

Of course if we promote the zoom sliders in status bars to a standard, we have to be aware that this standard applies only to applications that have a sidebar (which should be the minority, according to the status bar HIG).

The zoom icon equals often to search (magnifier glass) unless its decorated with +/-. Do we need and have better symbols?

Yes, that is a problem. Oxygen tried to avoid the ambiguity by using binoculars for search, but nowadays the magnifying glass for search is so omnipresent, people would associate it with search anyways (which your icon survey clearly demonstrates). But that's something for the icon designers to worry about, I guess

If we guide to use zoom for text it will be for all apps, effectively. I can see the potential for convenience. But I cannot imagine a good design with slider in toolbar. Perhaps it makes sense to hide the feedback unless the users does zoom, and show it then as some kind of overlay or head up display.

Heiko Tietze wrote:If we guide to use zoom for text it will be for all apps, effectively.

All applications should support zooming the content view in or out, yes. But not labels in the UI "chrome", that's certainly not what users would expect because that's a system-wide setting for accessibility reasons, not something one would want to change spontaneously. No KDE application does that, and no other application I know either.

I can see the potential for convenience. But I cannot imagine a good design with slider in toolbar. Perhaps it makes sense to hide the feedback unless the users does zoom, and show it then as some kind of overlay or head up display

Hm, that would make zoom a "hidden feature" because people would have to know how to zoom otherwise first.

I like the slider in the status bar, but you have right, the HIG say that's not the right place.

so how does it work when we use the zoom icons. here is an image from Okular.


Zoom Out and Zoom In is also available in Dolphin, Gwenview, ... I think we only need a drop down box like you see in the Okular screenshot to replace the slider. What do you think, does a drop down menue in the icon bar can replace the slider in the status bar.

On the other hand something like an "intelligent" icon as the sound button in Amarok for zoom would also be cool.

Intelligent in what respect? Do you mean the volume that pauses playing on click and shows a tooltip and a notification on mouse wheel?

I mean the volume icon where you can scrall via the mouse and see if the volume is at full power or noisy.

So when you have such an icon for zoom where you can scrall with the mouse and see on the icon the zoom rate. but of course this is not included in the HIG and could be complicated for the user. It's only thinking

andreas_k wrote:It's only thinking

Brainstorming is what we want to get from the forum! Sorry, if I always come up with drawbacks and showstoppers. The (more or less) intelligent button is a nice idea. And it could use the actual font size or the percentage for the particular zoom. But such an icon would need a lot of space, at least 48x48px I guess. I'll talk to the VDG guys during Akademy about this question.

In that last mockups zooming was implemented at some kind of functions bar, similar to the status bar. I think we should go with this idea and I would write the guidelines like this:

== Purpose ==
Zooming is a supportive and accessibility function with the purpose to a) resize text by increasing or decreasing the font size, with wrapping to avoid horizontal scrolling, leaving the size of the images the same, and b) resize images, other multimedia objects, and viewports on order to focus on details.

== Guidelines ==
== Is this the right control ==
* Provide zooming to enlarge images and documents to aid viewing.
* Use zooming to increase the number of pages displayed for multi-page documents or to change the number of items displayed in a viewing area.

=== Behavior ===
* Zoom in discrete steps depending on your content. For example 33,66,100,150,200,400% or 6,8,11,12,14,18,24pt. Add important steps like "Fit to size".
* Do not zoom by infinit, incremental steps.
* Use a [slider] for zoom located right hand in the functions bar at the bottom. Mark important zoom steps clearly.
* Show the current zoom factor in a label right hand of the slider.
* Provide access to zoom in/out via ctrl+mouse wheel, by keyboard short-cut ctrl+num +/-, and per main menu.
* Locate zooming feature in main menu below view as the first options.
* Reset zooming to default by ctrl+0 and per main menu.
* Use shift+ctrl+0 to adjust the zoom level so that the entire image is visible in the window.
* When the function affects a certain part of the screen, like the upper right corner of an image, center the zoom to the mouse cursor.

=== Appearance ===
^Mockup

Again, comments and mockups are highly appreciated. See as well Gnome's guideline: https://wiki.gnome.org/Design/HIG/Planning/Zooming

I think this is great Heiko. Thanks for sharing the GNOME guidelines as well. I think it's interesting that they accommodate the possibility of several different appearances.

Heiko Tietze wrote:* Use a [slider] for zoom located right hand in the functions bar at the bottom. Mark important zoom steps clearly.

Perhaps we should recommend the slider for zoom only when there are maximum and minimum zoom values. (It would violate the slider HIG otherwise).

* Show the current zoom factor in a label right hand of the slider.

For zooming on a map on in a file manager or something similar where there is no reference size (like 100%), a zoom factor may not communicate anything meaningful. The GNOME guideline suggests showing the zoom factor only on professional image editing software. I'm not sure that's the best approach for us. Perhaps something like:
* Only show the zoom factor when there is a meaningful 100% zoom factor reference.

Otherwise it all looks good to me. Even if we don't resolve my specific comments, I'm totally fine with getting this into the HIG as is for all the other portions that provide very helpful guidance. No sense in making the perfect the enemy of the good. Thanks again Heiko! :-)

alake wrote:Perhaps we should recommend the slider for zoom only when there are maximum and minimum zoom values. (It would violate the slider HIG otherwise).

My intention was to go the other way and to have only discrete steps with min and max.
* Do not zoom by infinit, incremental steps.

Every application has a fix range, image viewers/editors for instance with 25%...400% (I guess Krita uses a slider too). Even Marble cannot zoom out of the universe. It rather has no meaningful steps - and should either violate the HIG therefore or make it meaningful like using Harbor Island > Seattle > Washington > USA > North America, or per legend with 50m, 100m, 500m...
Sliders are perfect controls for a fix range. They are light weight, informative, and easy to use. That's my reason to use them by default, instead of either slider or up/down buttons as Gnome recommends.

Heiko Tietze wrote:My intention was to go the other way and to have only discrete steps with min and max.
* Do not zoom by infinit, incremental steps.

I agree with the "finite" part, but not with the "fixed steps" part. Most (all) zoom features I've experienced allow zooming only within limits (either for technical or practical reasons), so I agree that a slider makes sense.
However, I see sliders as especially useful if users can set any arbitrary value withing those limits, because a slider has an "analog" feel to it. You move the slider until you have the zoom factor you want (i.e. where you see the details you need while keeping the overview you need). If we allowed only to switch between discreet values, it would feel like an arbitrary limitation.
Many office applications use a combobox for zooming, where users can either choose between a set of predefined zoom values or enter an arbitrary percentage if none of the predefined values works for them. However, with a slider, there is no need to restrict yourself like that, and one does not need that precise level of control.
What I do like is what Gwenview currently does: One can zoom freely using the slider, or choose the useful values of "100%" or "Fit" via buttons. IF we think there are more useful predefined values than would fit comfortably into toggle buttons, we could use a dropdown instead, but I don't see more useful values than "100%", "Fit in window" and "Fit width" (for document viewers/editors).
All other values (like 25%, 50%, 200%, 400%) are completely arbitrary and don't offer any benefit over just dragging the slider to the desired zoom level. Why would you ever want to zoom to precisely 400%? You want to zoom so you can either see more details or see more of the document (or perhaps if you want to see if it still looks good in a certain size), but not because you want to see it exactly in 400% or 25% size.

There might be one instance where we want to zoom precisely and that is for graphics editing or viewing, where you sometimes quickly need to see how an image looks when it's scaled up or down to a specific size. Like how does this 256x256 icon look when scaled down to 32x32 or how might this photo look when reduced to half the size. Certainly you could just the resize function, but it's a lot quicker and non-destructive to use the zoom (Inkscape would be almost useless to me without that feature). That said, in those specific cases, a text field for directly setting the zoom label might be more direct than a slider.

So maybe
* a slider for arbitrary zoom factors
* buttons/droplist/[whatever] when specific, limited set of zoom factors are needed
* editable text field for when setting the precise zoom factor is needed

If your application requires only arbitrary zoom factors then use a slider.
If your application requires only specific, limited zoom factors (Page Fit, Window Fit, 1:1, etc.) then use buttons/droplist/[whatever]
If your application requires both arbitrary zoom factors as well as specific, limited zoom factors then use both buttons/droplist/[whatever] + a slider (like Gwenview).
If your application requires both precise zoom factor setting as well as specific, limited zoom factors use an editable droplist (like Okular).

And so on... I know it seems like we won't get one single pattern, but I think there's enough of a variety in real application needs that it might be worth crafting multiple patterns to suit those needs rather than trying in vain to come up with a single pattern that suits every need. For the specific limited zoom factors, I'd offer we just pick one control to recommend and go with it.

As an aside, one possible upside for using a slider as a control for specific, limited zoom factors is that it can sort of communicate how the zoom factors relate to each other in a visual way. Of course you couldn't use a slider for both arbitrary zoom and specific limited zoom at the same time.

Hope this is helpful.

alake wrote:There might be one instance where we want to zoom precisely and that is for graphics editing or viewing, where you sometimes quickly need to see how an image looks when it's scaled up or down to a specific size. Like how does this 256x256 icon look when scaled down to 32x32 or how might this photo look when reduced to half the size. Certainly you could just the resize function, but it's a lot quicker and non-destructive to use the zoom (Inkscape would be almost useless to me without that feature). That said, in those specific cases, a text field for directly setting the zoom label might be more direct than a slider.

Actually, I've been thinking about the "Would my icon still look good in 32x32px?" usecase as well. However, I don't think setting a specific zoom factor would be really beneficial for that, because it would require you to take out your calculator and divide the current size by the desired size to find out which zoom factor to use. That does not sound quick to me at all.
Wouldn't a "Zoom to AxB pixels" function be much more useful here? Actually, I still cannot imagine any usecase where setting a precise zoom factor would really be the most useful thing to have. I may be missing something here, but I'd encourage us to step back from the intuitive "There must be cases where users want to set a precise percentage!" and for each situation where we think imprecise zooming via a slider won't cut it think "Okay, what exactly does the user need to set and how can we offer that setting?".

I could as well ask for the use case to zoom to exactly 132,8 %. Is there really any application (except Gwenview) that allows it? Anyway, I'm not fixated on discrete steps. Discrete marks on the arbitrary scale and an easy way to adjust the slider to it would be fine too. But what I really want is consistency by promoting the slider in favor of the dropdown/button zooming. Right now it's only Andrew who needs to get convinced, or not?