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.
To tell you the truth it looks good to me, except I would miss the Unix tree. These examples are more suitable for Lindows/Lycoris an RH, no?
As long as the GUI doesn’t screw up the CLI. Than I suppose it’s fine. With regard to Storage though, I suppose it’s the same story. I see no reason however to rush headlong into a database file system. It could degrade the platform. If it were to be incorporated, it should first pass a very long testing and integration phase, at least a few years from now.
>Nice effort Eugenia but I’m afraid Erick did much better
Err… Erick just tweaked Eugenia’s design (which differs a lot from Tigert’s) and just placed the shortcut list on the side. The path navigator, the button/combo placement were all done beforehand by Eugenia so you should give some credit where is due, dude.
Eugenia’s mockups are better than the official mockups. but it’s hard to work on. the shourtcuts should be on the left side. it’s easier to drag from left and drop to right. it seems less logical to select the shorcut above the files level. i hope Eugenia will read this and responds.
> it seems less logical to select the shorcut above the files level
I explained my reasoning on the article and mentioned all advantages you get if you have it on the top, I haven’t read yours though. Is it maybe “logical” because this is what you have got used to?
While Eugenia’s mockup is pretty sweet, I’d all go for the one Erick derived. I think that one just kicks ass.
Well I’m sorry If I got misuderstood, I didn’t mean to say that Eugenia’s buttons and the overall “visual” look and design aren’t “good looking”. I definately like the whole thing from a visual point of view. Nothing to say about that. My problem is just with the whole placement of things and the ergonomics of it. I don’t hold the universal truth, as I said, it’s just my 2 cents.
I do not have anything against Eugenia, far from it, I really do enjoy her work on osnews.com but geez, this is not a reason to agree and embrace everything she say or think just because she’s Eugenia 
I already rarely ever use the open command of an application: it is much easier to browse to a file, then drag’n’drop it onto a window, or click/right-click to open it.
Now what about saving?
Here’s what I have been waiting for for about 10 years, ever since I saw Mac’s Finder having an icon next to the folder name in the title bar of all of its windows:
Each document window shall display the document’s icon in the title bar, right next to the document’s title/name.
The user should be able to click that icon, and drag&drop it to any location (e.g. into an explorer window) at will.
If the document had already been saved, this will by default copy the document to a new location. If not, a dialog (eventually the full file selector) will show up to let the user enter the document’s name.
I have been using file selectors for 20 years to save documents. I just wish I could use drag’n’drop instead, as I have been doing for years now for opening document.
File selectors are a legacy interface.
Regards,
Ivan
Looking at the various mockups presented here, i still think Tigert’s is best. But i wouldn’t mind if Tigert would steal some ideas from the others. I *really* like the breadcrumbs in Eugenia’s mockups; that is a very good idea.
Putting the locations on top are a bad idea though. The most important part of the file selector is actually the part where you select the file, not where you select the location. Therefore, the locations are secondary, so there is no reason to put them on top.
In Tigert’s mockup, i don’t get the bookmarks item. The (favorite!) locations on the left should cover that. Deleting the bookmarks item would leav some space for back an up buttons.
I agree that it’s better off having the shortcuts to the side. Being on top makes it feel more demanding of my attention. Having it off to the side makes it feel more like another section entirely, and lets the window fit better on the average, wider-than-tall display. It feels less intuitive moving a window with a different aspect ratio than the display itself. I also agree that having the shortcuts be a list rather than a grid makes it more navigable. You’ve said it yourself, Eugenia, about the minimize / maximize / close buttons; having too many buttons too close together makes actions take longer, because you have to concentrate a little harder to hit a smaller button that’s surrounded by similar buttons than it is to hit a big button that’s got good padding between itself and any other options / buttons.
That said, I’m not liking the new direction the File Selector is taking. It’s just gonna take more time to frobnicate my files now 🙂
Has anyone considered the golden ratio used in paintings, photography etc… while creating the dialogs? I think it will be better to consider that magic rule while creating any kind of user interfaces.
Note: I liked the terms “Save” and “Do Not Save” instead of “Save” and “Cancel” in Kevin Arwin’s mockup http://www.dmrtc.net/~kvnrvn/sky/Dialog.jpg
I have been using file selectors for 20 years to save documents. I just wish I could use drag’n’drop instead, as I have been doing for years now for opening document.
File selectors are a legacy interface.
Exactly! This is what RiscOS has been saying for ever—it never had file selectors in the first place. The ROX desktop environment http://rox.sf.net/ , best known for ROX-Filer but definitely not limited to that, has taken the idea of DnD filesaving to the Unix desktop (implemented in GTK). (ROX apps don’t actually have the concept of ‘opening’; if you want to open a file, you do just that, none of this opening-programs-to-open-files nonsense.) Though the saving isn’t implemented by dragging a titlebar widget; you need to give it a name before you can drag it.
Sorry to the followers of this thread for being so predictable.
Hi there,
Two things:
1. Main problem seen in postings is that it seems no one is thinking about desired functionality but about mockups. So first please agree on some set of functions (“less is more”, one would say), and then pass it to professional UI designer
2. So called PathMavigator was implemented in CDE File Manager some time ago
Anyway, vertical design is ok, as it requires less distance to travel from one area to another (with mouse of course), due to mentioned horizont-ill-ness of screen. But it is only my opinion
Very nice debate.
What I’m missing though is any discussions on how to design a more keyboard friendly filechooser. One of the things most desktop systems miss is easy keyboard navigation.
Why is this important? Some people are in pain after using a mouse the entire day (like myself). For me GUI is about making it easy and intuitive the first or second time I use an application. Afterwards a while I ‘just’ want to do things quickly. Think of the shell where commands can be typed very quickly specially if one has good completions. Think of emacs where the power user can do his/her job in a very short time.
If this could be combined with a nice GUI to let the first time user have an easy experience things would be perfect.
I know it’s more a toolkit question but it’s easyer to create the right keyboard navigation with a good visual design.
One thing I miss in Gnome/GTK is the ability to type some letter and then see the fileview change to the files starting with that letter. This feature makes it easy to navigate folders with lots of files even when one can’t remember the exact filename.
Another thing is moving between elements. Usually one can use TAB or Alt+TAB to move forth and back between elements but often the elements are not highlighted. Also in widgets with lot of elements the focus is often changed to a non-logical position (with no highlight). Once in a while one can ONLY use the mouse to navigate – which in my oppinion is a disaster.
Perhaps it should be possible to hold down TAB or another key and then move the focus with the arrow-keys. This could make it a lot easyer and perhaps more intuitive to use the keyboard.
So if any of the Gnome developers read this please remember to add easy keyboard navigation.
My main problem with the current GTK File selector is there’s no way to open or save .dotfiles. None of the new solutions address this problem.
That said I don`t like the shortcuts at the top. My problem isn`t with them being at the top, but having 2 rows in a grid layout makes for difficult navigation.
My main problem with the current GTK File selector is there’s no way to open or save .dotfiles. None of the new solutions address this problem.
Actually, I think that’s what the ‘change view’ drop downs are for.
Simply becouse it’s not normal flow of usage, to start navigation with shortcuts.
I expect an application to open a folder I had been lastly using that app and open/save a file there, or somewhere near in the directory tree.
Shortcuts are an auxilary control, which I would use to jump to work on a completely different set of files which is not often. I don’t need shortcuts to fill 1/3 of my fileselector – I’d rather like to see my files at that place used. Shortcuts as a dropdown menu would be just fine.
Sure – large, colorful, clickable icons list looks preety. But is it really that usefull?
Am I the only one preferring the file dialogs of Classic Mac OS or BeOS? When using a file dialog, all I want is a view of my files – no sidebars, no bookmarks, nothing else.
Those breadcrumbs are an excellent idea. An other enhancement could be to make every directorybutton a combobox (like the “Show all files” button in Eugenia’s mockup, i do not know what that thing is called exactly) and have every directory listed that is at the same level. This way you can navigate faster.
For example (I take Eugenia’s mockup), when I want to go to another directory in My Documents, I have to click on My Documents and than on the directory I want to go to in the filedisplay. If there is a little dropdownbutton next to the Photographs button with all the directories at the same level (that is: all directories in My Documents) I can navigate faster. Just an idea…
is it possible to rename/delete/etc within the fileselector widget? i find that useful in windows at some times.
Well said, it’s pathetic how some applications expect you to have or need a mouse to operate them. Especially, when the keyboard is the primary input device in most personal computers.
Keyboard navigation is tremendously important, unfortunately, it is the least thought and designed feature in graphic user interface design. Even game developers pay more attention to navigation with input devices than do desktop application GUI developers.
Isn’t it sad that I can’t effectively use a browser without a mouse? GUI design is about functionality not superficiality. Here we are arguing about how the file selector should look. Instead of focusing on features like auto-completion, globbing ala BASH, use of relative paths in the file locator editor instead of just absolute parts, navigation ease.
The features I mentioned will make openning a file a magnitude more faster than clicking through nested directories. Or celebrating trivial issues such as where to put what widget. I want to type ~/D*/pro{TAB KEY for completion}/ass*/filename.txt in a few seconds in the file locator editor, rather than click through, what, 5 folders just to open a file.
Yes, with appropriate keyboard navigation, I wouldn’t even need use the mouse and I’d be more efficient. But please, lets carry on whether we need icons or text to identify widgets and how wide or shallow the location area should be. :rollseyes:
It would be nice if the bookmarks list in the file selector synchronises itself with the nautilus bookmarks menu. That way one would have consistency.
offtopic: A similar wishlist for common bookmark formats for all the web browsers.
Personally I’d go for the shortcuts at the side. If an application is well written, then it’s probably defaulting to open from the folder where I keep my documents and saving to the same location. Consequently I’d be using the shortcuts to move around only infrequently, and would prefer them to not take any vertical height from the file list.
The path navigator looks interesting, but having separate buttons takes up too much space. I’d much rather see a normal “/” separated path, which would fit a longer path into the same space.
The “Freedom” fileselector on the old Atari ST had a feature whereby right clicking on part of the path would bring up a context list of all the directories at that level (plus “.”) – doing something similar would make it quicker and easier to move to another branch of the filesystem. For example, if I had “/home/xav/documents/graphics/” as the path and I right-clicked on “documents”, it would produce a context menu containing “.”, “divx”, “graphics”, “office_documents”, “mp3” (or whatever other folders were present in the documents directory).
Well, much has been said already etc. But here’s my 2 cents.
0. the pathfinder thing is a rip-off of SGI’s modifications of the Motif filedialog in IRIX. UNfortunately SGI now has left the Desktop space completely.
1. File dialogs are evil. Notice how much ‘filemanager’ functionality goes into it… Better to slim down that hog of a beast Nautilus and to hook it into the ‘filedialog’ role. Need a file op? make the app use Nautilus-lite (or your favourite fm du-jour) in file-dialog mode.
2. I want DnD open/save from _terminal_ windows. My desktop has any number of terminals open and sometimes a GUI filemanager is useful, but it would be super handy to be able to DnD into/from a terminal window.
Seriously, Eugenia, for a so-called useability experrt, you’ve come up with a bit of a mess. The subsequent modifications by Erick et al marginally improve it, but not by much. If I was faced with this, I would stare at it in blank incomprehension. This is useability?
The “Favourites” widget just looks horrible. It’s too big for the function if performs. DnD is highly counter-intuitive for using such a panel.
The pathfinder nice addition, but I don’t like it’s implementation. It’s not at all clear to the user what these buttons represent. A better idea is to use clickable text, seperated by non-clickable slashes.
There are no “Back”, “Forward” or “Up” buttons. Sorry, but the pathfinder does NOT replce them. There’s a reason why other file selectors have them: they’re useful, intuiutive and quick. They’re good enough for browsers, and they perform the same function in a file selector.
There is no preview panel. How the hell are you going to choose between hundreds of images which all have the filename “DSC…”?
What is the point of renaming “Filename” to “Search”? What does “Search” imply? Am I searching the entire filesystem?
Personally, I would seperate the directories from the files and give them a widget each.
The SkyOS mockup is far, FAR better in every respect. It contains everything that I want and nothing that I don’t. It uses a fraction of the screen real estate compared to the GTK one.
This whole discussion makes me dispair for GNOME. In the interests of “useability” you just end up discarding the very functions that allow users to get on and do things!
>> except I would miss the Unix tree
I wouldn’t.
At all.
This (tigert/Erick) mockup looks way more useful than this silly unix hiearchy, which is useful in a terminal but doesn’t belong on the (graphical!) desktop.
I wouldn’t want to give up the command line interface (CLI), but I also like to have both the GUI and the CLI.
The Linux shell has many small, powerful tools that make searching and modifying files, even file contents, very efficient. The ability to write scripts to automate batch jobs is a valuable strength of the Linux platform.
One of the best qualities of Linux is that it also has a rich GUI unlike traditional Unix platforms. I like to have a landscape wallpaper, I like the Noia Icons that I had to install myself for GNOME 2.4. On my hardware the GUI is responsive. It’s difficult to remember all of your applications but if you search under /usr/bin you can find the names of all your applications. Type ‘oowriter’ or ‘nautilus-cd-burner’ and those applications will run just fine from the command line.
For your efforts though, I will award Eugenia 10 points.
It could be much better if QT and gnome will be sharing the same file selector design! the actual qt/kde file selector is very similar to the windows one.
First of all let me congratulate all others that have previously provided mockups. Each one of them has great features. However I’m tempted to provide one of my own.
http://florosat.freeyellow.com/thanos1.gif
I think that the “Favorite locations” selection area, presented either horizontally or vertically, takes up too much space and results in some space being wasted when resizing the dialog (which is less in the case proposed by Eugenia). Moreover, selection of one of these locations is quite likely to happen only once during the file selection process (ie. selecting a starting point for the rest of the navigation).
This is why I propose the replacement of this area with a drop-down list, containing as choices all the favorite locations plus an entry for editing the list itself (this choice is shown in the mockup). The editing then would be done in a separate dialog, offering area for drag-n-drop of shortcuts and possibly “add” and “remove” buttons.
I also propose the movement of the “Recent locations” choice to a separate drop-down list in the main window, which would function as a replacement for the “back” button, offering a list of all the recently visited folders. This list will most of the time contain (in historical sequence) all the parent folders of the current folder. For this reason the “Path navigator” concept becomes redundant too.
Although this approach does require more mouse clicks than others for some operations, it does leave more space for the file list area (which is imperative for this kind of dialog IMHO) while enabling all the functionality of the other mockups. And if done correctly, it will offer useful information when resizing (eg. the “recent locations” list could gain width and be more readable).
I agree with most others though that the shortcut is better on the left. This is less a familiarity thing than a spacing issue. When you stack everything one on top of the other you have too much separation of components. For instance to go from shortcuts to search/file you need to travel through the file area. With the shortcut widget on the side each element adjoins all other elements, with the exception of the navigator buttons at top and search field at the bottom. But this makes sense as the finder is also the indicator of the current location.
I like the finder style button bar much more than forward/back/up buttons. I use up and back all the time but think the finder style buttons make more sense, especially in a spatial environment.
I love the “Path navigator”. Very intuitive, you always know where you are.
First of all let me point out that I have a)never used Linux b)been using Windows for about 13 years c)been using Mac OS 9 for the last 5 years and Mac OS X since it came out, so I definitely am aware of how more biased towards seeing things as Big Bro MS has taught me to I am.
I think Erick’s landscape layout is definitely better for the reason repeated to death of screens being lanscape. Besides, although Eugenia said:
>Just created a new mockup to show that my version can also be made wide
the “Favourite Locations” is a list, so laying it out in a grid table as Eugenia did would be quite a big UI mistake (IMHO of course) since it kills the idea of non-hierarchy that a list of Favourites should be (none of the locations is more important than any other). So Favourites list demands a vertical layout and thus takes too much space in a lanscape screen to bee usable. And ultimately, it is very similar to Windows, who more or less everybody knows. Note that I do not think that it should be followed because it is inspired from Windows, but quite the opposite that it was implemented that way in Windows because that is the more usable option they considered the same reasons of usability when designing it.
Contrary to another Eugenia’s opinion, I do think a “Favorite locations” label is needed, since it makes the user aware none of those locations has anything to do about where the user is at that moment. This is a concept that is not intuitive unless explicitly said, as I have witnessed first hand with my mother being repeatedly distracted by Windows’ “Favorite locations” sidebar and not knowing where she should be clicking and what part of the interface is really determining where is she going to save/open the file.
As pointed out, Add&Remove Favourite Locations buttons ARE needed, as well as keyboard access to those (and all other) functions.
As in Mac OS X, I would ALWAYS list all mounted volumes there too, wether or not they are a favourite folder, as Mac OS X 10.3 does.
Rayiner Hashem complained about the lack for a typeable path field. Keeping the nice idea of the Path Navigator, I would grab Windows’s concept of being able to type Paths in the Filename field (with autocompletion of course). Do you want to navigate a path? Use the Path Navigator buttons; do you want to navigate to a certain path with 1 step? Type the path in the Filename field, just as Windows allows. The Open/Save button should swatch to “Go” if the path entered is a folder (maybe noticing if the string ends with “/”, as autocompletion should do). Maybe because of that, I would choose neither “Filename” nor “Search” as label, but “Path”, with a “./” before the field (in the gray area) being there but disappearing if the user began the Path with a “/something/…”.
The “Path” (was “Filename”) field would also allow for regular Expressions to double as a “Search” field for that folder only, just as, again, Windows allows to do (well, although somewhat more limited than regexp). For instance, in Windows, go to File/open in notepad and the dialog will only list folders and .txt files, unless you type something like “*.html” in the Filename field and hit OK, which keeps the dialog open but only lists now folders and .html files. Whenever a wildcard or anyother sort of regexp would be entered in the “Path” field Open/Save should change to “Search”.
This option is quite more poweful than the “Show All Files” combo box (since the user is not limited by its suggested file formats), although I would not get rid of that combo box since my way of doing it would only be used by power users. Alternatively, the “Show all files” combo box might be dynamic so that it would list all file types in the folder currently being browsed, and only those. That would bring the problem, though, of navigating to another folder which does not have any of the file type previously selected, so the “Show All files” text should clearly change to “Show JPEG” or whatever, so that the user does not accidentally thinks the folder is empty. Whenever the user entered a customized regexp in the Path field, the “Show All Files” text should swap to “Show *.*” or whatever the user has entered.
Finally if back button is really considered to be accessory since it bloats the UI, I would at least add a keyboard shortcut that accomplishes that (the same that is used by whatever file manager gnome uses).
Anyhow, I found this thread to be a very interesting one.
Eugenia, I love the mockup. The favorites-dock thingy at the top gave me pause at first, until I thought through how it’d feel in use. I can’t agree with it being on the side any longer, except possibly as a Drawer like MacOS X has.
People are suggesting back buttons, I think the “Recent Locations” button can cover that, unless it’s something like “Recent Documents” for directories, which I already find useless.
The Path Finder is a dream replacement for the address bar and traditional navigation, with one lack: typing out or editing addresses. Editing is covered if you can select siblings of directories. However, it’s still quicker to type than to click.
“New Folder” is something I regularly use, but it doesn’t seem right to jam it in here. You found a nice place for it, at least. I think the Open dialog should be focused around getting to and selecting files. What we could use is a light and quick tool panel for certain tasks you’d want to do while in an Open dialog. Mostly, you’ll be clearing a workspace (new directory, simple copy and moves, a delete or two). It’s sort of a task-oriented file manager job. A couple of things we could use for this: A shelf to drop items to while moving about, a “detailed information” tool (/bin/file output, detailed properties, xfs attr, comments unique to filetype (ogg,jpg,gif)), creation tools for directories and hard/sym links. It’s enough for a new widget.
I fully admit the following are poweruser things:
I propose the text input box (“Search:” “Filename:”) immediately steal relative or absolute directory paths from the box when they’re typed. So, you could type “Documents/” and as soon as you hit the /, if the directory exists, it vanishes from the input box and goes to the Path Finder. A similar occurance should happen with “..”.
I made a series of mockups to demonstrate a sort of bash-like multiple file selection. They’re all kinds of rough, but I hope they show the kind of functionality I’d like for something like this. I renamed “Search” to “Select”, because I think it’s a more accurate descriptor. Missing from this is an icon next to “Select:” showing that this is a “multiple seletion” dialog. An icon for that might be togglable to single selection.
http://home.earthlink.net/~teluial/img/filesel-daelin-mod0.png
This is basic operation. Start typing and all matching files are selected. In Single Selection, this would select the first matching file. Tab completion should work just like bash, filling out until there are variations.
http://home.earthlink.net/~teluial/img/filesel-daelin-mod1.png
Here is the first step in making sets of selections. Wildcards can be used. After closing the quotes all the selected files are collapsed into an item at the top, and otherwise removed from the view.
http://home.earthlink.net/~teluial/img/filesel-daelin-mod2.png
Autocomplete, variation on wording.
http://home.earthlink.net/~teluial/img/filesel-daelin-mod3.png
After enter or tab have been hit for autocompletion. A comma will collapse “Zebra” into the previous selection set.
Also, starting with a single dot, or at least “./.” should display dot files (and only dot files) in the directory.
I have never used them.
If someone needs to get that info, he/she can right-click a file and select properties.
Also, one more thing about the Favorites. Apple got this right with Finder in 10.3. Emulation of that would be a great start.
Daelin, I do love the concept about text stealing in the Filename field (Path field for me), but I am not sure (that means I am not sure, not just i do not like it) I’d feel comfortable with it on folders. Note that I proposed that the Filename field also accepted paths, with the Open/Save button changing its text to Go. It does seem a nice thing not to need that, but the file listings changing dinamically as I type… I don not know. I guess I would only know if I liked it until I tried it.
I do love even more the automatic selection of files depending on text input on the Path field, but I think you are spoiling it by collapsing them to “3 files selected”. The purpose of the dialog is to SHOW what files you are open/you do not want to open. I would take that concept without the group collapsing.
The real problem with the shortcuts at the top are:
– scaling: fine for the first 6 but how are you scaling it when there is more or less ? you’ll add more rows ? let blank spaces ?
– it’s hard for someone who is not using a computer every day, who starts to have some vision problems, to see the different lines (not my case, but I imagine my father would hate it)
I wrote:
> Note that I proposed that the Filename field also accepted paths, with the Open/Save button changing its text to Go
I forgot to mention ‘changing its text to Go, if the text input is a path, which would be known by the dialog, I guess, if the string ends with “/”‘
This is honestly OT, but I was just curious about something.
Does anyone else see an analogy between the relationships of Gnome and KDE to Apple and Microsoft?
I don’t know if this is what you mean, but OS X Panther’s new Finder windows threw me off at first because of the sidebar on the left. It, like the Gnome box, has you looking in two different directions. I’m a “top-down” person and really like Eugenia’s “wide angle” mock-up. But, people perceive things differently and that must be one of the hardest parts of UI work – trying to find the best way for the majority.
But, it’s great to see this creativity – kudos to all who made mock-ups!
> This is honestly OT, but I was just curious about something.
> Does anyone else see an analogy between the relationships of > Gnome and KDE to Apple and Microsoft?
Hehehe, I do
I’d say It’s sort of an insult to compare KDE to Microsoft tho, but I do have the feeling that KDE is a bit bloated and a tad too “windows-wannabe-like”. I do prefer Gnome, but this being a personal preference, and respecting others tastes, I am not one of those that thinks one GUI should be “chosen” over the other one. I think they should both come with most distributions so u have choice to use whichever, just like u can with the other GUIs like windowmaker, blackbox, icewm, etc. Oh, one feature I like better from KDE tho is the ability to put a window and make it stay on top of all the others. Oh well, this if highly off-topic now anyways, sorry about that :/
Something that drives me completely nuts with the gtk file selector is that when you go “up” a directory, you loose the place you were when you went “down” that same directory.
Norton Commander and friends always put the cursor where you were when you last visited that directory in that session.
This greatly speeds up “cruising” where you are visiting a lot of directories, for example to pick some songs for a playlist.
Wow…I really like that version. Something about putting the shortcuts on the left just looks a little more professional than putting them at the top.
So finally, after having read all those comments, I feel that I’d like to say something too,
I really liked Athanassios Floros Fileselector, because it’s simple, but has a feature that most others lack: The inclusion of several recently used Locations.
But I have some other Ideas too. Sombody already mentioned that there plattforms where you can drag an icon from the titlebar to save it. I like this Idea, but I’d like to enter the filename into the titlebar too:
http://homepage.uibk.ac.at/~csad2715/dnd.png
And I’d like to add something to eugenias fileselector: drill-down context menüs for the
shortcuts-section:
http://homepage.uibk.ac.at/~csad2715/filesel-context.png
Finally what i’d think might be the best solution for all:
take Eriks second Mockup, add drill-down Menüs to the shortcuts and include a “recently used Locations”-DropDown Menü
IMHO
-Richard
> Something that drives me completely nuts with the gtk file
> selector is that when you go “up” a directory, you loose the
> place you were when you went “down” that same directory.
I belive the ROX-Filer offers a good Example of “How to do it right”:
if you use the “up” Button, there is a Frame around the Directory you came from, that flashes for a couple of times.
I prefer Tigert’s one + “Advanced…” Button that fires up a full file manager (nautilus or rox filer or what ever)
I think put a tree on the left side would make more sense than the path navigation. Because the tree is two dimension rather than one dimension of the path navigation. The tree also let the user know where he/she is at in the file hierarchical system. You can even get rid of the up button.
Also I’d to add a filter box. Since the filter allow user to look at only the interested file group. It might come in handy
when the user already have some idea about a file.
I’d really prefer re-integrating the folder view as a separate view. There’s quite a difference between running through folders and scanning filenames/endings and I rather like the old separation than this mix-up in one view. It doesn’t make sense and isn’t what people want when they search for typically only one of a folder or a file.
By the way, a tree-view for folders is better than a list view or just placing them above the files.
And, nobody said that a file dialog must be small and compressed like yours or the most I know. It can be of size and give things more space like any other (configuration-)dialog does. Consider this.
I’d prefer a wider dialog with some more height which puts the button stuff at top, some input stuff below and three widgets in the middle, as there are (from left to right) quick access, folders (in tree-view) and files.
Sometimes i need to open the same file several times
in diffrent applications.
If you can drag the path(or file and path)to the next
fileopen dialog, it is nice.
Or have the recent path saved i background.
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.
Wow. You seem to have no idea what you are talking about. Having some fancy path widget doesn’t make a file selector spatial! It just makes it more like a full-blown file browser. A spatial environment is one where there is a one to one relationship between the icons and files and between the windows and folders. This design would break any spatial metaphor and is too complex anyway. Tigert’s was design was probably the nicest – “new folder” for an open dialog is silly and bookmarks and the sidebar are somewhat redundant, but anyway. That design isn’t spatial either though. That’s not necessarily a bad thing.
As an aside, Path Finder for OSX was created to make a file browser that moved away from the spatial metaphor (it’s more complex, harder to learn, but many experienced users find it useful). Arguably the metaphor isn’t strictly adhered to in OSX Finder either (especially Pather).
A real spatial file selector would be where you just open a file from the file manager and it opened an application window (ie: no selector to worry about). To save you simply give the doc a name in a dialog and drag its icon to a folder (X Drag ‘n’ Save: http://www.newplanetsoftware.com/xds/). A real system wouldn’t really require an explicit save command anyway and would just store revisions of the document as you went, but I digress.
Read http://www.arstechnica.com/paedia/f/finder/finder-1.html and http://mpt.phrasewise.com/stories/storyReader$374 before replying.
But I have some other Ideas too. Sombody already mentioned that there plattforms where you can drag an icon from the titlebar to save it. I like this Idea, but I’d like to enter the filename into the titlebar too:
http://homepage.uibk.ac.at/~csad2715/dnd.png
Mate, that is awesome beyond belief. I especially like the ‘tipp tipp’ bit, it sounds so cute
Now all we need to do is make a webbrowser that lets you DnD links, and the only thing we need to worry about is when people think it’s okay to use refresh to cause downloads!
A pity I don’t think it’s implementable in the current X world, you’d need to have some sort of way of saying: ‘save yourself to this path’ to a program at a random time, and a program would have to have a way of saying ‘I can save files’.
(What on earth you’re doing running GTK1.2ish, though, I have no idea
It’s not really related to the UI, but one feature that I would like to see is the ability to add keywords to folders. For example I could type “current project:project backup:file.txt”.
This would save a copy of file.txt to the folders that have been assigned the keywords “current project” and “project backup”.
Richard Spindler,
Sibbling selection with the Path Finder
I think this is a little better, but still an ugly rendition of the desired function: http://home.earthlink.net/~teluial/img/filesel-daelin-mod4.png
So, even if people have problems with it, it’s still better than what they’ve got now. Personally, I think it isn’t as good as KDE’s default from two versions ago, but it’s a good try.
Felix, thanks for your informative answers. I was thinking about CnP as a keyboard equivalent of DnD (with the technical insight you provided, it’s even more obvious to me now, thanks again).
I wanted to know what was Eugenia opinion about this, since she quickly dissmissed the accessability issue raised in the 15th comment (in a quite insisting manner, that might be unpleasant I agree). I suppose it doesn’t matter much now anyway.
elmimmo,
“… I think you are spoiling it by collapsing … purpose of the dialog is to SHOW …”
I was stepping through with a process. While you’re typing, the files are selected. After you’ve got that set you want, you hit the comma to pick another set. So, the previous set is collapsed so you don’t look at what you’ve already selected when you’re picking a new bunch of files. You’re done with it for the moment, so it’s tucked away, out of your workspace.
I see your trouble with it, though. You should be able to review what you’ve selected, just to be sure. Personally, I think you should have been confident with the selection before yout hit the comma, but I agree it’s something you should be able to do, at least so you can trust the machine didn’t goof it up. Put the list at top? Make the “x Files Selected” item an expandable list, like MacOS X folders in columned views? I like the later a lot.
As for the paths, perhaps a confirmation key should be pressed. In Windows, you have to hit enter before the directory will change. Personally, I don’t like this. I’m always worried I’ll trigger “Okay”, usually because the app has an older version of the widget.
Let me explain how I want it to work. I’m going to open VLC and I’m going to type ( for tab):
“Mov /T /St G /St G 401 ”
to get to
“Movies/TV/StarGate SG-1/Stargate SG-1 [4×01] Small Victories 350-AC3-AMC.avi”
So, I want to type Mov, tab complete to get “Movies” and hit /. Mentally at that point, if I were on a shell, I’d be IN that directory, so I want the file selector to assist in this image, rather than showing a different one. I’ll type TV/, next one down. Now I’m in that DIR, where I’ve got Star Trek * and StarGate SG-1, so I’ll tab Star out and hit G then tab again. I hit / and I’m in the directory. At this point, I’ve got a long list of files, so I complete the filename up until the episode number. I know the season, so I pick that. Now, I don’t know what episode number I want, but I know the title, so I start scanning the file selector (which has followed me up to this point) for the title I want. I can click it if I had to scroll, or just tap in the episode number, hit tab, and hit enter.
current directory work?
where is it?
what if i don’t know where am i? if is not home, or documents, or pictures?
current directory work? is a *must*
preview for pics, videos, etc?
A feature very similar to the path navigator was implemented by SGI over 8 years ago. I loved that feature and thought it was one of the best attributes of the SGI desktop. Once you have used it, you’ll miss the feature when using other file selector dialogs. If I remember correctly, the main difference between this mockup and SGI’s path navigator is that SGI used short buttons that spanned the length of each directory above a text input widget that contained the path. With this setup, you could click on a button to change the path or change the text of the path directly. One advantage of this mockup is that when you below (toward the root) the current directory, you still have buttons for the previous directories. The SGI file selector just removed the previous directories from the path navigator when a directory below the current directory was chosen.
Here is a link to an image of SGI’s file selector:
http://www.sgi.com/software/irix/images/thumbnails.gif
SGI had another feature that was quite handy for large directories. You could click on a button (the blue button with a horizontal black line on the left side of the dialog) to create a “split” view of the contents of the directory, the upper, larger one would show all of the files and the lower would be initially empty and I believe was called the bookshelf. You could drag a file from the complete directory contents view into this bookshelf and a sort-of link would created between the icon in the bookshelf and the complete listing. Whenever you revisited this directory, the bookshelf would automatically be expanded, so you could access your previously selected files more quickly. It was a neat feature, though I didn’t use it much.
Call me a minimalist, but I think that this is a bit excessive. Sure, it’s 2004, but what if your mouse is inactive or you can’t use a traditional input device? The *drag-n-drop* is essentially useless in such a case. Why reinvent the wheel? These “favorite places” bars just take up tons of extra space and serve little purpose than the efficient bookmarks button that is already part of GTK’s subset.
I believe that this mockup totally negates Gnome’s idea of “simplicity” and “ease of use.” How often do you need to make use of “last modified” column? I might be able to see purpose in a “file size” column, but even that is bornerline excessive.
I personally belive that “right-click” submenu is in order more than this stuff. It might be possible that the submenu is too difficult for novice users, but I don’t see how adding extra buttons is going to simplify things. The new mockups just look cluttered, in my opinion.
Forget favourite locations! Replace with a drop-dowm
list of the 5-10 last-visited directories! This list should be common across applications.
This is the feature I have most missed in every file selector in every GUI I have used. In a workflow one typically works with files in some small set of directories, but this set changes over time. Therefore a statical favourite locations list is totally useless, but a LRU (least recently used) list would capture these directories automatically.
While we are at it, why don’t we just rip out Nautilus all together in favor of this file selector. If this thing gets drag-n-drop, you can always add Gnome-Thumbnail-Factory renders for images and movies, then you effectively have the same type of program that allows you to browse and manage your filesystem.
I just don’t understand why you guys want to reinvent the wheel. Simplicity is important.
Hi Eugenia,
Cure idea with the shortcuts on top, but I’m afraid I’ll have to argue against it:
— It violate the principle of least surprise
This is no small matter. Most people (>95%) are used to it to
the left, by virtue that everybody else does it. Moreover, most
people are forced to use a heterogeneous environment
(Windows at work, a mixture of Gnome/KDE apps at home),
we’re just making it painful for them to use Gnome apps.
The benefit is neglijable, I can’t see it outweigh this problem.
— It is an untested idea
There are reasons why everybody have placed them on the
left side. They have _years_ of large scale deployment behind
them, you have a mockup. Cute, but a mockup that works in
theory. Remember, it takes years OF TESTING to get to a
good UI idea, and most of the time it’s not the most logical or
obvious one. This is not an exact science.
— Not necessarily the most logical
You seem to like the flow from top to bottom. It’s an interesting
argument, but we have _zero_ proof that it makes any
difference. However, it’s not clear that it’s that good. Most of
us are used to read left to right, not top to bottom, and I see
no reason to break that.
— Wastes vertical space
Which on most setups it’s more precious than vertical setup.
This results in less files being displayed, which is a MAJOR
usability flaw.
Remember, inovation is not just changing stuff for the sake of
change. Change in fact has a fairly large hysteresis — you need
to add enough value to overcome the disruption you are causing.
In this case, due to the heterogenous environment (as I’ve explained), this is not a one time change. It a continuous nuisance
that has no chance of going away anytime soon.
Remember this will be used by millions of people, not just you. We have to design for the greater good. You have a lot of influence in the community, please use it well.
—
Dimi.
someold tiny innovation of open source/linux
only a unify standard user friendly less hassle OS will bring us a better life.
everyone thinks linux development pace is freakin fast. the truth is linux ‘rapid’ development is freakin sssslllloowwwww.
Hi.
Why do you know that it’s not usable? Because it’s other than usual? I personally have waited a long time until I get a new Fileselector in GTK and Eugenias’ is the best I have ever seen. The point is: You all use Applications like Gedit, Abiword, <YourBrowser>, File Roller etc. and all have this nice Toolbars at the top. And this Toolbars provide you Shortcuts for common actions. Why not copy this to the file selector? Your brain has not to switch between 2 interface designs. Think of it as a toolbar. Would you use a toolbar at the left? Most applications are designed from top to bottom. So this fileselector would behave more integrated and not like a foreign object in the desktop.
…
“Toolbars provide you Shortcuts for common actions.”
yes, but in this case the left pane is for “common places”, not a “common actions”.
so from your idea, “new folder”, “view..”, “show..” buttons of mockups in http://www.gnomepro.com/gtk-file-sel2.png
should be moved to the top (right?)
but those “desktop”, “documents”, .. PLACES are just in the correct position (left pane).
for a quick wrap-up,
“common actions” at top
“common places” at left
RE: By Tonguç Yumruk
I agree dump the cancel button and use a “Do Not Save” button….
Well, maybe something like this could be considered:
http://liebesgedichte.net/Temp/filesel-spark.png
Exactly my feeling! Do not pack too much widgets into one dialog. Keep it simple. But powerful!
Spark´s design by far the best, I believe.
Beatiful dialog, but I’d actually miss the “Up Directory” button. In order to move up several directory levels in your model you have to move the mouse to the left to chase the mini-tree buttons.
With the “Up Dir” you can stay in one spot and quickly go up the tree an arbitrary number of levels. Boo hiss.
Dave
Just replace “actions” with “places”. The word i wanted to say was “common”. When you work with an application and want to perform a common task (like “new file” or “go to home” or “go to documents” (just think of nautilus here: home button is at the top)) you go to the top and click the button. Then something below the button changes as requested. That’s the way things work! There are no common places, there are only common tasks or actions and for places this is “go to <shortcut>”.
Eugenias Design makes it easier to do the “save or open file” task. You can step from top to bottom, just move your mouse into one direction. You only have to move the mouse from left to right within one section but you know the next step ist down. Don’t you think that’s easier and faster if you get used to it?
First of all let me congratulate all others that have previously provided mockups. Each one of them has great features. However I’m tempted to provide one of my own.
http://florosat.freeyellow.com/thanos1.gif
I must say that this (Athanassios’s) is the mock-up I liked most. No fancy screen-eater icons, no strange locations for buttons… simple and effective.
It’s only a bit different that the regular one but incorporates the “locations” element in an unobtrusive way, so there is left a lot of room for the file listing (the real meat of the selector).
I’ll admit right away that I didn’t read all 170 replies posted so far.
Here are the problems I see with location bar on top:
– Different from all other OS and programs: Mac Finder, KDE, Evolution, bookmarks in all known web browsers, etc. Why be different?
– Top top reading order: as with the “spatial finder” argument, people get used to find things at specific physical place. Order is less important than finding things at familiar places.
– Button aspect ratio: text is naturally thin and wide, so more elements can be fitted in a vertical box.
– Stable order: in the two-dimensional layout of locations, the elements will move in unpredicable ways when new rows and columns appears when the window is resized.
– Alphabetization (or any other ordering) is less evident in 2D than 1D. Is the order row-first? column-first?
If this is implemented, it would be nice if there was an advanced mode that operated a bit more like the BeOS file dialogue. For those not familiar with it, instead of buttons for favourite locations, it has a Favourites menu at the top of the window. It’s a little more work to get to, BUT this menu also lets you “drill down” into the heirarchy and it preserves screen real estate by keeping it tucked away in a menu – for more advanced users, I think this offsets the extra step needed to get to Favs. Ideally, I’d like a file save/open dialogue that worked like this AND had configurable keyboard shortcuts for quickly jumping to a fav. folder – there are a few pre-defined ones in BeOS (Ctrl-D takes you to Desktop, Ctrl-H takes you to ~/), but you can’t set define shortcuts for favourites you’ve added.
Yet another file selector proposal: http://www.coleskingdom.com/james/file-selector.jpg
The columns should be customizable like they are in evolution.
Also, why limit a person from typing in the directory name themselves like I’ve done.
I also hate having to go through trickery to get to the dotfiles in a directory, with the file mask filter, you could type in .* and have them all. It’s more flexible than only allowing certain file listing options, let the user type stuff in.
Also, I use the up button all the time in every program I use… It is a must have. The back button is welcome on those occasions when you do accidently hit the shortcut button, or followed a symlink to another directory.
I’m very flexible on the text labels, I think there are probably better titles to use, but the layout is the most important thing to me.
After reading most of the posts today and trying to figure out what would make everybody happy, I decided just now to give it a try and make my own mockup as well… (Like there aren’t enough already!!
But well, correct me if i’m wrong, but I think I did pretty well trying to make everyone happy. I found some way to include a text-editable path as well as the buttons design for it (thanks to whoever posted the SGI OS screenshot for the inspiration on that one) and also add the UP and BACK buttons, while still making the window smaller and save more space! Check it out there:
http://24.203.229.48:99/images/toogreen_mockup.png
Also, why limit a person from typing in the directory name themselves like I’ve done.
I also hate having to go through trickery to get to the dotfiles in a directory, with the file mask filter, you could type in .* and have them all. It’s more flexible than only allowing certain file listing options, let the user type stuff in.
Also, I use the up button all the time in every program I use… It is a must have. The back button is welcome on those occasions when you do accidently hit the shortcut button, or followed a symlink to another directory.
I agree with you on most of this, but have some issues with the layout itself that you posted. Things just seem a bit scattered, and fields in which you may type are in completely different portions of the interface. If you know exactly what you’re looking for, you’re probably going to want to tab through the interface, and focus should shift from top-left to bottom-right in order, which means shifting through a great deal of extraneous widgets to go from the directory to the mask to the filename(s).
Drop the directory listing to the bottom (where the modify and new folder buttons are), move the buttons to the top, and clarify what the modify button actually does. As you said, text labels are fairly flexible, but the modify button in particular struck me as far too vague and isolated from the rest of the commands.
I can understand the urge to put the directory box at the top, especially because people will want to see it first to orient themselves in the file system, but it may not be the best place from a navigation standpoint. Another option would be to keep it where it is, and make the buttons smaller, arranging all 4 to the left of the directory box along the top. This would mean that keyboard navigation should only take you through the other two boxes if you’re typing into the directory box before getting to the mask and filename, and would still keep the actions (other than ok/cancel) together.
Euginia,
Scenario: I have the location of a directory, where my file resides, in the clipboard.
Question: In your mockup, how would I direct the mini-browser to the location in the clipboard? This is a feature I use often in windows.
What other view options are available?
Why not present an icon instead of text for the options?
How do I filter by filetype?
What is the mechanism for entering multiple filenames?
Why is there no ability to customise the columns of the list? IE the addition of other meta-information such as creation date, type, owner, permissions etc.
Thanks for the great work.
Eric’s is far better! Though…
I think all the toolkits on linux have same problem – margins.
Let’s have a look Both mockups show chooser windows that fill almost all 1024×768 screen, but the most important thing – the files’ list has only 7 entries visible – that’s horrible. What about ergonomy. I think every user hates scrolling finding file he wants to select but in GTK all the widgets are placed on every form in way the user always have to scroll something. Ok, sometimes dialogs are much cleaner aligned so, but application windows (i thing file selection dialog is seen by ergonomy like app window rather than dialog) has plenty of place wasted on mostrual toolbars, huge margins, around buttons, margins beetween controls and so on… Let’s look at the list header – those lousy margins around headers with squeesing just a liitle of all the entries could make this list showing 11 elems. Having little bit smaller margins, buttons, and thos horrible GTK’s combo could increase this number to 15 maybe more…
I think Gnome is light years behind M$ stuff with app windows’ layout with customization of toolbars, placing menu bar in the same line with toolbar… generally speaking making app window show the most important thing – THE DOCUMENT. By the way, AA fonts with this size look awful!!! After 10 minutes spent on looking at them most persons have a headache… Let’s make AA fonts but ONLY greater one…
As a graphic designer and having created many web applications, I agree with Dimi’s comments about the icon buttons being above rather than left is disruptive with what people expect. However, I feel both ways have its merits, only that the left side is more common and “safe”. If icons on the top is better as Eugenia says, ok. Let’s prove it with usability testing and hard data. If 100 people say it’s better after using it, I’m all for icons on top. Anyway moving on..
Tigert’s mockups are good due to their simplicity. I am leaning toward’s Erik’s mockups due to the good layout positioning. My comments are for Erik’s mockups. I think the three buttons “New Folder”, “Show as Files” and “View as List” should be moved above the File Listing box. My reasoning is that these boxes are less used than the Directory nav bar. My cursor and mouse is spending the most time the the text box and navigating the tree. If they’re next to each other, my mouse is hardly moving much and the keyboard tab order TAB/SHIFT-TAB is just a few keypresses away. I’m hardly make new folders, or modify the view more than once. I navigate the tree dozens of times either typing or clicking the tree view to get to where I want to be.
The idea of making directory navigation using “buttons” strikes me as odd and different. One idea I have is to make the directory tree not buttons but use text hyperlinks (web style like WinXP). I know this is radically different but hear me out. I like the cookie crumb idea. I think we should entertain the ideas of the “back/forward button, show the path but can’t click on it to navigate” and the “path as folder buttons, use left/right arrows to navigate deep folders”. I propose a third idea. Use web style text hyperlinks as each folder seperated by a forward slash. If the folder tree is shallow, the folder tree fits and there’s no problem. A deep folder directory would show the deepest last three folders, prefixed by “… / folder 1 / folder 2”, followed by a “>>”, “Show Path” button or some type of icon to indicate a way to show the entire path. Upon clicking this button, a tooltip pops out with the whole path and clickable hot links per folder “/ home / user / folder 1 / folder 2”, etc. Or add left and right arrow buttons just like Erik’s mockup but keep the directory as hyperlinks.
Please no flames, only constructive comments. I will try to make mockups of what this looks like soon.
This Dialog adds the “Last Folders” Drop Down and removes the “back” Button.
I think it looks a little cleaner now, I’d also drop Size and Date information,
http://homepage.uibk.ac.at/~csad2715/new_file_diag.png
I like it. It seems more intuitive if that can be judged by a screenshot/mockup. Especially the pathfinder buttons appeal to me, though. I also like the Drag’n’Drop of the “Favorite places”. I could finally modify them to what I need.
I find that too many commentors here are just nitpicking for the sake of it. This mockup tries to fix a basic usability issue (successfully IMO) and some people here still bicker about “Back”, “Forward”, and “Favorite Places” labels. As I see it, if this dialog really works out better than traditional ones, there will be much less need for labels, “Forward”, or “Back” buttons as there will be much less user interaction mistakes.
Thank you Eugenia!
Because “we” read from left to right, people used to reading in that style will scan information in a column to the left first, even if the column is somewhat long, then move on to the next item to the right.
Necessary tool to add include:
Metadata: A button should be added to enable users to add metadata. From this dialog, you would then be able to search on any of a variety of metadata items.
Default Options: You need to be able to define the default look from here. For example, show all files, show as icons, etc.
I still like Tigert’s design the best due to its simplicity, but I’m glad to see people being creative. My feeling is that the default Gnome should stay conservative (like Tigert’s) until user testing shows that more radical approaches like Eugenia’s and Eriks’s are better. They have some interesting ideas, but introduce some new widgets and use buttons in a new way. Hopefully, once a good, though unremarkable, design like Tigert’s makes it into Gnome/GTK+, people can stop wasting their time and energy complaining about the crappy file selector and instead focus on making it better. This, by the way, is exaclty what I’m seeing here today. Bravo.
First of all, the amount of postings in this thread is kinda threatening.
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 partly agree with both points. However I’m not sure that a button in the button area really always implies that it will dismiss the dialog. Think of the “apply” button in many dialogs. I agree though that this is somewhat unusual and that was exactly one of my doubts. It’s hard to find a different place for this button where it wouldn’t look sucky if it would appear only at some contextes.
As for the current location, I’m not really convinced that it’s a good idea to expose the entire URI to the user, but probably unavoidable as long as those dialogs are needed. :/ A simple label like on Federico’s current work[1] would probably do the job and if it’s added, the “New Folder” button could be placed to the right of it. Both could be shown at the top in one row.
My maint point is, that it should be as straight forward as possible and I like the integration of the “Parent Folder” item, because it seems _really_ hard to find a decent position for the Up button anywhere else. While TigerT’s layout works, I’m not happy with the Up button beeing so far away from the file list. :/
BTW, I also like ROX a lot, that’s good stuff. I just think that today it would be possible to go even further. Why should you have to save a document in the first place? How I imagine it to work would be to simply choose “Create Textfile” or “Create Spreadsheet” in your filemanager whereever you want to have the document (exactly like “Create Folder”), then you use any application to view or edit this file. The whole concept of using the empty buffer of an application to create a document and then save it somewhere seems unnecessary to me.
As for downloads in the web browser, I don’t see why drag and drop couldn’t cover this part as well. I remember that this worked flawlessly in BeOS, why shouldn’t it anywhere else. Just drag the link (of course Icons would be optimal) whereever you want to save it. It also goes the other way around, for example when you attach a file to a web form, you often have a “browse” button to select your file of choice. It would make more sense IMO to simply drag a file to it, just like you’d drag a file to an Evolution window to attach it.
The only time where drag and drop would break is when download scripts are used which don’t allow you to download manually (never show you the actual link to the file). But those really suck from a usability perspective.
[1] http://primates.ximian.com/~federico/news-photos/gtkfilechooser-200…
I don’t see how this is any better than the KDE file selector. Its just different, meaning new users will have a learning curve to figure it out.
It doesn’t look simple, but it looks more or less feature complete. I suggest some modification to layout and possibly something that stands out, is larger and more bubbly. Like large, easy to understand buttons, etc. I understand directory structures and know how to navigate them, but do end users really need the directory path thing? That just seems confusing, to me. Without it, or with a simpler replacement I’d be pleasantly surprised to find this in 2.6.
Personally I enjoy KDE’s directory navigation. One button for previous directory and one for the directory up from your current possition in the tree. Two buttons, simple. Microsoft uses just the up-one-level button in 2k and that works fine, too. K.I.S.S.
We don’t have a “New Folder” button on our desktops, right? So if it works in the context menu of Nautilus, shouldn’t it be sufficient to put it into the context menu of the file dialog?
– Stable order: in the two-dimensional layout of locations, the elements will move in unpredicable ways when new rows and columns appears when the window is resized.
– Alphabetization (or any other ordering) is less evident in 2D than 1D. Is the order row-first? column-first?
I agree completely with these remarks.
I like the Navigation Path. Instead of highlighting the selected directory I would simply show it as depressed button — the elements of the path look like and behave like (coupled) buttons, so they should be buttons.
The mockup I like most is the second one of Erick.
I would like to suggest the following additions:
* use a scrollbar for the favorites if they don’t fit anymore, because it is easier to use than scroll buttons IMHO; there should be no scrollbar as long as the favorites fit
* the vertical spacing and even the icon size and text size of the favorites should scale down to avoid a scrollbar as long as possible (the minimum size of icon and text is the same as used in the file list); I think MacOSX is doing that
* it should be possible to add application specific shortcuts like in KDE
Otherwise: great work and good discussions so far; I’m looking forward to the new file selector
I like Erics version the best because:
– in Eugenias version there are utility buttons between 2 ‘selection’ areas. What I mean is : if I push on a shortcut, I immediately want to see where I ended up (did I select the correct destination), the buttons between then form a barrier I must cross first.
– if I drag&drop a new shortcut from the file selection area to the shortcut area I again have to cross the button area, which seems counter-intuitive. Also having the shortcuts on the left shortens the distance you have to travel while ‘dragging’, important because your finger might slip or if you have an unreliable mouse or something.
Just a few thoughts regaring the various vertical versus horizontal discussions. I like some things about both Eugenia’s second dialog (the wider one) as well as Erick’s dialogs.
I think the concept of ordering things from top to bottom is reasonable, but I think where problems come in is that the ordering doesn’t fully match up to out though processes. For me (and probably others), the first think I think of when using a file dialog is “Is my file in the file selector?”. If I don’t find my file, my next thoughts are “Where am I?” and “What is the best way to get to the proper location?”. Granted, as long as I know where my file is, I don’t really need to know where I am, but I tend to think in terms of “Go from here to there and then get the file” rather than “Get the file from there”. In my mind, this is more of a parallel of retrieving physical objects.
If I were always going to select a location, I agree that the top would be the best place for it. However, since it is more of an optional thing, I don’t think that the top is the best place for it. Top to bottom and left to right are fairly ingrained concepts for speakers of many languages, but not all of them so I am not sure how well this would translate to other languages.
Some people have mentioned photography. I am by no means an expert, but I have heard that you want your main subject to lie on or near the lines created when dividing the image into thirds horizontally and vertically. Our focus tends to go to areas around the middle, so the file selector should occupy at least part of it. The other mandatory parts should flow from there, and the optional things should be farther from the center. The optional things should be more of a frame (tall and narrow if on the side, or short and wide if on the top or bottom).
I find it interesting to consider something which is a bit of a departure in some regards (note that I am tossing this out for discussion and have not fully thought this out). File selector occupies the middle and the middle of the left side. Current location is listed above the file selector along with the viewing preferences. Navigation widgets are located on the right in some manner such that they lie within an imaginary rectangle which is tall and narrow. The “open” and “cancel” buttons are located on the lower left.
The idea behind this is that the first thing to grab my attention is the file selector. If I don’t find what I want, I look up to check where I am (this feels natural due to its consistency in web browsers, and may also tie to the idea of physically looking up from what you are doing to check out where you are and what is going on). I then look to the right side to tackle my navigation. Having the navigation on the side seems reasonable since it is sort of a mental aside (I have been sidetracked from finding my file by having to navigate to the right location). I then draw my eyes to the left to return to the file selecotor and after I select my file, my eyes continue to the left and proceed down to the open or cancel buttons.
This seems like it would flow well for me, but I can’t be sure about other people. The other thing I like about it is that by putting myself into a right-left sweep at the end, the “cancel” to the left of “open” doesn’t seem so backwards since it separates me from the inclination that the first button I read should be the most commonly selected buttom.
Any thoughts?
Daelin,
to get to “Movies/TV/StarGate SG-1/Whatever.avi”
I want to type Mov, tab complete and hit /. Mentally at that point, if I were on a shell, I’d be IN that directory, so I want the file selector to assist in this image, rather than showing a different one.
Yes! When you first mentioned it I was somewhat afraid of the file selector dancing around my folders (I know that is not what you meant, that was just my first fear), but the more I think of it the more I like it, since there is really no need to stay in a folder where you do not want to open/save files. And it is probably the way everyone uses the shell (I do at least in Mac OS X), so it is indeed a proven way.
Somebody get rid of my “Go” button! ^_^
I made another mockup,
http://homepage.uibk.ac.at/~csad2715/new_file_diag2.png
but I just realised, that I actually like tigerts Dialog best.
If only the topmost dropdown-Box would contain the folders I recently used.
I like the idea of Path Navigator (and the SGI method).
A feature I’m missing is opening multiple files from mulitiple folders. I’d like to be able to select them without opening the file dialog again for every folder.
Personally I think the new file dialogs in Windows XP are better. They are really minimalistic, but still manages to include most of the functionality needed.
My initial concern is that this looks like it’s changing the file selector from being a “GTK” (i.e. toolkit) selector, to a “Gnome” (i.e. environment) selector. I run neither Gnome nor KDE — in fact I don’t run any desktop environment, except to the extent that my Fvwm configuration defines what I consider to be my chosen environment. Hence, I don’t have any of those “location” or “favorite” shortcuts. I do run several GTK apps. The most useful thing for me would be a filesystem tree view in the left pane, and a file view in the right. This handily removes the need for the “path navigator” or a back/up/down/forward button cluster. It seems quite intuitive to me as well. I realize this sounds very “old school” to some people, but there are still a lot of us who prefer to work with the filesystem the way it sits. I’m not saying that the “locations/favorites/bookmarks” thingie is bad for all people, but neither is it the proper way to go for everybody. So sure, have an optional widget that’s reactive to the available metadata from the desktop environment — if it’s there. But don’t assume it will be.
Regarding the “Search” text widget. I can’t imagine using a file-selector dialog box without it. [and perhaps I completely misunderstand the “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…). ” remark] Particularly for large directories, having to use the mouse and scrolling functions to find/select a file, when I know and can type the name much more quickly, would be a major pain. I agree that calling it “Search” is not the correct term — it’s overly broad. “File[s]:” seems the most direct/simple. Having the tree/filename panes reactive to this is something I find exceptionally useful, and TAB completion too.
Does one look have to exclude the others?
Why not include a few schemas/themes with gtk2 as standard
so people can choose whatever they like and add their own
layout in case they’re not satisfied with the included?
My idea is directories in the path to become clickable hyperlinks separated by the “/” symbol.
Left and Right arrows may be positioned:
1. One by one to the left of the path
2. Left most and right most, justified to corners of files list.
Eugenia’s top down design is solid. I would be happy with it as long:
1. tab completion works in the search field, and
2. regular expression search works in the search field.
What about saving and opening files located on:
a. An unmounted partition (nfs, usb hd and flash memory, samba)
b. ftp:///
c. scp:///
This could be implemented with a “Location field” of some sort.
Maybe it’s just me as a non-gnome user, but I would _love_ to see the options to filter on certain filetypes and choose these myself. This thing has always bothered me the most when useing gnome apps under different DE’s.
I have used gnome-apps and when saving, they didn’t automatically add the common filetype-extension for that type of file. Since the option “choose filetype” is non-existent in the fileselector when saving/opening, I didn’t know what the extention should be. Mime wasn’t always recognizing the file and without extention, neither was I… Good luck finding the right app for your UFO.
Make it larger by default! Make it BIG! Huge! Humungous!
In all of the mockups i’ve just looked at, you can see a total of about 8 files. Personally, i have many directories containing more than 8 files. It’s really annoying to have to scroll around a poky little window… it’s really annoying to have to scroll at all.
Is there any reason the open dialog shouldn’t fill almost the entire screen?
Is there someone working in fisheye menus? There is a good
example by HCIL Lab.:
http://www.cs.umd.edu/hcil/fisheyemenu/fisheyemenu-demo.shtml
Wow, that would probably take some getting used to, but pretty nifty. Only thing I don’t care for is when you move your mouse pointer over to the right to slow down the scroll, when you move it back over to the left, the menu goes back up to the top of the list.