1100103 - Add a remove button to every To/CC/BCC address in Composer

Status: RESOLVED FIXED

(Thunderbird :: Message Compose Window, enhancement)

Description

[Marco A.G.Pinto [:marcoagpinto]]

Attachment: moodle_thunderbird_20141115.png

Pressed the button to create a new message

The To/Cc/Bcc selected recipients appear in lines

This is just an idea to improve it:
They should appear in editor gadgets just like in Outlook, but with some improvements like in the screenshot of Moodle 2.5 of the university I work for.

Notice the "Professor" with the red "x". I think this is made in JavaScript since the "professor" is text when you try to select with the mouse.

Comment 1

[Marco A.G.Pinto [:marcoagpinto]]

[14:26] <clokep> I don't understand what that screenshot is trying to show. :-\
[14:27] <marcoagpinto> clokep: the names of the recipients: "Marco Pinto x" "Aceman x"
[14:27] <marcoagpinto> each name should appear like that in the editor gadget
[14:27] <marcoagpinto> then people should be able to delete them by clicking in the "x"

Comment 2

[Wayne Mery (:wsmwk)]

Address Close Button addon will get you the X

Comment 3

[Marco A.G.Pinto [:marcoagpinto]]

[14:28] <clokep> marcoagpinto: So you're just suggesting a small x appear so they can be deleted?
[14:28] <marcoagpinto> yes
[14:28] <marcoagpinto> :)
[14:28] <clokep> Have you seen JosiahOne's plans to totally redo the To/CC/BCC lines of the editor?
[14:28] <marcoagpinto> and a box for each
[14:29] <marcoagpinto> a box for To, other for Cc and other for Bcc

I also wanted to mention a box just like Outlook uses, with multiple recipients inside each.

Comment 4

[Suyash Agarwal (:sshagarwal)]

Attachment: proposed copy

Shouldn't we have something like this? :)

Comment 5

[Josiah Bruner [:jsbruner]]

Suyash, yes. That's very similar to my proposal, except the X will actually be a drop down icon to list options for the address. Regardless, this bug is kind of obsolete because of that bug.

Comment 6

[Marco A.G.Pinto [:marcoagpinto]]

sshagarwal: That is what I meant :p

Thanks for the screenshot which is better than my silly text.

Comment 7

[Suyash Agarwal (:sshagarwal)]

(In reply to Marco A.G.Pinto from comment #6)
> sshagarwal: That is what I meant :p
> 
> Thanks for the screenshot which is better than my silly text.
Nevermind :)

(In reply to Josiah Bruner [:JosiahOne] (needinfo > CC) from comment #5)
> Suyash, yes. That's very similar to my proposal, except the X will actually
> be a drop down icon to list options for the address. Regardless, this bug is
> kind of obsolete because of that bug.

Cool! So, can you please mention that bug so that the reporter can be convinced
and we can mark this bug as a dupe(?) or anything else that shows this is being
solved by that?

Thanks.

Comment 9

[Thomas D. (:thomas8)]

From a bug management perspective, this bug is not a duplicate of bug 440377:

1) This bug is also filed and valid against the current multiline layout; we never know when bug 440377 will actually land and it might very well be possible and faster to land an easy fix for this in the current layout (make an X appear on hovering address lines, or add an X to every address line).

2) Bug 440377 may or may not implement this exact functionality as requested here, and Josiah's tentative comment 5 suggests it might be done in a different way which does not provide the efficiency suggested here. So if bug 440377 actually implements this in a satisfying way, we can still close this, but until then, it's a bug in it's own right.

And of course, it's a long known issue already reported...

Comment 10

[Marco A.G.Pinto [:marcoagpinto]]

Could someone implement this add-on?

It is just 3 kB long.

https://addons.mozilla.org/en-US/thunderbird/addon/address-close-button/?src=search

Comment 11

[:aceman]

Is the addon not working in TB52+ ?

Looking at the addon, the feature is basically 3 lines of XUL plus some css to style the icon and the icon itself.
This could be easily implemented in base TB if accepted by UX.
There are some things to note though:
1. adding an icon to every recipient could be heavy (perf/memory). I'll test it on a message with thousands of recipients (which some users asked for). Maybe we could use some lighter X character.
2. clicking the icon does not only clear the recipient address, it removes the whole recipient row, also with the type picker (To/CC/BCC). So maybe the icon could be placed elsewhere, e.g. before the whole row, or the end of it.

Note that Outlook does not have it, because there the recipients aren't plain text, but objects that can be moved or deleted as a whole. In TB you have to delete the recipient as text and also the whole row.
So I can understand the benefit of this feature.

Comment 12

[Richard Marti (:Paenglab)]

Yes, this looks simple to implement. But maybe instead of the close icon we could use the delete icon. And it should also be accessible by key. I think we should add a button at the end of the row. Inside the textbox could give problems with different text sizes.

But then this should be implemented in bug 143147 and not in this duped one.

Comment 13

[:aceman]

The duping to bug 440377 is to be cut unless anybody wants to implement that one sooner.
Otherwise we can do this one fast.

Yes, bug 143147 is the same. We could keep one for SM and one for TB.

Marco, please email the author of the addon if he wants to implement the feature in core TB, with the changes from comment 12.
If he doesn't we can do it.

Comment 14

[Marco A.G.Pinto [:marcoagpinto]]

Well, I found the guy's e-mail address in the rdf, but it seems to not exist any more.

:-(

So, there is no way to reach him.

Comment 15

[Jorg K (CEST = GMT+2)]

(In reply to :aceman from comment #11)
> Is the addon not working in TB52+ ?
Works in Daily TB 60.

(In reply to Richard Marti (:Paenglab) from comment #12)
> I think we should add a button at the end of the row.
Yes.

Comment 16

[Wayne Mery (:wsmwk)]

It sounds lame to move the button action away from the name.  Not great for eye-hand coordination

Comment 17

[Richard Marti (:Paenglab)]

(In reply to Wayne Mery (:wsmwk) from comment #16)
> It sounds lame to move the button action away from the name.  Not great for
> eye-hand coordination

If we would have multiple addresses per row, yes. But with one address per row it's also more clear that the whole row will be removed.

Comment 18

[Thomas D. (:thomas8)]

(In reply to Wayne Mery (:wsmwk) from comment #16)
> It sounds lame to move the button action away from the name.  Not great for
> eye-hand coordination

+1, 100%.

(In reply to Richard Marti (:Paenglab) from comment #17)
> If we would have multiple addresses per row, yes. But with one address per
> row it's also more clear that the whole row will be removed.

I don't think there'll be much surprise about row removal given that we currently have a row-based recipient design. Removing a recipient is removing the row. But on wide screens, the ❌ can end up miles away from the name, which is really counter-intuitive as Wayne says.

Comment 19

[Thomas D. (:thomas8)]

Here's my ideas for the UX/design of this:

1.) X-button right after the recipient's name (ux-in-place, ux-efficiency, ux-consistency):
John Doe ❌

Far-end violates ux-in-place, ux-efficiency, and it's just odd, actually ux-implementation-level, making our non-standard tabular implementation stand out even more, and further reducing external ux-consistency with other agents where each recipient is a block which can be deleted in-place.

That said, the only reason for having ❌ at the end of the row would be higher efficiency for multiple deletions, but I think we need to come up with something smarter for that, maybe checkboxes and a floating action menu.

2.) Show X-button only on hover of the recipient row(sic!), not always (ux-minimalism):
John Doe        (normal state)
John Doe ❌      (row hovered state)

Nobody needs or wants dozens of ❌ permanently on the screen, and imo deleting recipients isn't a frequent enough action to justify that visual clutter. Maybe if they are *very* light and only get color on hover, but still. Also, there's near-zero difference in efficiency because you'll have to move onto that recipient anyway, so as you're moving, you'll see your ❌ target just when you need it.

3.) Use only plain unicode ❌ character for better performance, this must scale efficiently even for 1000 recipients, so no graphics please (ux-minimalism, performance). I think plain and simple ❌ is just fine, imo no other button effects, backgrounds etc. required. Maybe a css hover effect on the ❌.
http://www.fileformat.info/info/unicode/char/274c/browsertest.htm

Comment 20

[:aceman]

Yeah, far end may be too far to travel by hand.
Maybe before the recipient input field or even before the To/CC picker.
The button could show on mouse hover or when the particular recipient textbox has focus. Something like IE11 has in the URL bar history (X appears to remove hovered entry you typed into the URL field).

Comment 21

[Richard Marti (:Paenglab)]

Attachment: deleteAddress.patch

aceman, can you try this with many addressees to see if this slows down too much?

I'm using our delete SVG icon instead the close icon. With this it's more clear for what it is.

Comment 22

[Jorg K (CEST = GMT+2)]

Comment on attachment 8953223 [details] [diff] [review]
deleteAddress.patch

Sorry, but that's really ugly :-(
There should be a little X following the address, not a trash can preceding it. Also, when you hover the field to enter the address, before it's even entered completely, you see the trash can. We want to delete entered addresses, not see the trash can while entering them. So nothing should show on hovered empty fields or while the auto-complete is still in progress. I guess this needs a whole lot more JS code to do.

Comment 23

[Marco A.G.Pinto [:marcoagpinto]]

Hello!

What about sshagarwal attachment above from years ago?

The icon could look like that and the "x" become red while hoovered.

Comment 24

[Marco A.G.Pinto [:marcoagpinto]]

Hello!

What about sshagarwal attachment above from years ago?

The icon could look like that and the "x" become red while hoovered.

Guys, take a look at my Moodle screenshot example above, it should look something like this.

Comment 25

[:aceman]

(In reply to Richard Marti (:Paenglab) from comment #21)
> Created attachment 8953223 [details] [diff] [review]
> deleteAddress.patch
> 
> aceman, can you try this with many addressees to see if this slows down too
> much?

Interestingly, this didn't add any time to open a message with thousands of recipients.
Maybe the trick with the icon having width of 0 makes it not load/render in any way so it takes no time.
Only when an address is hovered the icon appears.

It would be better if the address wasn't moved when the icon appears.
I also got into cases where 2 rows had the icon, but those are hard to reproduce. Some may be caused by generally very slow display of recipients when there are many.

Comment 26

[Marco A.G.Pinto [:marcoagpinto]]

Can't someone give review+ to the current icon?

Then, later, if a better one appears it can be replaced?

The important is to have the feature on.

Thank you!

Comment 27

[:aceman]

Comment on attachment 8953223 [details] [diff] [review]
deleteAddress.patch

Review of attachment 8953223 [details] [diff] [review]:
-----------------------------------------------------------------

Me and Jorg have provided some comments on what should be improved here. The recipient should not jump around, and the icon should be more subtle.

::: mail/components/compose/content/messengercompose.xul
@@ +1095,5 @@
>                    </menupopup>
>                  </menulist>
>                </listcell>
>                <listcell class="addressingWidgetCell">
> +                <image id="deleteAddress"

This element will be replicated for each recipient row, so it can't have an ID, only a class.

Comment 28

[Jorg K (CEST = GMT+2)]

I've played around with the patch, but I haven't been able to achieve anything desirable.

Basically you have this:
              <listcell class="addressingWidgetCell">
                <textbox id="addressCol2#1" class="plain textbox-addressingWidget uri-element"
                         aria-labelledby="addressCol1#1"
                         type="autocomplete" flex="1"
                         ...
                </textbox>
              </listcell>
and you can place you image into the listcell, either before the textbox or after the text box.

Before the text box it's very prominent. And transition ("jumping") proposed in the patch doesn't make it better. Also, it's always there, even when no address has been entered or when the address is being entered.

What we'd like to have, a small [x]-style icon *in* the text box isn't possible. What is suggested in comment #19 is nice and I agree, but I don't see how that would be doable technically. It might be possible to place the ❌ after the address text with some CSS trick, but it would still be part of the text in the textbox and hence no delete action could be tied to it when essentially clicking onto the address itself text. I'd be very happy to be proven wrong on this one.

So I think the best way out here is to place a non-moving icon after the text box. That had its opposition, but we need to consider the case when the ❌-button would be used. That's mainly when replying to all and we get many undesired recipients we need to remove. Well, in this case, move the mouse to the right and click all the ❌'s. Yes, you need to follow the row to the left, not great for eye-hand coordination.

Someone with a better idea that can be implemented, please step forward.

Or how about this:

To: ___ Thomas ...

The ___ is essentially grey like the background of the "To:". When you hover that area, a small [x] appears that you can click.

Comment 29

[Jorg K (CEST = GMT+2)]

Attachment: 1100103-mockup.png

This should be doable. If the area is not hovered, so during address entry, the [x] doesn't show. It only shows when hovered.

Comment 30

[Jorg K (CEST = GMT+2)]

Attachment: deleteAddress.patch (JK)

Something like this. The icon needs to be a little [x] and it needs to be smaller.

Comment 31

[Jorg K (CEST = GMT+2)]

Attachment: This is the idea

Comment 32

[Richard Marti (:Paenglab)]

(In reply to Jorg K (GMT+1) from comment #31)
> Created attachment 8959848 [details]
> This is the idea

This is for me ugly. The addresses aren't aligned with the sender and subject fields. That's why I made the button hiding when the focus isn't in the boxes.

Comment 33

[Jorg K (CEST = GMT+2)]

Yes, it destroys the alignment. Can you do it a little more like the add-on does, it seems that the image sits in the cell. But I'd only show the image when hovered.

Comment 34

[Richard Marti (:Paenglab)]

And this is the problem. On Linux this makes the textbox grow.

Comment 35

[Thomas D. (:thomas8)]

(In reply to Jorg K (GMT+1) from comment #28)
> What we'd like to have, a small [x]-style icon *in* the text box isn't
> possible. What is suggested in comment #19 is nice and I agree, but I don't
> see how that would be doable technically.

Certainly non-trivial, but certainly doable if we're determined.
I don't have time to look into this in more detail, but I'd envision something like this:

The listcell or even some other parent element higher up the tree gets an onhover listener.
Listener function:
event.explicitOriginalTarget (or something like that) to get the textbox element.
Get the text node inside the text box, and the absolute coordinates of the text node's box.
Use js to insert the x button element after the text box element (.insertAfter), and then js again to reposition the x after the text, using the absolute coordinates of the text end.
x button element upon creation gets a target function call including reference to the current recipient element which must be deleted when clicked.

Comment 36

[Thomas D. (:thomas8)]

(In reply to Thomas D. from comment #35)

> Get the text node inside the text box, and the absolute coordinates of the
> text node's box.
> Use js to insert the x button element after the text box element
> (.insertAfter), and then js again to reposition the x after the text, using
> the absolute coordinates of the text end.

Or if we succeed to get the text node inside the text box node, maybe we can just insert our x node after the text node (inside the text box), and maybe have something like a span tag around it which holds the function call.

> x button element upon creation gets a target function call including
> reference to the current recipient element which must be deleted when
> clicked.

Comment 37

[Jorg K (CEST = GMT+2)]

Highly non-trivial. You're actually suggesting to dig around with the internals of the XUL element. Then we might as well not do it and wait for bug 440377 as Wayne suggested recently on IRC. There we'll have to redo the entire widget anyway and might include the [x] as suggested by attachment 8523518 [details].

Comment 38

[Jorg K (CEST = GMT+2)]

Attachment: Aceman's idea - put it at the front

Same patch almost, just like this:
              <listcell class="addressingWidgetCell" align="stretch">
                <image id="deleteAddress"
                       onclick="awDeleteHit(this);"/>
                <menulist id="addressCol1#1" disableonsend="true"
                          class="aw-menulist" flex="1"
                          oncommand="onAddressColCommand(this.id);">

Any good?

Comment 39

[Richard Marti (:Paenglab)]

Attachment: deleteAddress.patch

This time with the icon as the first of the line. I'm using the X because everybody wants to close the address and not delete it. I acquiesce me to the majority (I'm Swiss ;) ).

This still shows the icon when hovering the line also when the field is empty.

Comment 40

[Jorg K (CEST = GMT+2)]

Comment on attachment 8959952 [details] [diff] [review]
deleteAddress.patch

This is very nice. But please only make the [x] show up when you hover the the To/Cc/Bcc, not when hovering the address. When I'm capturing the address, I don't need the [x] to show.

If we can have this soon, I'm happy to ship this in the beta we're currently building.

Comment 41

[Richard Marti (:Paenglab)]

Attachment: deleteAddress.patch

Like this? I made the animation also a bit faster.

Comment 42

[Jorg K (CEST = GMT+2)]

Comment on attachment 8959954 [details] [diff] [review]
deleteAddress.patch

Yes, like hits, thanks. Should we get Aceman's feedback?

Comment 43

[Jorg K (CEST = GMT+2)]

Oops, "like this!"

Comment 44

[:aceman]

Much nicer, thanks. But the icon now shortens the recipient type picker and when you open the popup, icon still stays and the labels in the popup are truncated now.

Comment 45

[Richard Marti (:Paenglab)]

Attachment: deleteAddress.patch with full width menulist when open

(In reply to :aceman from comment #44)
> Much nicer, thanks. But the icon now shortens the recipient type picker and
> when you open the popup, icon still stays and the labels in the popup are
> truncated now.

How about this? It's a bit a hack, but shows the whole menulist when open. The X isn't shown when the menulist closes, but is it then needed?

Comment 46

[Jorg K (CEST = GMT+2)]

Comment on attachment 8959980 [details] [diff] [review]
deleteAddress.patch with full width menulist when open

Tricky, but nice. For my taste, the popup wasn't too narrow, I could still see To: Cc: and Bcc:. Some items are truncated even now.

Comment 47

[:aceman]

Yes, some items are truncated even without this patch. That looks kinda ugly. The default strings should be fully visible.
I hope localizations can expand the picker in some way.

Comment 48

[Richard Marti (:Paenglab)]

Here they are all fully visible on my Linux. Do we need to make https://dxr.mozilla.org/comm-central/source/mail/locales/en-US/chrome/messenger/messengercompose/messengercompose.dtd#261 wider?

Comment 49

[:aceman]

Comment on attachment 8959980 [details] [diff] [review]
deleteAddress.patch with full width menulist when open

Review of attachment 8959980 [details] [diff] [review]:
-----------------------------------------------------------------

Yes, I like this too. But please expand the size of the dropdown to about 17ch which makes them fully shown (for en-US on my Linux).

I have tested this on a message with 4000 recipients.
Everything is slow in such a compose window.
The delete icon takes a 1-2 SECONDS to fully show/expand, but that is still the much faster way to remove recipients in such a composition. Deleting them manually by backspace is much slower as processing each keystroke takes a second.

I tried to remove the animation, but it does not help. Just any change in the UI (e.g. the icon appearing immediately) is slow with so many recipients.
So I think this is OK.

Comment 50

[Richard Marti (:Paenglab)]

Thanks. I think we should change the width in a new bug.

Comment 51

[Richard Marti (:Paenglab)]

Comment on attachment 8959980 [details] [diff] [review]
deleteAddress.patch with full width menulist when open

A good candidate for beta.

Don't tell Marco this will land in TB 60. ;)

Comment 52

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/8a24899e36cd
Add a delete button in front of the recipient row in the composer. r=aceman,jorgk

Comment 53

[Jorg K (CEST = GMT+2)]

Beta (TB 60):
https://hg.mozilla.org/releases/comm-beta/rev/01c6b254c2037c36de2fe15a1cc4bc335f34713e

Comment 54

[Jorg K (CEST = GMT+2)]

No, landed on TB 61 and got uplifted. Target Milestone: Thunderbird 61.0.