Before / After

 Before

  Before

Note how the regular grid layout is destroyed by the long file name, which can make its row very large.

 After

   After (1/2)           After (2/2)

Note how the grid layout is preserved, while the whole filename is still visible as the file is selected or hovered.

Take that five year old bug report! Thanks to the incredible Pango grand master Behdad. Many play the Banjo, but only few master the Pango.

Update

I received lots of feedback. Many appreciations were given, some usability concerns were raised and some people just didn’t like the change. Therefore, I added GConf keys that allow you to control in detail (i.e. for all zoom levels, and for the desktop) how many lines of text you want.

Another proposal was that file extensions should never be truncated. This will be implemented as Pango supports it. There is also an interesting recent user request to ellipsize file names depending on the other displayed file names (assuming you have “alongfilename-01-continuin-hereg.jpg”, “alongfilename-02-continuing-here.jpg” the result is supposed to be “along…e-01-…ere..jpg”, “along…e-02-…ere..jpg”.

36 thoughts on “Before / After”

  1. Hey this is good, I had been wondering occasionally about this. Keep up the good work.

  3. Good improvement. I wonder how a smaller font size would look like for really long filenames

  6. Thank you. I can’t wait for new Nautilus.

    I don’t have to move icons all the time anymore. :)))

  9. i have to agree with Martin. Personally i like the “before” layout. This was always one of my main annoyance whit filemanager like konqueror where i had a lot of “foobarfoobar…” file names instead if the full filename. I don’t want to select the file to see the full name and i don’t like how it looks like (cover the icon below).

    Usability vise i think it is better to see always the length of a filename should mostly be in a range which allows the “before” layout without destroying the complete layout. If a file name is really that long that it makes the nautilus view unusable the filename should probably changed and not truncate filenames.

    But that’s all just IMHO.

  10. Sorry for the bad comment (lot of typos and incomplete sentences). It’ s probably just to late for me to write comments. 😉

    Here a better version:

    i have to agree with Martin. Personally i like the “before” layout. This was always one of my main annoyance with file managers like konqueror where i had a lot of truncated file names like “foobarfoobar…” instead of the full file name. I don’t want to select the file to see the full name and i don’t like how it looks like (cover the icon below).

    Usability vise i think it is better to see always the complete file name. The length of a file name should mostly be in a range which allows the “before” layout without destroying the complete layout. If a file name is really that long that it makes the nautilus view unusable the solution is probably to rename the fie and not to truncate the file names.

    But that’s all just IMHO.

  11. Mårten:
    > Does this work in Compact view as well?

    It overlaps the item on the right hand side (for RTL), which seems to look crappy in compact view. Feel free to propose solutions.
    Also note that it is just an issue in “all columns have equal width” mode, because otherwise the lines may have any length.

    pinky / Martin:
    The majority of users seems to appreciate the change. If it turns out that lots of people are against it (as well), we might add a preference. However:

    > If a file name is really that long that it makes the nautilus view unusable the filename should probably changed and not truncate filenames.

    So shorten your file names, and you will not see any ellipsis. If you think it’s the user’s fault anyway to have overlong file names, you shouldn’t care ;).
    Besides, the entire file name shows up if you hover over the item, and not just if you select it.

  12. Finally. Thanks! But what about having the ellipsis not at the end but within the filename so at least X endcharacters are shown allways? This would make it possible to still differentiate files like thisisaverylongfilenamenumber1 and thisisaverylongfilenamenumber2 or to still see the extensions … Or what about putting the ellipsis in the middle ? I think the most interesting information in a filename is mostly in the beginning or the end and least in the middle … so if you have to choose what not to shown it would be the middle. Thoughts?

  13. >So shorten your file names, and you will not see any ellipsis. If you think it’s the user’s fault anyway to have overlong file names, you shouldn’t care 😉

    Why have i expected this respons? 😉

    The point is that this limit is somehow hard coded. And there is something between “short enough to be not truncated” and “that long that it really desctroys the layout”.

    Some example would be your screenshot. An example is your screenshot. The file name is long but i thing not that long that the layout really looks bad. I think that is the case for most reasonable long file names. A file name which probably would make the layout look really bad (e.g 6 and more lines) should be really seldom for good named files.

    My problem is this “hard coded” limit. With the “before” layout i have the full control. I see the full file name and if i think it is really to long i can rename the file. In the “after” scenario the program decides to truncate the file name and i can do nothing against it if i want to see the full file name and thing that the length of the file name is reasonable.

    An option (at least in gconf) would be really good!

  14. I’m also one of the ones who thinks the existing behavior is better than the new one. Having moved to KDE 4, it’s not going to kill me if this becomes an unchangeable default behavior, but I do really miss it when using Dolphin, and wish I had least had an option to use the current Nautilus behavior. (Also, I guess I kinda care long term in case the planets align “just right” and I end up back on GNOME, but I don’t see that happening, so far.)

  15. I’ve always hated this filename truncating that I’ve seen on some other file managers. Having to hover over the filename or to select it to see the full filename is a huge pain, especially in directories where there are a lot of files, that differ only in the last characters.

    I feel like filing a bug report titled “Filebrowser fails to show filenames”. This is the most important feature of a filebrowser after all. Everything else, including grid aesthetics, is far less important. And regarding the grid aesthetics, I don’t see anything destroyed or preserved, isn’t it just a case of how tall the rows are streched?

    What is your cut-off for this? 3 lines maximum? Does it depend on the zoom level? I can somewhat understand that you want to cut it somewhere, but even six or seven lines look perfectly all right to me, at least in icon view with 100 % zoom.

  16. @pinky: I don’t fully understand what you mean by “With the “before” layout i have the full control.” but did you know about the list view? It should give you a better view to organize files with many different name length.

    I am really thankful that this bug is finally closed!

  17. As someone with more experience working with usability issues (together with “nerds”) than most people, I can tell you that this change is probably more of a disadvantage than an advantage. If you are adding this change because it “looks crappy” the other way, you are doing it for all the wrong reasons. This solution will add excise, meaning users will have to take additional steps to be able to see the filename.

    Maybe the solution is more suited for the “Compact View” mode instead? This could maybe belong better there as the idea of a compact view gets pretty screwed up with long filenames and the old solution. Maybe. It still adds the same problems though.

    The majority of users will probably not appreciate this as the default behaviour… The users hanging around your blog (or on bugzilla) are not “normal & average” human beings. Always think about who will use nautilus other than the nerds and hardcore users.

    Bottom line… This doesn’t seem to add any usability advantage. So usability-wize its a regression.

    All of this is ofcourse just a guess…. But it is well based one. If you did some real user tests, people would probably choose information and information correctness over grid symmetry.

    Good luck 🙂

  19. I don’t know much about the view modes discussed here, maybe because I always used the detailed view in nautilus windows. But the most visible view is the desktop and this looked crappy in my eyes since I switched back from KDE to Gnome 3 years ago. IMHO it is not only usability, but also esthetics being broken – long file names are cut on weird positions and make some words unreadable. additionaly I don’t like to read the whole file name on the desktop, so a BIG THANK YOU for the commited fix!

  20. I’m in complete agreement with Adam. Information completeness is more important to users than grid symmetry in this case.

    How about enabling this only in compact mode?

    When it comes to the desktop, perhaps you could detect if the filename of a file overlaps another icon and if so, ellipsize it. Or maybe not allow placing an icon so its filename overlaps.

  21. I have folders with about 200 files where the first 20-or-so chars of each file name are the same.. Using Windows Explorer its a real pain to find the file I’m looking for, but using Nautilus (before) it was very easy, as it displayed the whole name.

    I’d stick to the “Before” version…

  22. I also prefer the old behavior. Typically, if I create a file, it has a nice short name, but this isn’t always the case with automatically-generated files, or with files downloaded from others. I agree with Adam that filename completeness trumps grid symmetry.

    Incidentally, to make sure I’m not complaining over nothing, I did go and have a look in my own filesystem to make sure I really do have files that would be truncated by the new scheme; I do.

  23. I also am of the ones who think of it as a bad thing.

    Think about photos. You often happen t have lots of photos in a folder with the exact same name, except for an increasing number in the end (that’s the way most photo cameras name the pictures I guess).

    If those names happen to be too long for the limit that was chosen here (let’s say you name your photos “YYYY-MM-DD – WHERE – picX.jpg” where X is an increasing number), then you won’t be able to know the only part of the name that is diffenrentiating those files…

    It sure looks better, but it definitely kills usability.

  24. OK, as usual, it seems there are people who like “the old way” no matter how broken it is (and this is also IMO 😉 So you could just add e.g. a GConf setting and everyone can set how many characters/lines they wish to see before truncating it, where 0 equals “Show this whole file as I have tons of these with the only difference that this ends with 7.png”. Thanks for fixing this!

  25. I think this is a good behavior for nautilus. i hate when too long filename break into a thousand lines, making icons a thousand kilometers far from each other. I have to scroll too much to find my file. On the other side it is quite impossible to read a string 12 chars wide and 6 lines height.
    I think the new compact view is much better to handle this kind of names, and for every other kind of name 🙂 (compact view is always better when file-managing, with some exceptions). However, a gconf option is the best thing for nostalgic. This is my personal user experience, not the holy bible (in which i don’t believe, anyway 😉 ).
    PS I can’t wait 2.24, with full featured tabs and compact view: with this nautilus will become almost perfect…
    @C. Neumair: thanks, you’re doing a great job for GNOME users.

  26. “Information completeness”? Geez, way to oversell the argument. One could equally say that the “information completeness” was improved by maintaining the grid rather than allocating more space and pushing rows off the bottom of the screen.

    This is an improvement. Great job, Christian!

  27. if we compile what has been said so far into a single solution, we (i believe) can get to a point that pleases mostly everyone:

    – the ellipsization should only take place on really long filenames (exact limit to be decided. compact layout may have a lower limit)

    – ellipsis should be placed at the middle rather than end of the file name

    may be this can spare us from another option in the preferences dialog.

  28. I mostly agree with Adam as well.

    Clearly, filenames can become too long (e. g., 10 lines seems too much) which somehow impedes usefulness of the icon view, so some amount of ellipsation seems neccesary. On the other hand, ellipsation of important information is clearly a loss of usefulness of the icon view, things that used to be visible at a glance are now hidden and require manual fiddling *every single time*. This will clearly punish users who made use of the old behvior to give their files descriptive names, and will in the worst case require them to manually rename several years’ worth of file names.

    Increasing the number of lines might be a good idea, 4 lines is a size you can easily hit in normal usage, especially if one zooms out a bit. Using long words is also a big problem, as Nautilus will not split them unless neccessary, which will cause them to not fill up the lines completely and hit the information loss barrier earlier. Increasing the limit to 5 or 6 lines will cover more everyday uses while still stopping overly long file names, and might be a good idea.

    Does it always show the extension? I can’t see it from your screenshot, if not it probably should. Whether it’s the png or xcf version of an image (or, say, a .c or .h file) can make a big difference, and this information will always be hidden first.

  29. This is a crap fix to a stupid bug. Most of the time you have a whacking great icon (which mostly conveys very little information) taking up 3 lines and in order to maintain a regular grid, the solution is to truncate the file name. Why truncate it by removing the end? Why not remove letters from the middle or the front, or just a random selection? Who are you to decide which parts of the filename are important to represent on this truncated view?

    A better solution, would be to use some of the space taken by the icon, perhaps overlay the icon with the text.

    However you look at it, arbitrary truncation is *not* the correct action. This an annoying usability issue with windows (and apparently other file managers), and until every file has metadata associated with it meaning we can store information in a sane manner, we are stuck with putting all our data into files, with names that describe them. The natural way to index a set of similar files is to SUFFIX an index onto a generic description, which when you’re dealing with piles of data may very well be several lines long.

    Why do people in Gnome keep making really stupid usability regressions. Gnome 2.0 started so promisingly in a usability sense. Usability is not difficult, it just requires one to think carefully about the use cases and pay attention to the subtle details.

    That all said, I do very much value the work you put in, so thanks for that.

  30. Seeing alot of people here do not know much about interface design or usability; lets bring up some points that immediately spring to mind when implementing something like this:

    The fact that this solution “overlaps” the icon below when selected adds some very nasty side-effects usability-wize.

    Think about what happens when the top row files have very long filenames and the user selects them. Several rows below could “disappear” making them inaccessible, forcing the user to click an aditional time somewhere outside the selection in order to reveal the other files => more excise.

    There are more problems.

    How to distinguish between two files (when ellipsis is on) that are identical but just end differently ? When implementing an ellipsization feature, it should be “smart”. It has to be able to decide where its most suitable to shorten the filename (so users can find the files without having to click around everywhere). Its not enough to place ellipsis in the middle either, as the same problem might occur.

    Always consider the side-effects that an implementation like this brings :).

  32. Why do you people insist on describing situations that may be easily managed with compact or detail view? Icon view is useful when you are searching “visually” the thumbnail or the icon (“icon view”, do u remember?); for this kind of search the regularity of the grid is much more important than the file name, IMO. If you find two or three identical images or text document with different extensions, well i don’t think you will become crazy finding the exact one you are looking for.
    If you are managing so many files by name, then icon view is not for you. I don’t say this can’t be improved: i.e. to not hide the extension is a good idea, this is enough for 99% of the objections. Another good improvement could be on the fly filtering filenames, i.e. implementing regexp in the search feature of nautilus: you simply press .*(png|gif) when you are in a folder and all other kind of files disappear 🙂

  33. Sorry i didn’t see the update to the post. The last suggestion is very elegant and innovative if well implemented, but i’m sure Christian will do it the right way or nothing 🙂 Anyway, just unhiding the extension will do the job quite well, IMO.

Leave a Reply

Your email address will not be published. Required fields are marked *