GNOME Bugzilla – Bug 311945
tree view should check for content in dir before showing triangle control
Last modified: 2012-07-20 12:03:21 UTC
Currently the tree view doesn't check if a directory has any content at all (in the case where also files should be displayed) or has subdirectories (in the case where the "only folders" option is selected). This results in the message "empty folder" to be shown in many cases - of course the problem is much worse when the "only folders" option is used. This is fundamentally broken UI wise: You should never show an (active) control, when using this control makes basically no sense. The tree view should check (of course asynchronously and with appropriate caching) when to display a triangle control and add it to the view then. (Note: this is the continuation of a discussion of bug #85141, but which should really reside in its own bug)
OK, this has been 1.5 years now, which is sad. It really seems that nobody is interested in the tree view at all... (I know, don't bitch about a bug, send a patch... sorry, I'm a user as far as gnome goes.)
I agree this is ugly, but IIRC the nautilus devs have said in the past that it's not practical to fix this due to the performance hit of looking for subfolders in every listed folder. (FWIW, the Mac does the same thing; don't have a Windows box here to check what it does.)
Windows works as expected - you will never see a "empty folder" string in the tree. I can't see the mentioned performance problems if it's done asynchronous and a caching is employed. One could either a) start with no triangle and the in the background test the folders and add a triangel for every folder that has subfolders or b) start with triangles on every folder and remove them where appropriate. Of course for a) clicking on a folder will still open the folder directly, check for subfolders and add a missing triangle or for b) remove an excess one. Personally I think a) is the better version by far. With all the pride gnome people have for their famed UI I fail to see how one can miss the stupidity of expanding an expandable folder (which has some files as content but no subfolders) and then having the word "Empty" printed in the tree. I still stand by my opinion that the tree view was completely neglected since the time "spatial" became the hype of the day and is essentially dead today, which is very sad.
(In reply to comment #3) > Windows works as expected - you will never see a "empty folder" string in the > tree. I can't see the mentioned performance problems if it's done asynchronous > and a caching is employed. One could either a) start with no triangle and the > in the background test the folders and add a triangel for every folder that has > subfolders or b) start with triangles on every folder and remove them where > appropriate. > > Of course for a) clicking on a folder will still open the folder directly, > check for subfolders and add a missing triangle or for b) remove an excess one. > > Personally I think a) is the better version by far. a) has a big problem: Imagine loading a very large directory (that will take nautilus some time to process), and you then want to expand directory 'x' when it appears. If the arrows are not added until later, you may be waiting some time while staring at the directory before the button appears. b) is much better, since it avoids this kind of problem. One problem with b is that if someone clicks it, and it just disappears, this is potentially startling and confusing to the user. To avoid this (provided this actually bothers anyone), maybe the (Empty) message could be shown but animated or something so that it goes away after a second (fades into the background and then the space taken by the message is closed up), and there are no surprises to the user. By the way, in the interest of keeping this bug report just a bug report and not some kind of political forum, I think it would be best to avoid using emotionally charged language (talking about pride, stupidity and neglect). I understand that people feel strongly about some bugs, but this is not the place for that kind of discussion.
One could use a dimmed version of the triangle as long as it's not checked which would indicate a place to click for "try to expand if there are subfolders". The background thread could fade the triangles to the full opaque version or fade out to transparent (or simply replace it or delete it, if the animation stuff is crack) Still I don't think in reality there would be a problem with a). If the directory is THAT large, the time it takes to display it is so big anyway that it becomes more or less unusable. With other words: The main killer won't be the checking for subfolders, which can be implemented quite fast. Please see for example comment 21 on the parent bug #85141. It's not that I'm arguing for something that has been never implemented before. By the way, "stupid" or not in a discussion on UI can serve a purely technical role, no need to take this personally.
At the moment (Gnome 2.20 in Ubuntu Gutsy), a triangle is shown AND the string "Empty" is displayed if there is no subfolder. That string makes the user think that the folder is empty... but it can contain files! At least, that string should be changed to "No subfolders", or something indicating that the folder can still contain files.
Thank you for the interesting discussion guys, but ... the parent bug (Bug 85141) was opened 6 years ago! :-O In my opinion, it's really frustrating to browse folders in the tree ("see only folders" enabled) and see that the [now "traditional"] "(Empty)" string is still there, under final folders. The cause of not being still implemented seems to be that there's no agreement on the solution: - Many people like the Mac-like behabiour (the "(Empty)" string). - Many people like the Windows-like behabiour (a background process to remove/add the arrow in final folders). Ok, no problem. "Preferences" were invented to allow several posibilities. Just let the user to choose, by adding some option to Preferences. For example: What to do with final folders: ( ) Show all arrows and, when openning, insert an "(Empty)" string if folder is empty. (*) Show initially all arrows, and check in the background for keeping/removing the arrows. ( ) Don't show initially any arrow, and check in the background for adding the arrows. Personally I prefer the second option (show all & check in background to remove), but I understand that other people may prefer other options. So, let's go on. I'm sure you developers can do this... and much more ;-)
(In reply to comment #7) > Ok, no problem. "Preferences" were invented to allow several > posibilities. Just let the user to choose, by adding some option to > Preferences. For example: > > What to do with final folders: > ( ) Show all arrows and, when openning, insert an "(Empty)" > string if folder is empty. > (*) Show initially all arrows, and check in the background for > keeping/removing the arrows. > ( ) Don't show initially any arrow, and check in the background > for adding the arrows. I strongly disagree this would be an useful thing to put in to Preferences. Preference dialogs work fine as long as they list useful options and are not too crowded; adding an item there just to decide whether to show or not an arrow or a string is really overkill.
Ok, then I strongly disagree with you. ;-) Perhaps showing an arrow/string is not important for you. But usability is very important for many peopple (including me). From the discussion, we can see that there is no agreement on the arrow/string decision. Aproximately half of people prefer the arrow, and the other half prefer the string. Then, what do we have to do? Do we have to vote and, if an option gets 51%, then only that option is implemented? I don't think that abandoning half of people preference will be the correct way. And I don't think we must say "never mind, it's only an usability point, it's secondary". I think that, when there is no a clear majority on what to do, the correct way is to let the user choose. And this can be implemented with Preferences. A little loss in the usability of the Preferences window, may mean a big increase in the usability of the filesystem.
a_64, if you did a survey of the computer-using populace, it wouldn't be 51% one option and 49% the other. It would be more like 0.1% one option, 0.1% the other, 4.8% "why are you wasting my time with such drivel?", and 95% "what on earth are you talking about?". That's why it would be inappropriate as a preference.
How do you know that? Have you done a survey? ;-) Ok, let's supose that you're right (the triangle/string usability point is not important for 99% of people). How do you make a decision on what option to implement? What procedure do you suggest to decide? In this bug discussion thread, we have seen that, for people that care about the usability point, there are two possible implementations: - the arrow updated by a background process. or - the "(empty)" (or similar) string. How do we decide what option to implement? Do we implement only one option? Why only one? (half of the thread prefer one option, and the other half prefer the other option) What's your proposal?
*** Bug 556225 has been marked as a duplicate of this bug. ***
*** Bug 615210 has been marked as a duplicate of this bug. ***
This bug should no longer be present with the latest Nautilus redesign.