GNOME Bugzilla – Bug 331319
"root" icon unclear and confusing.
Last modified: 2009-06-16 20:55:04 UTC
In first using the new gtk filechoosers I was confused by the fact that the path bar displays all the buttons as text except root. The icon itself is too small and inexplicit to convey the idea of a disk (which is inappropriate , nearly always a partition). This is a classic case of obsurity by icons. An icon should be clearer and more explicit than the text it replaces , if not it is detrimental. Anyone using a computer must be familiar with the path separator if they have ever seen a filename. Let's not assume the user has a mental age of 4 and will go running to Mummy full of fear if we put a "/" in the dialogue. The path_bar uses text, let's be consistant . Other information:
Created attachment 59427 [details] [review] patch to display root folder button as text "/"
Please stop this "redesign of the file chooser in 5 easy bugs" effort. Read Owens comment in the other bug of yours. If the file chooser design has issues, these need to be discussed on the gtk-devel mailing list.
http://www.gtk.org/mailinglists.html >>The main point is that bugs should be entered into bugzilla rather than sent to a mailing list, though gtk-devel-list is an appropriate forum for discussing bug reports once they have been entered into bugzilla. >> Federico Mena Quintero asked me to write a patch and submit so I did. http://bugzilla.gnome.org/show_bug.cgi?id=327733 I thought I was doing the right thing here. I noticed that you and Søren expressed sceptisism but wanted to wait to see it in action. Guess you have not had time to take a look yet. It's not a case of five easy bugs. Last time I got some remark about user gripes so I thought it better form to roll-up my sleves and post some patches with the usability bugs. Thanks to a reply I got from Owen, I have created a more general critique of the interface which I posted as a basis for discussion of the overall issues. http://bugzilla.gnome.org/show_bug.cgi?id=331404 Maybe this could the basis for a discussion.
So if I post to ML I'm told to enter bug reports. If I enter a bug report I'm told to user ML. If critisize a feature I'm told to write a patch , if I submit a patch I'm told to stop submitting patches. Finally after 3 years the bug is sumarily closed with WONTFIX without the slightest comment having being given at any stage in relation to my initial critisism or the solution I provided. This is not a satisfactory attitude.
Hey, don't take it so bad! I'm not saying all the patches you've quoted should go away, and, guess what, I've read your review of the file chooser and there are many things that I'd like us to implement if we can discuss that. But the present bug was kind of rejected by Matthias and I don't think it's a good idea either; the patch is not really an important work (4 lines commented out), and nothing has evolved for three years. Now, if you really want us to keep it open, please do - I'm not sure that will help things getting done. Generally I guess you know getting patches for the file chooser in is slow and risky; though most things get committed if you pass the maintainer's test, insist and fix your work. If you want to wake up an(other) old bug so that we fix it together, please subscribe me to it, I'll be glad we try!
Hi Milan, thanks for your positive approach. Yes, I have noted over the years that the filechooser can be harder to change than national energy policy ;) It has some good features but is still not the most ergonomic interface known to man. It's one of the things that most often gets in my way in my daily usage which is why I decided to dedicate some time to trying to improve it. Many of these usability improvements are very simple and can be done without large scale redesign. Some of the suggestions and patches I posted finally got through (like the full width path bar) but outside input is not generally very well received here. As I detailed in #10 which ever way one goes about it , it's the wrong way. Mattius did not reject this patch. He did not even comment on it, he told me to stop posting these small improvement patches. My review of the overall design assumptions of filechooser got similarly short schrift. If nothing has evolved in three years that's why. Now if someone can tell me how the current icon, which looks like an envelop to me, somehow indicates the root of the fs tree better than "/" there may be some discussion and maybe there is a better solution. In any case the current "obscurity by icons" solution is poor. The only reason I suspect it is something like the root is the fact that it's on the left. A blank box on the left would equally (un)functional. Seriously, I'm not being sarcastic. I admit I got rather tired with the whole process. I don't mind investing my time in identifying solutions and submitting patches. However, I don't wish to have to follow that up by a sustained political campaign to get things accepted. I'm glad you thought some of my suggestions had merit. Hopefully this interface will improve with time. Finally, thanks for bringing this one to my notice. I'd forgotten to add it to my local gtk patch set. best regards. ;)
For the record, I like the path bar's concept, but the implementation based on GtkButtons makes it look pretty ugly :) I'd really like to see if a custom widget would make things better. You know, something more streamlined, with less wasted space due to the bevels. I guess that's a nice one-week project for someone who wants to play with custom widgets.
well I quite like the _look_ of the gtkbuttons but thier bulkiness defeats much of benefit of the pathbar concept. As you say they waste a HUGE amount of space especially when displaying rediculous directory names like "my documents/download files/music/mp3" and such which sadly seems to be part of the linux's desktop destiny to copy all the crap ideas that ever came out of Redmond. Once the path bar starts to scroll much of it's reason to exist is negated. Using gtkbuttons was probably a quick solution that should have been improved on long ago. I believe a custom widget like you suggest should occupy barely more than the equivalent text as it would in a text entry widget. It seems to me that the defining feature of the pathbar is that part of the text can be clicked on and the file window changes to display that part of the path. This can be a big ergonomic gain , the equivalent editing of an address bar being at best : click-drag-select;backspace;enter. The essential point is that it should not go into scroll mode since this requires extra mouse movement and clicking which largely negates its main interest.
Just to voice a dissenting opinion here, there is quite a bit of value to make something that behaves like a button also look like a button... Sure, a scrolling pathbar is less than optimal. But scratching a few pixels out of each pathbar element is not going to buy you more than a few characters at best. And making the filechooser work well for navigating deep hierarchies efficiently is going to take more radical changes than that...
>> making the filechooser work well for navigating deep hierarchies efficiently is going to take more radical changes than that... >> Well long directory names make the problem manifest on not-so-deep hierarchies as well. In fact it is not really adapted to "navigating" at all. It assumes you only work in one or two directories. This lack of effective navigation is the biggest shortcoming of the current filechooser. Most of the other flaws are knock on effects of this fundamental limitation. When there is a willingness to consider such radical change please let me know , I'd be interested in contributing. However this discussion is in danger of drifting seriously off topic: whether the current root icon effectively communicates what it represents. regards.
Created attachment 136761 [details] Mockup for sexy pathbar Matthias is right on two counts: * Removing the bevels won't save much space. * Keeping a button's aspect and semantics is desirable. However, the buttons look pretty bad due to excess of bevelitis. There doesn't need to be an up-then-down pair of bevels separating every path component. Here is a mockup that is less cluttered than the current pathbar. For path components that are too long (say, more than the width of two average words), we can ellipsize them. For the look of scrolling... well, that's left as an exercise for the reader :) This would take custom drawing, but I hope we can make something that doesn't look bad even when it doesn't match the current theme 100%. You don't even need bevels that match the theme --- simple, rounded corners for the exterior, and diagonal separators inside, are enough. You can make the whole thing a solid color with something else for the separators. The main points for the visual aspect are these: * The pathbar is visually contiguous. There is no visual separation between path components. * Path separators are *diagonal*, and are drawn slanting left or slanting right depending on the direction of the user's language. This is so that people who know what pathnames are will perceive something that actually looks like a path. * Path components that are too long get ellipsized to a standard width (pick something reasonable; the width of two average words sounds about right). And for the behavior: * Clicking on a path component takes you to that directory, as usual. * Dragging a path component drags the URI up to that component, as usual. * Bonus points for "Copy folder name to clipboard" in a context menu. If you create a git branch somewhere, please point us to it so that we can follow the development.
I like the idea. If each element changed visually on mouseover it would accentuate the idea of an active element. I don't much like the idea of elipsising dir names. I hate long names but if someone feels the need it maybe pretty unhelpful to chop them about. I think there has to be a scroll mechanism. It could jump one segment at a time or smooth scroll if animations are on , similarly to what is done now.
> * Path separators are *diagonal*, and are drawn slanting left or slanting right > depending on the direction of the user's language. This is so that people who > know what pathnames are will perceive something that actually looks like a > path. I know what pathnames are, but I only perceive this as an attempt at being overly cute. Better keep it straight, if you ask me.
And just to make the bar for using a custom widget a little higher - needs to be fully themable (including details like focus indication) - needs to have keynav and a11y support
(In reply to comment #13) > I know what pathnames are, but I only perceive this as an attempt at being > overly cute. Better keep it straight, if you ask me. Bah. Cute is the new black. Yet another alternative is to borrow some ideas from the old Irix file dialog: http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi/0530/bks/SGI_Developer/books/UI_Glines/sgi_html/ch09.html#id43846 (In reply to comment #12) > If each element changed visually on mouseover it would accentuate the idea of > an active element. Sure; this can just reuse the GtkStyle's colors. > I don't much like the idea of elipsising dir names. I hate long names but if > someone feels the need it maybe pretty unhelpful to chop them about. It may be better to show [/home/federico/Documents/ridiculously lon.../blah] than [/home/federico/Documents/ridiculously long directory name/blah] if space is limited. Ellipsizing lets you avoid scrolling. People *do* use long names for directories. My wife has stuff like Documents/School year 1/Theory of education/Final assignment. > I think there has to be a scroll mechanism. It could jump one segment at a time > or smooth scroll if animations are on , similarly to what is done now. Right now, path components that don't fit on the rightmost end are just not shown. So you get [<][Documents][Gnome] [>] if you are in /home/federico/Documents/Gnome/Architecture/html. We did this, I think, because just chopping the rightmost button looked ugly. But if you have an integrated, continous appearance for the pathbar, you can certainly use all the space for scrolling without special cases for hiding anything.
I don't think that's being cute, I find it quite a good visual indicator. that something called a pathbar actually look something like a path seems like a positive design feature to me. The fact that this can work equally well with other systems separators is very convenient.
Yes things getting truncated to look like there's nothing after is definitely bad. A bar like you suggest could scroll one letter space at at time if the whole image was composed in one go and the pathbar was a view port on it. That , operated by the mousewheel would be a lot more ergonomic than the arrow buttons at the end popping in and out. Also arrow keys for disabled access or challenges hardware with no scroll wheel, then enter or spacebar to go. Scrolling like that would be fast, especially for long names. Just as important it would be smooth so that the eye can follow it without having to mentally readjust as things jump about.