Re: Downloader design proposal

[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 :)

El sáb, 17-01-2004 a las 01:36, +0100, Marco Pesenti Gritti escribió:
(...)
> DESIGN PROPOSAL
> 
> There are three main components:
> 
> 1 Download folder
> 
> It's an object on the desktop and acts like a sort of cache for stuff
> Renata and Armando downloaded from the web. Files are automatically
> sorted in subfolders (Music, Video, Docs etc).
> 
> Renata has a fast connection so she often prefer to just open the web
> site again and click the link. A few times though the folder helped her
> to find documents she was not able to find again on the web.
> Armando didnt use that folder at first, he had his nice hierarchy,
> though he was in a hurry a few times and decided to just download there.
> It was nice to find the files there later !
> 

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.

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

> 3 Browser
> 
> Renata can finally see his documents without the help of Armando. She
> click on the link and the file opens.
> 
> Armando changed a preference in epiphany and now he feel the behavior
> much more flexible. He can confirm to download the link he clicked on
> and use the download folder when he is in a hurry (he can move files to
> his nice hierarchy later). When he wants to put his file in his
> downloads hierarchy or something else he just choose another button in
> the dialog.
> 
> SHORT TIME
> 
> To end the funny story here is a description of the actual user
> interface I'm proposing. They are very simple to hack, and we have
> alredy most of them, so I think we can easily target 2.6:
> 
> - A preference for the downloads directory. Default should be
> "Downloads" translated. It doesnt seem a big issue if changing language
> create another dir (it doesnt seem like a common use case to switch
> languages of the same user), and we can find a better solution for 2.8.
> 
> - "Download and open files automatically" checkbox in the preferences.
> Default ON, when it's OFF we show a confirmation dialog.
> 
> - 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. Besides, we added Download Link
As... in the context menu, which will show a filepicker in case you
really want that. 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.

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

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

> Ok, there is not much that is mine in the design. I just tried to put
> together Dave, Mickael, Alan ideas in a plan (esp short time).
> Do you think it make sense ?
> 
> /me fear Dave flames coming very soon :P
> 
> Marco
> 
> _______________________________________________
> 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