[Usability] Downloads recommendation
- From: Marco Pesenti Gritti <marco gnome org>
- To: usability gnome org
- Subject: [Usability] Downloads recommendation
- Date: Sat, 20 Dec 2003 11:00:49 +0100
we experimented with a different downloader design with 1.2. While I
think we reached some interesting results, it doesnt seem to be mature
enough to actually make 1.2. Maybe you can help us solving the problems
or showing us that we are going in a wrong direction.
Safari behavior is very similar and I'm somewhat surprised given the
number of the issue it raise. Maybe our implementation is just not
mature enough ...
[Cut/Paste from a Dave Bordoley mail explaining the controversial
So there are two majors changes we've made to the downloader ui in
epiphany 1.2. First we've added a default downloader folder to which all
files downloaded via the context menu 'download link" action are saved
to. In addition we've made click a link automatically open a linked file
(if it is considered safe).
I will address each change and its rationale seperately and we can
continue the discussion from there.
Default Download Directory and Download Link Behavior
The change in the download link behavior had several motivations. First
were some observations that I and I believe Xan had both made. Many
users tend to download files to the same folder and then later organize
their files. In fact one user that Xan worked with had explicitly
mentioned to him that he found it kind of wierd that the ui kept asking
him the same question when he tried to download more files (where to put
The default download folder has a few advantages imo. First its less
stressful on the user who doesn't want to micromanage everything. This
is especially true of user who may be downloading multiple files at once
(think lots of rpms from freshrpms). Continuously prompting the user for
a folder to save to becomes annoying. Further evidence of this can be
seen in all file sharing programs i've ever used. They all use the idea
of a default downloads folder to facilitate fast downloading. Users can
later go ahead and categorize, rename etc.
The important thing is to make access to the downloads folder fast. We
really have two options here. Currently we are defaulting to the
This decision to the best of my knowledge is really based upon i18n
concerns. Honestly I'd much prefer a desktop subfolder called Downloads,
but too many flame wars have erupted about using non-localized folder
Its also been suggested that we should go even further and support
multiple default folders based on mime types. While the idea is sound,
the real solution to this issue is something akin to search folders
implemented at a a level above of the traditional filesystem
Anyway I at least find the current behavior much more usable, probably
due to the fact that i'm not a micromanager. I don't really think we
should add additional "save link as," as its somewhat redundant with
download. Plus I'm fairly certain that the main user action on links are
open and download (bookmarking is probably even a rare action here).
Open Link Behavior
I guess there has been concern about single click a link, opens
documents in their specific application. I'm not really sure what the
concern here is as long as we are sufficiently sane about the
implementation. Obviously we don't want to automagically run scripts,
executables etc. However it seems pretty sane to me at least that
clicking a link automagically opens in a viewer. Every viewer should
include save as functionality which should make saving the viewed file
in the users filesystem area pretty trivial. My only real grievance with
the current implementation is that it uses a temporary downloaded file
instead of something like gnome_vfs_url_Show. Other technical reasons
exist probably too i suppose.
- People that organize their downloads in subfolders feel the new
behavior too slow. They have to remember the name of the file, and use
the filemanager to move it there.
A possible solution would be to add a "Save Link As..." item that show a
- Often the name of the downloaded files are bad like 261a96.ps,
R64838.pdf, Setup.exe. With a file picker you can rename them while
downloading (how many users does it though ...). Doing that later
require to remember the name of the file.
- Should the files be saved in the downloads dir also when opening them
(click) or just saved in a temporary location and then deleted ?
Both behaviors seem to have problems. You dont want to keep around all
files you viewed but, especially on slow connections, you want to keep
some of them.
There is the Download link item in context menu but many users doesnt
use context menu and not all downloads start from a link.
- The click behavior can be inconsistent when there is no handler for
the file (i.e. the file is not opened but just downloaded).
This could be easily solved by showing a Cancel/Download dialog in that
- With very small files that does not have an handler we lack feedback.
The download progress dialog is showed and hidden quickly.
We considered to have a minimum time the download progress is kept
visible. Though if we decide to show a dialog for files that has not an
handler application, this could be not necessary anymore. In fact an
application or a dialog will popup in any case.
- People are used to click on links without worrying about what is going
to happen. With the new behavior you often dont know if a file will be
downloaded or a web page opened. The difference is that you will have a
new window opened, you will need to wait some time to see the document
(the time necessary to download it), a file will be saved on disk, a
possibly slow to start application will be launched. While I guess
opening a new window is not a problem (the same happen for nautilus),
the others are probably the reasons that makes unexpected downloads
This is what I'm more worried about. I cant think of any possible
Thanks for any feedback. I hope I gave enough details, if something is
unclear please ask.
] [Thread Prev