Linked by Eugenia Loli on Wed 7th Jan 2004 01:28 UTC
GTK+ 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.
Order by: Score:
v image?
by MB on Wed 7th Jan 2004 01:33 UTC
Wow
by Quadu on Wed 7th Jan 2004 01:40 UTC

This really should be implemented, it's beautiful and intuitive! Perfect replacement, I'd say.

:)
by Anon on Wed 7th Jan 2004 01:43 UTC

This is very creative, Eugenia. You should be a Gnome developer. They really need a creative woman's touch. In fact, come to think of it, along of UI programming needs that.

Not Too Bad
by Matt Jones on Wed 7th Jan 2004 01:43 UTC

The great thing about the new gtk file selector is that it is completely modular - you can switch between tigert's and eugenia's. Someone should make a setting to allow one to choose (or, atleast, a gconf key). Although i initially thought this selector was a bit weird, its actually kinda nice. But, I think the file type should be on the bottom, by file name. A bit more intuitive. And the buttons for path look a bit weird, although possibly very useful.

But, is it HIG compliant (this isn't a joke - HIG-stuff normally looks very nice - just look at gimp 1.3: all HIG, all beautiful)

Re: Not Too Bad
by Anon on Wed 7th Jan 2004 01:51 UTC

True, HIG is very important.

Not Bad, But...
by Erick on Wed 7th Jan 2004 01:53 UTC

I hacked it up a bit. Have a look:

http://www.gnomepro.com/gtk-file-sel2.png

I am sure that Federico will come up with something brilliant that impreeses us all! :-)

Keep the tab-completion working!!
by Anonymous on Wed 7th Jan 2004 01:54 UTC

Whatever you do what the GTK file selector PLEASE KEEP THE TAB-COMPLETION funcionality. Yes, new users don't care about it. But I bet that experienced shell users apreciate it. Personally, I love the file selector over the rest. I don't care a lot about the UI, I just know that the gtk file selector is the only one that does it. I appreciate it a lot. I'm used to things like /us<TAB>sha<TAB>, and there's no mouse in the world that can be faster than that.

RE: Not Bad, But...
by Eugenia on Wed 7th Jan 2004 01:55 UTC

Nice one Erick. ;)

question
by Anonymous on Wed 7th Jan 2004 02:04 UTC

Is fileselector only meant for opening files or is it also used for saving files?

RE: question
by Eugenia on Wed 7th Jan 2004 02:05 UTC

For saving files as well.

Some comments
by -=StephenB=- on Wed 7th Jan 2004 02:05 UTC

Eugenia:
In the risk of having a few thousand Unix traditional users cursing at me, I decided to leave the "Filename input box" in. One of my test mockups had it in only as optional, but I understand that it is not yet the right time to ditch it completely (soon my friends, soon...).

That makes sense for an Open file selector, but what about a Save/Save As one? How would the user specify the filename?

Other than that, it looks/sounds pretty good.

RE: Some comments
by Eugenia on Wed 7th Jan 2004 02:07 UTC

> That makes sense for an Open file selector, but what about a Save/Save As one? How would the user specify the filename?

Yes, indeed. I created my mockup mostly working on the "Open" side of things, carried away by Tigert's title on his mockup.

RE:question
by Audun on Wed 7th Jan 2004 02:07 UTC

and.. if it's only for opening files, why is there a big new folder button (which I always bumps into)

"focus"
by Sean Etc. on Wed 7th Jan 2004 02:08 UTC

You mention the pathfinder-like navigation buttons "gain focus" when selected - tell me you didn't actually mean that? Focus should be given to things where users are actually going to use the keyboard, like the path entry or icon list. I think what you meant is that the button for the current directory should be visually highlighted in some way, so as to make it clear which directory the user is in. That isn't focus, in X terms, as focus includes also keyboard input.

Well, I've seen better
by Anonymous on Wed 7th Jan 2004 02:10 UTC

It just doesn't work for me. It needs something. I'll stare at if for a little while longer.

accessibility
by Sean Etc. on Wed 7th Jan 2004 02:13 UTC

just a quick note, you *must* (i repeat, *must*) have buttons for adding and removing items to the shortcut list, because there are people who are unable to use drag-n-drop, and context menues are not discoverable.

that said, I like erick's modification with the shortcut list on the left. one thing to remember is that windows which are wider than they are taller are more aesthetically pleasing, due to the shape of our screen. the "Favorite locations" label is also nice. again, tho, those "helpful" drag-n-drop labels should be gotten rid of, and nice clear (and accessible) Add/Remove buttons are needed.

so far as saving, i believe (not sure) the new API is capable of changing the UI based on whether an open or save operation is being carried out, which is a *good* thing. it is also hopefully capable of changing the UI based on whether a file or directory is being selected. (for example, personally, i'd like files to not be shown when selecting a directory, at least by default, and have the option to show them in the event I need to select a directory that has a certain file and somehow manage to forget my nice clean folder layout.)

Re: Some comments
by -=StephenB=- on Wed 7th Jan 2004 02:13 UTC

>> That makes sense for an Open file selector, but what about a Save/Save As one? How would the user specify the filename?

>Yes, indeed. I created my mockup mostly working on the "Open" side of things, carried away by Tigert's title on his mockup.


Ah - I figured it was either that, or you'd been reading that Pavel Cisler interview where the talks about wanting to eliminate file save dialogues altogether ;)

RE:question
by Eugenia on Wed 7th Jan 2004 02:16 UTC

> and.. if it's only for opening files, why is there a big new folder button (which I always bumps into)

It is mostly a historical remnad. Sometimes people might want to move a few items around in a new test folder (or duplicate a file) and then use that instead of using the original file. It is not a very common action, but it happens to me, mostly when I work with PaintShopPro and graphics.

> I think what you meant is that the button for the current directory should be visually highlighted in some way,

Yes, this is what I mean. Visually focused to be distinguished by the other buttons. I am sure most people would understand what I meant there.

File Selector Views
by Dmytro Taranovsky on Wed 7th Jan 2004 02:18 UTC

An important feature lacking in many file-selectors is multi-column view. If one can see only a single column of names, then it may take a long time to find the needed file. By contrast, when a file selector is maximized, with multi-column view one can get a panoramic view of all or many files in the folder. Let us hope that GTK-2.4 file selector will include multi-column view and other features and options that make finding files easier.

Back button
by Audun on Wed 7th Jan 2004 02:19 UTC

I miss the back button..

If I use the nice path buttons it's ok, but if I accidentally push one of the shortcuts, I need a way to get back to where I was..

Cool
by Alex on Wed 7th Jan 2004 02:19 UTC

Sounds like some good suggestions.

I also remember once that you criticized the KDE file selector, can you write up a similar little article, for me it sben great and I haven't seena ny usability problems except that in soem view modes it wont seem to remember on 3.1.

It would be great if you could do this, you seem to have an eye for this stuff and kde-usability alwaysa appreciates constructive criticism.

RE: accessibility
by Eugenia on Wed 7th Jan 2004 02:21 UTC

>the "Favorite locations" label is also nice

I believe that it is not needed. You don't give a title to the main file selection area either. These should be intuitive enough.

>you *must* (i repeat, *must*) have buttons for adding and removing items to the shortcut list

If there are people who can't use drag n drop, the toolkit should offer a mouse driver that allows that (e.g. click the fourth mouse click to select a file, navigate somewhere and reclick that button to drop it). The accessibility should be in the toolkit level in this instance, not in the UI level necessarily.

RE: Cool
by Eugenia on Wed 7th Jan 2004 02:24 UTC

> I also remember once that you criticized the KDE file selector, can you write up a similar little article

There is no reason to write a similar little article. Just rip this idea and move it to KDE if you need to. It would work regardless of the toolkit. ;)

One thing about Erick's mock-up
by Brad Griffith on Wed 7th Jan 2004 02:25 UTC

There is a line dilineating between the two main columns on the window (between "Favorite Locations" and the main file selector area) that intersects with the line that separates the "Cancel" and "Open" buttons from the main file selector widget. This intersection makes it seem a bit more cluttered than the other two mock-ups--notice how the other two have a distinctly separate area for "Cancel" and "Open." Just an observation.

I like Erik's
by Mutiny on Wed 7th Jan 2004 02:26 UTC

Something just isn't "right" with protrait windows. I don't know why, but I don't care for them. Maybe because monitors are landscape?

I like the shortcuts on the side and especially the "Drag folders here" option to add your own shortcuts.

I do think that the proper place for the "view" and "show as" buttons is above the list, since the actions work on the list rather than the filename.

The search input box confuses me. Filename makes sense and 100% of the users understand how the normal "box right there" usually works.

I don't understand why there is a separator between the open/cancel buttons and the filename. When used as a filename box, having these as a unit helps tell the user that this button works with that filename.

Just a few thoughts. Thanks guys.

Mutiny

more...
by lx3hf on Wed 7th Jan 2004 02:28 UTC

I like Erick more..

Re: Audun - Back button. I second your comment. Add it to the Erick's mock would be perfect.

Nice
by Rayiner Hashem on Wed 7th Jan 2004 02:31 UTC

I think its pretty spiffy, but I've got a few gripes:

- You turned the path input box from a something you could type in to something you have to click. I use that feature pretty much exclusively. Who wants to have to click through all of those folders when you can just type the path into the box?

- I like the location bar on the left, just for asthetic reasons.

Otherwise, it looks very cool.

Oh, and the size column...
by Brad Griffith on Wed 7th Jan 2004 02:31 UTC

Like tigert, I would leave the size column off of the file selector. I don't think file size ever has much to with opening a file in an already open application.

RE: I like Erik's
by Eugenia on Wed 7th Jan 2004 02:31 UTC

Erick's mockup has a more traditional approach. Many people are just used to it because all other OSes use this paradigm. The two mockups do not follow the same logical flow (on Erick's mockup you go from left to right and then down-down while on mine is a simple top-down - you need to use it to feel the difference).

>Back button. I second your comment

There is no need for a back button. Bloat of the interface just to go around a possible/rare user error.

Loved it
by Victor on Wed 7th Jan 2004 02:31 UTC

Loved it. Hope the GTK people will see this one... i kinda liked Erik's more, but maybe it's just me...

Victor.

I like them both but...
by Bob on Wed 7th Jan 2004 02:41 UTC

I like Eugenia's a bit more. Simpler layout.

Scriptable
by Lipo on Wed 7th Jan 2004 02:41 UTC

Indeed the result is nice. But so are lots others in different OSes. But I think that the best design comes from expressing visually the process of opening, saving etc... of files and firectories.

Now although I linke what I saw I see that one bill does not fit all.

So I think that it would be best if the layout and usage of components would be scriptable. Then create 2-5 most used scenarios and name them. Then allow developers to extend them or rewrite the script if they need that.

I think that would be a perfect file chooser.

Back button
by lx3hf on Wed 7th Jan 2004 02:42 UTC

> There is no need for a back button. Bloat of the
> interface just to go around a possible/rare user error.

Unfortunately, I use back/forward buton rather often.

Re: Not Bad, But...
by Jeremiah on Wed 7th Jan 2004 02:42 UTC

Regarding Erick's Mockup:
I agree with the others who have questioned the separator between the files and the open/cancel buttons, but I LOVE the "Favorite Locations" label and the "Drag & Drop to add..." those were the first things I noticed! If you have enough favorites to fill the window you won't see the labels, and if you have the stock layout you have the white space there anyway. Best to put a little explanation there! I also prefer the landscape layout to the portrait one. I can't fault Eugenia's logic though.. The vertical does make more sense; I just like the look of the other better.

RE: Back button
by Eugenia on Wed 7th Jan 2004 02:44 UTC

>Unfortunately, I use back/forward buton rather often.

These are implemented with the Path Navigator widget. Read the article before commenting. What these readers are asking is a "back" button after have accidentally clicked something on the *shortcut* list, not in the main file selector widget.

Re: Nice
by bsdrocks on Wed 7th Jan 2004 02:51 UTC

Same here, sometimes I do type the path by myself because it's quick task. Well, everything what you have said and I agree.

I'm leaning towards Tigert's mockup
by Ronald on Wed 7th Jan 2004 03:13 UTC

1. Folders should be seperated from files
2. we are moving from 4:3 to 16:9, so it should be wide not tall
3. drop the "View as" button. "View as List" is enough for an open/save window. It's not a full blown file manager here.

The window should be like a mail client view: left shortcuts, up right folders and down right the files themselves.

I wish I was good at making mockups. ;)

Seems to me that tabs would do a better job of reflecting each level of the path as a separate view into the filesystem. Kind of the same way radio buttons imply only one of the available choices, tabs imply that you are switching between views.

I think one major problem that people have is that they "click on a button and everything changes." The more tightly we can tie visual clues to changes in sections of the interface, the better.

As far as top-down vs. shortcuts on the left, I'm not sure your argument that there's better flow is really valid. It seems that the favorite places is an optional part of the saving or opening process, and so putting them off to the side is as logical as anywhere else and takes better advantage of screen real-estate.

Customizing shortcuts!
by WorknMan on Wed 7th Jan 2004 03:15 UTC

I really don't care how they do it percisely, so long as there is the ability to customize ths shortcut list - that's important. I hate not being able to customize the shortcut list in the Windows Open/Save file dialog. (I can customize it by picking from a static list of locations using TweakUI, but I can't add my own.)

I changed it...
by Erick on Wed 7th Jan 2004 03:16 UTC

I made a few changes based on feedback here. Both are now included in the original image. Check it again, if you want to.

http://www.gnomepro.com/gtk-file-sel2.png

> Seems to me that tabs would do a better job of reflecting each level of the path as a separate view into the filesystem.

Yuk, no please. They are big and fat and ugly. ;)

Search Label
by alanj on Wed 7th Jan 2004 03:25 UTC

It's probably not a good idea to label the filename field as search, for a couple of reasons.

First, what about when the dialog is being used to select multiple files. That field should ideally do similar to what Windows does, and contain multiple file names. Search wouldn't make much sense if a user was control clicking on individual files to choose multiple files.

Second, it's fairly vague to say search. We search for all sorts of things... does your search box search Google? I know that's absurd, but really, does it search the entire directory structure? Does it search recursively through the visible folders? Basically, it's not very concise to say search, especially when the window has the primary purpose not of finding files, but of choosing files.

Another thing I might mention is that a dropdown box isn't really much more difficult than the path selection buttons... although the path selection buttons are pretty cool. With the dropdown box, you click, then move the mouse to select the proper folder, and then click again. Once you get to a path that is deep enough in terms of characters, the path buttons are going to require a click or two, then moving the mouse, and then another click. So, I don't really see much benefit... in fact, it makes the file selector look more cluttered.

Re: I changed it...
by bsdrocks on Wed 7th Jan 2004 03:27 UTC

It looks much better, I like it. :-)

Looks good except...
by Anonymous on Wed 7th Jan 2004 03:31 UTC

...just don't change the file locator from "filename" to "search". If I wanted to search for a file, I could use the gnome find utility. More often than not, users who use the file selector know what file they want to open/save and where it is located. If not, they could use the find utility as mentioned above. It would be a usability error to replace "filename" with "search".

RE: I changed it...
by Anonymous on Wed 7th Jan 2004 03:39 UTC

Good job Eric. I'd be pleased if the new file selector looked like your latest mock up. And let's hope it will continue to be a work in progress.

A question
by clausi on Wed 7th Jan 2004 03:43 UTC

Nice mockups. However, a comments on Eric's and Tiggert's:

Does it make sense to have a "Favorite Locations" _and_ and "Bookmarks" widget? IMHO, only if "Favorite Locations" wouldn't be editable and this would be horrible.

I can't stand, for example, the "Documents" item because it reminds me on Microsoft and my first action would be a right-click to get a "Delete item" menu. Same to the CD-ROM item because I don't open files from the CD-Rom drive very often.

But then an extra bookmarks widget makes no sense.

Tigert dialog
by Deb Ian on Wed 7th Jan 2004 03:45 UTC
I like Eugenia's
by Felix on Wed 7th Jan 2004 03:51 UTC

I personally think that wide screens should mean taller windows. My favorite UIs are those when I can have two windows on screen at the same time, arranged vertically. Wide dialogs always get in my way.

Of course, an Open dialog box is pretty meaningless to me. I haven't used one in a very long time. And the new GTK API, IIUC, will mean that I can use XDS saveboxes a la ROX instead ;)

RE: RE: accessibility
by dc on Wed 7th Jan 2004 03:55 UTC

>If there are people who can't use drag n drop, the toolkit
>should offer a mouse driver that allows that (e.g. click the
>fourth mouse click to select a file, navigate somewhere and
>reclick that button to drop it). The accessibility should be
>in the toolkit level in this instance, not in the UI level
>necessarily.

Hmm, what if I can't do dnd because I can't use a mouse ?

Up button.
by chicobaud on Wed 7th Jan 2004 04:05 UTC

> Unfortunately, I use back/forward buton rather often.

So do I. Since we are commenting, may I suggest the addition of a "Up" button (I use it quite often).

RE: RE: accessibility
by Felix on Wed 7th Jan 2004 04:06 UTC

Hmm, what if I can't do dnd because I can't use a mouse ?

In one of the various discussions on DnD and copy and paste in Linux on one of the usability or freedesktop.org lists hosted by Red Hat, someone---I think it was Thomas Leonard of ROX, but I'm not certain (sorry I'm being really vague, but there's a link to the discussion from somewhere on http://rox.sf.net/ ---suggested, accurately in my opinion, that copy and paste should be a synonym for DnD, so that wherever you can drag and drop, you should be able to copy and paste and vice versa.

So if you don't have a mouse, you should select what you want, Ctrl+c, select where you want to drop it, Ctrl+v. Seems simple and logical enough to me. (I would add that the clipboard should be more permantent than DnD, and selecting something to drag and drop it should only overwrite the hackers' clipboard (PRIMARY?), not the real one.)

RE: Up button.
by Eugenia on Wed 7th Jan 2004 04:10 UTC

> So do I. Since we are commenting, may I suggest the addition of a "Up" button (I use it quite often).

Please read the article carefully before adding such one more uniformed comment. The Path Navigator eliminates the need for "Up".

nice interface
by ace on Wed 7th Jan 2004 04:13 UTC

Eugenia you are the woman!!!

RE: RE: accessibility
by Felix on Wed 7th Jan 2004 04:14 UTC

Here is what I was talking about:

https://listman.redhat.com/archives/xdg-list/2003-August/msg00128.ht...

Not quite as detailed as I had remembered, but still a good idea IMHO.

Up Button is still needed.
by chicobaud on Wed 7th Jan 2004 04:28 UTC

Please read the article carefully before adding such one more uniformed comment. The Path Navigator eliminates the need for "Up".

I just would like an up button icon. Don't tell me about clutter... In my daily usage it would make my life much easier if an icon was there (preferably next to "new folder"). That's just my personal opinion (and I did read the article, thank you).

Looks good BTW,
I wish the dev team include a similar file selector "save/open file" dialog.

My thoughts
by Spark on Wed 7th Jan 2004 04:30 UTC

Great, just when I was about to go sleeping, such an interesting topic gets brought up. :/

Recently, I came to my personal conclusion, that "filechooser" dialogs are pretty much obsolete already. Sure, we still need them, but they don't really play as much a central role as they used to.
For example when opening a file, in most cases it feels much more natural to navigate to the file via the file manager and then open it like you'd open a folder. Opening a new application just to select "open" and use the mini-filemanager of the application to browse to my file of choice seems more and more awkward to me, even when I'm already working with this application.
When it comes to the save dialog, my thoughts are similar. We still need that one, but I think that the whole concept of "saving" isn't very logical and basically just a legacy implementation detail. Why don't we just use our filemanager to create a new document at some place and then use a tool (application) to edit it? There are many reasons why this wouldn't work well yet, but those are mainly technical reasons, which will be solved some day.

With this in mind, I see those dialogs mostly as a band aid and don't believe that too much thought should be put into them. Of course we need a reasonably good one for the time being, I just don't think that it's important to do anything groundbreaking with them. The way I see them used in the future is mostly for selecting special locations, for example to tell your web browser where you want to have your downloads saved by default.

So, what I'm trying to get at is (Notice that I'm never able to use few words when I'm tired), that I believe that the file chooser should be really simple, other than that I don't really mind. I think that the mock ups of TigerT, Eugenia and Erick are really nice and I would be happy with either of them, even though I don't think that anyone of them is really ideal.
What I don't like about all three of them is, that they don't really keep in mind the different scenarios. There are basically three of them: Choosing a file, choosing a folder and saving a file and what you want to do differs a lot between those scenarios. For example you don't need to enter a filename when choosing a file or folder (though die-hard Gtk freaks will kill you if you remove their tab completion), but this is the primary action for save dialogs. You don't really need "new folder" in the open file dialog, but it's necessary for open folder and save dialogs. And so on... So I'd really love to see more attention at separating those tasks and actually making use of the possibility to show different dialogs with the new API.

I also have some more doubts specific to Eugenia's layout.
Shortcuts at the top: There are several problems with this. For one, we don't have a widget yet which could do this, so it would extremely alien with everything else. I don't really think that the file dialogs are special enough to deserve their own unique widgets. It would also require someone to actually code it up, which is very unlikely for Gtk 2.4 and maybe the work would be better spent on fixing other outstanding problems.
Another big problem is, that this basically only looks good as long as there are only the few locations. Imaging adding five custom locations and it would look rather crowded and bloated already. A list view is much more flexible in this regard.

Basically the same points apply to the path navigator. While I do kinda like the idea, I don't think that introducing such a special widget exclusively for the file dialogs would be a good idea. It also makes it impossible to remember the location of the "up" button, the most common action becomes actually harder to do.

Another thing I'm not happy about is placing so much stuff between the locations and the files. This means you have to travel above them everytime, even though they are really optional as you have pointed out. In most cases you will do this to open a file: "Select location -> select file -> click open button" or of course "Select location -> double click file". Having the locations directly besides the file list makes this faster and also eases drag and drop operations.

If you use the same layout for open and save operations, another thing to consider is that the workflow on save dialogs changes to "select location/folder -> enter filename" or even "enter filename -> select location/folder". In any case TigerT's mockup has all the involved elements directly connected to each other, so as long as not different dialogs are used, I think that's a big advantage.
Also don't forget that their can be custom widgets added by the application. Eugenia-mockup and Erick-mockup don't even consider them and it would look it even more crowded.

To sum it up, currently I think that TigerT's mockup is the most reasonable one, at least for open file operations. I only whish the "New Folder" button wouldn't be there, the Bookmarks button is completely pointless (should go away) and I'm not even sure about the folder drop down list. Also it's a pity that the up button is not above the file list but above the locations, but that's really hard to solve. :/ Maybe the button could be somehow integrated in the file list... Well, maybe something like this could be considered:
http://liebesgedichte.net/Temp/filesel-spark.png
(where the New Folder button would obviously only appear in save of folder selection context)
(and that Parent Folder label is supposed to be bold, but Gimp has another idea of bold than me)

Well, I'm pretty sure that will be shot down anyway for beeing too simplistic, but that's in fact exactly how I would like it to be. ;) Placing the New Folder in the button area probably wouldn't work out for one reason or another, but at least this would make it possible to only show it when it makes sense, without completely breaking the flow.

Uh... good night.

Observations and comments
by Rds on Wed 7th Jan 2004 04:33 UTC

I'm not sure if anyone else mentioned any of this, but here's my two cents. ;)

A) The bookmarks are too crowded
For this, we will be reffering to bookmarks are 'shortcuts' as one, because they are. ;)

The ones on the top are too crowded to be of any use, and the small ones at the center are WAY to small to be of use. The fact that one in your mock-up needed it's name cut off speaks further about then then I possibly could.

B) Two areas for bookmarks are confusing and unneeded.
In both mockups, we have two areas for bookmarks. In one the second list is under the file lists, and the other has it in a dropdown. This is over-complex, and they should be combined into the one 'shortcuts' space.

C) Search
The search lacks a obvious means of activation. If it replaces open when used, then it is over-confusing, if it works on the press of the enter key then the usage is non-obvious. If it constantly updates as it is typed in, then it can and will lead to stress in the user as they watch the files 'vanish.' The fact that I do not know how it would work should say something about it. However, if there was a obvious way to interact with it, this would be a good addition.

D) Size column should not be there.
Opening a file is a question of finding a file. Filesizes are useless, and take visual space that should be better used for file names. File sizes belong in a file browser, not a openbox.

Of course, as I say this, I believe ROX has the perfect file open/save dialog. Namely, the file browser. The file browser already has support for showing any directories in any ways, ROX has shortcut built-in already, and a save dialog that is meant to be drag-and-dropped allows for UNIX-style chaining of actions or just plain saving.

RE: Observations and comments
by Eugenia on Wed 7th Jan 2004 04:35 UTC

>The search lacks a obvious means of activation

It does not require activation. Results are highlighted as-you-type.

That Up Button again...
by chicobaud on Wed 7th Jan 2004 04:38 UTC

I could not see this up button on the www.cocoatech's path finder screenshots either (but it must be there somewhere...).

I vote for
by Anonymous on Wed 7th Jan 2004 04:40 UTC

http://tigert.gimp.org/files/screenshots/filesel-tig2.png

I believe it's the most functional because:

1. You know your current working directory
2. With the "locations" on the left, it allows easier scrolling
3. Not is much emphasis on create a "new folder" (since this is an Open File widget.
4. Easily handle file extensions
5. Must I say it, it's almost identical to Microsoft - which everyone has grown to learn....

Re: Erick
by Alex (The Original) on Wed 7th Jan 2004 04:40 UTC

I believe Erick's one is better

http://www.gnomepro.com/gtk-file-sel2.png

RE: Re: Erick
by Anonymous on Wed 7th Jan 2004 04:47 UTC

I agree. I can't quantify why, but it has a much more professional, and inviting feel.

Save file dialog are past ?
by chicobaud on Wed 7th Jan 2004 04:48 UTC

that "filechooser" dialogs are pretty much obsolete already...
...
whole concept of "saving" isn't very logical and basically just a legacy implementation detail. Why don't we just use our filemanager to create a new document at some place and then use a tool (application) to edit it?


That's a perspective but you still need a "save file" dialog when downloading a file from the network. Unless all downloaded files go to the /home/mary/downloaded_files by default with *all* applications. Just an example. Open/Save dialogs are quite handy for me.

The ideia of "create it first and edit it and *then* save it within the application" is already a bit in use on the "create folder" before add the files to it.

Re: Erick
by Anonymous on Wed 7th Jan 2004 04:49 UTC

Ericks one looks very nice

Good Stuff
by Eric on Wed 7th Jan 2004 04:50 UTC

I really dig this. The "Path Navigator" is an awesome idea. The verticalness of it does look a little odd, but I think it is justified.

Instead of having a tab-completed search, the search should be interactive (like XMMS's jump to file search). Why make users have to hit an extra button? Plus it makes it seem more responsive.

RE: Rds
by Anonymous Coward on Wed 7th Jan 2004 04:51 UTC

File sizes belong in a file browser, not a openbox.

And if I don't remember which DSC000????.jpeg I'm looking for, but know approximately what size it is? Hm... that reminds me... they're all missing a preview pane...

Save file dialog are past ?
by Felix on Wed 7th Jan 2004 05:00 UTC

That's a perspective but you still need a "save file" dialog when downloading a file from the network. Unless all downloaded files go to the /home/mary/downloaded_files by default with *all* applications. Just an example. Open/Save dialogs are quite handy for me.

The general approach to that scenario is to simply provide an icon which you DnD to where you want to put it. Take a look at---sorry to sound like a fanboi---ROX. A ROX app like Edit doesn't contain an Open dialog box, and the rarely used New command is at the bottom of the File menu (ROX apps have a very different UI from the standard one. I find the stark abandonment of the past very useful), with no toolbar item. When you ask to save the document, you are presented with a dialog box containing an icon representing a text file and a filename text entry. You can, if you feel like it, enter the entire pathname into the filename text entry (e.g. ~/Documents/Random/foobar.txt), or you could simply enter the filename and drag and drop the icon to an XDS-supporting file manager window. Or indeed to Archive, and have it automatically compressed, which gives you a similar dialog for the compressed file. And/or the SSH/SCP wrapper and automatically upload the (possibly compressed) file. (In fact, any program that can accept text on stdin by being called with the - argument will work.) In the case of a file browser, you'd get presented with a savebox which you could then drag to Archive and drag the icon to wherever you want it to go.

[If all this dragging and dropping sound tedious, ROX applications tend to be small and single-purpose, rather than the monolithic applications favored by Windows and to some extent Gnome. As such, they mostly stay out of the way, so dragging and dropping is less of a chore. And as I mentioned in a previous post, DnD and Copy and Paste should be unified.]

Down with mini filers! ;)

RE: RE: Rds
by Wrawrat on Wed 7th Jan 2004 05:05 UTC

Preview pane, yuk! Well, I don't mind having one... as long as I can disable it. ;)

Personally, I prefer TigerT's selector, although they're all good.

Re: My thoughts
by Felix on Wed 7th Jan 2004 05:06 UTC

Well, maybe something like this could be considered:
http://liebesgedichte.net/Temp/filesel-spark.png


The first thing I'd say to that is the New Folder button cannot go where it is. By putting it there, you're implying it'll dismiss the dialog and create a new folder with the name in the Filename box. Most programs wouldn't appreciate that ;)

Secondly, I do think you need to put some context into where you are. I might have three similarly-structured programs that I'm working on; your dialog would confuse me if the filenames differed by one file in one folder and I forgot which it was, and was trying to find it, and thought I was in a different directory tree. (Which sounds like a lot of assumptions, but it isn't.)

I'm also inclined to say that Locations bars like that seem too much like folder trees. Perhaps I'm odd like that though.

...
by Anonymous on Wed 7th Jan 2004 05:07 UTC

I saw the "Network" button. Will work on the new GTK file selector?

TigerT
by lx3hf on Wed 7th Jan 2004 05:10 UTC

After comparing (visual only) TigerT, Eugenia and Erick side-by-side, I kinda like TigerT more (initially was Erick). It just... feel right.

v Not your decision
by Jim Jones Freaky on Wed 7th Jan 2004 05:14 UTC
RE: TigerT
by Eugenia on Wed 7th Jan 2004 05:15 UTC

> It just... feel right.

No, it just feels "common ground". This doesn't make it right. Innovation is not alway intuitive at first, remember. ;)

Sky
by Kevin Arvin on Wed 7th Jan 2004 05:17 UTC

I made this mockup for the SkyOS contest. I like the tabs for the shortcuts since it makes it easy to see which folder you are in. I also prefer the forward / back buttons to the path navigator as the navigator looks cluttered.

I wuold prefer to just right click on the forward / back buttons, or have a path button like Apple does.

http://www.dmrtc.net/~kvnrvn/sky/Dialog.jpg

Re: Not your decision
by Felix on Wed 7th Jan 2004 05:19 UTC

Did anyone else think to just let the Gtk and GNOME people handle this?

Of course they will have the deciding vote, but many hands make light work. Seeing as we're only putting ideas forth but sensible people will veto before they're all included, too many cooks won't spoil the broth.

Half the reason to use open source is because people's ears are stronger.

What I learned today...
by Eric D. Fields on Wed 7th Jan 2004 05:26 UTC

...that something called ROX exists, and that it is probably the most innovative open source desktop enviornment out there. I hope GNOME steals a few of its ideas (DnD everything and the ROX-Filer system looks awesome, but may just happen naturally after things like spatial Nautilus and GNOME FS become the norm).

Oh yeah... um, defnitely something like Erick's 2nd model is the way to go. I like the way the "Favorite Locations" panel is labled in the first one though; including that title within the little grey box makes it seem all the more a special little enclosed place of wonder that it _is_.

RE: TigerT
by lx3hf on Wed 7th Jan 2004 05:35 UTC

> No, it just feels "common ground". This doesn't
> make it right. Innovation is not alway intuitive
> at first, remember. ;)

Yes, it might be due to "common ground" reason. Because the "common" is the most practical (so far) f/s produced by the industry. Sorry Eugenia, I don't think your mockup is any near being innovative.

RE: RE: TigerT
by Wrawrat on Wed 7th Jan 2004 05:39 UTC

Her mockup is quite good but I don't really like the bookmarks/favorite at the top of the file selector. It just doesn't seem right to me. I prefer wide windows to tall ones.

Changes
by error27 on Wed 7th Jan 2004 05:43 UTC

I like it a lot. It's not a wretched horizontal slider like Windows or KDE. Making the favorites box easy to configure and just one click use is good. I like the Path Navigator, the combo box is difficult to use and you have to click a bunch of times to get where you to go.

I agree with whoever said the "View as List" combo box was not needed.

Also I agree with the people who say the "Search" is a bad label. It would be nice if there was a "Search" button that brought up a GUI interface to the `locate` command.

I like the path buttons, but I think I would prefer the URL bar if it were just clickable text with unclickable slashes. It would be like a URL type thing. The reason is that when I first saw the buttons, I didn't realize it was a path. (Also I like UNIX pathnames. In Windows people ask me for help because they saved things in a folder but don't know the path to the folder to open it back up.)

The "New Folder" button is not necessary. Even if you create a new folder, how would you move stuff into the folder?

I didn't want to say this, but I have to agree with the people who like the "Favorite Locations" on the side. When it's on the side you would use the extra space to display files. With the Favorite locations on the top if you want to add a seventh favorite then you either need to add a third row or you need to add a horizontal scroll bar. I really hate horizontal scroll bars. Also when the favorites are on the side, there is always one spot empty slot at the bottom where you can have a label "Drag and drop folders here".

Instead of a "Show All Files" combo box, I would prefer a "Show All Files" button that became a "Hide Hidden Files" button after it was clicked. (That text is too long for a button, but something to that effect would work).

Anyway, if Gnome used your suggestion as is, they would still have a better file selector than anyone else.

RE: Changes
by Eugenia on Wed 7th Jan 2004 05:49 UTC

> With the Favorite locations on the top if you want to add a seventh favorite then you either need to add a third row or you need to add a horizontal scroll bar.

No, you don't need a horizontal scroll bar. You would need just a third row. But don't forget that the default size of my shortcut list has the same properties as the side one. It can hold the same amount of icons as the default side one, this is not a problem. As I wrote in the article, the two shortcut lists share the exact same features and properties, only their location to the window differs and the fact that you don't waste screen space when resizing the window.

Re: Re: Rds
by Rds on Wed 7th Jan 2004 05:54 UTC

And if I don't remember which DSC000????.jpeg I'm looking for, but know approximately what size it is? Hm... that reminds me... they're all missing a preview pane...

This is why a open box is too limited, and is a broken UI idea. In reality, you shouldn't be using file names for that at all, but thumbnails.

But beyond that, there shouldn't even be a list of image files that you remember by file size. Most users will not use file size as a means of memorizing a file's location. They will, however, use a name. File sizes which would be useless for 9/10ths of a users work and only good for poorly-named saves from (if you have a list of files like that) broken programs are inexcusable.

Of course, the way I see it instead of having a open box, imagine a file browser open, and just dragging the image you want, listed as thumbnails with any extra info you wanted, into the app. This is what should be happening. Heck, although it's really broken right now (it's really kinda earily, and just grew out of a want for the KDE slide show app ;) ), but that's what my image viewer <a href="http://rdsarts.com/code/picky/">Picky does. You open a ROX filer view, and can drag a image to it to view it. You drag a image to the icon of the GIMP to open it. You drag it from ROX to a open instance of the GIMP or Picky, and it opens it for you. This is how it should be done. When you work this way for five minutes, you see how natural it feels, and you find youself wondering how anyone can do things any other way.

And.. I think here's where I drop it before I get too off topic. ^^;

Re: What I learned today...
by Felix on Wed 7th Jan 2004 05:55 UTC

...that something called ROX exists, and that it is probably the most innovative open source desktop enviornment out there.

Well... many of ROX's principles were taken from RiscOS. That's what the R stands for (RiscOS On X). RiscOS was (and still is, there's a few articles post here every now and again on it), apparently, a heavily drag-and-drop user interface, with saveboxes and no menubar and apparently it was RiscOS programmers who put the context menu into Word, or so I've heard. It's something of a pity if even the most innovative open source desktop copies many of its ideas from others, but on the other hand: If something works, you'd be a fool to let it rot.

I Love Inovation
by Bill T. on Wed 7th Jan 2004 06:07 UTC

I love this. People actually inovating. I think all these
ideas look good.
<p>
Now for my observations.
<p>
I've always thought the Windows filebrowser has been a huge
waste of screen real estate. When browsing a directory with many or few files there is a rectangle on the left that is almost always completely blank below the dir/file info. I say avoiding blank/wasted window space is extreamly important.
<p>
P.S. I have not had MS on my desk at work or home since 1988.

...
by Anonymous on Wed 7th Jan 2004 06:12 UTC

Please don't turn GNOME into a MS Windows clone!

my vote
by are on Wed 7th Jan 2004 06:18 UTC

add a back button to Erics suggestion, then it fits perfectly my needs! go Eric, go ...

- are -

...
by Anonymous on Wed 7th Jan 2004 06:26 UTC

I guess it looks okay but who says that we will ever implement storage? Are we doing that just because the dictator Monopoly is doing it? What value does it add?

Eugenia's design is far and away the best
by Anonymous on Wed 7th Jan 2004 06:34 UTC

Eugenia's design is clearly far superior probably to any file selector out there. What could be more quick and intuitive than a logical series of steps from top to bottom to accomplish the task of selecting a file? The other selectors are *awful*. Blast the "navigation" buttons into the center of the Sun -- they are *so* confusing (what the f**k does "Back" *do* anyway?!?)! Don't put the shortcut bar at the left, put it at the top! The first step in selecting a file is selecting the general location of that file. And putting shortcuts in a vertical list gives the impression that each shortcut is "beside" its neighbors, which is totally *wrong* and destroys the user's spacial orientation.

Eugenia: please, *please* push hard to make your ingenious top-down design the default file selector in GTK!

Thank you for your comments.

> Eugenia: please, *please* push hard to make your
ingenious top-down design the default file selector in GTK!


I am trying, but it ain't easy for everyone to understand the strong points of this design by leaving behide their own legacy and think out of the box. When something is so different it is normal to meet resistance. You are welcome to join the cause though ;)

All perception...
by pixelmonkey on Wed 7th Jan 2004 06:42 UTC

I think the only reason Eugenia's looks weird is because it is in portrait. If you took Eugenia's model and resized it to have a wide aspect ratio, you'd end up with a top shortcut bar of only one row and five (or six) columns, a wider view and a prettier dialog.

As someone mentioned earlier, wider looks better, especially on computer screens. Apple knows this, look at their monitors.

How about reverse the Cancel and Open(Save) buttons......
by David on Wed 7th Jan 2004 06:49 UTC

Does anyone else think these are in the wrong order?
Most times we will want the open (or save) button, and the majority of the world still reads left to right.....

So how about the most used button goes to the left of cancel.
I believe this is a fairly common convention amongst OS's - why change it now?

-david

RE: All perception...
by Eugenia on Wed 7th Jan 2004 06:55 UTC

>I think the only reason Eugenia's looks weird is because it is in portrait.

Just created a new mockup to show that my version can also be made wide. All you have to do is resize the window and have GTK+ save a GConf key to remember all Open or Save windows' desirable sizes. Here it is:
http://www.osnews.com/img/5582/filesel-wide.png

The Path Navigator
by DCMonkey on Wed 7th Jan 2004 06:56 UTC

Some interesting additions to the path navigator idea can be gleaned from the Windows Longhorn PDC Build. Longhorn folder windows have a breadcrumb bar very similar to the path navigator at first glance. It has a button for each folder in the hierarchy and arrows at each end to scroll horizontally. There are two additional features:

- The folder buttons behave like most browser buttons in that clicking the little down arrow next to the text gives you a list of other folders at the same level as the one represented by the button. This makes for a sort of Mac OSX-column-browser-in-one-row.

- The right hand arrow IIRC is all the way to the right of the window rather than directly to the right of the last folder. If you click in the empty space in between, the whole breadcrumb bar turns into the old style address bar where you can type in path names like in the olden days.

Nice looking mockups all around.

Eugenia, some good, some ick
by mikesum32 on Wed 7th Jan 2004 07:04 UTC

Eugenia, your mock up way too clutered. The main cause is the location widget being above the main file widget. You say that people should see it first, but since most people read left to right they would see it first anyway if it were on the left like every other.

Also it is easier to hit the buttons if they were all line up on one axis. I would much prefer to just move your mouse up and down, and not up and down AND side to side.

This is why most people don't make their Windows task bar more that the default height. It's much easier to hit the wrong button when you go up and down and left and right.

Good job getting rid of the bookmarks button.

I also like the Path Navigator.

But I think a back/forward button would be nice still.


What if I hit the "home" button and lost my place? The Path Navigator wouldn't be much help.

The Back/Forward buttons could pop into the window only after you actually changed to a folder that wasn't up or down on the hierarchy.

Please don't hurt me ! ;)

I believe this is a fairly common convention amongst OS's - why change it now?

This is the standard on Gnome (and many GTK+-based environments such as ROX-Filer). I think also on the Mac.

size of the file list
by Anonymous on Wed 7th Jan 2004 07:38 UTC

I believe the file list widget should have *full* height.

The mockups present only couple of files. Surely users have much more into a single folder (especially digital pictures), and because this dialog is about choosing a file (remember?), it should presents as much files as possible.

Scrolling a long list with a limited display area is difficult because of the page's size being very small, making the scrolling very sensitive.

RE: Eugenia's design is far and away the best
by +V on Wed 7th Jan 2004 07:44 UTC

Don't put the shortcut bar at the left, put it at the top! The first step in selecting a file is selecting the general location of that file. And putting shortcuts in a vertical list gives the impression that each shortcut is "beside" its neighbors, which is totally *wrong* and destroys the user's spacial orientation.

First problem that comes to my mind when thinking about this shortcut bar, is that our monitors are landscape and many are still using 800x600 or smaller resolution. For them the height of the windows can be a big problem. I have rarely seen window that maxes the width of the screen.

I don't think there are any screenspace saving qualities in having shortcut bar at the top, as the size of the icon+text will always be the same (excepting that they don't overlap). Resizing the windows doesn't matter as shortcut bar's don't have to stretch, well except for vertical bar to stretch vertically and horizontal bar horizontally.

I think it is very logical to have the shortcut bar on the side because they are kind of separate entities. I rarely use shortcut bars (excepting that the application i am using remembers in which folder i have been last time i used this dialog in that application), and when i open a file dialog then first of all i check where i am at from the titlebar or from the combobox displaying current directory, if i am at the wrong location THEN i'm going to check the shortcut bar if there are any shortcuts near my target location. By this it would seem to be logical to have bookmarks/shortcuts combobox but that would be unintuitive because i can't check it out quickly by just glancing at it.

Another theory supporting the "legacy" left position of the shortcut bar is the golden mean / the golden section. With the shortcut bar on the left, combobox & new folder buttons etc. at the top, and the file selecter at the middle type of ordering of the widgets supports the golden mean by pointing your eyes at the file selecter (which is the most important widget of the dialog) when the dialog opens.

Maybe placing shortcut bar at the right would also be good, because then it would be at even more unimportant position to interfere with casual browsing but it would tamper with preview windows.

Oh well.. back to work.


+V

user defined fileselector
by Anonymous on Wed 7th Jan 2004 07:47 UTC

So much writting about the file selector, and so much different point of views. Of course it is important as it is a much used widget.

But why don't we let users plug in their favourite one, overwritting the gtk's default?

It could be provided by a theme, or stand alone.

You may imagine also the deployement advantage: a company/distribution/what-ever could easly set up its own fileselector, with their own must wanted button!

Program specific shortcuts
by Thumper on Wed 7th Jan 2004 07:56 UTC

Not sure if this is the way it is supposed to work or if it has already been posted (too late and lazy to check), but perhaps programs should be given the option of using their own shortcuts or the general system shortcuts.
In other words, if I was using the Gimp and wanted to open some image files, I would want the shortcuts at the top to be different then if I was in Nautilus or Anjuta or such. A program could be written to see if it has its own config file for the shortcuts and if not default to the general system ones.
Just an idea, let me know what you think.

RE:Anonymous (IP: ---.cg.shawcable.net)
by BR on Wed 7th Jan 2004 07:56 UTC

Maybe because it will allow us to dispense with most of these "open/save/file" discussions, which are a bit of a cludge were limited machne meets flexible human.

[pixelmonkey]
Actually I thought the moniters were that way because of DVDs letterbox format.

Anyway why not a birds-eye-view of the filesystem arranged in spoke-wheel fashion* coupled with something like logitech's pan and mouse wheel zoom? An appropriate use of colors and shapes (size?) of course. Mouse gestures could help here.

*or for the more advanced the wheel of association.

re : user defined
by mecolik on Wed 7th Jan 2004 07:58 UTC

A good idea indeed.
Can we imagine a totaly configurable file selector ?
I mean : the favs could be a selectable item to place where I want, idem for filename, ..
Why not use draggable "tabs" for it?
But indeed, we need a default file selector and they all look very good for me.

re : user defined
by Eugenia on Wed 7th Jan 2004 08:01 UTC

>Can we imagine a totaly configurable file selector?

Yes we can, in the KDE world. Not in the Gnome one though.

RE: Eugenia's design
by toogreen on Wed 7th Jan 2004 08:06 UTC

Just my 2 cents; as a graphic/web designer, I'm totally FOR new ideas and innovation, but it does have to also be user-friendly, ergonomic, intuitive and allows you to do things quickly. I'm sorry Eugenia but even after really trying hard to see something positive with your concept of the favorites buttons, it really doesn't work for me. First, there's the obvious problem of bloated look/too many buttons after adding many favorites to the existing list. Also,the "grid" design of the buttons positioning is confusing for the eyes. The time needed to find one particuliar button is at least twice as much since you have to look from left to right, top to down, etc. Also this whole design would be a bit annoying when u have to work on something fast, as there's buttons in between the favorites and the files, I know i would end up accidently clicking on "new folder" quite too often because I wanted to click on the favorite over it. Which makes me believe if we would actually use such a concept then at least we would need the "new folder" etc, above the favorites. But then its almost the same problem, if u want to hit those more often than the favorites. 3 different levels of buttons in the same col just doesn't work, It's obvious to me. Erick design's is the best, as the favorites are directly next to the files, which allows quick click very fast in between them without click anything else by accident. So u want to add new folder, click up, easy, fast. You want to click a favorite, click left, easy, fast. Keep it simple. Nice effort Eugenia but I'm afraid Erick did much better ;)

...
by Anonymous on Wed 7th Jan 2004 08:07 UTC

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.

RE: Eugenia's design
by Jon on Wed 7th Jan 2004 08:12 UTC

>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 has better but...
by Lee on Wed 7th Jan 2004 08:15 UTC

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.

RE: Eugenia has better but...
by Eugenia on Wed 7th Jan 2004 08:18 UTC

> 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?

My opinion
by Rudo on Wed 7th Jan 2004 08:19 UTC

While Eugenia's mockup is pretty sweet, I'd all go for the one Erick derived. I think that one just kicks ass. ;)

RE: RE: Eugenia's design
by toogreen on Wed 7th Jan 2004 08:23 UTC

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

Best of both worlds...
by frits on Wed 7th Jan 2004 08:33 UTC

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.

 RE: Eugenia has better but...
by Nathan O. on Wed 7th Jan 2004 08:36 UTC

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 :-)

Golden Ratio?
by Tonguç Yumruk on Wed 7th Jan 2004 08:42 UTC

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

Re: There would be better than a file selector ...
by Felix on Wed 7th Jan 2004 08:44 UTC

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.

CDE File Manager
by victor on Wed 7th Jan 2004 08:50 UTC

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

keyboard 'only' users
by Sven on Wed 7th Jan 2004 08:55 UTC

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 opinion.
by Mong on Wed 7th Jan 2004 08:57 UTC

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.

Re: My opinion.
by Rds on Wed 7th Jan 2004 09:00 UTC

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?

how about a simple one?
by stew on Wed 7th Jan 2004 09:22 UTC

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.

Extended breadcrumbs
by Anonymous on Wed 7th Jan 2004 09:43 UTC

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...

renaming and other functions?
by chendo on Wed 7th Jan 2004 09:48 UTC

is it possible to rename/delete/etc within the fileselector widget? i find that useful in windows at some times.

RE:keyboard 'only' users
by Anonymous on Wed 7th Jan 2004 09:52 UTC

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:

Bookmarks
by Bharat on Wed 7th Jan 2004 10:10 UTC

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.

Context sensitive path buttons
by Xav on Wed 7th Jan 2004 10:16 UTC

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).

RE: new gtk+ filedialog...
by Avi Bercovich on Wed 7th Jan 2004 10:17 UTC

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.

Yuck!
by salmacis on Wed 7th Jan 2004 10:21 UTC

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!

Re: ...
by Rich on Wed 7th Jan 2004 10:42 UTC

>> 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.

...
by Anonymous on Wed 7th Jan 2004 10:43 UTC

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.

Very good but....
by ra1n on Wed 7th Jan 2004 11:15 UTC

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.

Another suggestion
by Athanassios Floros on Wed 7th Jan 2004 11:19 UTC

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).

A big improvement
by Mephisto on Wed 7th Jan 2004 11:25 UTC

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.

pah navigator is great
by Anonymous on Wed 7th Jan 2004 11:25 UTC

I love the "Path navigator". Very intuitive, you always know where you are.

Some tweaks to Eugenia's and Erick's
by elmimmo on Wed 7th Jan 2004 11:30 UTC

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.

New widget and Keyboard navigation
by Daelin on Wed 7th Jan 2004 11:36 UTC

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.

RE: New widget and Keyboard navigation
by Daelin on Wed 7th Jan 2004 11:39 UTC

Also, starting with a single dot, or at least "./." should display dot files (and only dot files) in the directory.

Size & Modified.
by Ziggamon on Wed 7th Jan 2004 11:44 UTC

I have never used them.

If someone needs to get that info, he/she can right-click a file and select properties.

Favorites
by Daelin on Wed 7th Jan 2004 12:00 UTC

Also, one more thing about the Favorites. Apple got this right with Finder in 10.3. Emulation of that would be a great start.

Re: New widget and Keyboard navigation
by elmimmo on Wed 7th Jan 2004 12:18 UTC

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.

top shortcuts
by Guillaume on Wed 7th Jan 2004 12:19 UTC

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)

Re: New widget and Keyboard navigation
by elmimmo on Wed 7th Jan 2004 12:21 UTC

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 "/"'

Admitably Off Topic
by Zen Lunatic on Wed 7th Jan 2004 12:22 UTC

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?

Re:  Admitably Off Topic
by Jay on Wed 7th Jan 2004 12:36 UTC

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!

RE: Admitably Off Topic
by toogreen on Wed 7th Jan 2004 12:37 UTC

> 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 :/

Please select the dir you came from!
by Wout on Wed 7th Jan 2004 12:38 UTC

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.

RE: Not Bad, But...
by Anonymous on Wed 7th Jan 2004 12:41 UTC

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.

Some More Mockups :)
by Richard Spindler on Wed 7th Jan 2004 12:54 UTC

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.

FileSelector
by Anonymous on Wed 7th Jan 2004 13:01 UTC

I prefer Tigert's one + "Advanced..." Button that fires up a full file manager (nautilus or rox filer or what ever)

How about a tree on the left
by Vanh on Wed 7th Jan 2004 13:06 UTC

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.

DnD paths
by Lolight on Wed 7th Jan 2004 13:13 UTC

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.

Spatial?
by Drew on Wed 7th Jan 2004 13:22 UTC

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.

Re: Some More Mockups :)
by Felix on Wed 7th Jan 2004 13:25 UTC

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 ;)

Keywords
by Kevin Arvin on Wed 7th Jan 2004 13:30 UTC

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".

Re: Some More Mockups :)
by Daelin on Wed 7th Jan 2004 13:37 UTC

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

It's better than what they've got now...
by Joe on Wed 7th Jan 2004 13:38 UTC

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.

RE: RE: RE: accessibility [50th comment answer]
by dc on Wed 7th Jan 2004 13:41 UTC


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.

v KDE...[troll-alert]
by Anonymous Coward on Wed 7th Jan 2004 13:42 UTC
Re: New widget and Keyboard navigation
by Daelin on Wed 7th Jan 2004 14:00 UTC

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 (t for tab):
"Movt/Tt/SttGt/SttGt401t"
to get to
"Movies/TV/StarGate SG-1/Stargate SG-1 [4x01] 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?
by Anonymous on Wed 7th Jan 2004 14:19 UTC

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?
by Anonymous on Wed 7th Jan 2004 14:21 UTC

preview for pics, videos, etc?

Path Navigator
by Jim Shepherd on Wed 7th Jan 2004 14:28 UTC

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.

Well.
by Minimalist. on Wed 7th Jan 2004 14:28 UTC

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.

Why not LRU list of recent directories?
by E.R. on Wed 7th Jan 2004 14:28 UTC

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.

By the way.
by Minimalist. (again) on Wed 7th Jan 2004 14:30 UTC

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.

Shortcut list location
by Dimi on Wed 7th Jan 2004 14:55 UTC

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.

typical...
by Anonymous on Wed 7th Jan 2004 14:58 UTC

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.

v Dimi
by Daelin on Wed 7th Jan 2004 15:01 UTC
Ok Kids.
by Sven on Wed 7th Jan 2004 15:02 UTC

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.

...

re: OK Kids.
by bact' on Wed 7th Jan 2004 15:26 UTC

"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

Do not save button
by Leslie Donaldson on Wed 7th Jan 2004 15:27 UTC

RE: By Tonguç Yumruk
I agree dump the cancel button and use a "Do Not Save" button....

Spark: simple and elegant
by Rugbuz on Wed 7th Jan 2004 15:33 UTC


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.

Comment on lack of "Up Directory" button
by Dave on Wed 7th Jan 2004 15:49 UTC

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

re: re: OK Kids.
by Sven on Wed 7th Jan 2004 15:50 UTC

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?

Re: Another suggestion
by Dario on Wed 7th Jan 2004 15:51 UTC

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).

Why locations on top is bad
by Anonymous on Wed 7th Jan 2004 15:53 UTC

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?

Suggestions for an advanced mode
by -=StephenB=- on Wed 7th Jan 2004 15:57 UTC

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.

YAFS
by Intangible on Wed 7th Jan 2004 16:00 UTC

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.

My own mockup; SGI OS buttons thing is the solution to me
by toogreen on Wed 7th Jan 2004 16:21 UTC

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

re: YAFS
by PainKilleR on Wed 7th Jan 2004 16:30 UTC

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.

Function requirements
by Moriarty on Wed 7th Jan 2004 16:38 UTC

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.

Linux GUIs' cancer
by Mike on Wed 7th Jan 2004 16:40 UTC

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 1024x768 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...

Comments
by jglass on Wed 7th Jan 2004 16:45 UTC

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.

toogreen's dialog improved
by Richard Spindler on Wed 7th Jan 2004 16:56 UTC

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
by alternate on Wed 7th Jan 2004 16:58 UTC

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!

Why Erick's is better.
by Anonymous on Wed 7th Jan 2004 17:13 UTC

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, but...
by Roy on Wed 7th Jan 2004 17:16 UTC

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.

Re: My thoughts [Felix]
by Spark on Wed 7th Jan 2004 17:24 UTC

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...

Um
by hmmm on Wed 7th Jan 2004 17:29 UTC

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.

Something else to consider
by Spark on Wed 7th Jan 2004 17:33 UTC

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?

RE: Why locations on top is bad
by thorsten on Wed 7th Jan 2004 18:06 UTC

- 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


Yet another comment
by Tyr on Wed 7th Jan 2004 18:10 UTC

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.

vertical vs. horizontal
by Gabe Yoder on Wed 7th Jan 2004 19:30 UTC

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?

Re: New widget and Keyboard navigation
by elmimmo on Wed 7th Jan 2004 19:31 UTC

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! ^_^

Hm,
by Richard Spindler on Wed 7th Jan 2004 19:51 UTC

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.

Comments
by N.N. on Wed 7th Jan 2004 20:11 UTC

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.

The "old way" mentality
by jed on Wed 7th Jan 2004 20:52 UTC

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.

choice?
by Dahl on Wed 7th Jan 2004 22:24 UTC

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?

Path Navigator as hyperlinks ...
by Veselin Pavlov on Wed 7th Jan 2004 22:24 UTC

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.

location field
by i_code_too_much on Wed 7th Jan 2004 23:02 UTC

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.

Option to choose "Filetypes"
by joost jodel on Thu 8th Jan 2004 00:18 UTC

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.

Larger! Please!
by Paul Harrison on Thu 8th Jan 2004 04:10 UTC

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?

Fisheye menus
by Thiago Santos on Thu 8th Jan 2004 04:47 UTC

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

Re: Fisheye menus
by WorknMan on Thu 8th Jan 2004 05:19 UTC

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.

Just one question
by Kanwar Plaha on Thu 8th Jan 2004 05:30 UTC

Why can't the GTK+ file selector look more like what KDE has? What KDE has designed is functional, pretty, intuitive and everything in between ... so why can't we just pick that design? Why can't we accept a good thing when we see one? Okay, so make the subject Just three questions :-)

How not to do it.
by mikesum32 on Thu 8th Jan 2004 06:29 UTC
Re: Larger! Please!
by Spark on Thu 8th Jan 2004 06:31 UTC

Just save the size of it, problem solved...

Re: Just one question
by Spark on Thu 8th Jan 2004 06:46 UTC

Because the KDE file dialog is like four times as complex as the GNOME file manager (not even considering the spatial mode of GNOME 2.5). That wouldn't make a whole lot of sense. Not everyone really likes the KDE dialog anyway, I certainly don't.

Fisheye menus
by Anonymous on Thu 8th Jan 2004 13:49 UTC

http://www.cs.umd.edu/hcil/fisheyemenu/fisheyemenu-demo.shtml


Woah, that looks *damn* useful. The problem is, that usually things arent sorted in order. Anyway, It'd be cool to try

Re: Re: Larger! Please!
by Paul Harrison on Thu 8th Jan 2004 23:02 UTC

Saving the size: That would be a partial solution (cf having a "make interface non-annoying" checkbox somewhere in your config). It would mean adding some complex stuff to gtk for saving configuration on a per-application basis (or maybe it should be a system wide configuration option...).

I still think it would be better to just get it right from the start. Just need to change a couple of numbers, very simple.

Ditching the "Search"
by Notorious coward on Thu 8th Jan 2004 23:38 UTC

It shouldn't be "ditched", because although you'll be providing the same functionality just by typing right away, the Search gives the (precise/exact) visual feedback of what you're typing. I don't think just selecting according to what is typed is enough, at least this doesn't make me feel confident. What if I sort by a criteria other than alphanumeric, and try to select by typing? (not all possibly selected files would be shown)

RE: Another suggestion
by Athanassios Floros on Fri 9th Jan 2004 09:36 UTC

On second thought...

I think that we all got carried away in the designs (mock-ups) we provided. In every single design there is a file selection area that displays mixed types of files (e.g. folders and image files), something that would require support by a MIME database. Otherwise it's not possible to display different icons for different kinds of file.

Seems like we all suggested that the file list area is a “nautilus” view, but I think that this is not possible for a GTK-only dialog (the GNOME libraries form a layer above GTK so it should look odd to introduce such a dependency).

So I think that the new GTK dialog-box will continue to use separate lists for the files and the subfolders of the current folder (as the current implementation does).

A revised mock-up of my suggestion with this in mind can be found here:

http://florosat.freeyellow.com/thanos4.gif

This version also introduces an alternative way to exit the dialog (find the file by searching) and the “Show hidden files” option.