Here's finetuninng the attachment adding experience. STR 1. Have an existing list of 5 attachments with default size of attachment list, so the list is full: A, B, C, D, E 2. Add more attachments F, G, H Actual result - very little visual feedback that/which attachments have been added: only attachment counter and size increases, but new attachments are not even visible, and have already blended into the list - no way for user to double-check what he just added Expected result - select all newly added attachments - ensure their visibility in the list (auto-scroll if required) - consistency with any other file handling application out there, where adding new things will keep them selected and ensure their visibility UX-consistency: Pasting files in Explorer and adding files to the attachment list are essentially the same type of action, so we should have a similar UX for better ux-userfeedback and ux-control/ux-error-prevention.

So when playing with this, I found that selecting just added attachments is too heavy and too sticky, as it's difficult to get rid of that selection in a right way, but we don't want to just keep selected items around. So here's a lighter way of providing better ux-feedback to the user after adding attachments: - Flash a short visual hint to point out the newly added attachments, similar to the way we're indicating newly arrived messages with a volatile star (but I didn't take it that far). - Ensure their visibility (top of new block scrolled up as far as possible). - Set focus on the first newly added attachment (allowing user to trace the top of the new block), which also fixes a focus bug. Similar UX is used in FF for downloads and loading pages, where there's a short visual flash to confirm that downloads or page loading has finished, and where they have gone. I believe this is an improvement over the current UX where we provide almost no feedback for adding attachments at all, so it's hard for the user to verify if succeeded to add the right files or not. Fully customizable: - adjust flash time to your liking in CSS - remove related CSS to disable the feature

Comment on attachment 8941032 [details] [diff] [review] Patch V.1: Flash visual hint and ensure visibility for just added attachments Caveat: So far CSS-wise, works in Windows only.

Best tested like this: With default size of attachment list: First, add 3 attachments. Then, add another 3 attachments with different names. Then, add 1 attachment. Try with and without focus on attachment pane.

Interesting proposal. Thanks for the improvements in the attachment bucket. The patch here looks empty. You can use ensureIndexIsVisible() on a listbox element to ensure the newly added attachment is in view.

Comment on attachment 8941032 [details] [diff] [review] Patch V.1: Flash visual hint and ensure visibility for just added attachments Empty patch.

(In reply to :aceman from comment #4) > Interesting proposal. Thanks for the improvements in the attachment bucket. > > The patch here looks empty. Oops. Indeed. It IS empty... Forgot to refresh in TortoiseHg. I'm working with two repositories, my flat install (daily.workbench) and comm-central, so I produce and test things on the former, then copy to the latter (using WinDiff). As I'm not building, there's no need for me to refresh the comm-central patch so often except when I want to publish or update existing patch... > You can use ensureIndexIsVisible() on a listbox element to ensure the newly > added attachment is in view. I used scrollToIndex() to ensure visibility of as many of the added items as possible. When they are less than fit in the list height, the last added item will be "stuck" at the bottom of the list (no further scrolling possible), so some existing items will still show on top (same effect as ensureIndexIsVisible()). But when they are more than fit, they'll fill the entire list height starting from top, which is intended to show as many newly added items as possible.

Comment on attachment 8941087 [details] [diff] [review] Patch V.1.0: Flash visual hint and ensure visibility for just added attachments This patch has also parts of bug 1428631 in it. Maybe you shouldn't do too much in parallel with every patch rotting the others. Maybe push that you can first land one before you continue with the other. I have sometime also multiple patches but wait until the older land before I upload the next. This is an interesting idea but when you add more files than the bucket height, the effect is too fast over and then it's not really clear for what this is because all visible attachments have this animation (also when you open a draft with already attached files, the have this animation too). Mavbe the new files should have a light gray background, or the old files have a little pale text color, until the user does something with the attachments. With this the user can scroll and see all new attachments. f+ for the idea

Comment on attachment 8941087 [details] [diff] [review] Patch V.1.0: Flash visual hint and ensure visibility for just added attachments I'm trying to clear my f? r? queue, so let me do an easy one first. Altogether the idea is good. Currently if you add an attachment to a full bucket there is zero feedback that it got added. So focusing onto it is great. I can't say I'm 100% crazy about the yellow animation, but an animation is better than a static colour of the last one added as Richard suggested. So instead of a yellow corner, make it a highlight of the row of some sort that fades away. I don't mind all attachments you drag to receive that feedback, like if you drag more than the bucket can show at once. As Richard said, let's settle some of the other bugs first.

Comment on attachment 8941087 [details] [diff] [review] Patch V.1.0: Flash visual hint and ensure visibility for just added attachments Review of attachment 8941087 [details] [diff] [review]: ----------------------------------------------------------------- Thanks, I like the idea, but the implementation could be improved. ::: mail/components/compose/content/MsgComposeCommands.js @@ +4534,5 @@ > + getPropertyValue('--attachmentsJustAddedTimeout'); > + if (isNaN(parseFloat(millisecs))) > + millisecs = 500; > + > + gAttachmentsJustAddedTimer = setTimeout(attachmentsRemoveJustAddedAttribute, millisecs); Do we really need a timer for this? Can't the animation be solved via some css attributes? There are some that can do an async animation. Paenglab could know. I see you want to remove the attribute from the new items after the timeout, but even the attribute may not be necessary in the first place. @@ +4547,5 @@ > return items; > } > > +function attachmentsRemoveJustAddedAttribute() { > + markedElements = [...GetMsgAttachmentElement().querySelectorAll("[justadded='true']")]; Missing "let". @@ +4550,5 @@ > +function attachmentsRemoveJustAddedAttribute() { > + markedElements = [...GetMsgAttachmentElement().querySelectorAll("[justadded='true']")]; > + markedElements.forEach( el => el.removeAttribute("justadded")); > + > +} Surplus space and empty line. ::: mail/themes/windows/mail/attachmentList.css @@ +29,5 @@ > } > > +attachmentitem[justadded="true"] { > + background: linear-gradient(to right, rgba(241,218,54,1) 0%,rgba(254,252,234,1) 43%); > + border-left: 1px solid rgba(241,218,54,1); When this border is removed after the timeout, the attachment names are re-re-rendered with the new size available and the characters displayed change. The animation shouldn't change the spacing of the labels. @@ +30,5 @@ > > +attachmentitem[justadded="true"] { > + background: linear-gradient(to right, rgba(241,218,54,1) 0%,rgba(254,252,234,1) 43%); > + border-left: 1px solid rgba(241,218,54,1); > + --attachmentsJustAddedTimeout: 500; 0.5s seems too short for me, I can barely see the effect (when I applied this style to the linux theme).