Re: Downloader UI Rationales

["David Adam Bordoley" <bordoley msu edu>]

Marco Pesenti Gritti writes:
> 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.

This is a common usability problem that is created by using a fileselector 
to select a download folder for every file as opposed to a common download 
folder. This happens all the time and is due to saving state nature of the 
file selector. In normal situations it makes sense to default the filesel to 
the last used folder. The only problem is that when used less frequently 
users forget where this is. This is one of the problems that the current 
design aims to address by providing a common/standard folder that all 
downloads are stored in. Less complex hierarichal memory is needed, and 
users can later on perform the task of organization. 

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

Yes and no. Assuming the desktop has a limited number of items on it 
(probably a somewhat resonable assumption) a subfolder of the desktop that 
is clearly labeled and perhaps a special icon or emblem should be equally 
usable and discoverable, since the number of items to scan is low. 

The downloads folder also is nice in that users can continue to dump stuff 
into it without getting the feeling of mess that can be associated with too 
many icons on the desktop. 

However for now I think sticking with desktop is probably a good idea if 
only to avoid the i18n issues. I'm not really fond of puttin an icon on the 
desktop labeled "Downloads" for japanese/italian/every language other than 
english etc. Eventually we can just switch to a storage based solution which 
will use a translatable .desktop file on the desktop which will fix this 
problem anyway and allow for a lot more leeway in the design. 


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

Well there is a lot of evidence suggesting that most users just dump their 
files into a big "My Documents" like folder and never micromanage (or do 
very little). Since micromanaging is an issue, the question than is when do 
we force micromanaging. Poping up a fileselector forces file management at 
download time. A default folder never "forces" micromanagement, but allows 
those who want to the ability to do it after succesful completion of a 
download. 

> Yeah, not many people does it. Though I think we have
> several items in context menus that are much less used.

Yeah image context menus are particularly scary :P 

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

I think this is a good idea in principle. I think the main concern in that 
since the desktop is the default download dir, user may end up with a 
cluttered mess. 

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

Maybe i'm just confused. I was pretty sure most pdfs i was opening were 
being downloaded first and then viewed instead of having a helper app open 
the remote file (gpdf which i believe uses gnome_vfs?)... 


dave