A lot of waiting and criticism has being wasted on Gnome/GTK’s new file selector window. I decided to give my two cents on how I would personally perceive a good GTK+ file selector and make an honest suggestion. Special thanks to Tigert who gave me the motivation to work on this earlier today. First of all, make sure you check the mockup on the right so you have a visual representation of its explanation below. The FileSelector consists of five logical “departments”: The Shortcut location/places, the preference/actions of the window, the main file selection widget, the (optional?) Search/filename input box and the Cancel/Open buttons.
1. Shortcut Location/Places
Obviously, these are shortcuts that are leading to common places. They are in alphabetical order. Clicking to each of these will update the main file selection widget below it. Resizing the window horizontally, the application should have some code in it to make calculations and place 2, 3 or more rows and re-arrange the icons on the fly (however, it shouldn’t be common for people to resize the window horizontally as much as they will vertically). These are system and user-defined shortcuts – should be as easy as drag-n-drop to add some new ones. My shortcut suggestion has the exact same properties/features/usage as the original vertical one (it can show scrollbars, it can be resized to show more icons etc etc). The only differences are that it has columns in addition to rows and that it ain’t on the left hand side as traditional file selectors.
The question that everyone asks by now is probably “why did you put the Locations widget above the main file widget and not next to it as seen on OSX, Windows or KDE?”. There were two main reasons for this:
a. This widget includes supposedly the most common places, therefore chances are that people will reach for it. If users won’t reach for it it just means that we didn’t do a good job including the right shortcuts in there (when Storage is ready, some “clever” code should be added there too). So, if done right (and it should be), the shortcut widget should be the first to be encountered by the user.
b. The shortcut widget modifies the main file widget. It can also be perceived as rows and columns of “tabs” that each have its own content. When I modified Tigert’s original mockup I had trouble placing the other widgets like the “new folder”, “show all files”, “filename”, the “up” and the “combo box” in my test window. I didn’t want to put these widgets on the same vertical orientation (above or below) as the shortcut bar because they are not related. For example, clicking on the “Up” button at Tigert’s mockup doesn’t change the shortcut list below it, but the main file selection widget. This way of placing the widgets was not making it clear as to which widget modifies what widget. So, the shortcut bar should go away from being in the midst of all this widget jungle and in fact, it should be given prominent place because it should do what it is supposed to do well. Hence, it goes up there first.
More about the shortcut list being in this location read towards the end of this article in my update.
2. Preferences/actions
The fourth logical area of the window includes a mix of preferences and actions. The “New Folder” is an action, the “Show All Files/.doc/.xls/etc” combo box is a mix of an action and a preference (mostly a preference though) and the “View as List/icons/etc” is clearly as preference.
3. The main file selection widget
The file viewer area is the same as Tigert’s, but I just added the Size column. Nothing truly new to see here.
However, where the big change takes place is above the file viewer area. I have completely ditched the “Up” and the “PATH combo box” because these are legacy ways of navigating, plus they are confusing and fill up the interface. What I added instead, is the Path Navigator (first seen in Path Finder).
The Path Navigator adds auto-magically a new mini-button to the bar each time you navigate into a new folder. For example, the current folder is the “Photographs” in my mockup (its button is selected). Now, if I navigate through to the “Flying” folder, a new mini-button will be added there, named “Flying”, and it will be visually focused. If I run out of window space when the panel will keep adding new mini-buttons for me as I move deeper inside a folder tree, there are two arrows left and right to help me move to next/previous folder (however it will be faster if I just keep clicking the outmost left mini-button each time if I want to go fast to the / folder in case I am currently 10 or 15 levels deep). This should work well for most common usages. For outrageously nested folders, well, even the combo box wouldn’t be a great solution either (the real solution to this problem is to not use a hierarchical filesystem at the fist place, there is no way around it).
Now, if I want to go back to the folder named “tigert”, I can do it by just clicking its button (which it now gains focus). The folders I have already navigated earlier which they live inside “tigert” (My Documents, Photographs and Flying) they stay open until I press a new folder that lives inside “tigert” but it doesn’t follow the same tree. For example, if I now click the folder named “My Music” which lives inside “tigert”, the “My Documents, Photographs and Flying” buttons will go away (because I am not on that tree path anymore) and they will be replaced by “My Music”. This is great for usability, because if I had hit by mistake the “tigert” folder, I could always go back to “Photographs”, cause its buttons will only go away if I choose a new tree path.
The Path Navigator eliminates the need for the “Up”, “Back” and “Next” obscure navigation buttons and instead lays out the whole path to the user to let him/her select easily the destination he/she desires (and cleans up the interface from weird arrows all looking at different directions). Path Navigator also eliminates the very ugly/obscure old-style combo box with the not so user friendly paths (e.g. /home/tigert/My Documents/Photographs) which could end up have many options after you drop down its box, and all options would look the same except the last nested folder. But the most important reason why the Path Navigator should be used is because it is “spatial-friendly”. As you might know, the new Nautilus for Gnome 2.6 will be spatial, that is, each folder/file will be an “object”. Path Navigator’s buttons also look and behave kinda like objects. You click a mini-button and you go there, you do not “navigate” in the traditional sense of file managers. It would be nice to have both a spatial Nautilus and a spatial-friendly Open/Save Selectors for consistency’s sake (plus the added usability and productivity Path Navigator brings as I described above would rock).
View a live demo of Path Navigator. The video is an Mpeg-4 clip (3.8 MB).
4. Search/filename input box
In the risk of having a few thousand Unix traditional users cursing at me, I decided to leave the “Filename input box” in. One of my test mockups had it in only as optional, but I understand that it is not yet the right time to ditch it completely (soon my friends, soon…).
As you can see, I have renamed the “Filename” to “Search”. This is because, fundamentally, the action it does is a search. The input box should work both ways:
1. When a user types “DCS”, automatically the main file selection window should select all files/folders that start with “DCS” (if an application does not allow more than a single file opening at the time, it should be programmed this way via GTK’s API).
2. When a user presses the TAB key it should auto-complete the file(s) and select them to the main file selection window (almost as it works currently).
I believe that the Input box is a very legacy way of doing things and in the future it should be deprecated from the UI. When the main selection widget is focused and the user types fast “DCS” in that view (without the use of an input box) it should provide the exact same functionality as the input box does today. However, this second way has a discoverability issue and so for the time being it might be good to leave the “Search” in the ball.
5. Cancel/Open buttons
Nothing new to see here, move on.
The logic behind the layout suggested above is the following:
1. Select a destination from a predefined shortcut list. [optional user action]
2. Setup the way you want to view the outcome of the above action. [optional user action]
3. Select the actual file(s) you need.
4. Haven’t you find what you need? You might want to try our suppa-duppa search facility. [optional user action]
5. Decide what you want to do with the file(s).
My UI suggestion’s logic is from “top to bottom” without forcing the user to “move his brain pathways” (sick) from left to right and then up and down to do the default action. It follows an intuitive and user-expected flow.
That’s all folks. I think this suggestion is different enough from anything else out there today to ensure some “differentiation” from competitors and I believe it could end up being a very productive way of doing things.
It took me about 45 minutes to design this file selector (I didn’t have time to fully HIG-ify it) but more than 1.5 hours writing this article (poor man’s “specification”) for it. Blah.
UPDATE regarding the shortcut list being on top:
If you start perceiving the shortcuts, the main gtk filesel widget and the input box as “Locator widgets” (they lead the user to a place when used), it makes no sense why the shortcut list would be on the left, the main widget on the right and the search box under it. The search box should have being in the right as well on this line of though, and that would indeed look really ugly.
Additionally, when a user resizes the open/save window in any direction (it should be allowd to resize) my shortcut list can benefit immensely and show more shortcuts just by being on top rather on the left and also because it has columns instead of just rows. You see, in the traditional shortcut list on the left side the user will only benefit after resizing the window vertically. And even in this scenario, he would see one new shortcut at the time, while in my case, at least three shortcuts will be revealed in one resizing step! So this is more viewing area and space for these shortcuts.
Similarly, in the very common case where a user only uses the default 5-6 shortcuts, by resizing tigert’s window vertically you end up creating white space in the shortcut list. Wasted screen space. In my suggestion, this scenario would almost never happen.
Some people said that the vertical window looks odd, but as I explained above, its layout makes sense and requires less “hops” for the brain to follow the order and it can offer more screen area for the widgets and is more intuitive for new users even if it doesn’t look as aesthetically pleasing for what people are got used to so far using Windows or OSX or KDE. At the end of the day it is a trade off between usability and looks and I chose usability for this particular instance. Besides, innovation comes when going against the tide even if it might not feel as intuitive at first. 😉
UPDATE 2: I created a new mockup (look at it here) to show that my version can also be made wider as 4:3 aspect ratio (however I still maintain the opinion that my original mockup is best that this one). All a user has to do is just resize the window and have GTK+ save a GConf key to remember all Open or Save windows’ desirable sizes.
This really should be implemented, it’s beautiful and intuitive! Perfect replacement, I’d say.
This is very creative, Eugenia. You should be a Gnome developer. They really need a creative woman’s touch. In fact, come to think of it, along of UI programming needs that.
The great thing about the new gtk file selector is that it is completely modular – you can switch between tigert’s and eugenia’s. Someone should make a setting to allow one to choose (or, atleast, a gconf key). Although i initially thought this selector was a bit weird, its actually kinda nice. But, I think the file type should be on the bottom, by file name. A bit more intuitive. And the buttons for path look a bit weird, although possibly very useful.
But, is it HIG compliant (this isn’t a joke – HIG-stuff normally looks very nice – just look at gimp 1.3: all HIG, all beautiful)
True, HIG is very important.
I hacked it up a bit. Have a look:
http://www.gnomepro.com/gtk-file-sel2.png
I am sure that Federico will come up with something brilliant that impreeses us all! 🙂
Whatever you do what the GTK file selector PLEASE KEEP THE TAB-COMPLETION funcionality. Yes, new users don’t care about it. But I bet that experienced shell users apreciate it. Personally, I love the file selector over the rest. I don’t care a lot about the UI, I just know that the gtk file selector is the only one that does it. I appreciate it a lot. I’m used to things like /us<TAB>sha<TAB>, and there’s no mouse in the world that can be faster than that.
Nice one Erick.
Is fileselector only meant for opening files or is it also used for saving files?
For saving files as well.
Eugenia:
In the risk of having a few thousand Unix traditional users cursing at me, I decided to leave the “Filename input box” in. One of my test mockups had it in only as optional, but I understand that it is not yet the right time to ditch it completely (soon my friends, soon…).
That makes sense for an Open file selector, but what about a Save/Save As one? How would the user specify the filename?
Other than that, it looks/sounds pretty good.
> That makes sense for an Open file selector, but what about a Save/Save As one? How would the user specify the filename?
Yes, indeed. I created my mockup mostly working on the “Open” side of things, carried away by Tigert’s title on his mockup.
and.. if it’s only for opening files, why is there a big new folder button (which I always bumps into)
You mention the pathfinder-like navigation buttons “gain focus” when selected – tell me you didn’t actually mean that? Focus should be given to things where users are actually going to use the keyboard, like the path entry or icon list. I think what you meant is that the button for the current directory should be visually highlighted in some way, so as to make it clear which directory the user is in. That isn’t focus, in X terms, as focus includes also keyboard input.
It just doesn’t work for me. It needs something. I’ll stare at if for a little while longer.
just a quick note, you *must* (i repeat, *must*) have buttons for adding and removing items to the shortcut list, because there are people who are unable to use drag-n-drop, and context menues are not discoverable.
that said, I like erick’s modification with the shortcut list on the left. one thing to remember is that windows which are wider than they are taller are more aesthetically pleasing, due to the shape of our screen. the “Favorite locations” label is also nice. again, tho, those “helpful” drag-n-drop labels should be gotten rid of, and nice clear (and accessible) Add/Remove buttons are needed.
so far as saving, i believe (not sure) the new API is capable of changing the UI based on whether an open or save operation is being carried out, which is a *good* thing. it is also hopefully capable of changing the UI based on whether a file or directory is being selected. (for example, personally, i’d like files to not be shown when selecting a directory, at least by default, and have the option to show them in the event I need to select a directory that has a certain file and somehow manage to forget my nice clean folder layout.)
>> That makes sense for an Open file selector, but what about a Save/Save As one? How would the user specify the filename?
>Yes, indeed. I created my mockup mostly working on the “Open” side of things, carried away by Tigert’s title on his mockup.
Ah – I figured it was either that, or you’d been reading that Pavel Cisler interview where the talks about wanting to eliminate file save dialogues altogether
> and.. if it’s only for opening files, why is there a big new folder button (which I always bumps into)
It is mostly a historical remnad. Sometimes people might want to move a few items around in a new test folder (or duplicate a file) and then use that instead of using the original file. It is not a very common action, but it happens to me, mostly when I work with PaintShopPro and graphics.
> I think what you meant is that the button for the current directory should be visually highlighted in some way,
Yes, this is what I mean. Visually focused to be distinguished by the other buttons. I am sure most people would understand what I meant there.
An important feature lacking in many file-selectors is multi-column view. If one can see only a single column of names, then it may take a long time to find the needed file. By contrast, when a file selector is maximized, with multi-column view one can get a panoramic view of all or many files in the folder. Let us hope that GTK-2.4 file selector will include multi-column view and other features and options that make finding files easier.
I miss the back button..
If I use the nice path buttons it’s ok, but if I accidentally push one of the shortcuts, I need a way to get back to where I was..
Sounds like some good suggestions.
I also remember once that you criticized the KDE file selector, can you write up a similar little article, for me it sben great and I haven’t seena ny usability problems except that in soem view modes it wont seem to remember on 3.1.
It would be great if you could do this, you seem to have an eye for this stuff and kde-usability alwaysa appreciates constructive criticism.
>the “Favorite locations” label is also nice
I believe that it is not needed. You don’t give a title to the main file selection area either. These should be intuitive enough.
>you *must* (i repeat, *must*) have buttons for adding and removing items to the shortcut list
If there are people who can’t use drag n drop, the toolkit should offer a mouse driver that allows that (e.g. click the fourth mouse click to select a file, navigate somewhere and reclick that button to drop it). The accessibility should be in the toolkit level in this instance, not in the UI level necessarily.
> I also remember once that you criticized the KDE file selector, can you write up a similar little article
There is no reason to write a similar little article. Just rip this idea and move it to KDE if you need to. It would work regardless of the toolkit.
There is a line dilineating between the two main columns on the window (between “Favorite Locations” and the main file selector area) that intersects with the line that separates the “Cancel” and “Open” buttons from the main file selector widget. This intersection makes it seem a bit more cluttered than the other two mock-ups–notice how the other two have a distinctly separate area for “Cancel” and “Open.” Just an observation.
Something just isn’t “right” with protrait windows. I don’t know why, but I don’t care for them. Maybe because monitors are landscape?
I like the shortcuts on the side and especially the “Drag folders here” option to add your own shortcuts.
I do think that the proper place for the “view” and “show as” buttons is above the list, since the actions work on the list rather than the filename.
The search input box confuses me. Filename makes sense and 100% of the users understand how the normal “box right there” usually works.
I don’t understand why there is a separator between the open/cancel buttons and the filename. When used as a filename box, having these as a unit helps tell the user that this button works with that filename.
Just a few thoughts. Thanks guys.
Mutiny
I like Erick more..
Re: Audun – Back button. I second your comment. Add it to the Erick’s mock would be perfect.
I think its pretty spiffy, but I’ve got a few gripes:
– You turned the path input box from a something you could type in to something you have to click. I use that feature pretty much exclusively. Who wants to have to click through all of those folders when you can just type the path into the box?
– I like the location bar on the left, just for asthetic reasons.
Otherwise, it looks very cool.
Like tigert, I would leave the size column off of the file selector. I don’t think file size ever has much to with opening a file in an already open application.
Erick’s mockup has a more traditional approach. Many people are just used to it because all other OSes use this paradigm. The two mockups do not follow the same logical flow (on Erick’s mockup you go from left to right and then down-down while on mine is a simple top-down – you need to use it to feel the difference).
>Back button. I second your comment
There is no need for a back button. Bloat of the interface just to go around a possible/rare user error.
Loved it. Hope the GTK people will see this one… i kinda liked Erik’s more, but maybe it’s just me…
Victor.
I like Eugenia’s a bit more. Simpler layout.
Indeed the result is nice. But so are lots others in different OSes. But I think that the best design comes from expressing visually the process of opening, saving etc… of files and firectories.
Now although I linke what I saw I see that one bill does not fit all.
So I think that it would be best if the layout and usage of components would be scriptable. Then create 2-5 most used scenarios and name them. Then allow developers to extend them or rewrite the script if they need that.
I think that would be a perfect file chooser.
> There is no need for a back button. Bloat of the
> interface just to go around a possible/rare user error.
Unfortunately, I use back/forward buton rather often.
Regarding Erick’s Mockup:
I agree with the others who have questioned the separator between the files and the open/cancel buttons, but I LOVE the “Favorite Locations” label and the “Drag & Drop to add…” those were the first things I noticed! If you have enough favorites to fill the window you won’t see the labels, and if you have the stock layout you have the white space there anyway. Best to put a little explanation there! I also prefer the landscape layout to the portrait one. I can’t fault Eugenia’s logic though.. The vertical does make more sense; I just like the look of the other better.
>Unfortunately, I use back/forward buton rather often.
These are implemented with the Path Navigator widget. Read the article before commenting. What these readers are asking is a “back” button after have accidentally clicked something on the *shortcut* list, not in the main file selector widget.
Same here, sometimes I do type the path by myself because it’s quick task. Well, everything what you have said and I agree.
1. Folders should be seperated from files
2. we are moving from 4:3 to 16:9, so it should be wide not tall
3. drop the “View as” button. “View as List” is enough for an open/save window. It’s not a full blown file manager here.
The window should be like a mail client view: left shortcuts, up right folders and down right the files themselves.
I wish I was good at making mockups.
Seems to me that tabs would do a better job of reflecting each level of the path as a separate view into the filesystem. Kind of the same way radio buttons imply only one of the available choices, tabs imply that you are switching between views.
I think one major problem that people have is that they “click on a button and everything changes.” The more tightly we can tie visual clues to changes in sections of the interface, the better.
As far as top-down vs. shortcuts on the left, I’m not sure your argument that there’s better flow is really valid. It seems that the favorite places is an optional part of the saving or opening process, and so putting them off to the side is as logical as anywhere else and takes better advantage of screen real-estate.
I really don’t care how they do it percisely, so long as there is the ability to customize ths shortcut list – that’s important. I hate not being able to customize the shortcut list in the Windows Open/Save file dialog. (I can customize it by picking from a static list of locations using TweakUI, but I can’t add my own.)
I made a few changes based on feedback here. Both are now included in the original image. Check it again, if you want to.
http://www.gnomepro.com/gtk-file-sel2.png
> Seems to me that tabs would do a better job of reflecting each level of the path as a separate view into the filesystem.
Yuk, no please. They are big and fat and ugly.
It’s probably not a good idea to label the filename field as search, for a couple of reasons.
First, what about when the dialog is being used to select multiple files. That field should ideally do similar to what Windows does, and contain multiple file names. Search wouldn’t make much sense if a user was control clicking on individual files to choose multiple files.
Second, it’s fairly vague to say search. We search for all sorts of things… does your search box search Google? I know that’s absurd, but really, does it search the entire directory structure? Does it search recursively through the visible folders? Basically, it’s not very concise to say search, especially when the window has the primary purpose not of finding files, but of choosing files.
Another thing I might mention is that a dropdown box isn’t really much more difficult than the path selection buttons… although the path selection buttons are pretty cool. With the dropdown box, you click, then move the mouse to select the proper folder, and then click again. Once you get to a path that is deep enough in terms of characters, the path buttons are going to require a click or two, then moving the mouse, and then another click. So, I don’t really see much benefit… in fact, it makes the file selector look more cluttered.
It looks much better, I like it. 🙂
…just don’t change the file locator from “filename” to “search”. If I wanted to search for a file, I could use the gnome find utility. More often than not, users who use the file selector know what file they want to open/save and where it is located. If not, they could use the find utility as mentioned above. It would be a usability error to replace “filename” with “search”.
Good job Eric. I’d be pleased if the new file selector looked like your latest mock up. And let’s hope it will continue to be a work in progress.
Nice mockups. However, a comments on Eric’s and Tiggert’s:
Does it make sense to have a “Favorite Locations” _and_ and “Bookmarks” widget? IMHO, only if “Favorite Locations” wouldn’t be editable and this would be horrible.
I can’t stand, for example, the “Documents” item because it reminds me on Microsoft and my first action would be a right-click to get a “Delete item” menu. Same to the CD-ROM item because I don’t open files from the CD-Rom drive very often.
But then an extra bookmarks widget makes no sense.
http://tigert.gimp.org/files/screenshots/filesel-tig2.png
This is the best one I’ve seen.
I personally think that wide screens should mean taller windows. My favorite UIs are those when I can have two windows on screen at the same time, arranged vertically. Wide dialogs always get in my way.
Of course, an Open dialog box is pretty meaningless to me. I haven’t used one in a very long time. And the new GTK API, IIUC, will mean that I can use XDS saveboxes a la ROX instead
>If there are people who can’t use drag n drop, the toolkit
>should offer a mouse driver that allows that (e.g. click the
>fourth mouse click to select a file, navigate somewhere and
>reclick that button to drop it). The accessibility should be
>in the toolkit level in this instance, not in the UI level
>necessarily.
Hmm, what if I can’t do dnd because I can’t use a mouse ?
> Unfortunately, I use back/forward buton rather often.
So do I. Since we are commenting, may I suggest the addition of a “Up” button (I use it quite often).
Hmm, what if I can’t do dnd because I can’t use a mouse ?
In one of the various discussions on DnD and copy and paste in Linux on one of the usability or freedesktop.org lists hosted by Red Hat, someone—I think it was Thomas Leonard of ROX, but I’m not certain (sorry I’m being really vague, but there’s a link to the discussion from somewhere on http://rox.sf.net/ —suggested, accurately in my opinion, that copy and paste should be a synonym for DnD, so that wherever you can drag and drop, you should be able to copy and paste and vice versa.
So if you don’t have a mouse, you should select what you want, Ctrl+c, select where you want to drop it, Ctrl+v. Seems simple and logical enough to me. (I would add that the clipboard should be more permantent than DnD, and selecting something to drag and drop it should only overwrite the hackers’ clipboard (PRIMARY?), not the real one.)
> So do I. Since we are commenting, may I suggest the addition of a “Up” button (I use it quite often).
Please read the article carefully before adding such one more uniformed comment. The Path Navigator eliminates the need for “Up”.
Eugenia you are the woman!!!
Here is what I was talking about:
https://listman.redhat.com/archives/xdg-list/2003-August/msg00128.ht…
Not quite as detailed as I had remembered, but still a good idea IMHO.
Please read the article carefully before adding such one more uniformed comment. The Path Navigator eliminates the need for “Up”.
I just would like an up button icon. Don’t tell me about clutter… In my daily usage it would make my life much easier if an icon was there (preferably next to “new folder”). That’s just my personal opinion (and I did read the article, thank you).
Looks good BTW,
I wish the dev team include a similar file selector “save/open file” dialog.
Great, just when I was about to go sleeping, such an interesting topic gets brought up. :/
Recently, I came to my personal conclusion, that “filechooser” dialogs are pretty much obsolete already. Sure, we still need them, but they don’t really play as much a central role as they used to.
For example when opening a file, in most cases it feels much more natural to navigate to the file via the file manager and then open it like you’d open a folder. Opening a new application just to select “open” and use the mini-filemanager of the application to browse to my file of choice seems more and more awkward to me, even when I’m already working with this application.
When it comes to the save dialog, my thoughts are similar. We still need that one, but I think that the whole concept of “saving” isn’t very logical and basically just a legacy implementation detail. Why don’t we just use our filemanager to create a new document at some place and then use a tool (application) to edit it? There are many reasons why this wouldn’t work well yet, but those are mainly technical reasons, which will be solved some day.
With this in mind, I see those dialogs mostly as a band aid and don’t believe that too much thought should be put into them. Of course we need a reasonably good one for the time being, I just don’t think that it’s important to do anything groundbreaking with them. The way I see them used in the future is mostly for selecting special locations, for example to tell your web browser where you want to have your downloads saved by default.
So, what I’m trying to get at is (Notice that I’m never able to use few words when I’m tired), that I believe that the file chooser should be really simple, other than that I don’t really mind. I think that the mock ups of TigerT, Eugenia and Erick are really nice and I would be happy with either of them, even though I don’t think that anyone of them is really ideal.
What I don’t like about all three of them is, that they don’t really keep in mind the different scenarios. There are basically three of them: Choosing a file, choosing a folder and saving a file and what you want to do differs a lot between those scenarios. For example you don’t need to enter a filename when choosing a file or folder (though die-hard Gtk freaks will kill you if you remove their tab completion), but this is the primary action for save dialogs. You don’t really need “new folder” in the open file dialog, but it’s necessary for open folder and save dialogs. And so on… So I’d really love to see more attention at separating those tasks and actually making use of the possibility to show different dialogs with the new API.
I also have some more doubts specific to Eugenia’s layout.
Shortcuts at the top: There are several problems with this. For one, we don’t have a widget yet which could do this, so it would extremely alien with everything else. I don’t really think that the file dialogs are special enough to deserve their own unique widgets. It would also require someone to actually code it up, which is very unlikely for Gtk 2.4 and maybe the work would be better spent on fixing other outstanding problems.
Another big problem is, that this basically only looks good as long as there are only the few locations. Imaging adding five custom locations and it would look rather crowded and bloated already. A list view is much more flexible in this regard.
Basically the same points apply to the path navigator. While I do kinda like the idea, I don’t think that introducing such a special widget exclusively for the file dialogs would be a good idea. It also makes it impossible to remember the location of the “up” button, the most common action becomes actually harder to do.
Another thing I’m not happy about is placing so much stuff between the locations and the files. This means you have to travel above them everytime, even though they are really optional as you have pointed out. In most cases you will do this to open a file: “Select location -> select file -> click open button” or of course “Select location -> double click file”. Having the locations directly besides the file list makes this faster and also eases drag and drop operations.
If you use the same layout for open and save operations, another thing to consider is that the workflow on save dialogs changes to “select location/folder -> enter filename” or even “enter filename -> select location/folder”. In any case TigerT’s mockup has all the involved elements directly connected to each other, so as long as not different dialogs are used, I think that’s a big advantage.
Also don’t forget that their can be custom widgets added by the application. Eugenia-mockup and Erick-mockup don’t even consider them and it would look it even more crowded.
To sum it up, currently I think that TigerT’s mockup is the most reasonable one, at least for open file operations. I only whish the “New Folder” button wouldn’t be there, the Bookmarks button is completely pointless (should go away) and I’m not even sure about the folder drop down list. Also it’s a pity that the up button is not above the file list but above the locations, but that’s really hard to solve. :/ Maybe the button could be somehow integrated in the file list… Well, maybe something like this could be considered:
http://liebesgedichte.net/Temp/filesel-spark.png
(where the New Folder button would obviously only appear in save of folder selection context)
(and that Parent Folder label is supposed to be bold, but Gimp has another idea of bold than me)
Well, I’m pretty sure that will be shot down anyway for beeing too simplistic, but that’s in fact exactly how I would like it to be.
Placing the New Folder in the button area probably wouldn’t work out for one reason or another, but at least this would make it possible to only show it when it makes sense, without completely breaking the flow.
Uh… good night.
I’m not sure if anyone else mentioned any of this, but here’s my two cents.
A) The bookmarks are too crowded
For this, we will be reffering to bookmarks are ‘shortcuts’ as one, because they are.
The ones on the top are too crowded to be of any use, and the small ones at the center are WAY to small to be of use. The fact that one in your mock-up needed it’s name cut off speaks further about then then I possibly could.
B) Two areas for bookmarks are confusing and unneeded.
In both mockups, we have two areas for bookmarks. In one the second list is under the file lists, and the other has it in a dropdown. This is over-complex, and they should be combined into the one ‘shortcuts’ space.
C) Search
The search lacks a obvious means of activation. If it replaces open when used, then it is over-confusing, if it works on the press of the enter key then the usage is non-obvious. If it constantly updates as it is typed in, then it can and will lead to stress in the user as they watch the files ‘vanish.’ The fact that I do not know how it would work should say something about it. However, if there was a obvious way to interact with it, this would be a good addition.
D) Size column should not be there.
Opening a file is a question of finding a file. Filesizes are useless, and take visual space that should be better used for file names. File sizes belong in a file browser, not a openbox.
Of course, as I say this, I believe ROX has the perfect file open/save dialog. Namely, the file browser. The file browser already has support for showing any directories in any ways, ROX has shortcut built-in already, and a save dialog that is meant to be drag-and-dropped allows for UNIX-style chaining of actions or just plain saving.
>The search lacks a obvious means of activation
It does not require activation. Results are highlighted as-you-type.
I could not see this up button on the http://www.cocoatech‘s path finder screenshots either (but it must be there somewhere…).
http://tigert.gimp.org/files/screenshots/filesel-tig2.png
I believe it’s the most functional because:
1. You know your current working directory
2. With the “locations” on the left, it allows easier scrolling
3. Not is much emphasis on create a “new folder” (since this is an Open File widget.
4. Easily handle file extensions
5. Must I say it, it’s almost identical to Microsoft – which everyone has grown to learn….
I believe Erick’s one is better
http://www.gnomepro.com/gtk-file-sel2.png
I agree. I can’t quantify why, but it has a much more professional, and inviting feel.
that “filechooser” dialogs are pretty much obsolete already…
…
whole concept of “saving” isn’t very logical and basically just a legacy implementation detail. Why don’t we just use our filemanager to create a new document at some place and then use a tool (application) to edit it?
That’s a perspective but you still need a “save file” dialog when downloading a file from the network. Unless all downloaded files go to the /home/mary/downloaded_files by default with *all* applications. Just an example. Open/Save dialogs are quite handy for me.
The ideia of “create it first and edit it and *then* save it within the application” is already a bit in use on the “create folder” before add the files to it.
Ericks one looks very nice
I really dig this. The “Path Navigator” is an awesome idea. The verticalness of it does look a little odd, but I think it is justified.
Instead of having a tab-completed search, the search should be interactive (like XMMS’s jump to file search). Why make users have to hit an extra button? Plus it makes it seem more responsive.
File sizes belong in a file browser, not a openbox.
And if I don’t remember which DSC000????.jpeg I’m looking for, but know approximately what size it is? Hm… that reminds me… they’re all missing a preview pane…
That’s a perspective but you still need a “save file” dialog when downloading a file from the network. Unless all downloaded files go to the /home/mary/downloaded_files by default with *all* applications. Just an example. Open/Save dialogs are quite handy for me.
The general approach to that scenario is to simply provide an icon which you DnD to where you want to put it. Take a look at—sorry to sound like a fanboi—ROX. A ROX app like Edit doesn’t contain an Open dialog box, and the rarely used New command is at the bottom of the File menu (ROX apps have a very different UI from the standard one. I find the stark abandonment of the past very useful), with no toolbar item. When you ask to save the document, you are presented with a dialog box containing an icon representing a text file and a filename text entry. You can, if you feel like it, enter the entire pathname into the filename text entry (e.g. ~/Documents/Random/foobar.txt), or you could simply enter the filename and drag and drop the icon to an XDS-supporting file manager window. Or indeed to Archive, and have it automatically compressed, which gives you a similar dialog for the compressed file. And/or the SSH/SCP wrapper and automatically upload the (possibly compressed) file. (In fact, any program that can accept text on stdin by being called with the – argument will work.) In the case of a file browser, you’d get presented with a savebox which you could then drag to Archive and drag the icon to wherever you want it to go.
[If all this dragging and dropping sound tedious, ROX applications tend to be small and single-purpose, rather than the monolithic applications favored by Windows and to some extent Gnome. As such, they mostly stay out of the way, so dragging and dropping is less of a chore. And as I mentioned in a previous post, DnD and Copy and Paste should be unified.]
Down with mini filers!
Preview pane, yuk! Well, I don’t mind having one… as long as I can disable it.
Personally, I prefer TigerT’s selector, although they’re all good.
Well, maybe something like this could be considered:
http://liebesgedichte.net/Temp/filesel-spark.png
The first thing I’d say to that is the New Folder button cannot go where it is. By putting it there, you’re implying it’ll dismiss the dialog and create a new folder with the name in the Filename box. Most programs wouldn’t appreciate that
Secondly, I do think you need to put some context into where you are. I might have three similarly-structured programs that I’m working on; your dialog would confuse me if the filenames differed by one file in one folder and I forgot which it was, and was trying to find it, and thought I was in a different directory tree. (Which sounds like a lot of assumptions, but it isn’t.)
I’m also inclined to say that Locations bars like that seem too much like folder trees. Perhaps I’m odd like that though.
I saw the “Network” button. Will work on the new GTK file selector?
After comparing (visual only) TigerT, Eugenia and Erick side-by-side, I kinda like TigerT more (initially was Erick). It just… feel right.
> It just… feel right.
No, it just feels “common ground”. This doesn’t make it right. Innovation is not alway intuitive at first, remember.
I made this mockup for the SkyOS contest. I like the tabs for the shortcuts since it makes it easy to see which folder you are in. I also prefer the forward / back buttons to the path navigator as the navigator looks cluttered.
I wuold prefer to just right click on the forward / back buttons, or have a path button like Apple does.
http://www.dmrtc.net/~kvnrvn/sky/Dialog.jpg
Did anyone else think to just let the Gtk and GNOME people handle this?
Of course they will have the deciding vote, but many hands make light work. Seeing as we’re only putting ideas forth but sensible people will veto before they’re all included, too many cooks won’t spoil the broth.
Half the reason to use open source is because people’s ears are stronger.
…that something called ROX exists, and that it is probably the most innovative open source desktop enviornment out there. I hope GNOME steals a few of its ideas (DnD everything and the ROX-Filer system looks awesome, but may just happen naturally after things like spatial Nautilus and GNOME FS become the norm).
Oh yeah… um, defnitely something like Erick’s 2nd model is the way to go. I like the way the “Favorite Locations” panel is labled in the first one though; including that title within the little grey box makes it seem all the more a special little enclosed place of wonder that it _is_.
> No, it just feels “common ground”. This doesn’t
> make it right. Innovation is not alway intuitive
> at first, remember.
Yes, it might be due to “common ground” reason. Because the “common” is the most practical (so far) f/s produced by the industry. Sorry Eugenia, I don’t think your mockup is any near being innovative.
Her mockup is quite good but I don’t really like the bookmarks/favorite at the top of the file selector. It just doesn’t seem right to me. I prefer wide windows to tall ones.
I like it a lot. It’s not a wretched horizontal slider like Windows or KDE. Making the favorites box easy to configure and just one click use is good. I like the Path Navigator, the combo box is difficult to use and you have to click a bunch of times to get where you to go.
I agree with whoever said the “View as List” combo box was not needed.
Also I agree with the people who say the “Search” is a bad label. It would be nice if there was a “Search” button that brought up a GUI interface to the `locate` command.
I like the path buttons, but I think I would prefer the URL bar if it were just clickable text with unclickable slashes. It would be like a URL type thing. The reason is that when I first saw the buttons, I didn’t realize it was a path. (Also I like UNIX pathnames. In Windows people ask me for help because they saved things in a folder but don’t know the path to the folder to open it back up.)
The “New Folder” button is not necessary. Even if you create a new folder, how would you move stuff into the folder?
I didn’t want to say this, but I have to agree with the people who like the “Favorite Locations” on the side. When it’s on the side you would use the extra space to display files. With the Favorite locations on the top if you want to add a seventh favorite then you either need to add a third row or you need to add a horizontal scroll bar. I really hate horizontal scroll bars. Also when the favorites are on the side, there is always one spot empty slot at the bottom where you can have a label “Drag and drop folders here”.
Instead of a “Show All Files” combo box, I would prefer a “Show All Files” button that became a “Hide Hidden Files” button after it was clicked. (That text is too long for a button, but something to that effect would work).
Anyway, if Gnome used your suggestion as is, they would still have a better file selector than anyone else.
> With the Favorite locations on the top if you want to add a seventh favorite then you either need to add a third row or you need to add a horizontal scroll bar.
No, you don’t need a horizontal scroll bar. You would need just a third row. But don’t forget that the default size of my shortcut list has the same properties as the side one. It can hold the same amount of icons as the default side one, this is not a problem. As I wrote in the article, the two shortcut lists share the exact same features and properties, only their location to the window differs and the fact that you don’t waste screen space when resizing the window.
And if I don’t remember which DSC000????.jpeg I’m looking for, but know approximately what size it is? Hm… that reminds me… they’re all missing a preview pane…
This is why a open box is too limited, and is a broken UI idea. In reality, you shouldn’t be using file names for that at all, but thumbnails.
But beyond that, there shouldn’t even be a list of image files that you remember by file size. Most users will not use file size as a means of memorizing a file’s location. They will, however, use a name. File sizes which would be useless for 9/10ths of a users work and only good for poorly-named saves from (if you have a list of files like that) broken programs are inexcusable.
Of course, the way I see it instead of having a open box, imagine a file browser open, and just dragging the image you want, listed as thumbnails with any extra info you wanted, into the app. This is what should be happening. Heck, although it’s really broken right now (it’s really kinda earily, and just grew out of a want for the KDE slide show app
), but that’s what my image viewer <a href=”http://rdsarts.com/code/picky/“>Picky does. You open a ROX filer view, and can drag a image to it to view it. You drag a image to the icon of the GIMP to open it. You drag it from ROX to a open instance of the GIMP or Picky, and it opens it for you. This is how it should be done. When you work this way for five minutes, you see how natural it feels, and you find youself wondering how anyone can do things any other way.
And.. I think here’s where I drop it before I get too off topic. ^^;
…that something called ROX exists, and that it is probably the most innovative open source desktop enviornment out there.
Well… many of ROX’s principles were taken from RiscOS. That’s what the R stands for (RiscOS On X). RiscOS was (and still is, there’s a few articles post here every now and again on it), apparently, a heavily drag-and-drop user interface, with saveboxes and no menubar and apparently it was RiscOS programmers who put the context menu into Word, or so I’ve heard. It’s something of a pity if even the most innovative open source desktop copies many of its ideas from others, but on the other hand: If something works, you’d be a fool to let it rot.
I love this. People actually inovating. I think all these
ideas look good.
<p>
Now for my observations.
<p>
I’ve always thought the Windows filebrowser has been a huge
waste of screen real estate. When browsing a directory with many or few files there is a rectangle on the left that is almost always completely blank below the dir/file info. I say avoiding blank/wasted window space is extreamly important.
<p>
P.S. I have not had MS on my desk at work or home since 1988.
Please don’t turn GNOME into a MS Windows clone!
add a back button to Erics suggestion, then it fits perfectly my needs! go Eric, go …
– are –
I guess it looks okay but who says that we will ever implement storage? Are we doing that just because the dictator Monopoly is doing it? What value does it add?
Eugenia’s design is clearly far superior probably to any file selector out there. What could be more quick and intuitive than a logical series of steps from top to bottom to accomplish the task of selecting a file? The other selectors are *awful*. Blast the “navigation” buttons into the center of the Sun — they are *so* confusing (what the f**k does “Back” *do* anyway?!?)! Don’t put the shortcut bar at the left, put it at the top! The first step in selecting a file is selecting the general location of that file. And putting shortcuts in a vertical list gives the impression that each shortcut is “beside” its neighbors, which is totally *wrong* and destroys the user’s spacial orientation.
Eugenia: please, *please* push hard to make your ingenious top-down design the default file selector in GTK!
Thank you for your comments.
> Eugenia: please, *please* push hard to make your
ingenious top-down design the default file selector in GTK!
I am trying, but it ain’t easy for everyone to understand the strong points of this design by leaving behide their own legacy and think out of the box. When something is so different it is normal to meet resistance. You are welcome to join the cause though
I think the only reason Eugenia’s looks weird is because it is in portrait. If you took Eugenia’s model and resized it to have a wide aspect ratio, you’d end up with a top shortcut bar of only one row and five (or six) columns, a wider view and a prettier dialog.
As someone mentioned earlier, wider looks better, especially on computer screens. Apple knows this, look at their monitors.
Does anyone else think these are in the wrong order?
Most times we will want the open (or save) button, and the majority of the world still reads left to right…..
So how about the most used button goes to the left of cancel.
I believe this is a fairly common convention amongst OS’s – why change it now?
-david
>I think the only reason Eugenia’s looks weird is because it is in portrait.
Just created a new mockup to show that my version can also be made wide. All you have to do is resize the window and have GTK+ save a GConf key to remember all Open or Save windows’ desirable sizes. Here it is:
http://www.osnews.com/img/5582/filesel-wide.png
Some interesting additions to the path navigator idea can be gleaned from the Windows Longhorn PDC Build. Longhorn folder windows have a breadcrumb bar very similar to the path navigator at first glance. It has a button for each folder in the hierarchy and arrows at each end to scroll horizontally. There are two additional features:
– The folder buttons behave like most browser buttons in that clicking the little down arrow next to the text gives you a list of other folders at the same level as the one represented by the button. This makes for a sort of Mac OSX-column-browser-in-one-row.
– The right hand arrow IIRC is all the way to the right of the window rather than directly to the right of the last folder. If you click in the empty space in between, the whole breadcrumb bar turns into the old style address bar where you can type in path names like in the olden days.
Nice looking mockups all around.
Eugenia, your mock up way too clutered. The main cause is the location widget being above the main file widget. You say that people should see it first, but since most people read left to right they would see it first anyway if it were on the left like every other.
Also it is easier to hit the buttons if they were all line up on one axis. I would much prefer to just move your mouse up and down, and not up and down AND side to side.
This is why most people don’t make their Windows task bar more that the default height. It’s much easier to hit the wrong button when you go up and down and left and right.
Good job getting rid of the bookmarks button.
I also like the Path Navigator.
But I think a back/forward button would be nice still.
What if I hit the “home” button and lost my place? The Path Navigator wouldn’t be much help.
The Back/Forward buttons could pop into the window only after you actually changed to a folder that wasn’t up or down on the hierarchy.
Please don’t hurt me !
I believe this is a fairly common convention amongst OS’s – why change it now?
This is the standard on Gnome (and many GTK+-based environments such as ROX-Filer). I think also on the Mac.
I believe the file list widget should have *full* height.
The mockups present only couple of files. Surely users have much more into a single folder (especially digital pictures), and because this dialog is about choosing a file (remember?), it should presents as much files as possible.
Scrolling a long list with a limited display area is difficult because of the page’s size being very small, making the scrolling very sensitive.
Don’t put the shortcut bar at the left, put it at the top! The first step in selecting a file is selecting the general location of that file. And putting shortcuts in a vertical list gives the impression that each shortcut is “beside” its neighbors, which is totally *wrong* and destroys the user’s spacial orientation.
First problem that comes to my mind when thinking about this shortcut bar, is that our monitors are landscape and many are still using 800×600 or smaller resolution. For them the height of the windows can be a big problem. I have rarely seen window that maxes the width of the screen.
I don’t think there are any screenspace saving qualities in having shortcut bar at the top, as the size of the icon+text will always be the same (excepting that they don’t overlap). Resizing the windows doesn’t matter as shortcut bar’s don’t have to stretch, well except for vertical bar to stretch vertically and horizontal bar horizontally.
I think it is very logical to have the shortcut bar on the side because they are kind of separate entities. I rarely use shortcut bars (excepting that the application i am using remembers in which folder i have been last time i used this dialog in that application), and when i open a file dialog then first of all i check where i am at from the titlebar or from the combobox displaying current directory, if i am at the wrong location THEN i’m going to check the shortcut bar if there are any shortcuts near my target location. By this it would seem to be logical to have bookmarks/shortcuts combobox but that would be unintuitive because i can’t check it out quickly by just glancing at it.
Another theory supporting the “legacy” left position of the shortcut bar is the golden mean / the golden section. With the shortcut bar on the left, combobox & new folder buttons etc. at the top, and the file selecter at the middle type of ordering of the widgets supports the golden mean by pointing your eyes at the file selecter (which is the most important widget of the dialog) when the dialog opens.
Maybe placing shortcut bar at the right would also be good, because then it would be at even more unimportant position to interfere with casual browsing but it would tamper with preview windows.
Oh well.. back to work.
+V
So much writting about the file selector, and so much different point of views. Of course it is important as it is a much used widget.
But why don’t we let users plug in their favourite one, overwritting the gtk’s default?
It could be provided by a theme, or stand alone.
You may imagine also the deployement advantage: a company/distribution/what-ever could easly set up its own fileselector, with their own must wanted button!
Not sure if this is the way it is supposed to work or if it has already been posted (too late and lazy to check), but perhaps programs should be given the option of using their own shortcuts or the general system shortcuts.
In other words, if I was using the Gimp and wanted to open some image files, I would want the shortcuts at the top to be different then if I was in Nautilus or Anjuta or such. A program could be written to see if it has its own config file for the shortcuts and if not default to the general system ones.
Just an idea, let me know what you think.
Maybe because it will allow us to dispense with most of these “open/save/file” discussions, which are a bit of a cludge were limited machne meets flexible human.
[pixelmonkey]
Actually I thought the moniters were that way because of DVDs letterbox format.
Anyway why not a birds-eye-view of the filesystem arranged in spoke-wheel fashion* coupled with something like logitech’s pan and mouse wheel zoom? An appropriate use of colors and shapes (size?) of course. Mouse gestures could help here.
*or for the more advanced the wheel of association.
A good idea indeed.
Can we imagine a totaly configurable file selector ?
I mean : the favs could be a selectable item to place where I want, idem for filename, ..
Why not use draggable “tabs” for it?
But indeed, we need a default file selector and they all look very good for me.
>Can we imagine a totaly configurable file selector?
Yes we can, in the KDE world. Not in the Gnome one though.
Just my 2 cents; as a graphic/web designer, I’m totally FOR new ideas and innovation, but it does have to also be user-friendly, ergonomic, intuitive and allows you to do things quickly. I’m sorry Eugenia but even after really trying hard to see something positive with your concept of the favorites buttons, it really doesn’t work for me. First, there’s the obvious problem of bloated look/too many buttons after adding many favorites to the existing list. Also,the “grid” design of the buttons positioning is confusing for the eyes. The time needed to find one particuliar button is at least twice as much since you have to look from left to right, top to down, etc. Also this whole design would be a bit annoying when u have to work on something fast, as there’s buttons in between the favorites and the files, I know i would end up accidently clicking on “new folder” quite too often because I wanted to click on the favorite over it. Which makes me believe if we would actually use such a concept then at least we would need the “new folder” etc, above the favorites. But then its almost the same problem, if u want to hit those more often than the favorites. 3 different levels of buttons in the same col just doesn’t work, It’s obvious to me. Erick design’s is the best, as the favorites are directly next to the files, which allows quick click very fast in between them without click anything else by accident. So u want to add new folder, click up, easy, fast. You want to click a favorite, click left, easy, fast. Keep it simple. Nice effort Eugenia but I’m afraid Erick did much better