Closed Bug 142482 Opened 22 years ago Closed 19 years ago

redesign directory selection behavior of file picker (modeGetFolder)

Categories

(Core :: XUL, defect)

Product:
Core
Component:
XUL
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: johann.petrak, Assigned: neil)

References

Details

(Keywords: helpwanted)

Attachments

(1 file)

Proposed patch
2.77 KB, patch
janv
: review+
bryner
: superreview+
Details | Diff | Splinter Review 
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)
Blocks: 125133
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....
Keywords: helpwanted
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?
Attached patch Proposed patch — — Splinter Review 
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)
Attachment #156255 - Flags: review?(varga)
Attachment #156255 - Flags: review?(varga) → review+
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: 19 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.

Attachment

General

Creator:
Created:
Updated:
Size: