Re: Downloader UI Rationales

[Xan Lopez <xan masilla org>]

On mar, 2003-12-16 at 12:53 -0500, David Adam Bordoley wrote:

> 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] 

More than finding it weird, he found it annoying. We were at school
downloading some files from the intranet to our computer, and he had to
a) click link b) press ok c) close download window like 15 times. With
out implementation, 15 clicks would have been enough. Of course, I don't
intend to base a whole design in this, but I think it's an interesting
example of a behaviour in the old downloader that could be really
improved.

> 
> 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.[2] 

That's exactly my point, although some people seem to think
micromanaging every file in the filepicker is a better idea. Like marco,
I think adding Save file as to the context menu could be a good
compromise.

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

Well, I think Desktop is more visible, but I don't really have a strong
opinion about where to put files by default (as long as they are "easy"
to find).

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

Amen.

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

IIRC, it's Mozilla who stores stuff in /tmp, but we could try to move it
if we think it's important, I suppose.

> 
> Anyway lets talk more about this, and sorry for getting involved late in the 
> discussion. 
> 
> dave 
> 
> [1] Xan I hope I'm not misrepresenting our IRC conversation from awhile back 
> (I think it may have even been summer time). :)
> [2] The file manager is a far superior interface for managing files than the 
> file selector anyway.
> [3] Although since gnome_vfs uses epiphany as the http:// handler this 
> creates an interesting problem. 
> 
> _______________________________________________
> epiphany-list mailing list
> epiphany-list gnome org
> http://lists.gnome.org/mailman/listinfo/epiphany-list
-- 
"The missionaries go forth to Christianize the savages -- as if
the savages weren't dangerous enough already" [Edward Abbey]

xan, xan masilla org