In recipient pill context menu, replace "Copy" by "Copy Email Address" and "Copy Name and Email Address"
Categories
(Thunderbird :: Message Compose Window, enhancement)
Tracking
(Not tracked)
People
(Reporter: richard.leger, Unassigned)
References
(Blocks 1 open bug)
Details
+++ This bug was initially created as a clone of Bug #1601748 +++
Bug 440377 introduced the new mail-address-pill Custom Element, which drastically changes User Interface of the entire recipients header area.
Let's use this bug to track the improvements and changes necessary to refine and polish this new implementation.
Todo:
- In pill context menu replace "Copy" (one entry) by "Copy Email Address" and "Copy Name and Email Address" (two separate entries)
Such features are already available in other part of TB related to recipients... when reading/previewing emails so why not in pill context menu as well for consistency?
|
Reporter | |
Comment 1•5 years ago
|
||
"Compose To" come to mind as well... could be added as well perhaps...
|
||
Comment 2•5 years ago
|
||
How come you're adding all these flags of blocking and dependent bugs?
Blocks means that this bug must land before in order to allow the other bugs to land, which is not the case.
All these bugs you're creating are standalone and independent from each other.
They all depends from bug 1601748, but nothing more.
There's not even need to add bug 440377.
|
||
Comment 3•5 years ago
|
||
I'm not sure this would be all that useful in the compose mode - what you have there is data you just entered. We shouldn't confuse "real" data with essentially nicely formatted data the just entered.
Copy is also acting on the pill itself, which contains name+address. But if someone wants to copy the pill having two entries like suggested would be a bit confusing and I think more of needless choice we'd be forcing the user to do than anything else.
|
|
Reporter | |
Comment 4•5 years ago
•
|
||
(In reply to Alessandro Castellani (:aleca) from comment #2)
How come you're adding all these flags of blocking and dependent bugs?
Blocks means that this bug must land before in order to allow the other bugs to land, which is not the case.
All these bugs you're creating are standalone and independent from each other.
They all depends from bug 1601748, but nothing more.
There's not even need to add bug 440377.
Apology, it was not my intention just wanted to create a follow-up bug linked to the first one... but to be dealt with later... maybe I don't have the right method... I don't know how else to do it...
|
|
Reporter | |
Comment 5•5 years ago
•
|
||
(In reply to Magnus Melin [:mkmelin] from comment #3)
I'm not sure this would be all that useful in the compose mode - what you have there is data you just entered.
Because of auto-completion and adressbook, most pills are created after typing only few characters (in my case max 3) so most of the time the entire data is never typed at all (mostly only first time for new recipient)... very neat "magic". Data remain not directly accessibly...
The current pill "Copy" is already equivalent to "Copy Name and Email Address" so when you paste that is what you get in a text format (not a pill) that is then converted into a pill after pressing Enter. If it was to Copy the pill then when pasting in a recipient field I would get a pill not data text formated (though this is useful).
But there is no possibility to just Copy Email Address (often used) if it need to be referred to in email body or elsewhete... while composing a message (e.g not sent yet)...
Pasting just the email address in field area would still be formatted as text and convertable into a valid pill. So not breaking any existing feature.
We shouldn't confuse "real" data with essentially nicely formatted data the just entered.
To avoid confusion and make it clearer you could order function as follow in context menu:
Edit
Delete
---
Move to Cc
Move to Bcc
Move to Reply-To
---
Copy Name and Email Address
Copy Email Address
---
Cut
Also this may be more relevant because of pill (which prevent in a way direct access to data) and once the "Move to" functions are implemented to easily move pills between fields... as Copy and Cut function where implemented to enact the Move feature "manually" while it is implemented.
I don't think a pill would ever be copied in another recipient field (or rarely though still possible) it means if copied the intention is to copy the data for pasting elsewhere...
As feature already exist on Recipients elsewhere it would create consistency in expected behaviour of Thunderbird.
This is a feature request (enhancement, nice to have), not a blocking bug (apology again) based on daily usage of pills system as currently implemented in beta... identifying area for possible improvement...
If you consider this not useful I can simply stop suggesting improvements. Just let me know.
In fine, again, the final choice is yours.
|
||
Comment 6•5 years ago
•
|
||
Richard, please let your bug summaries start with something unique, there's no need to include "Improve the UI of the mail-address-pill custom element - " for all of these bugs, which makes it very hard to tell them apart, and it doesn't carry much informational value.
|
|
||
Comment 7•5 years ago
•
|
||
(In reply to Richard Leger from comment #0)
+++ This bug was initially created as a clone of Bug #1601748 +++
Bug 440377 introduced the new mail-address-pill Custom Element, which drastically changes User Interface of the entire recipients header area.
Let's use this bug to track the improvements and changes necessary to refine and polish this new implementation.
Todo:
Similarly, it's not much helpful to always copy over the above sentences for all of your bugs, because your bugs are not tracking bugs in the sense of meta bugs where activity is coordinated, and it's a bit odd to present your requests for feature enhancements as Todo's as if that's already determined. Pls just start each bug with your proposal. Dependency on bug 440377 and the mention of recipient pills / new recipient area somewhere will suffice for us to make the link. Thank you.
|
|
||
Comment 8•5 years ago
|
||
(In reply to Richard Leger from comment #5)
Edit Delete --- Move to Cc Move to Bcc Move to Reply-To --- Copy Name and Email Address Copy Email Address --- Cut
Wrt correct formatting of your comments, there's a link "Markdown styling now supported" under the comment input with information how to apply correct formatting. Kindly use "Preview" tab above comment input to preview the formatting of your comment.
You can use backticks to avoid unfortunate auto-formatting of your text, like this:
menu
---------------------
some other menu
You can even use the small edit button (pen) in the upper right corner of comments to fix the formatting of existing comments.
Just trying to help so that odd presentation doesn't get in the way of your ideas. Thanks.
|
|
||
Comment 9•5 years ago
|
||
(In reply to Alessandro Castellani (:aleca) from comment #2)
How come you're adding all these flags of blocking and dependent bugs?
Blocks means that this bug must land before in order to allow the other bugs to land, which is not the case.
All these bugs you're creating are standalone and independent from each other.
They all depends from bug 1601748, but nothing more.
There's not even need to add bug 440377.
Alessandro, this happens automatically when using BMO's feature of "cloning" an existing bug, and it gets worse when cloning the clone without fixing depencies first.
- It's easy to overlook that the whole set of dependencies gets copied over to the clone.
- It's not easy to remember fixing the depencies whilst you'll be focused on filing your issue.
- Worse, it's damn hard to fix them even if you do remember because at the time of entering a new bug, they'll just be bug numbers without any hint of their summaries. So it's non-trivial and very time-consuming to sort out dependencies when filing the clone, more so for the average BMO user.
(In reply to Thomas D. from comment #7)
(In reply to Richard Leger from comment #0)
Dependency on bug 440377 and the mention of recipient pills / new recipient area somewhere will suffice for us to make the link. Thank you.
In fact, along Alessandro's comment, your RFE's should probably block only bug 1601745, the tracker for UX improvements of the new pill-style recipient area. Richard Leger, you can edit the dependencies in the "Depends on" or "Blocks" fields when filing (or at any time as required).
|
|
||
Comment 10•5 years ago
|
||
(In reply to Magnus Melin [:mkmelin] from comment #3)
I'm not sure this would be all that useful in the compose mode - what you have there is data you just entered. We shouldn't confuse "real" data with essentially nicely formatted data the just entered.
Copy is also acting on the pill itself, which contains name+address. But if someone wants to copy the pill having two entries like suggested would be a bit confusing and I think more of needless choice we'd be forcing the user to do than anything else.
+1. An unfinished composition is neither likely nor ideal as a data pool for copying plain email addresses. It's much more likely that you'd just want to copy the entire pill (display name & address) as it is. So forcing the user into choices for this simple action would indeed make the more likely/frequent user action unnecessarily complex. You can always remove the display name after pasting if you really need the email address only. Or you can edit the pill text and just copy the address only.
I recommend wontfix for this bug, but I'll let Alex make the call.
|
|
||
Updated•5 years ago
|
|
|
Reporter | |
Comment 11•5 years ago
•
|
||
Then what is the point of keeping "Copy Email Address" and "Copy Name and Email Address" for recipient in preview pane and not just "Copy" to keep consitancy in the UX...?!
In email preview or reading pane you could simple have the ability to access the pill data read-only the same way you do in compose email... and keep similar context menu entries... where applicable...
|
|
||
Comment 12•5 years ago
•
|
||
(In reply to Richard Leger from comment #11)
Then what is the point of keeping "Copy Email Address" and "Copy Name and Email Address" for recipient in preview pane and not just "Copy" to keep consitancy in the UX...?!
Different scenario, different context, slightly different design. Received message headers are more robust data, and data coming from others, so it's arguably more likely to extract email address information from there. Here in composition, we want to streamline the process of composing, for which extracting an email address without the display name appears less likely and less useful (as you can define the display name yourself, or it has already been defined/accepted/used by yourself if picked from autocomlete), plus before sending, that data may not be in its final, correct state.
In email preview or reading pane you could simple have the ability to access the pill data read-only the same way you do in compose email... and keep similar context menu entries... where applicable...
I'm all for ux-consistency, but I think we have offered several reasons why we wouldn't want that here.
It's a balancing act because what is useful for your scenario can be distracting clutter for other scenarios, and for the main process of composing - as Magnus said, it looks wrong to force users into deciding what exactly they want to copy here, as in most cases, it'll probably just be the entire recipient pill including display name (at least, you can always extract the email address from that).
ux-efficiency/ux-consistency vs. ux-minimalism/avoiding ux-interruption.
You could just press Ctrl+S to save your msg as a draft (with or without closing), then go to drafts folder which will show the same message in message reader mode, so you could use the two distinct context menus from there if it's a regular use case for you.
Btw, so far you haven't even described your particular use case in the context of composition.
Btw (fwiw), having two "copy..." context menus for contacts in message reader was indeed also debated. As always in UX design, there's pros and cons. I had originally proposed to have "Copy | v" to keep the default action simple, with a dropdown menu for copying other flavors like email-only. We eventually ended up with two menus.
Description
•