125210 - Save as should remember N recently used directories saved to in dropdown

Status: RESOLVED DUPLICATE of bug 24625

(Core :: XUL, enhancement, P5)

Description

[[e-mail]]

The save as dialog currently has a history dropdown menu that just remembers
the history of directories browsed during the current save as interaction.
This should be changed to contain a persistent list of the last N directories
where files have been saved to. This is a very important and convenient 
features since users often save different types of data (html, images,
postscript) to entirely different local directories.
For a quick solution i propose N to be 6 and a temporary sorted list in the 
drop down (most recent first).

Comment 1

[Quinn Yost (mythdraug)]

*** This bug has been marked as a duplicate of 115574 ***

Comment 2

[Boris Zbarsky [:bzbarsky]]

sorry, not the same.  The other bug is an All bug filed by a windows user.

This bug, filed per my request, I must note, is for the XP filepicker to support
this functionality, which is a totally separate kettle of fish.

I should also note that the current dropdown has no history in it anymore, it
just has the ancestor list.

Mpt, I'm not sure whether it would be better to have a separate dropdown for the
recent dirs or whether I should put them in the ancestor list dropdown (with a
separator before them, of course).  Thoughts?

Comment 3

[Boris Zbarsky [:bzbarsky]]

Gonna try to get to this for 1.0.

Comment 4

[Quinn Yost (mythdraug)]

BZ: No problem..

Removing myself from CC

Comment 5

[[e-mail]]

I think there should be seperate lists: it is semantically clearer,
each list will be shorter, also the list of recent dirs has a limited 
number of entries whereas the ancestor list is fairly unlimited (is there
a limit to directory nesting?). 
The problem when having it in one list: if the ancestors come first, 
one might have to scroll down an unknown, possible large number of
entries to find a recent dir. If it is the other way round, simply
going up one level becomes extremely clumsy.

Comment 6

[[e-mail]]

discussion and proposals for the enhancement of filepicker are 
in bug http://bugzilla.mozilla.org/show_bug.cgi?id=125133 

Comment 7

[Boris Zbarsky [:bzbarsky]]

No time to work on this for 1.0.  Adding helpwanted keyword.  If you want to
work on this, please let me know and I can give some pointers...

Comment 8

[Boris Zbarsky [:bzbarsky]]

*** Bug 102877 has been marked as a duplicate of this bug. ***

Comment 9

[Boris Zbarsky [:bzbarsky]]

Attachment: what I have so far

very rough proof-of-concept patch in case people want a jumping-off point. 
Issues with this patch:

1)  The recent dirs list should be a menubutton with an image (a la bookmarks
    button on personal toolbar), not a menulist.
2)  Pref observers are needed.	If multiple filepickers are open and a file is
    picked in one, the others need to update the recent dirs list
3)  The "number of things to save" may need to be made non-prefable.  This
would
    significantly simplify the code assuming we picked one value and never
    changed it.
4)  For open/save we should remember the _file_ not the directory.  Selecting
    that file from the list should go to the correct dir and select the file in

    the outliner (but not trigger ok).

Comment 10

[[e-mail]]

Boris, I have already taken first steps to include your code in the 
new filepicker stuff I am working on in bug 125133. 
Here a few comments:
1) the design in attachment 72579 [details] originally planned to have the recent files
in the "look in" menulist instead if the ancestor list. The ancestor list
would be moved to the dropdown list that is attached to the "up" button, 
where it seems to belong naturally. The dropdown list near the home button
should eventually contain a list of bookmarked (favorite) directories.
I wouldnt know a good and intuitive way to design two different buttons,
one for the MRU directories and one for the favorite/bookmarked ones ...
2) why do we need pref observers when the filepicker dialog is modal?
no two of them seem to be able to exist at the same time anyway.
OTOH I am the first to support getting rid of modal dialogs, so could you
point me to an example js where pref observers are used?
3) I think having this just as a hidden pref for now wouldnt be that
complicated? I think ultimately, the dropdown menu should have two
"special options", set apart by a separator, that allow to clear the 
list and maybe pick the number of dirs to remember (though the latter is 
not that important)
4) I really dont see the advantage of this and I think 
it would make things harder to implement and harder to understand by the user.
Also it would work differently from MRU dir menues in other programs, and 
thus be confusing.

Comment 11

[Boris Zbarsky [:bzbarsky]]

> the design in attachment 72579 [details] originally planned to have the recent files
> in the "look in" menulist instead if the ancestor list. The ancestor list
> would be moved to the dropdown list that is attached to the "up" button, 
> where it seems to belong naturally.

The "ancestor list" is a dropdown from the current directory in every
application I have looked at which has an ancestor list.  People depend on this
behavior and we should follow it...  

> I wouldnt know a good and intuitive way to design two different buttons,
> one for the MRU directories and one for the favorite/bookmarked ones ...

Me neither, but that's the part at which we ask a UI design person to help... :)

> why do we need pref observers when the filepicker dialog is modal?

Because filepicker should be _window_-modal.  That is, filepicker in one window
should not freeze other windows.  The fact that it does is a but in the toolkit
code which will get fixed at some point...

You can open multiple filepickers with Ctrl-O as it is (due to yet another bug
in event code).

Pref observers are used in, say, navigator.js (search for
addObserver/removeObserver).  My current code is kinda sucky since it's not
clear what one should observe...

> I think having this just as a hidden pref for now wouldnt be that
> complicated?

Well, it makes the code complicated because making that number smaller involves
trimming off the extra prefs and such.... Hence the branch-clearing hack.

> clear the list

Hmm.. sure, if we feel that's needed....  Let's not overcrowd the UI here. :)

> pick the number of dirs to remember

This is one of those "if this is pref-able at all, it should not have UI"
things, imo.  Again, let's not clutter up the UI with things only about 10
people will ever use.

> I really dont see the advantage of this and I think 
> it would make things harder to implement and harder to understand by the user.
> Also it would work differently from MRU dir menues in other programs,

That's because it's not an MRU _dir_ menu, it's an MRU _file_ menu.  See, eg,
what MacOS itself or Word have -- list of most recent files you have worked
with.  The advantage is that users tend to open the same _files_ over and over
(the ones they're working with).

This is for modeOpen.  For modeSave and modeSelectDir I think storing the
directory itself is better (yes, I know that's not what point 4 said; I have
thought about it more since then).

Again, we may want UI design's feedback on this stuff.

Thanks for working on this stuff, Johann.  :)

Comment 12

[[e-mail]]

Hmmm well, I think that there is not that much reason from a usability
point of view to give the ancestor 
list such an importance except that obviously it is easiest to implement
(e.g. KDE apps usually have a recent dir list instead). I have looked at quite
a few apps on my machine and there is not much standardization here. 
However the GTK filepicker is pretty common, but IMHO it is *very* badly
designed. The ancestor list IMO logically belongs to the up button --
I later found out that StarOffice has adopted a similar solution.
Staroffice in addition to the up button with the ancestor list also
has a "default dir" (not home dir) button that has a menu attached with
both recent and bookmarked dirs, but recent dirs are too hidden there.
I am all for standards and not puzzling users, but certainly Mozilla should be 
better where there is room for improvement .. .:)

I'd sure be glad to hear opinions of UI people here (even though I believe that
I do have some experience when it comes to UI design and usability issues )

OK, filepicker should be window modal, agreed, we need pref observers ..

I too dont want to overcrowd the UI, thats why I came up with that idea
of double-using up and home buttons in the first place. However I foresee
that people will complain about not being able to clear the MRU list
out of security and privacy reasons (not as big an issue as on single-user
OS, but still people might share users on a linux machine)
Anotehr thing is that both the recent and the favorite dir menu would
have a separated "section" of options for managing the entries. I think
that fits quite nicely with the interface people are used to when using
the bookmark menu. But of course we can postpone this for simplicity.

Agree to have N be a hidden pref, if at all.

I agree that for open it could make sense to remember files instead of 
dirs, but it makes the semantics of this a bit inconsistent. 
We would also have to change the text "recent dirs" to "recent files"
dynamically. Another thing is that opening ten different files from a 
single dir will make go away the other *dirs* from which files were 
recently opened. My understanding was that the purpose of the MRU dir
list was to a great extend to cut down the number of clicks needed 
to navigate to some "distant" directory. I often open files from
N different dirs (e.g. work, fun, tmp) on different file systems
so personally I would prefer that.

OTOH if we also have favorite dirs (e.g. folder bookmarks), that
need vanishes because the user can just bookmark his favorite folders.

Comment 13

[Boris Zbarsky [:bzbarsky]]

1.1alpha is frozen.  Unsetting milestone and will retriage in a few days when I
can make a realistic assessment of the situation.

Comment 14

[Boris Zbarsky [:bzbarsky]]

no time to work on this.  Really helpwanted now.  

Comment 15

[[e-mail]]

A couple of issues I am still not sure of:

Should we remember different sets of files/dirs for the different modes?

Do we want this to remember recent files or recent dirs, and which for which mode?

Where should that functionality be located in the GUI? I addition to my suggestion
to add this as a menu-button to the "up" button there is another option: 
Change the filename text entry field into a editable menu list. The advantage
of the latter is that it is located "closer" to the field that is active per
default and hence can be activated much easier using the keyboard.

Comment 16

[Boris Zbarsky [:bzbarsky]]

I have no plans to continue work on this... someone else will need to step up.  :(

Comment 17

[Peter Lairo]

*** This bug has been marked as a duplicate of 24625 ***