1351219 - Implement downloads progress indicator button for easy access to recently saved attachments (as in FF)

Status: NEW

(Thunderbird :: Mail Window Front End, enhancement, P2)

Description

[Thomas D. (:thomas8)]

Attachment: Screenshot 1: Proposal for new downloads accessor button

+++ This bug was initially created as a clone of Bug #907732 +++

Let's port the goodness of Firefox animated download progress indicator and accessor button to TB!

STR

1) Receive loads of attachments which need further management from within your local OS file manager (opening, renaming, editing, sorting, forwarding etc. of locally saved copies)
2) Save/detach/download attachments from message preview via TB attachment commands
3) Without prior knowledge, try to access the very files which you just saved to a known location, from that OS file folder location, for purposes listed in 1)

Actual result:

* TB workflow for this simple and basic operation is seriously impeded/interrupted, as there's no direct link nor hint to "Saved Files" tab (see user story).
* Unaware users might resort to searching the files again from within their local file manager, which is absurd given that their location is known to TB
* "Saved Files" tab is hard to discover, a bit bulky and workflow is not as efficient as it could be, forcing user to abondon the context of main 3-pane window

Expected result:

* On main "Mail Toolbar", have a minimalist downloads progress and accessor button with exactly same UI and behaviour as in FF (see mockup screenshot attached with this description)

+ ux-discovery: animated button provides easily discoverable way of accessing files just saved from attachments
+ ux-efficiency: this button delivers significant improvements for efficient handling of just saved files: instead of switching to "Saved Files" tab which user may not even know about, have files and containing locations available at your fingertips, without leaving the context of main 3-pane window
+ ux-userfeedback: animation provides excellent user feedback to let you know about attachment saving progress (for big files), and where your files have gone.

Comment 1

[Thomas D. (:thomas8)]

^^

"Show all downloads" should be renamed to "Show all saved files"

Comment 2

[Thomas D. (:thomas8)]

Fyi

Comment 3

[Richard Marti (:Paenglab)]

Comment on attachment 8851924 [details]
Screenshot 1: Proposal for new downloads accessor button

Looks reasonable. Like FX after a restart the panel will be empty, correct? Instead of showing then a empty panel with only the link to All Downloads, I would open directly the Downloads tab to save a click.

Comment 4

[Thomas D. (:thomas8)]

(In reply to Richard Marti (:Paenglab) from comment #3)
> Comment on attachment 8851924 [details]
> Screenshot 1: Proposal for new downloads accessor button
> 
> Looks reasonable.

Is that shorthand for "I like it"? ;)

> Like FX after a restart the panel will be empty, correct?

We should probably discuss such details when we get there...
But I guess yes.

> Instead of showing then a empty panel with only the link to All Downloads, I
> would open directly the Downloads tab to save a click.

I think we should be consistent with the Firefox download button, they show:
+--------------------------------------+
|   No downloads for this session.     |
+--------------------------------------+
|       Show All Downloads             |
+--------------------------------------+

So for TB, this would be:

+--------------------------------------+
|   No saved files for this session.   |
+--------------------------------------+
|       Show All Saved Files           |
+--------------------------------------+

It would be unexpected and ux-inconsistent for the same button to sometimes open a panel and remain in 3pane context, but sometimes jump straight into the saved files tab. It also defeats muscle memory, especially for keyboard users, where their habitual [s] or Alt+s access key press to "_Show All Saved Files" might end up on some other control in the Saved Files Tab.
Plus, the "empty" panel actually has some informational value, depending on user workflow.
For jumping into "Saved Files" tab straight, there's Ctrl+J keyboard shortcut, which is also advertised in the FF button tooltip.

Comment 5

[Thomas D. (:thomas8)]

I think this RFE comes with a very good cost-benefit ratio, and we'd actually have a nice and nifty, visible new thing to show off in the next release. This streamlines the currently broken every day attachment downloading experience a lot.

How can we get some traction on this RFE?

Can someone find starting points in the FF code base so that we might borrow from them?

Comment 6

[Thomas D. (:thomas8)]

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #5)
> ...find starting points in the FF code base so that we might borrow
> from them

The Firefox download button lives here:
https://dxr.mozilla.org/mozilla-central/source/browser/components/downloads/content/indicatorOverlay.xul#21

Comment 7

[Thomas D. (:thomas8)]

We might want to use duplicate bug 1471833 [EDIT: the bug was morphed, see comment 8] to implement at least a minimal version of this until we succeed to get to the full goodness of the FF download experience in TB: Just having a dedicated toolbar button for accessing "Saved Files" directly from main 3-pane would go a long way.

Comment 8

[Thomas D. (:thomas8)]

(In reply to Thomas D. (:thomas8) from comment #7)

We might want to use duplicate bug 1471833 to implement at least a minimal version of this until we succeed to get to the full goodness of the FF download experience in TB: Just having a dedicated toolbar button for accessing "Saved Files" directly from main 3-pane would go a long way.

FTR Bug 1471833 (originally more about implementing a Download button on 3-pane main toolbar) was morphed to implement "Open containing folder" icon for each file on Saved Files tab.

Comment 9

[Thomas D. (:thomas8)]

#1 in the thomas8 UX-papercuts series.

Aleca, Ryan and I agreed that this would be great to have, also wrt enterprise usage where ux-efficiency matters even more. Can we try this?
I am envisioning an exact duplicate of the FF downloads progress button. For details, see comment 0, which also has a mockup screenshot (attachment 8851924 [details]). Of course we'd now use the current FF download progress icon (including the nifty animation on there).

This is a daily nuisance: The workflow to retrieve a just-saved attachment in the target folder is broken, as there's no direct link to the Saved Files Tab, which is virtually undiscoverable (Ctrl+J can only help if you know it, and it won't help mouse users). It's so boring that we make our users search for a just-saved file with their file managers again, but Thunderbird knows where it is and could easily link up! I imagine that this happens a million times every day for Thunderbird users.

Comment 10

[Thomas D. (:thomas8)]

Attachment: Screenshot 2: Mockup of the Downloads progress/accessor button in Mail Toolbar

Here's a mockup featuring the FF's current Download Progress / Accessor button in Thunderbird. When you click it, you get a modernized variant of the screenshot seen in comment 0, attachment 8851924 [details].
Imo, the button should be on the Mail Toolbar:

• Always accessible, even when the current message does not have attachments.
• This will also be good for future workflows when we allow saving attachments from multiple messages.
• Similar top priority location as in Firefox - Access to Saved Files is quite important!

Comment 11

[Alessandro Castellani [:aleca]]

Indeed, this is an important feature we should aim at having it before next ESR.
Showing it beside the main app menu is a good and expected location for it.

Always accessible, even when the current message does not have attachments.
This will also be good for future workflows when we allow saving attachments from multiple messages.

Wait, I'm a bit confused. Are you proposing to always have that indicator visible?
I think it should behave as it doesn't now on Firefox, which means:

• It appears only after you saved files.
• It has a blue highlight color when a new file finishes downloading, and it remains highlighted until you click on it.
• It remains visible unless you clear your recently downloaded files list.

Comment 12

[Richard Marti (:Paenglab)]

What should also be considered: TB forgets the downloaded files when it closes. The list is empty on next start.

Comment 13

[Thomas D. (:thomas8)]

(In reply to Alessandro Castellani [:aleca] from comment #11)

Are you proposing to always have that indicator visible?

Yes, I think that would be helpful for easy and consistent access to Saved Files tab.

• Firefox think they can afford to hide the button because they have another one right next to it which still allows retrieving Downloads: View History, saved bookmarks, and more [incl. Downloads]. TB does not have that.
• We should provide an easy access to Saved Files tab even when the topmost entries (most recent entries) have been removed. There's a thousand reasons to look into yesterday's Saved Files which are still on the list. Having the button always available imo reduces the cognitive burden of sometimes finding Saved Files via the button, but sometimes not, which requires a totally different click pattern then.
• We should consider making Saved Files (Ctrl+J) a top-level entry in the app menu (especially if you want to hide the button). Perhaps underneath the Save As... submenu item.

(In reply to Richard Marti (:Paenglab) from comment #12)

What should also be considered: TB forgets the downloaded files when it closes. The list is empty on next start.

Is that by design? If yes, why? Shouldn't we just keep the list until the user clears it? Or some other smarter clearing which keeps things for a while?

Comment 14

[Alessandro Castellani [:aleca]]

Firefox think they can afford to hide the button because they have another one right next to it which still allows retrieving Downloads: View History, saved bookmarks, and more [incl. Downloads]. TB does not have that.

I think this is a bit of a wrong assumption.
That toolbarbutton is always visible unless the user clears all downloads. If there's nothing in the list of saved files, the button has no need of being there as accessing an empty tab is not something we should guide the user to.
That button remains visible until the list is cleared.

We should provide an easy access to Saved Files tab even when the topmost entries (most recent entries) have been removed.

This would mean having 2 completely separated and independent lists. One for recently downloaded, and one for all download files, like a persistent history.
If we do that, using 1 toolbarbutton for both lists is not a good idea.

I think we should try to keep things simple and not complicate them unnecessarily, with one "saved files" list the user can fully control. And if the user always wants that button visible, the only thing that they need to do is to not clearing the list.

Comment 15

[ISHIKAWA, Chiaki]

Attachment: image.png

(oops, I am sorry that I use Japanese locale, and so the [save] button near the lower-right corner shows 保存　instead of Save. )

|I would like to understand the proposal better.

This proposal is to add a button for download administration for all the downloads that have been done lately, and NOT for the single message's download per se. Correct?

I am asking because I have been a bit confused with the two paths for saving the attachment of a message.
See bug https://bugzilla.mozilla.org/show_bug.cgi?id=549719 (12 years ago...)
Also, it was mentioned in a post to bug 907732.
See bug 907732 Comment 9 there.
Two paths remember DIFFERENT directories for saving.

It would be great to merge the two functionalities into one, and for me, I always click on the attachment listing itself (in the lower-left corner) to save it. So the right button could be made to work like the download administrative button as proposed here. But I bet there must be people who use the save button in the lower-right corner of the message pane to save an attachment.

In a work done for this bugzilla, it would be great to see the merging or at least make the lower-corner right button to invoke the new admnistrative functionality because in my case, when I notice there is an attachment (at the lower-right corner.: I don't use full HTML mail modes often and thus inline graphics, etc. show up as attachments indicated in the lower-right corner), and thus my eyesight is near the bottom of the screen when that happens, it would be handy to be able to invoke the full download administrative feature by the existing button in the lower-right corner [the red circle in my attachment, too.]

NOTE: BTW, the default download directory rememberd by the direct interaction with the attachment name in the lower-left corner is PER MESSAGE FOLDER, and this has turned out to be VERY USEFUL. This has been like this for the last several years IIRC.
I hope this feature won't be dropped from the result of discussion.

Comment 16

[ISHIKAWA, Chiaki]

Attachment: Two circles that refer to the lower-left and lower-right positions for "save" operation.

I uploaded unmarked image. Here are circles that refer to the lower-right and lower-left key locations.

Comment 17

[Thomas D. (:thomas8)]

(In reply to Alessandro Castellani [:aleca] from comment #14)

Firefox think they can afford to hide the button because they have another one right next to it which still allows retrieving Downloads: View History, saved bookmarks, and more [incl. Downloads]. TB does not have that.

That toolbarbutton is always visible unless the user clears all downloads.

No. That toolbarbutton is visible until the user clears the most recent downloads, which are the only downloads shown directly from the button. The full list lives in the downloads tab and may have downloads history items even when the button is gone. Are you aware that download history can be cleared one by one?

If there's nothing in the list of saved files, the button has no need of being there as accessing an empty tab is not something we should guide the user to.

Please re-read my comment 13:

We should provide an easy access to Saved Files tab even when the topmost entries (most recent entries) have been removed. There's a thousand reasons to look into yesterday's Saved Files which are still on the list. Having the button always available imo reduces the cognitive burden of sometimes finding Saved Files via the button, but sometimes not, which requires a totally different click pattern then.

I am not talking about access to an empty tab, I am talking about access to the (All) Saved Files tab which can have dozens of entries even when the button does no longer have any entries as the user might have manually deleted the most recent entries or there are no recent entries.

This would mean having 2 completely separated and independent lists. One for recently downloaded, and one for all download files, like a persistent history. If we do that, using 1 toolbarbutton for both lists is not a good idea.

That's exactly how it works in Firefox - please look at their implementation. It's not two different lists. It's two different views on the same list.

• Button view: Most recent files only (just saved; I don't know the exact algorithm used in FF, but it's a subset of the full list based on recency).
  • Link: Button view has "Show all downloads" to go to the tab view and see all files.
• Tab view: All saved files

I think we should try to keep things simple and not complicate them unnecessarily, with one "saved files" list the user can fully control.

I am failing to see the complexity in the current Firefox UX, which has two different views on the same list, which is exactly the right thing to have. We should find out how FF handles "auto-hiding" of the recent downloads list on the button, which actually maintains the full downloads history in the All downloads tab unless deleted by user. Iow, for some time (or until closing FF or whatever), your most recent downloads are shown on the button, then later they are only available from the All downloads tab.

And if the user always wants that button visible, the only thing that they need to do is to not clearing the list.

So what's the easy way in TB to access yesterday's attachments if for some reason today's are gone?
Firefox has another pretty easy way of accessing Downloads tab, on the library button right next to the downloads progress/accessor button. Thunderbird does not have that. Implementing another button to access the TB Saved Files tab would be redundant if we can just keep the downloads progress/accessor button always available, which has a permanent menuitem to link to the Saved Files tab - hence providing a reliable access to both recent and earlier saved files.

Having the button always available imo reduces the cognitive burden of sometimes finding Saved Files via the button, but sometimes not, which requires a totally different click pattern then.

Comment 18

[Thomas D. (:thomas8)]

Personally, I would never hide the button - if I want to check if I still have a link to yesterday's attachment in there, I wouldn't mind even getting to an empty tab and knowing for sure. Ymmv - so if you prefer to hide the button, we could hide it when there is no history at all in the Saved Files tab. As long as there's history, the button will provide an easy access to that via the link menu item (even when there are no recent items) - see my mockup in comment 4 where this was discussed.

• Show button as long as there is any item in downloads history (Saved Files Tab, regardless if recent or not)
• Hide button when there's nothing in downloads history (Saved Files Tab).

Comment 19

[Thomas D. (:thomas8)]

(In reply to ISHIKAWA, Chiaki from comment #15)

Hi Chiaki, nice to hear from you and thanks for following up on things Thunderbird!

This proposal is to add a button for download administration for all the downloads that have been done lately, and NOT for the single message's download per se. Correct?

Correct, sort of. Same as in Firefox, I envision this button to show a most recently downloaded subset of your Saved Files list (which lives in a Tab [Ctrl+J], but nobody knows about that tab because it's not linked to the main UI).

I am asking because I have been a bit confused with the two paths for saving the attachment of a message.
See bug https://bugzilla.mozilla.org/show_bug.cgi?id=549719 (12 years ago...)
Also, it was mentioned in a post to bug 907732.
See bug 907732 Comment 9 there.
Two paths remember DIFFERENT directories for saving.

Totally agree that this must be looked into, but let's use your bug to fix that problem:
Bug 549719 - Unify/Merge two code paths for saving an attachment in a message (different save directory in "double click/save file" vs "context menu/save as")
Doing that might also be related to bug 539198 and bug 814000 (which needs some deep thoughts wrt UI/UX).

All of these bugs iiuc are pretty orthogonal/unrelated to what we're doing here.
Here we just want add the downloads progress/accessor button as a discoverable convenience shortcut to access most recently saved attachments in their containing folder, and the Saved Files tab with the full list (regardless how they were saved).

It would be great to merge the two functionalities into one, and for me, I always click on the attachment listing itself (in the lower-left corner) to save it. So the right button could be made to work like the download administrative button as proposed here. But I bet there must be people who use the save button in the lower-right corner of the message pane to save an attachment.

How you save your attachment should not matter for the shortcut button proposed here (see above).

In a work done for this bugzilla, it would be great to see the merging or at least make the lower-corner right button to invoke the new admnistrative functionality ... it would be handy to be able to invoke the full download administrative feature by the existing button in the lower-right corner [the red circle in my attachment, too.]

I'm not sure if I understand you correctly, but maybe you're proposing that the downloads progress/accessor button (per this bug) should be located on the attachment header bar? That is certainly worth considering as it might make a nice in-place addition. However (as I explained before), there's a fundamental disadvantage of placing the button on the attachment header bar: It will only be available for messages with attachments. So it'll become very inconvenient if you're looking for fast access to recent saved files whilst on a message without attachments. And it won't work well for future actions (save all attachments of all selected messages). See my comment 10.

NOTE: BTW, the default download directory rememberd by the direct interaction with the attachment name in the lower-left corner is PER MESSAGE FOLDER, and this has turned out to be VERY USEFUL. This has been like this for the last several years IIRC.
I hope this feature won't be dropped from the result of discussion.

No worries! We're not going to have that discussion here, that's bug 549719 and bug 539198 / bug 814000 territory.

Comment 24

[Thomas D. (:thomas8)]

This proposal also covers the problem underlying bug 297662 in a generic way.