Re: Downloader UI Rationales

[Marco Pesenti Gritti <marco gnome org>]

> 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 this?) [1] 

FWIW it happened to me a few times to be called to support people that
was not able to understand where the file they downloaded was gone, to
be able to open it. And they was not complete newbies, they was using
computers for their work everyday.

> The important thing is to make access to the downloads folder fast. We 
> really have two options here. Currently we are defaulting to the desktop. 
> 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 names. 

Not using the desktop _could_ mak harder for people to find where their
files has been saved.

> 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 (medusa+storage). 

Agreed.

> 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). 

I think an "as" context menu would be a decent compromise. With current
file system if you want to keep a lot of stuff locally you are forced to
micromanage. Yeah, not many people does it. Though I think we have
several items in context menus that are much less used.

> 
> 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.[3] Other 
> technical reasons exist probably too i suppose. 

I think the plan was not to use a temporary file but download the file
in download folder and then open it. Did we change our minds on that ?
(fwiw that's what apple does too). I think using a temp file is pretty
risky, you cant assume viewers have a save functionality, if they dont
you end up making very very hard for user to keep the downloaded file on
disk.

I dont understand your problem with the url_show thing. Files are
downloaded by epiphany when they cant be handled directly by the helper
app ...

Marco