Closed Bug 142482 Opened 19 years ago Closed 16 years ago
redesign directory selection behavior of file picker (mode
The filepicker as it is now is not very well suited for selection of directories (modeGetFolder). There are a number of problems: - when the filepicker comes up the initial current directory is the one that is currently selected. This directory cannot be easily reselected, since the "select" button is disabled when the "file name" entry field is empty. - since directories can only be selected from the parent directory there is no way (short of entering the path in the file name field) to select directories where the parent is unreadable, or the root directory. My suggestion would be to allow the selection of the current directory - i.e. enable the select button when the file name field is empty and no directory is selected in the list to select the current directory. The logic of the filepicker seems to be that what gets selected is the current directory with the subdir appended that is selected from the tree, and the name of which shows up in the entry field. Changing the name in the entry field will select the dir that is made up from the current dir with the chanegd name appended. However *clearing* the name will not allow to just select the current dir which seems illogical. (based on a discussion of these matters in bug 58311)
Summary: redesign directory selection behavior of file picker (modeGetFolder) → redesign directory selection behavior of file picker (modeGetFolder)
Confirming. I talked to mpt about this yesterday for a while... here is what we decided on: == parent dropdown == (up) (home) (new) -------------------------------------- | directory listing | | | -------------------------------------- [ textfield ] ( Select "foo" ) [ ] Show hidden (Open)(Cancel) My ascii art sucks, but here is an explanation.... The "open" button is enabled whenever something is typed in or selected. It just does goToDirectory(0 on that something. The "Select" button is _always_ enabled. If something is typed in or selected, "foo" is that thing (whatever is in the textfield, basically). If the textfield is empty, "foo" is the current directory's leafName (with some magic to make the root dir have a "leafname" of "/"). So now you open the filepicker. If you do nothing and just bonk the "Select" button the currently open dir is selected. If you click on something in the list and then bonk "Select", the thing you clicked on is selected. If you double-click something in the list and then bonk "Select" the thing that was double-clicked on is selected. More importantly, the "Select" button always says _what_ will be selected. It might be nice to whip up a patch that does this so that if we actually do usability testing we can test both the current version and the proposed one....
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hmm wouldnt the open button belong closer to the directory listing and entry field? Logically "open" is just another way to enter/pick stuff, while select and cancel are action related.
That was bothering me too.... :) I think the point was to try to make the "Select" button as big and obvious as possible.... I'm still working on getting my hands on a Mac filepicker to see how that's handled there.
WindowsNT has a directory picker that just shows the tree of directories. Whichever folder gets selected will be shown with an "open folder" icon, and doubleclicking it will change into that directory (making it the current, with the tree view expanding the branch and leaving the selection on it). There is no way to *enter* a path though. This looks a lot like the tree view I get in mozilla when browsing a directory with file:///... - what are the reasons for not using this in the filepicker "directory listing" box, btw?
None, really, save "the back end would need to be written".
I'm confused. What does it mean to be 'selected'? It sounds like it means something very different here than everywhere else in the UI. If the Open button opens what is selected, does that mean I have to click Select followed by Open? Or does the select button dismiss the dialog? Is it the default button? IMO, it would be good to get the desired behavior defined before whipping up any patches.
Where is "select" used in the UI elswewhere and whats the difference? The term "select" is already used in the current version of the filepicker for the action in modeGetFolder ("Save" & "Open" for the other two modes). OTOH the button that leads to this dialog for selecting the cache directory is called "Choose Folder". (hey is it a folder or directory? :) ) So the idea behind this design is to make it more explicit *what* gets selected if the select button is pressed. The need to get more explicit arises from the confusion that might be caused from the fact that you can either select the currently shown directory when nothing is in the entry field or a directory that is determined from what has been picked in the directory listing in combination with what is in the entry field. The open button is something new that allows to more easily navigate to what will ultimately get selected while still staying within the dialog. So Peter, does your confusion arise from what I mentioned in comment #2, that the open button looks and takes the place of the default action button? If so, a solution might be to use other means to show what will get selected if the select button is pressed :) E.g.: == parent dropdown == (up) (home) (new) -------------------------------------- | directory listing | | | -------------------------------------- [ textfield ] (Open) Select: /the/dir/that/will/be/selected [ ] Show hidden (Select)(Cancel)
Johann, obviously selection is fundamental, used all over the UI, but isn't used anywhere else in the same way it is being used here, as an action that dismisses the dialog. It is important to be consistent, and we are already using select to indicate identification of objects within the interface, such as highlighting a particular directory, so we can't switch to using 'pick' for that here (as in comment #7). Since selection is currently overloaded even within the dialog, I'd suggest that another word such as Choose be used to indicate picking a folder (such as the one that is currently selected ;-)) and dismissing the dialog. My comment about placement was for platforms that have a standard for placement of default buttons, which includes MacOS, Windows, and probably Gnome 2.0. I think it would be confusing to put a default button in the middle of the dialog, and to have Open appear where it is usually the default button in the file picker variant of this dialog. BTW, they should be called directories on Unix, but folders on MacOS.
I agree, `Choose "foopy"' makes more sense than `Select "foopy"'. Folderpicker from the Mac OS Standard File API (used since System 6): <http://www.ucsf.edu/its/license/images/sophosmac2.gif> Folderpicker from the Mac OS Navigation Services API (used since Mac OS 8.x): <http://mactech.com/macintosh-c/classic-images/16bimage7.gif> The problem with the Navigation Services folderpicker is that it's unclear which folder you're selecting -- you could easily double-click the folder you want, then click `Choose', and end up choosing a child folder by mistake. Therefore I suggested including the folder name in the button text (like the Standard File folderpicker). Therefore it wouldn't be in the same row as the other buttons, otherwise it wouldn't fit. Following the GNOME button order is bug 110647. AFAIK both GNOME and KDE refer to directories as folders.
Hmm, I am not enthusiastic about the Mac design - I think Peter's comment about the ambiguity which of the buttons is the action button that dismisses the dialog applies here too. What do you guys say to my piece of crappy ASCII-art in comment #7 ? Just replace the term "select" with "choose" in it. The reasoning behind it: put the action button "choose" where it belongs, put the open button where it logically belongs, and display the info what gets chosen seperately. This makes it possible to put the "choose" button in the expected location and it will also make it easier to choose something with a long name (the complete path should be shown, if it is really long possibly with truncation in the middle)
The wide Choose button in the middle would be appropriate if we could leave Open in place as the default button. That's what the new MacOS folder picker does, and it makes sense, since Open is the most commonly used command in the dialog, and is consistent with the file picker equivalent.
Peter I dont get your argument: from the design Boris presented, the "open" button is only used when the user does not navigate to the directory through the directory list or the buttons above them, but directly enters a path. Open will then switch to that path (make it current) and the user stays in the dialog. Clicking "choose" will then actually choose that directory and dismiss the dialog. So Choose is equivalent to Open/Save in the other modes and should be at the same location. It should also be the default button. Open is an addition and should be placed so that the user immediately sees what purpose it serves: hence my suggestion to place it beside the path entry field.
Choose may be equivalent, but Open is identical in the way it operates on folders, so moving it and making it not be the default button could be confusing. It would be better to leave it exactly as is, to allow for transfer of training and muscle memory from use of the similar dialogs. In navigating by keyboard, Open (via Enter) is much more commonly used than Choose, so it makes sense for it to be the default. Finally, leaving choose by itself allows more space to include the folder name. What reason do you have for Choose being the default button?
No it is not identical, because the purpose of the button is defined by what it does with regard to the dialog's function, not within the dialog. When the dialog is started, it is clear that it serves the purpose to choose a directory, therefore the user will expect the button to be at the same location as the "open" button when the dialog is used to open a file. The default action is to do whatever the dialog is supposed to do, choosing a directory in this case. The open button in this design is just here to make it easier for the user to specify which directory to choose.
I'm not sure I understand all of what you just wrote. AFAICT, the Open button need not change at all from the way it is in the current Open File dialog. In Open File, it is the default button, and when the selection is a folder it opens the folder. I don't think we need to move it or change its behavior as the default. Users choosing a folder are likely to open several before they find the one they are looking for, so leaving Open as the default button enables them to do that quickly using exactly the same means they are familiar with from the Open File dialog. We need more horizontal space for the Choose button, to indicate the folder it will choose, and putting it by itself would allow that. There is no need to make Choose the default button, although if we have a default button on the Mac OS, then it should be the one that dismisses the dialog.
Is any work being done on this? I ran into a bug related to this in Phoenix when choosing a default directory for downloads. I was surprised not to be able to enter a directory and then hit Select (instead I had to be in parent directory).
Feel free to suggest a change to the UI that actually works.
Boris, I'm not UI designer so I'm not the right person to ask really. What I do know is that in other apps that I use I can double-click on a folder and then hit OK to choose that directory (or, optionally just select it like it works in Mozilla now). Blake says the Windows filepicker allows this too.
No one else involved is a UI designer either... Should we all quit and go home?
what about "if no directory is selected, hitting ok closes the dialog, selecting the current directory"
There are actually two issues: 1) What should the OK button do in all four cases (directory selected or not in the tree view, a directory name, possibly different typed or not in the text input)? 2) What should double-click on a directory in the tree view do? In particular, is it possible for me to select the directory /afs/athena.mit.edu/user/b/z/bzbarsky/www/testcases/dynamic-inline-style-correctness without having to type anything other than the /afs/athena.mit.edu/user/ part in? (Why we don't just separate out typing of dir names and typing of filenames is beyond my comprehension).
something typed, dir exists: change into that dir & show contents does not exist: show error msg if nothing typed: double-click/dir selected ok clicked: show contents of that dir. in case of dbl click, leave input field untouched. nothing selected ok clicked: that directory is selected, dialog is closed
> if nothing typed: > double-click/dir selected ok clicked: > show contents of that dir. In the dir-selected-ok-clicked case this is precisely the behavior considered "buggy", no? We could decouple the tree widget from the textfield, but if we do so we should do it for all filepicker modes (may be a good idea in any case).
bz: from comment 0, I get the impression that my suggestion is exactly what is wanted
Ah, good point. I misread. :) biesi, do you want to do it? I really won't have time to get to it, but I could review... (though coordinate with bryner's modeOpenMultiple patch if you do want to do it).
I have had this problem with "Save All Attachments" When trying to select a folder to save all attachments into, it seems illogical to have to go to the parent directory to select the folder. In this case, the most logical solution would be to make it exactly like Save Attachment, except that you can't select the name of the file. So as far as I can see, "Select" or "Choose" should be the only button, and should always choose the Current directory, regardless of what is selected above. That way double-clicking on a folder/directory always takes you into that directory, Choose always selects the current directory. Although I'd also be happy with comment #22 if this wasn't possible.
Not sure if I understand you fully, but wouldn't it be equally inconvenient to have to go into the directory if you're in the parent directory, especially if the desired directory is already selected?
Peter, the filepicker would alway make the default directory the "current target directory", so you would not have to change into it, just press select. I again propose something that is similar to my original proposal: The top dropdown always shows the current directory which is, what will be selected as the target directory when "select" is clicked or enter pressed. To make this clearer, the text in front of that dropdown is changed from "look in:" to "select:" If a directory is selected in the listbox, the name shows up in the text entry field as it does now. However in that case, pressing select just changes into the directory, if possible. If the directory cannot be used because of some error condition, an error alert is shown and nothing changed. If the user enters something in the text entry field, again the select button will try to make that the current target directory. So we have a clear functionality here: there are ways to change what is shown in the "select: " directory dropdown and whatever is shown there will be used unless an action is still pending. An action is pending when the text field is not empty. One potential problem here is with directories that cannot be read, but stored into. For this the code would have to avoid to really make the directory current, but instead just keep track of what the target directory is. The dialog design would stay exactly the same as now and the select button and enter key would always be active, having two different functions depending on whether the text entry field is empty or not. This would be similar to the other two modes of filepicker where the function of save or open depends on whether what is in the entry field is a directory (change to it) or a file (save/open it).
Sorry, but I'm still not sure I clearly understand what you intend.
Peter, maybe you should point out what part is still not clear to you, so I don't have to give you the whole sermon in even more detail again?
The part about how it would work. What is needed here is not a sermon, but a clear, unambiguous mini-spec.
Peter, maybe it is my poor english for which I apologize. Likewise for my attempt to be funny. Trying to be more concise: Choose: [/the/current/dir] (up)(home)(new) +------------------------------------------+ |subdir | |subdir2 | .. | | +------------------------------------------+ Direcotry name: [ ] Show hidden [x] (Choose) (Cancel) -If the Directory name entry field is empty, pressing (Choose) or hitting Enter will close the dialog and return the directory that is shown in the top left (/the/current/dir) - If the user double clicks "subdir" in the directory listbox, the directory name shown in the top left will change to /the/current/dir/subdir. - If the user single-clicks subdir, the name "subdir" will show up in the Directory name entry field. - If something is in the Directory name entry field, the label of the button "Choose" changes to "Open" and pressing (Open) or hitting Enter will update the dialog so that the changed directory will show up in the top left and the text entry will be cleared again and the Button label will be restored to "Choose". Depending on whether what is in the Directory entry field is a relative or absolute path, the top left directory name will have been extended or replaced by it. - Cancel will always abort the dialog. - If something is in the Directory entry field (typed in or by single clicking an entry in the directory list box) that causes an error when clicking (Open) or pressing enter, an error alert is shown and the dialog left unchanged for correction. - Potential errors: the permissions of a directory are not adequate: I am not certain, but it seems that the directory selection dialog only ever comes up for *storing* something in there, right? So it would be necessary for the chosen dir to have write permissions, but not necessarily read permissions. - hence: if the directory shown in the upper left cannot be read, the directory list box is replaced by an informative message (this is already done for other filepicker modes and can be copied). - if what is entered in the Directory entry field is not a directory, an error alert is shown and the dialog left unchanged for correction. I have replaced the word "Select" by "Choose" here, based on your comment #8. Note that this proposal not only tries to make this work better but also to make it similar to and consistent with the other modes of the filepicker (open file and save file).
Thanks Johann. I still stand by my earlier comments about leaving the Open button as the default, and adding a Choose button that could operate on the current directory, i.e. the one selected, or the one displayed if there is no selection (in which case it could become the default button, as per comment #20). I think it is important to allow for quick keyboard access here, since the dialog supports typed input, and may need to navigate through multiple directories, while they are only dismissing the dialog once.
Peter, as far as I can see your solution reduces the number of necessary interaction by at most one. In those cases where the user navigates by double clicking through the directory structure or using the ancestor, up, home, (and upcoming favorites/recent) buttons the number of interactions is exactly the same. Do you agree that this is so, i.e. I understand you correctly? The disadvantages one could see with your solution: - it is different from how the other modes work. Note that exactly the same problem of navigation vs action exists there too, and we *do* have a single button that does both there. It is also different from the way other filepickers, at least under Linux do it. Both the (horrible) GTK filepicker and the KDE filepicker use the same button for navigation and action (save, open). - It makes the meaning of the Enter key ambigous: if something is in the Directory entry field and you press enter, does that mean that you want to navigate into that directory or choose that directory? With my solution both the meaning of the button and the meaning of the Enter key coincide and are always non-ambigous. - It clutters the dialog with an additional button On the other hand, doesnt Boris' suggestion of how to separate navigation and action do what you want, when a few tiny changes are made? I will give you a new attempt at ASCII art: Look in: [/the/current/dir] (up)(home)(new) +------------------------------------------+ |subdir | |subdir2 | .. | | +------------------------------------------+ Show hidden [x] Directory name: < > (Open ) (Choose /the/current/dir ) (Cancel) The solution is different from Boris' original in that it more clearly seperates navigation from action (which is at the bottom) and uses different words (choose instead of select for the action). It also groups (Cancel) with (Choose) instead of (Open) since (Cancel) aborts the action, not the navigation. Possible problems that remain with this solution: - long dirnames cannot be shown fully in the button, but this could be made less problematic by providing tooltip information on the button. - the semantics of the Enter key in some situations, i.e. which of the two buttons (Open) and (Choose ...) will be marked active when both would do something? - should the other two modes of the filepicker work similarily? I think we are getting close ... :)
The key difference here is that directories can be selected, not just files, which makes the file picker UI less appropriate here. The difference is not just 'one', but rather usable keyboard operation, and in particular saving gestures for each folder traversed. The Enter key should always do the default action, which should be unambiguously indicated but is not necessarily fixed, and can reasonably be expected to change based on selection, etc. Your latest proposal still doesn't appear to allow choosing 'subdir' without first navigating into it, which should be an unneccessary step. I think the choose button should apply to the selection, if there is one, or to the current dir if not. A better solution, IMHO, would be to present a tree of directories, as is done on Windows. This makes more choices visible, and minimizes the number of buttons, clicks and refreshes.
I did not explain all details, but I think it should be possible to update the string shown in the (Choose) button whenever something is typed or changed in the Directory entry field. Note that part of the problems we are getting here is that we give the user the convenience of entering absolute or relative paths. The windows solution simply does not allow that and you have to do an awful lot of clicking to arrive at your directory sometimes. All in all I do not think that even one additional step is that bad, given the other advantages. Note also that the filepicker will grow eventually to remember recent dirs and favorite dirs, which will make it even more easy to choose a dir, again even with the additional step.
sudden revelation: type "." (without quotes) under Directory name and press Enter or click Select this selects the current directory (I really want the other solutions in this bug to be implemented, but I just realized the above works and is much easier when you've already got the directory than going to the parent and selecting it)
*** Bug 229776 has been marked as a duplicate of this bug. ***
Hi! This bug has been opened for a year and a half. Anyone working on it? I'm using Mozilla 1.6b under Linux. When I have a number of email attachments, and I need to [Save All] on the attachments, I have to go through an akward dance of going to the parent directory of where I start out at, clicking once on the directory I want to save into, then clicking select. A big song and dance for a simple action. For my issue, at least, the ability to save into the current directory would be a plus.
Josh, no one is working on this, no. If someone were, a target milestone would be set. Feel free to propose UI that addresses the concerns expressed in this bug....
As a user (and a bit of an amateur interface freak), I agree with the idea in the original description by Johann. Allow the current directory to be selected. That is, allow the [Select] button to be hit if no name is specified in the Directory Name prompt. The meaning of which would be the current directory. This would be a very minimal change and would give the correct functionality that users want. If this could be considered confusing, then at the bottom of the box, put "Selected Directory: /home/jmccorm/download" or whatever which shows what they would end up selecting if they hit [Select] at any time (input or not input). (This also fits in with Johann's later comments, I see.) If a directory name HAS to be highlighted to make this done, then, perhaps at the top of the file list should be [Current Directory] or something, which is already selected and a valid option. But there may be some ambiguity in there on what a double-click would mean (select it, or change into it). Either way would also have the bonus of allowing a user to double-click into the directory that they want and hit select. (Rather than double click up to the parent, then single click on the directory, then click select. That is such an odd UI choice.) I do see the core problem that other people here see, and that is a collision of two interface metaphors: "directory navagation vs file selection". And there are better UIs to handle directory navigation. While it is all a good argument, really, that goes well beyond the bug's description. (The description isn't about the ambiguity between select and open. It is more narrow, just being able to select the current directory.). My belief is that we should fix what we have, and if someone wants to rewrite the entire thing later to fix the broken metaphor, that's great too. But the mixed metaphor should be a different bug. It is of wider scope than this simple issue of selecting the current directory. Am I winning anyone over with this suggested approach?
Neil, what do you think of comment 41?
OK, so I made the following changes: * Removed a superfluous setAttribute("ondialogcancel") * Removed a .focus() that caused a focus race condition * Made it so that the accept button is always enabled in folder mode * Allowed the picker to traverse unreadable folders (previously it was only allowed to open on unreadable folders)
Assignee: jag → neil.parkwaycc.co.uk
Status: NEW → ASSIGNED
Attachment #156255 - Flags: superreview?(jag) → superreview?(alecf)
*** Bug 134634 has been marked as a duplicate of this bug. ***
Why not simply use native dialogs from GTK as Firefox in Ubuntu already does? (see bug 134634 comment 10 )?
Rimas: Mozilla/Firefox already uses the native dialog for gtk2. The native dialog for gtk1 is bad, specifically not handling multi-byte encodings, so Mozilla uses its own.
Even firefox doesn't use the GTK2 dialog except on latest-and-greatest GTK2 versions. It's too broken in the early GTK2 versions to be usable.
Attachment #156255 - Flags: superreview?(alecf) → superreview?(bryner)
Comment on attachment 156255 [details] [diff] [review] Proposed patch Looks ok, and it somewhat closer to gtk's file selector.
Attachment #156255 - Flags: superreview?(bryner) → superreview+
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Am i getting it right that this dialog will only be used with GTK1 from now on?
You need to log in before you can comment on or make changes to this bug.