Files: zooming is hidden

[snowparrot]

There is no hint in the menues or in the UI, that you zoom in or zoom out. Just the keys work. Another problem is to know what is 100 % or normal zoom after you zoomed in or out.

Expected behaviour:

Have a zoom menu somewhere in the UI.

behaviour now: Its not.

Proposal: The context menu might be a good start as it isnt a common feature.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[danrabbit]

Personally, I'm inclined to get rid of zooming in Files. It would reduce the test surface for things like selection badges and probably simplify view code quite a bit.

I'd be interested to hear thoughts from @elementary/ux about the purpose of being able to zoom in Files. I think it's important to note that zoom in Files does not change the text size, only the icon and thumbnail size. My thought is that if zoom is about thumbnails, Photos is the app to use to browse images if you want large thumbnails. If zoom is about mimetype icons, then we need to make sure our 32px and 64px mimetype icons are clearer.

Something to consider is that we have some feedback from users that they actually find thumbnails to not be useful in the list and column views. So if zoom is about thumbnails and users don't want thumbnails, then it follows that zoom is also not useful.

I'd also be interested to hear from @jeremypw about the maintenance burden involved with the zoom feature and whether he would be more interested in removing the feature or expanding it.

[jeremypw]

Zooming has not given rise to any bugs for a long time, that I can recall, although there is a fair amount of code associated with it. We need to be able to deal with different size icons in different views anyway so the saving by removing it may not be that great. The views are all derived from the same class and use the same renderers so share a great deal of code (90+% at a guess). So treating list and column view differently would add some complexity.

I agree that showing thumbnails larger than a certain size may not be useful for most people but could be useful for the visually impaired.

Also below a certain size thumbnails are not so useful. It would probably be possible to automatically switch to mimetype icons below a certain size.

Personally I find zooming moderately useful and is generally something I would expect in apps displaying images. It would be interesting to get user feedback on this.

It would also be possible to change the fontsize on zooming if appropriate.

[jeremypw]

There is a hot-key for "normal" zoom (Ctrl-0) but since what is normal or optimal will vary between users I do not consider this very useful.

[snowparrot]

" I agree that showing thumbnails larger than a certain size may not be useful for most people but could be useful for the visually impaired." is a great point.

[cassidyjames]

I'm mixed on this as well. I do see the accessibility concerns/advantages to having zoom. I agree that if we have and actively support zoom, it should be more accessible in the UI. Although if someone has trouble seeing things at the default size, is it likely that they will want to make the entire UI larger, either by setting a lower resolution on their machine or by increasing the text size globally?

[snowparrot]

Increasing the text size globally doesnt increase the size of icons in Files.

[jeremypw]

Setting the screen resolution lower sounds like a sledgehammer with potential unwanted side-effects but there are other aids such as screen magnifier tools. Input from those actually effected is needed though rather than speculating.

[jeremypw]

I would have thought that <Ctrl>-Scroll and/or the corresponding hot-keys are generally used for zooming in many applications (Terminal, Code, Photos, Chromium etc) so kind of part of learning to use a computer. However if maintained, I would be in favour of exposing it Files in the same way as Terminal and Code for consistency.

[4jNsY6fCVqZv]

@jeremypw The issue is still relevant. Any idea how to solve this elegantly or close it?
Maybe related to https://github.com/elementary/files/issues/282 and in a first perception somehow also to https://github.com/elementary/files/issues/712 as well ... (->cause it's thumbnail related)

[jeremypw]

@4jNsY6fCVqZv Sorry this has not been addressed yet - there is a limit to the number of unmerged PRs it is practical to support and there are a lot of issues to potentially work on! To date, the UX team have resisted adding an AppMenu button to the Files headerbar, which is how Terminal and Code expose the zoom UI. I'll ask whether there is a consensus on whether to add zoom UI and how.

[4jNsY6fCVqZv]

@jeremypw Exciting, I always thought it is the strength of elementary OS design to look at the desktop environment holistically. I also thought of the examples Code and Terminal. I'm curious to see what the UX team thinks about such a solution. Or how other solutions can look and make sense. From the user's point of view, I see hidden features rather critically. Maybe it doesn't need the feature then?

[jeremypw]

From the previous ux team comments it seems they are not persuaded it is a useful feature but I think a significant number of users might complain if it were removed altogether. Rather like the "double-click to activate" mode it may just remain a less discoverable feature.

[4jNsY6fCVqZv]

Isn't it useful when people want to use it?
Are hidden features useful from the user's point of view?

[jeremypw]

I agree - it is a controversial issue. It is not easy to determine how many users use or would miss a certain feature (except from the number of complaints when it is removed!). This may be relevant: https://elementary.io/docs/human-interface-guidelines#concision. However, the UX team is willing to revisit this and seem to be relaxing their resistance to an AppMenu button for this and some other global settings.

[4jNsY6fCVqZv]

Yes, I understand that the issue is controversial. I also want clear apps that don't overflow with things no one needs. I'm also happy that the UX team wants to get back to this topic. Gladly I give feedback. And I'm curious to see what idea we can develop together as a community.

[4jNsY6fCVqZv]

@jeremypw You mention global settings. What other settings would make sense for you in an extra AppMenu in Files?

[jeremypw]

@4jNsY6fCVqZv : Possibilities that come to mind are "Show hidden files", "Show remote thumbnails", "Hide local thumbnails", "Restore tabs", "Double-click to activate". These settings affect the application as a whole, not just the current view so do not really belong on the view background context menu. You may find some more by inspecting the schema at "io/elementary/files/preferences".

[jeremypw]

Probably best to make each addition to such an AppMenu the subject of a separate issue so they can be discussed and approved individually.

[4jNsY6fCVqZv]

@jeremypw "Show hidden files" and "Hide local thumbnails" can already be found in the context menu, right? How could the context menu evolve if there is an AppMenu in Files in the future?

[jeremypw]

@4jNsY6fCVqZv Yes, but they could be considered out of place since context menus are meant to only apply to the object you clicked on whereas those two options apply to the application as a whole (i.e. to every view). They are candidates for moving to the AppMenu therefore, which would have the advantage of reducing the size of the view context menu.

A redesign of the view context menu has already been proposed at #629, although an AppMenu was not considered at that point.

[4jNsY6fCVqZv]

@jeremypw I like the redesign for the AppMenu. When should it be integrated into elementary OS? However, I am also in favor of moving the app's wide settings to the AppMenu. This is visually more logical for me. I also noticed that I don't have to click on a file or folder for the context menu to appear. A right click goes everywhere in the white area of the view and lets the context menu appear, doesn't it?

[jeremypw]

@4jNsY6fCVqZv Right clicking on white space give a context menu for the active folder, whereas right-clicking on a file or folder item gives a context menu for that item (or selection of items).

[4jNsY6fCVqZv]

@jeremypw "Folders Before Files" is another global setting within the context menu, right?

[jeremypw]

Yes, good point.

[4jNsY6fCVqZv]

Do you think it makes sense to create a first design for a new global AppMenu for Files? To inspire the design process ... Of course in close coordination with https://github.com/elementary/files/issues/629

[jeremypw]

I have just created a Files project for designing and implementing such a menu.

[jeremypw]

I note that Terminal and Code have zoom in the AppMenu but in those cases it is applied globally so it makes sense. Applying zoom globally in Files would be problematic as there are three different view modes which have different optimum zoom levels. I may be possible to define a different base (100%) zoom-level for each view mode and scale each according to a global control. It depends how much people want to control the zoom level of each open tab independently.

[4jNsY6fCVqZv]

Thanks for creating the new project! Which issues should be part of it?

[4jNsY6fCVqZv]

It depends how much people want to control the zoom level of each open tab independently.

Good question! How can we find out? Through a survey? For example on the elementary OS Mastodon account?

[jeremypw]

I have added this issue, although it is uncertain whether zooming belongs in a global menu or the context menu.

[jeremypw]

Closed accidentally

[jeremypw]

@4jNsY6fCVqZv When I said "people" I really meant @elementary/ux , at least initially. If they want to go for a poll of some kind then I guess they will arrange it.

I added some candidate functions to expose in the AppMenu to the project. I'll create new issues to track progress as required, once one or more candidate is approved.

[4jNsY6fCVqZv]

@jeremypw Thank you for getting this off the ground!