Are you referring to the default zoom level, or the available zoom levels? Why are they too large?

The default icon zoom level is too small for usable thumbnails, but too large to scan across. The small icon zoom level is also still a bit too big.

So, for what I collected from users.

Default icon size is too big because:
- when it's not thumbnails, it feels out of place with the overall nautilus (like the icons in buttons and the sidebar)
- they use icon grid instead of list view because you can see more items at once, and the icons (not the thumbnails) help them to figure out if it is a folder, a document, or a picture. So they figure out quickly the type of the file. In list view you need to read to figure it out.
If the icons are big in this case, doesn't provide a big win to the user.
- If they try to use the small zoom, items are too close between each other, so the labels get ellipsize very quick (that's a technical problem with nautilus, not a design problem, since nautilus takes a default padding and modifies it for each zoom level, but we can't do/don't worth it to do anything until the rework of the views). But increasing the space for the label in the current standard zoom to alleviate that problem on the smaller zoom would make it too much space in the standard zoom for a normal use.

My proposal would be to:
- Make the standard zoom level 64px (so you can scan icons and labels quick but the quality of icons-thumbnails is semi acceptable) and increase the padding.
- Make the small one 48px (this was the standard size in 3.14) for those who want more items in the same view instead of the quality of icons/thumbnails.
- Let the biggest zoom level as it is 128px, for those who want navigate with thumbnails.
- Make the big zoom level as default in the Pictures folder.

I think this is a sensible solution. What do you think Allan?

(In reply to Jasper St. Pierre from comment #2)
> The default icon zoom level is too small for usable thumbnails, but too
> large to scan across. The small icon zoom level is also still a bit too big.

In general you get the same number of thumbnails for the available space, since we reduced the padding between them - so I'm not really sure what you mean about scanning.

I have to say that I'm not a fan of second-hand bug reports. While I understand the desire to utilise feedback, it makes it is rather hard to get to grips with what is actually happening.

(In reply to Carlos Soriano from comment #3)
> So, for what I collected from users.
> 
> Default icon size is too big because:
> - when it's not thumbnails, it feels out of place with the overall nautilus
> (like the icons in buttons and the sidebar)

It's hard to know exactly what to make of that. I can think of many many examples of large content thumbnails and smaller controls, and there are practical reasons to do that.

> - they use icon grid instead of list view because you can see more items at
> once, and the icons (not the thumbnails) help them to figure out if it is a
> folder, a document, or a picture. So they figure out quickly the type of the
> file. In list view you need to read to figure it out.

But you still get the icons in list view, and they're certainly sufficient to differentiate between files and folders, for example.

I can understand the "view many items" argument, but this should hopefully be helped by the changes we made to the smallest zoom level in list view.

> If the icons are big in this case, doesn't provide a big win to the user.
> - If they try to use the small zoom, items are too close between each other,
> so the labels get ellipsize very quick (that's a technical problem with
> nautilus, not a design problem, since nautilus takes a default padding and
> modifies it for each zoom level, but we can't do/don't worth it to do
> anything until the rework of the views). But increasing the space for the
> label in the current standard zoom to alleviate that problem on the smaller
> zoom would make it too much space in the standard zoom for a normal use.

I agree that there are issues with labels in the smallest icon zoom level. Would it work to increase the amount of horizontal padding in that case?

> My proposal would be to:
> - Make the standard zoom level 64px (so you can scan icons and labels quick
> but the quality of icons-thumbnails is semi acceptable) and increase the
> padding.
> - Make the small one 48px (this was the standard size in 3.14) for those who
> want more items in the same view instead of the quality of icons/thumbnails.
> - Let the biggest zoom level as it is 128px, for those who want navigate
> with thumbnails.
> - Make the big zoom level as default in the Pictures folder.
> 
> I think this is a sensible solution. What do you think Allan?

I think it really depends on what we consider the goals for these different views to be. My view is that icon view is primarily of use when there are thumbnails, and I'm not convinced that 48x48 thumbnails are all that useful.

If people want to see lots of files, complete with filenames, in an easy to scan manner, the obvious answer seems to be a compact list view. Making list view the default instead of grid view could be a good move in this respect.

One thing that we didn't implement from the original designs was replace thumbnails with icons when at the smallest list view size - since thumbnails aren't useful for differentiate file types at this size.

*** Bug 749165 has been marked as a duplicate of this bug. ***

(In reply to Allan Day from comment #5)
> I have to say that I'm not a fan of second-hand bug reports. While I
> understand the desire to utilise feedback, it makes it is rather hard to get
> to grips with what is actually happening.
> 

Rigth, but I can't see a better way. Also, I agree with those points myself, that's why I could explain them.

> (In reply to Carlos Soriano from comment #3)
> > So, for what I collected from users.
> > 
> > Default icon size is too big because:
> > - when it's not thumbnails, it feels out of place with the overall nautilus
> > (like the icons in buttons and the sidebar)
> 
> It's hard to know exactly what to make of that. I can think of many many
> examples of large content thumbnails and smaller controls, and there are
> practical reasons to do that.
> 
Right, but having icons with so much different size, looks a little odd. Although I agree is not a very good point to back up the change and more like a good thing that can happens.
> > - they use icon grid instead of list view because you can see more items at
> > once, and the icons (not the thumbnails) help them to figure out if it is a
> > folder, a document, or a picture. So they figure out quickly the type of the
> > file. In list view you need to read to figure it out.
> 
> But you still get the icons in list view, and they're certainly sufficient
> to differentiate between files and folders, for example.
> 
Rigth, I wrote it wrong.
> I can understand the "view many items" argument, but this should hopefully
> be helped by the changes we made to the smallest zoom level in list view.
> 
Not much, icon view still takes advantage of horizontal space. It's a big difference.
> > If the icons are big in this case, doesn't provide a big win to the user.
> > - If they try to use the small zoom, items are too close between each other,
> > so the labels get ellipsize very quick (that's a technical problem with
> > nautilus, not a design problem, since nautilus takes a default padding and
> > modifies it for each zoom level, but we can't do/don't worth it to do
> > anything until the rework of the views). But increasing the space for the
> > label in the current standard zoom to alleviate that problem on the smaller
> > zoom would make it too much space in the standard zoom for a normal use.
> 
> I agree that there are issues with labels in the smallest icon zoom level.
> Would it work to increase the amount of horizontal padding in that case?
> 
As I said, the problem is currently technical (and we can revisit the zoom levels and look after the views rework), increasing the small zoom padding increase also the standard zoom padding, which makes the standard zoom padding too big with the size of the icons.
> > My proposal would be to:
> > - Make the standard zoom level 64px (so you can scan icons and labels quick
> > but the quality of icons-thumbnails is semi acceptable) and increase the
> > padding.
> > - Make the small one 48px (this was the standard size in 3.14) for those who
> > want more items in the same view instead of the quality of icons/thumbnails.
> > - Let the biggest zoom level as it is 128px, for those who want navigate
> > with thumbnails.
> > - Make the big zoom level as default in the Pictures folder.
> > 
> > I think this is a sensible solution. What do you think Allan?
> 
> I think it really depends on what we consider the goals for these different
> views to be. My view is that icon view is primarily of use when there are
> thumbnails, and I'm not convinced that 48x48 thumbnails are all that useful.
> 
I think icon view is not only used for thumbnails, even for my own use. But it serves two purposes at once. Sometimes (99% of the times) at least for me it serves the purpose to navigate through items without thumbnails (folders/documents), just caring about the type and the name.
> If people want to see lots of files, complete with filenames, in an easy to
> scan manner, the obvious answer seems to be a compact list view. Making list
> view the default instead of grid view could be a good move in this respect.
> 
But the problem of not taking advantage of the horizontal space is still the big issue, which icon view fixes.
> One thing that we didn't implement from the original designs was replace
> thumbnails with icons when at the smallest list view size - since thumbnails
> aren't useful for differentiate file types at this size.
Right, I completely forgot that one

The goals for me for icon view is to scan through a *large* amount of files to find something that roughly matches. Icon view allows me to get a large number of items on the screen at once. As such, I need a fairly large amount of padding. Windows has a fairly decent implementation of this mode which is useful for me.

http://i.imgur.com/hGSBju8.png (don't laugh at my dumb taste in music, please)

List view is for finding a specific file. I care a lot about the specifics. Common use cases are sorting by file type or more recently touched so I can find new downloads in my Downloads folder, or specific .zip files I know are somewhere in this folder. Padding and icons really aren't necessary here, except as a file type indicator. The data in the data grids is what I care about. Again, Windows, even when showing pictures, the most thumbnailable things, ever, does *not* show thumbnails in list view.

http://i.imgur.com/7EFinIQ.png

It instead has preview / details below. The preview sidebar on the right isn't as helpful except to get large previews when the window is bigger. You can toggle it on/off with the button next to help.

Sometimes I use list view alphabetical mode to navigate, but I find it just isn't as good for that.

Hopefully this gives you some understanding of what I use these two modes for, and why the recent Nautilus changes make a poorer experience for me. I'm on Windows right now since my laptop with GNOME on it is actually at the office.

Please let me know if this helps at all, or if it's not what you wanted!

Created attachment 303226 [details]
screenshot - 3.16 smallest icon zoom level

Both comment 7 and 8 seem to suggest that it is density of items that is the critical factor in this bug. I'm not entirely sure about this as a design goal, but nevertheless, it isn't clear how the current zoom levels are insufficient in this regard.

The attachment shows the current implementation of icon view at the smallest zoom setting. It is actually very dense, and shows many more items than the default zoom level in 3.14.

Compare the icon size and density from my screenshot with nautilus's. And that's actually the *medium* size in Windows, too! You can drag a slider to get it to:

http://i.imgur.com/F51Rtui.png

At some point, there's a threshold, at which point it switches to something more like the compact mode.

http://i.imgur.com/cRxkryn.png

Dragging it all the way down to "Small Icons" on the slider, you see the classic compact mode:

http://i.imgur.com/FwD27Ss.png

(In reply to Jasper St. Pierre from comment #10)
> Compare the icon size and density from my screenshot with nautilus's. And
> that's actually the *medium* size in Windows, too! You can drag a slider to
> get it to:
> 
> http://i.imgur.com/F51Rtui.png

Leaving the multi-column layouts aside for the time being, I can see that this minimum grid size in Windows shows marginally more items. Roughly speaking, Nautilus shows a 10x5 grid, whereas Windows shows 13x6.

One thing I'm concerned about here is that it doesn't seem easy to scan a highly populated grid. A list is so much easier to browse when there are lots of items, even if it does require scrolling.

(In reply to Allan Day from comment #9)
> Created attachment 303226 [details]
> screenshot - 3.16 smallest icon zoom level
> 
> Both comment 7 and 8 seem to suggest that it is density of items that is the
> critical factor in this bug. I'm not entirely sure about this as a design
> goal, but nevertheless, it isn't clear how the current zoom levels are
> insufficient in this regard.
> 
> The attachment shows the current implementation of icon view at the smallest
> zoom setting. It is actually very dense, and shows many more items than the
> default zoom level in 3.14.

A specific problem with the current small zoom is that the padding is not enough, and therefore most of the times labels ellipsize, and therefore the purpose of using the small zoom vanishes.
If we increment the padding, sadly it will increment all padding in all zooms, and the current standard zoom goes even worse. That's a technical problem.
Also it's even worse with no dynamic padding...

So what I proposed is do a trade-off until we have better views with dynamic padding, etc., and then maybe using a bigger zoom is not a real problem.

Anyway, I still think that the usual use of the icon view in nautilus is what Jasper also said, scanning thru files names/types (that's why I also proposed that for the Pictures folder we could increase the default zoom, since we know for sure that there the use is for thumbnails). So I can see a point to make the standard zoom smaller than the current one. But I don't have more data than mine and people I know to back up this.

I didn't know that Windows solves it in that way, it's a smart way since is like list view but takes advantage of the horizontal space as well so labels are not ellipsized. The visuals are not very great, but it's okay I guess.

The giant folder icon takes up most of the space and is noise. Windows at least has a bit of "preview content" in the thumbnails themselves, but a giant 64x64 folder icon just isn't useful. It's distracting more than anything.

I don't think the list density is bad for scanning, as long as there isn't noise around. Personally, looking at the two screenshots, I find the Windows version *much* easier to scan.

I just mention my own experiment
I'm a student with lots of book that i read daily.
Before updating to 3.16 I can access my fav book with just one click thanks to 48x48 icon. But after updating i see the below view

I can't fit all my book in a single view so everytime I need to scroll all the way. personally i didn't need preview and thumbnail.I dont want ListView either because it confined me more(less book in a page)
https://i.imgur.com/9fWHrJf.png
Default big icon size for use in thumbnail sounds good, but some people like me not interesting in preview at all.
But I see the POV of you. I Think this option (custom icon size) isn't need for all user. so add some option for set size in some more pro way (like DConf) is just fine.

How's that sounds

I know it's not good netiquette to throw in a "me too", but I feel I really have to here. I've just spent the best part of two hours trying to get my desktop usable again after upgrading to 3.16.

Some icon themes don't have all icons available at sizes between 48x48 and 96x96. I still use Bluecurve, for instance, and even when Nautilus is set to the "small" zoom level it still picks its 96x96 icons -- they end up practically overlapping!

I would really love for 48x48 to be supported by Nautilus again, even if it means thumbnails are not available at that size.

*** Bug 757090 has been marked as a duplicate of this bug. ***

Nautilus could have 4 size levels: the ones it already has + 48x48px

What's wrong with 48x48px as "NAUTILUS_CANVAS_ZOOM_LEVEL_SMALL" ? List view zoom level has 16px as smallest. If that is not possible, then, please introduce another zoom level with 48px as the smallest.

(In reply to Khurshid Alam from comment #18)
> What's wrong with 48x48px as "NAUTILUS_CANVAS_ZOOM_LEVEL_SMALL" ? List view
> zoom level has 16px as smallest. If that is not possible, then, please
> introduce another zoom level with 48px as the smallest.

read comment 12

I'd welcome experimental patches for this bug, either to make the smallest grid zoom size use 48px icons or to introduce another smaller zoom level.

I'm still fairly attached to the 64px default level, partly because I don't want to optimise for super-dense views, and because thumbnails aren't very useful when they're much smaller than that.

And just to reiterate: I know that these views aren't perfect, but we are limited by the technology.

It might be worth thinking about other things we can do to help with scanability, also. I find the line spacing too high for icon captions in grid view, for example.

Hello, yesterday I did some experiments and what if we reduce the font size as well? I've tried with 9 and 8. 9 is still big but 8 seems to be readable. Here is a ss:

https://www.dropbox.com/s/it5xcevpz7pn7yg/Nautilus%20Proposal.png?dl=0

I changed the icon size in the source, but I changed the font using the inspector, so that's why you have all scaled down to 8px, the idea it to have a property just for this case.

To compare here is how it's today:

https://www.dropbox.com/s/8gpk6d1zki243qb/Nautilus%20Current.png?dl=0

So, you go from 55 files to 98 files.

PS: I'm using a 1366x768 display, but I know much of you guys use bigger screens, so this might be fine just for my use case.

(In reply to igaldino from comment #21)
> Hello, yesterday I did some experiments and what if we reduce the font size
> as well? I've tried with 9 and 8. 9 is still big but 8 seems to be readable.
> Here is a ss:
> 
> https://www.dropbox.com/s/it5xcevpz7pn7yg/Nautilus%20Proposal.png?dl=0
> 
> I changed the icon size in the source, but I changed the font using the
> inspector, so that's why you have all scaled down to 8px, the idea it to
> have a property just for this case.
> 
> To compare here is how it's today:
> 
> https://www.dropbox.com/s/8gpk6d1zki243qb/Nautilus%20Current.png?dl=0
> 
> So, you go from 55 files to 98 files.
> 
> PS: I'm using a 1366x768 display, but I know much of you guys use bigger
> screens, so this might be fine just for my use case.

Hey, thanks for sharing experiments.
I think reducing the font size is not an option. What seems users wants more is to read the file name, and for that we need a good readability for it.

I'm tending towards modifying the zoom/padding of the icons, but we well see.
Any experimenting patch/mockup welcome!

No need to make things unnecessary complicated. As long as padding/icon_grid_width remains constant among many zoom levels it is not going to work. All we need is dynamic padding along with two more zoom levels, 48px being the smallest.

(In reply to Khurshid Alam from comment #23)
> No need to make things unnecessary complicated. As long as
> padding/icon_grid_width remains constant among many zoom levels it is not
> going to work. All we need is dynamic padding along with two more zoom
> levels, 48px being the smallest.

imho I still want to try to make the current situation better even if we cannot do dynamic padding.

That's why we need a middle ground solution.

GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version of Files (nautilus), then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/nautilus/-/issues/

Thank you for your understanding and your help.