Re: Downloader design proposal

[Marco Pesenti Gritti <mpgritti oltrelinux com>]

--------------------------------------------------------------------------
2004 Jan 17 - 02:20
Xan Lopez <xan masilla org>
--------------------------------------------------------------------------
>As I seem to have wasted lots of time coding for a sucky design I can't
>resist to add my opinion too :)

I dont think you wasted your time. Current design has several positive aspects, it just have some issues that needs to be solved. My proposal cover it like it was a fully new design for completeness sake but I'm just proposing a few changes and you put in place already most of the code for them.
The fact you feel it like a waste is totally my fault. I shouldnt have started a redesign and then run away for months. Though I have to finish univ at some point, I'm getting old ;)

>So it's like our own version of /tmp in Mozilla? We will copy from
>there? We will cache *everything* even if the user does not download
>there? I think the current design is better. Default to a dir you can
>choose in prefs, but if the user explicitely selects another destination
>do what he says, he should know what he is doing. We could change the
>default from Desktop to Downloads, doing the auto-managing thing, but
>it's too late for 2.6 IMHO.

I have to look at how implementing it exactly, though it was meant to work that way from beginning.
Sure if the user select another destination we shouldnt put it in the downloads dir (my cache like description was confusing in this respect.
Basically this is the prob we was discussing yesterday, I think we should save the files we open in download dir: reasons was at the end of my mail.

>> 2 Downloader
>> 
>> It's mostly hidden to the user but it provides feedback on the status of
>> the download.
>> 
>> Renata doesnt look at it that much, though it was useful one time to
>> know how much time she was going to wait to see his document. Armando
>> looks at it every two minutes, start another download when others
>> finished...
>> 
>
>Right. I suppose you agree about a minimal ammount of interaction
>(Cancel, Pause/Resume) as we provide now.

Yeah, I think current design of downloader is correct.

>> - Confirmation dialog:
>> 
>> (Sucky text, it should prolly be something like 1.0 text)
>> 
>> It's not possible to open the link directly in the browser. The file
>> will be downloaded.
>> 
>> Save As - Cancel - Open (prolly Download when there is no handler).
>> 
>> It should be showed when automatic download is off or when the download
>> has been started automatically.
>
>I agree about something like this for automatic downloads (in fact we
>already have it, without pref). But I have yet to see a good reason to
>why is so important for people to be able to micromanage every single
>file they download *from the filepicker*. If using nautilus, the GNOME
>file manager, to manage files is such a horrible nightmare we are surely
>making some big mistakes in its design.

I think the main reason this doesnt work is memory. To be able to move the file you have to remember his name. I think filepicker less software will be possible only once we will be able to do rich autocategorization.
(There is a reason we show an add bookmark dialog).

>Of course, this requires one more click, but I see it
>as the way for skilled people to make their downloads, and I think we
>should try to design for the average user, not the expert one. 
>But it seems this is a lost battle, so I'll agree with whatever most of
>you think it's the best solution.

I think my proposal has average user as primary target. Though if we can accomodate also the expert one (not linux geeks only, there are more people with some sort of well organized files hierarchy), using the intersection with anotherproblem (the no confirmation thing) and adding virtually no clutter for the average user, then I think we should do it.
The Download link As... was a good solution, though since we need the automatic pref to solve the other issue, I think an alternate button add less clutter for the average user.

>> - Security Dialog
>> 
>> [Text to write.]
>> 
>> Cancel - Download
>> 
>> It should be showed when the mime type is unsafe.
>
>Disagree, I prefer feedback in another point of the interface as mpt
>suggested and not yet another dialog.

Can you elaborate on this ? I think for security probs feedback need to be very very strong. Files executed accidentally is possibly the worst usability issue of the Internet ;)

>> 
>> The Download link as... in context menu is at this point controversial.
>> Since we have already a way to Save As, maybe we can avoid it.
>> DID WE ADDRESS ANY PROBLEM ?
>> 
>> Yeah, we addressed 1 with the checkbox preference. I think it's ok to
>> use a pref here because:
>> 
>> - A totally clean design is impossible without assuming web sites does a
>> good work with downloads links. And we cant really assume it ...
>> - We have two behaviors that are good depending on the persona we
>> consider. This looks like a case where personalization is good and
>> necessary.
>> It's not a choice between two borked behaviors. We should keep working
>> to make using another app to open the file the less annoying it's
>> possible.
>> - Mainteinance cost is low
>> 
>> We addressed 2 with the alternate action in the confirmation dialog. In
>> my opinion there is intersection between the two problems. If you want
>> to micromanage files you will be very annoyed to have stuff downloaded
>> on your disk without confirmation.
>> If there is no intersection the Download Link As... context menu will be
>> still necessary.
>> 
>> Also we adressed 3 that I forgot to mention. We never actually made a
>> call about saving the file in Downloads dir or in tmp with clicks on
>> links. I think we should save in Downloads directory for these reasons:
>> 
>> - Downloading on the desktop we would make unwanted downloads annoying
>> for Renata too. She got a few icons on the desktop and she heavily
>> depend on them: we cant clutter it.
>> - Having a download directory isnt that useful if the only way to use it
>> is a context menu item.
>> - If we use a Downloads folder instead of the desktop, esp with
>> automatic categorization, there is no penalty to keep the file on disk.
>> I think the main advantage to use the desktop would be quick open,
>> though that's not necessary since we autoopen.
>> - We can do automatic categorization
>> - It could be a good place to download pages, parts of sites ...
>> 
>
>Probably it's sane to create a Downloads dir and default to it, I'll
>agree with that. I wonder if we'll be able to do it for 2.6 though.

I think the automanaging thing is post 2.6. It's nothing difficult to hack but it certainly qualify as a new feature.
What's the problem with the dir though ? It would seem like just changing default and support "Downloads" in the same way we support "Desktop".

Thanks for the feedback

Marco