posted by Eugenia Loli on Wed 7th Jan 2004 01:28 UTC
IconA 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.

GTKFileChooser Mockup - Eugenia Edition 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.

e p (0)    212 Comment(s)

Technology White Papers

See More