After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 341666 - Download dialog is confusing
Download dialog is confusing
Status: RESOLVED OBSOLETE
Product: epiphany
Classification: Core
Component: Downloads
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: Epiphany Maintainers
Epiphany Maintainers
: 466718 511984 (view as bug list)
Depends on: 618443
Blocks:
 
 
Reported: 2006-05-13 17:28 UTC by Josselin Mouette
Modified: 2011-03-07 20:43 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Remove distinction between "save as" and "download" directories (6.46 KB, patch)
2007-01-20 20:47 UTC, Josselin Mouette
none Details | Review
Simplify download dialog (5.37 KB, patch)
2007-05-18 22:54 UTC, Josselin Mouette
none Details | Review
Simplify download dialog (updated for 2.22) (5.30 KB, patch)
2008-07-21 10:51 UTC, Josselin Mouette
none Details | Review

Description Josselin Mouette 2006-05-13 17:28:02 UTC
[ forwarded from http://bugs.debian.org/280280 ]

Having to choose between "download" (which goes in a default directory) and "save as" is quite confusing.

How about removing entirely the "download" option?
Comment 1 Reinout van Schouwen 2006-05-13 18:01:38 UTC
Thanks for your bug report.
This happens only when downloading files with an unrecognized / unsafe MIME types, right?

When the "download" option would be removed, it would be inconsistent, because downloading recognized MIME types simply saves it in the default downloads folder. What reason is there to make the user select a folder to save to when the MIME type isn't recognized? 

If the dialog really is confusing because of this, maybe we should remove the "Save as..." button instead :-)
Comment 2 Josselin Mouette 2006-05-13 18:09:05 UTC
For recognized MIME types, epiphany gives the choice between "save as" and "open". This is good.

For unrecognized ones, it gives the choice between "save as" and "download". That's the "download" option which I think should be removed. This would still be consistend with the dialog box for recognized types.
Comment 3 Reinout van Schouwen 2006-05-14 09:59:47 UTC
Ah, I see that I forgot about the possibility to unset the preference to automatically download and open files. (Auto download is the default setting, if I recall correctly).

Of course, I am all for simplifying the user interface, but removing the Download button would come at the cost of some extra mouse clicks for the Save As dialog that asks me where I want to save the download, even when I have specified my  download directory already in the Preferences! Since either of the two buttons will save the file to disk there is no risk of data loss in case a user finds it confusing-- is it really worth it to remove this button then?
Comment 4 Josselin Mouette 2006-05-14 10:28:13 UTC
When a user first starts epiphany, he has no idea that "download" will put the files in the default download directory. Therefore, if he clicks on it, he'll then ask "where has my download gone?" and try again with "save as".

I can see several scenarios for fixing the bug without adding extra mouse clicks.

1. Keep things as is, but rename the "download" button to something like "save to default directory".

2. Remove the "download" button, and make the "save as" always bring up the default download directory *if* it has been defined by the user. Otherwise, remember the last download directory. That's still one extra mouse click for users like you, though.

3. My preference: remove the "download" button, but add in the "save as" filechooser box an extra checkbox: "Always save to this directory". Once it has been set, don't ask anymore where to put files.
Comment 5 Reinout van Schouwen 2006-05-14 10:46:57 UTC
The lack of download feedback is covered in bug 138876 (please test the patch :).

1) The text on the button would be (too) long, but I would reword this to [[ Save to folder “<download folder name>” ]]

2) Possible, but bug reports would start to come in asking to remember the last selected folder in the file chooser. A workaround could be to completely remove the Download folder preference and rely on the last selected folder at all times. 

3) 'Always do X' checkboxes are bad, because you need a place to revert them too. Besides, they clutter the UI and in my experience most users, even advanced, don't ever bother to use it but simply always click the first "Get out of my way" button they see.
Comment 6 Wouter Bolsterlee (uws) 2006-05-14 10:47:25 UTC
Please, no checkboxes in dialog boxes! They're horrible and hide preferences in non-obvious places.
Comment 7 Josselin Mouette 2007-01-11 23:13:28 UTC
After some thinking, I'm not giving up on this issue. How about the following:

* Grey out the "Download folder" combo box in the preferences, unless "Automatically download and open files" is checked.

* Use the same data store for this value and for the last folder used by the "save as" filechooser dialog.

* Make the "Download" action in the context directory download the file in the same last used folder.

* When clicking on a link with an unknown MIME type:
 - If "Automatically download and open files" is disabled, directly bring the "save as" dialog. No first question to ask whether you want to download or save the file. You can still cancel the download at this stage.
 - If "Automatically download and open files" is enabled, save to the directory defined in "Download folder" - which happens to be the same last used folder when using it for the first time - without asking.

I think this would greatly simplify the download UI without any of the drawbacks that have been described so far.
Comment 8 Josselin Mouette 2007-01-20 20:47:34 UTC
Created attachment 80773 [details] [review]
Remove distinction between "save as" and "download" directories

Here is the implementation of what I proposed.
Comment 9 Christian Persch 2007-01-20 21:57:23 UTC
IIRC there was resistance against that idea... maybe conatained in one of the download threads at http://mail.gnome.org/archives/epiphany-list/2003-December/thread.html ...
Comment 10 Josselin Mouette 2007-01-22 19:40:41 UTC
The arguments that were explained at that time are still valid, but that doesn't make the current implementation better. Furthermore, it was before GtkFileChooser and its nifty bookmarks appeared, serving almost the same purpose.

The idea to at that time was that there are two kind of users, those who download everything at the same place and sort it later, and those who download things directly where they want it. That's true, but as these are two kinds of users, you can make the distinction once and for all by clicking on "Automatically download and open files".

In the end, the patch removes one click for each download for one kind of users. That can mean quite a lot of clicks saved at the end of the day.
Comment 11 Reinout van Schouwen 2007-01-22 20:51:45 UTC
Josselin, could you please bring this up on the mailing list?
Personally, I don't think merging last-used and default download directories is a good idea. Among other reasons, because distributors depend on the feature to set a custom download directory.
Comment 12 Josselin Mouette 2007-05-18 22:54:30 UTC
Created attachment 88423 [details] [review]
Simplify download dialog

After having finally found the time to work again on this issue, I have to agree that merging the two directories is a bad idea. Plus, it doesn't really bring much usability improvement.

Here is another try. I have kept the download dialog improvements, and removed the last cases where "download" could be shown without the user having selected auto-download.

It also makes it clear in the preferences dialog that the download directory is only meaningful when auto-download is selected, by making it insensitive otherwise.

In the end, this change should save about one click per download, therefore increasing mice lifetimes.
Comment 13 Josselin Mouette 2007-07-25 13:02:09 UTC
The latest patch has been applied in Debian unstable for a while, and so far I haven't received any negative feedback.

If there's anything you'd like me to improve before including the patch, just tell me.
Comment 14 Reinout van Schouwen 2007-08-14 20:40:49 UTC
*** Bug 466718 has been marked as a duplicate of this bug. ***
Comment 15 Diego Escalante Urrelo (not reading bugmail) 2007-12-23 06:45:32 UTC
I'll add my use case to the chat:

When I'm downloading -say- some tarballs, I usually hit "Download" because I know Download will put stuff in $download-dir.
When I'm downloading -say- pictures, I hit "Save as..." so I can choose where exactly to save this stuff (say: ~/pics/).

I've been using sid's epiphany and I miss the Download button, but maybe it's just MY use case, MY expected behaviour. 
Sometimes I only want to get the stuff to my laptop, to my incoming dir, I don't really care about it in that moment. And sometimes I want to save it somewhere specifically. I don't think neither of the cases should exclude the other.

I just wanted to add my 2 cents.
Comment 16 Reinout van Schouwen 2007-12-28 09:50:00 UTC
Does the patch make the file chooser pop up with the XDG download directory pre-selected?
That way we could keep the amount of extra work for the use case where you just want to download and inspect later to a minimum, while satisfying the people who expect Save As and a file chooser.
The current situation isn't very ideal either, as you must develop mental concepts of downloading vs. saving in a folder, while it's almost the same thing.
Comment 17 Reinout van Schouwen 2008-01-25 11:25:49 UTC
*** Bug 511984 has been marked as a duplicate of this bug. ***
Comment 18 Josselin Mouette 2008-07-21 10:51:13 UTC
Created attachment 114913 [details] [review]
Simplify download dialog (updated for 2.22)

Here is an updated version for 2.22 that works with gecko 1.9, and formalizes better what is done and under which conditions.
With auto_downloads on:
 - safe types are opened directly
 - safe types without helper are downloaded directly
 - unsafe types are downloaded after asking
With auto_downloads off:
 - safe types are asking whether to open or save as
 - safe types without helper bring directly the "save as" dialog
 - unsafe types bring the "save as" dialog after asking

The proposition in bug#511984 to configure auto-download and auto-open is interesting, but it opens the door to endless configuration. You can configure ephy to download files automatically when you like to click on a lot of tarballs and find them later in your downloads directory, but if later you click on a PDF, it behaves the same and that’s not really useful.

(In reply to comment #16)
> Does the patch make the file chooser pop up with the XDG download directory
> pre-selected?

Nope. A previous version did merge the two preferences (download directory and last directory where you saved), but it wasn’t good since it makes the path where files are going unpredictable. I fear that doing the opposite (always pre-selecting the download directory) is going to be similarly confusing, and would diverge from all other applications where the "save as" dialog brings to the last directory you used.

Maybe instead, we should add the download directory to the dialog with gtk_file_chooser_add_shortcut_folder.
Comment 19 Wouter Bolsterlee (uws) 2008-07-21 11:01:40 UTC
(In reply to comment #18)
> Maybe instead, we should add the download directory to the dialog with
> gtk_file_chooser_add_shortcut_folder.

I think that already happens.
Comment 20 Diego Escalante Urrelo (not reading bugmail) 2011-03-07 20:43:24 UTC
The just committed bug #618443 (new downloads UI) makes this bug(s) obsolete.