1616155 - Trim "From" input field to relocate "Cc Bcc >>" extra recipient labels more to the left

Status: RESOLVED FIXED

(Thunderbird :: Message Compose Window, enhancement, P3)

Description

[Richard Leger]

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

• Iterate on the design for the Cc, Bcc, Reply-to labels to find a better location...
• Reduce left space in front of field labels to make the x icon closer to the field label...

Such UI refinement also discussed in:
https://thunderbird.topicbox.com/groups/ux/T320a92088a949458/work-started-on-redesign-recipients-address-fields-to-cc-bcc-etc

Comment 1

[Richard Leger]

Attachment: CcBccReplyToReLocationRLMockup.jpg

Alessandro, Thomas,

Following feedback, discussion and proposals on https://thunderbird.topicbox.com/groups/ux/T320a92088a949458/work-started-on-redesign-recipients-address-fields-to-cc-bcc-etc and your suggestion to submit mock-up... find one attached... for your possible review...

It was mentioned that similar solution was tested out but I don't think any advanced users using beta channel have seen such solution implemented as possible alternative to current Cc Bcc >> location in the UX... in order to provide feedback...

The basic idea being moving back Cc Bcc >> to where they logically belong context/workflow wise, under the To: field while converting such text links into pill-shaped-buttons so they are vertically narrow enough not to clutter too much vertically but providing an intuitive access to feature and slight visual separation between recipients fields and Subject field... which is welcomed from a visual focus point of view...

Hope that may make sense... and you would reconsider this small matter as part of UX refinement still on-going...

The rest of the work is great so far :-)
Looking forward to new available features coming up...

Regards,

Comment 2

[Richard Leger]

Also...

• From field shall adjust to its content so the drop down icon would be just after the text... no need to have the field expand all the way wide...
• Subject label/field moved to the left to reduce left space area, all other field aligned-right with Subject as currently (just less space between label and x icon to delete)

Hope that make sense...

Those are just suggestions that I hope you may (re)consider... but I think they may make the interface more sleek... on a laptop/desktop computer screen especially...

Comment 3

[Wayne Mery (:wsmwk)]

Anyone tried adding such choices to the mail toolbar? That would avoid taking vertical space.

Comment 4

[Thomas D. (:thomas8)]

(In reply to Wayne Mery (:wsmwk) from comment #3)

Anyone tried adding such choices to the mail toolbar? That would avoid taking vertical space.

We have "Composition Toolbar" and "Formatting Bar", which one is "mail toolbar" for you?
Are you suggesting that the [CC], [BCC] etc. disclosure buttons should be on one of those toolbars?
I don't think the toolbars would be a good location, because that would remove them from the "recipient area" to which they belong, and dislocate them between other quite different actions.

Comment 5

[Wayne Mery (:wsmwk)]

I'm suggesting make it available for placement in "Composition Toolbar" in addition to wherever else it is in the UI. Sure it's above the recipient area, but you can place it next to Send a mere 1/2 to 3/4 inch above To: which is certainly a fair choice against having it 9 inches to the right.

Comment 6

[Richard Leger]

Attachment: CcBccReplyToReLocationRLMockup2.compromise.jpg

Here is another idea/iteration for consideration, a bit of a compromise between what currently is and my previous mock-up (which was looking very similar to what Roundcube does as I discovered by the way)...

The idea is based on:

• the Cc, Bcc,Reply-To links still becoming buttons pill formatted like (to make it evident it is recipient related and more visually prominent and discoverable)
• the width of From field reduced and adjusted to its content, so the links/buttons remain next to From field but are moved much closer to the left area, so less far from focus... and will always be close to the left in any screen size... so much easier to find/access
• all fields moved to the left to reduce white space left side, though this can be adjusted as you see fit best...

I would tend to think that the Cc Bcc Reply-to links/buttons shall remain in the recipient area to keep them into context/workflow...

Comment 7

[Richard Leger]

Attachment: CcBccReplyToReLocationRLMockup3.movedFarLeft.jpg

Here is yet another alternative mock-up idea where the Cc, Bcc, Reply-To links/buttons are placed far left instead... which again make them closer to access and focus on... than the far right area of the screen...

Comment 8

[Magnus Melin [:mkmelin]]

I think those suggestions make for a rather cluttered UI. It's also disregarding that there are more than To/Cc/Reply-To fields. The newsgroup fields also need to be there, but are not relevant to most users so having them visually in the UI is not nice. There are also more advanced fields we could add there in the future, and then it doesn't scale for mail either to always have these fields showing. I'd suggest to wontfix this bug.

Comment 9

[Magnus Melin [:mkmelin]]

(In reply to Wayne Mery (:wsmwk) from comment #5)

I'm suggesting make it available for placement in "Composition Toolbar" in addition to wherever else it is in the UI.

It's not always showing, it's not a customizable toolbar, and it's not the area for addressing, so that would not be a good place to have them.

Comment 10

[Richard Leger]

(In reply to Magnus Melin [:mkmelin] from comment #8)

I think those suggestions make for a rather cluttered UI. It's also disregarding that there are more than To/Cc/Reply-To fields.

Any of ideas suggested does not prevent to keep the use of >> for additional options I just used what is currently available in UI to make my suggestions and mockup ideas more real...

Your can always do [Cc][Bcc][>>] if need be... this is not the issue here... I am fine with it... tough currently considering that only three options are made available it seems a bit silly to hide reply to within >>... but that is just building for the future I guess...

If at least we could have the From field width adjusting to its content (so it is smaller instead of going all the way to the end of the right side of screen) that would reduce part of the current issue I raised here while keep your current design... which is the kind of the CcBccReplyToReLocationRLMockup2.compromise.jpg idea suggested...

Currently also in the From field some data seem to appear duplicated, is that really necessary? Removing duplicate data, would reduce the field width size and make the links/buttons closer to the left and center of the screen... still out of context but therefore more accessible and in eye focus...

Comment 11

[Wayne Mery (:wsmwk)]

(In reply to Magnus Melin [:mkmelin] from comment #9)

(In reply to Wayne Mery (:wsmwk) from comment #5)

I'm suggesting make it available for placement in "Composition Toolbar" in addition to wherever else it is in the UI.

It's not always showing, it's not a customizable toolbar, and

That's true of the formatting toolbar, not the composition toolbar which is totally about the compose window - so this argument isn't relevant.

it's not the area for addressing

Well, the addressing area isn't customizable. So What then, is your alternative to the status quo?

Comment 12

[Magnus Melin [:mkmelin]]

Why does there need to be an alternative?

Comment 13

[Richard Leger]

(In reply to Magnus Melin [:mkmelin] from comment #12)

Why does there need to be an alternative?

Current implementation is:

• out of context
• out of logical workflow
• not intuitive
• to far away on the right side - already on 14" screen but especially on 27" screen (e.g iMac)
• "long distance" to access or drag/drop recipients on any of the links/buttons

As I said in Comment 10 if at least the From field could be reduced in width to fit its content (removing duplicated displayed data), then the links/buttons for optional field would be closer to the left/center of the screen... assuming they would remain located just after the From field and not stay on the far right... (see mockup2 attachment 9127474 [details] to get the idea)
Still out of context/workflow but don't break your current design... while bringing improvement... closer to eye focus so more intuitive... reducing the distance gap (context/logical workflow issue)...

Out of all people I ask to compare between...

• current design implemented (links/button top far right)
  and
• my first suggestion/mock-up (attachment 9127175 [details]) with links/buttons placed under To field, before Subject where they naturally belong...
  ...they all preferred the second design (my mockup) except one person... shouldn't that tell something?

But in the end I know it is up to the design team and technical committee... so up to you guys...

Maybe part of the issue currently encountered may also partially be linked to Bug 1616514, the last state of visibility of optional fields not being stored in user profile currently for persistency... meaning that you have to click on Cc, Bcc or else every time you Write a new message... not the most user friendly either...

Hope that help to clarify a bit...

Comment 14

[Alessandro Castellani [:aleca]]

Why does there need to be an alternative?

I think the question Magnus asked was related to what Wayne wrote regarding having an alternative in the toolbar, which I agree with Magnus we shouldn't do as it doesn't make sense having double entry points for the same thing. Also, locating the addressing labels in the toolbar makes them totally disconnected from the entire addressing widget area.

If at least we could have the From field width adjusting to its content (so it is smaller instead of going all the way to the end of the right side of screen) that would reduce part of the current issue I raised here while keep your current design.

I can give it a try, but I think I will want to change the UI of the From as it looks weird not expanding the whole width.
Also, it might look strange when the user changes the identity and that sizing updates.

Thanks for the suggestions and the mock-ups. I'll take some time to prototype these ideas, keeping in mind there are a lot of keyboard accessibility fine tuning that happened, so changing the location of those fields is very tricky.

Comment 15

[Alessandro Castellani [:aleca]]

Comment on attachment 9127476 [details]
CcBccReplyToReLocationRLMockup3.movedFarLeft.jpg

I think this is not doable at all.
Those strings change in length based on the current language, and having them floating there makes it extremely hard to reach with keyboard focus.
That's a hard NO from me.

Comment 16

[Alessandro Castellani [:aleca]]

Comment on attachment 9127474 [details]
CcBccReplyToReLocationRLMockup2.compromise.jpg

This feels the most doable of the proposals as it doesn't affect the current keyboard focus cycle and keeps everything tight.
I'll play with this and see if I can improve the visual separation of the Form field since it doesn't align anymore with the rest.

Comment 17

[Alessandro Castellani [:aleca]]

Comment on attachment 9127175 [details]
CcBccReplyToReLocationRLMockup.jpg

I don't think we want to go this route either.
Even if it this seems like an obvious direction, having those labels there create a couple of problems.

We're reserving an entire row for a couple of elements, and we don't want to print them all and keep the extras in the `>>` popup, as we might have 5 to 6 extra labels based on user's headers. That looks weird.

Also, having the labels there creates issues with the focus cycle, adding extra steps to reach the Subject line, which it should always be 1 step away from the last addressing row.

Comment 18

[Alessandro Castellani [:aleca]]

Attachment: message-identity.jpg

A couple of high fidelity mock-ups to see how it might look

Comment 19

[Richard Marti (:Paenglab)]

Comment on attachment 9127630 [details]
message-identity.jpg

I like the bottom mock-up better because of the not existing menulist box. The top one doesn't look well balanced which could also be dependent of the window width and the width of the From box.

Would the width of the from box be fixed or dependant of the from address in it? If latter what happens when I change the identity and it is longer than the default?

On the bottom image, what happens on hover? Does it show the box like it's now? Then aybe don't align the from address with the border of the fields below.

Comment 20

[Thomas D. (:thomas8)]

Comment on attachment 9127630 [details]
message-identity.jpg

I think the general idea is good, it actually normalizes the sender field which is currently overlong.
It can also make users who want the CC/BCC/>> buttons more in their visual focus a bit happier.

However, there's a caveat: Sender field currently has up to two pieces of important extra information after the email address:
- John Doe <[e-mail]> *Account Name* [which can be set to differ from the email address in account settings]
- John Doe <[e-mail]> (Identity label) *Account Name* [which gets shown for any custom identities, label defined at the bottom of identities dialog]
For the default case where the From address matches the account name, we might get away with eliminating that - which will give us more of the desired space-saving effect for the default case.
For any other case where account name differs, and for identity labels, we would have to continue showing that information, because it's quite crucial to know exactly under which account and identity I am sending my message. I would not want to depend on tooltips for that, and I will readily accept that [CC] & friends will be a bit further away (but maybe still more to the left than now, especially on big screens).

Between the two variants, both are ok.
I'd expect the bottom "flat" variant to show the input box with white input on hover as in current release. I think we have to do that also to allow "Customize from address", where users can actually enter random sender text.
So Richard is right, you'd have to push the sender text a bit offset to the right so that when the white input box appears, that should align with the other input boxes.

In fact, dare I say it, sometimes I catch myself wishing that not only sender, but the entire recipient field including pills would return to some sort of "flat" layout when I am no longer working on them... pills are awesome for working on them, but still quite noisy for permanent presence...

Comment 21

[Alessandro Castellani [:aleca]]

In fact, dare I say it, sometimes I catch myself wishing that not only sender, but the entire recipient field including pills would return to some sort of "flat" layout when I am no longer working on them... pills are awesome for working on them, but still quite noisy for permanent presence...

I feel you, in fact, my original idea was something like this: https://invis.io/EQW2JVDJDS5, but don't tell anyone ;-P
It's a bit of a drastic change, but we're slowly moving towards it through tiny improvements and iterations.

Comment 22

[Richard Leger]

(In reply to Alessandro Castellani (:aleca) from comment #18)

Created attachment 9127630 [details]
message-identity.jpg

A couple of high fidelity mock-ups to see how it might look

I agree the bottom design looks good, it would be a good compromise...

I like the flat design (no white background) for the From field, making it more discreet and helping focusing on what really matter... but please don't make the other fields To, Cc, Bcc, etc... and Subject flat as suggest in Comment 20 and Comment 21, it is a no go for me, you completely loose contrast and visibility !!! Change would be way too drastic...
:-)

Comment 23

[Richard Leger]

Thank you guys for considering some adjustments really appreciated...

Few comments below on extra feedback you provided... if I may...

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

Comment on attachment 9127630 [details]
message-identity.jpg

I think the general idea is good, it actually normalizes the sender field
which is currently overlong.
It can also make users who want the CC/BCC/>> buttons more in their visual
focus a bit happier.

I cannot but think this one comment is for me... among others looking at the same sort of improvement :-)

However, there's a caveat: Sender field currently has up to two pieces of
important extra information after the email address:

• John Doe <[e-mail]> Account Name
• John Doe <[e-mail]> (Identity label) Account Name

I would strongly advocate against showing Identity Label and Account Name unless the From field selection box is triggered (maybe in a second line within the selection box unfolding?) showing just the Display Name <email_address> by default shall be largely sufficient...

Indeed while you may have same Display Name for various identity, I doubt anyone would have the exact same email address set as identity within two separate accounts... Display Name <email_address> shall be sufficient to identify which account your are sending from (that is the case today)...

Also noted recently, in my case because when account is setup the Account Name (or possibly Identity Label) is set by default with the email address value, you currently end up with a from Field that look like this:

Display Name <email_address> email_address <-- duplicated info, not required to be displayed by default in the From field!

The above is not really directly linked to this bug but though it was worth mentioning while at it...
In the such default case, the duplicated info shall simply not be displayed, it looks odd... and take way to much space generating clutter :-)
If Account Name (or Identity Label) are set with same value of Display Name or email address they should not be displayed in the From field to avoid duplicated info.

Removing this clutter would incidentally make the Cc, Bcc etc... links closer to the left... as the From field width would simply shrink... which may make people even happier :-)

Also I would expect the From field to adjust its width based on the selected value.... and consequently the Bcc, Cc, etc... links positioned on the right side to dynamically slide horizontally accordingly as value change (position relative to the From field right edge)...

For the default case where the From address matches the account name, we
might get away with eliminating that - which will give us more of the
desired space-saving effect for the default case.
For any other case where account name differs, and for identity labels, we
would have to continue showing that information, because it's quite crucial
to know exactly under which account and identity I am sending my message. I
would not want to depend on tooltips for that, and I will readily accept
that [CC] & friends will be a bit further away (but maybe still more to the
left than now, especially on big screens).

Personally I would not want this to be the default display of From field...

I don't really think this is crucial as the email address shall be sufficient to identify which accounts it relate to...
Maybe this should ONLY happen if two identities on two different accounts are set exactly the same Display Name and email address... but I doubt it would ever be the case... (niche case example anyone?)

Between the two variants, both are ok.
I'd expect the bottom "flat" variant to show the input box with white input
on hover as in current release. I think we have to do that also to allow
"Customize from address", where users can actually enter random sender text.

Maybe not on a mouse-over but if on mouse-click on the selection box arrow perhaps it would make sense...
So it is not drastically shocking for the selection box to appear with grey background, as it is unfolds anyway...

In fact, dare I say it, sometimes I catch myself wishing that not only
sender, but the entire recipient field including pills would return to some
sort of "flat" layout when I am no longer working on them...

Flat design = lack of contrast ==> reduced visibility

While it may make sense for the From field, I strongly advocate against for the other recipient fields (To, Cc, Bcc, etc...) that encompass pills and the Subject field. Those need to remain on a white background at all time...

pills are awesome for working on them, but still quite noisy for permanent presence...

I quite like them as they are... they provide a good contrast... I would tend to think that the display name could be appearing in bold vs the email address not being in bold within a pill but that may be just a matter of taste just to accentuate visibility and distinction between the two peace of data within a pill and between recipient pills (but that is outside the scope of this bug) :-)

But maybe I would need also to see an iteration of the idea to really understand what you mean by enabling white+pills when mouse-over or field focussed vs returning to flat design when not working on them... maybe useful for proof reading, but I may be hard to convince :-)

I am personally just afraid that it may be a bit "brain-tiring" (sorry I am not sure of the right term) to see all this "blinking" happening all the time you move the mouse and focus in and out of the fields... especially when you work every day all day with TB with multiple emails and accounts to manage... just a thought...

Thank you for your consideration...

Comment 24

[Magnus Melin [:mkmelin]]

Comment on attachment 9127630 [details]
message-identity.jpg

Agreed the lower one looks pretty good.

Comment 25

[Alessandro Castellani [:aleca]]

Attachment: 1616155-msgidentity.diff

Richard, can you take a look at the Windows side of things (still waiting for the computer to arrive and I can't build on a VM >_>)

Comment 26

[Richard Marti (:Paenglab)]

Comment on attachment 9128996 [details] [diff] [review]
1616155-msgidentity.diff

Good start, thanks.

This patch makes that the dropmarker is outside of the menulist under Windows. I fixed this through using the dropmarker as background-image like Mac and Linux do. The textfield, when the menulist is in editable mode, overlaps the dropmarker.
I fixed both in my patch, I'll attach.

Your actual approach has an issue with long addresses in the #msgIdentity: It grows until the address fits but it moves the buttons out of the view. Something like flexing and have a max-width would be needed but this could be still too wide for smaller windows.

Comment 27

[Richard Marti (:Paenglab)]

Attachment: 1616155-msgidentity.diff

Patch that should work on all platforms.

Comment 28

[Alessandro Castellani [:aleca]]

Thanks for the updated patch.

Your actual approach has an issue with long addresses in the #msgIdentity: It grows until the address fits but it moves the buttons out of the view. Something like flexing and have a max-width would be needed but this could be still too wide for smaller windows.

Yeah, I'll iterate on that to fix the issue.
Also, I think I'll need to change the pseudo element to be wider and use the border right as coloured separator, otherwise, if the address is longer and we shrink the container, the ... appears underneath the dropdown chevron due to the negative margin.
I'll update this patch.

Comment 29

[Alessandro Castellani [:aleca]]

Attachment: 1616155-msgidentity.diff

Patch updated.
How does it look on Windows with the width on the pseudo element?

Comment 30

[Richard Marti (:Paenglab)]

Comment on attachment 9129248 [details] [diff] [review]
1616155-msgidentity.diff

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

Looks good on Windows too.
Please update the commit message. You don't remove now the flex property. And please update the reviewer.

r+ with the comments fixed.

::: mail/components/compose/content/addressingWidgetOverlay.js
@@ +1111,5 @@
> +  // of the msgIdentity field.
> +  document
> +    .getElementById("msgIdentity")
> +    .classList.toggle(
> +      "pseudo-separator",

I'm not really happy with the "pseudo", what do you think about "addressingWidget-separator"?

::: mail/components/compose/content/messengercompose.xhtml
@@ +2164,5 @@
>  
>                </hbox>
>              </hbox>
> +
> +            <hbox flex="1"></hbox>

Is this really needed? It works for me also without it.

::: mail/themes/linux/mail/compose/messengercompose.css
@@ +222,5 @@
>  }
>  
>  #msgIdentity > html|input.menulist-input {
>    -moz-appearance: none;
> +  margin-inline-end: 32px;

This margin should be no more needed with your change to the width of the pseudo-separator.

::: mail/themes/osx/mail/compose/messengercompose.css
@@ +108,4 @@
>  }
>  
> +#msgIdentity.pseudo-separator::after {
> +  margin-right: -22px;

`margin-inline-end` to be RTL compliant.

@@ +113,5 @@
>  
>  #msgIdentity > html|input.menulist-input {
>    color: inherit;
>    padding-inline-start: 3px;
> +  margin-inline-end: 32px;

Also this margin should be no more needed with the new approach.

::: mail/themes/shared/mail/messengercompose.css
@@ +483,5 @@
> +#msgIdentity.pseudo-separator::after {
> +  display: block;
> +  content: '';
> +  width: 32px;
> +  border-right: 1px solid var(--toolbarbutton-hover-bordercolor);

`border-inline-end` makes the separator also RTL compliant.

@@ +485,5 @@
> +  content: '';
> +  width: 32px;
> +  border-right: 1px solid var(--toolbarbutton-hover-bordercolor);
> +  height: 14px;
> +  margin-right: -32px;

Same here: `margin-inline-end`for RTL compatibility.

And can you move this line to the Linux/Windows files? In the shared files we have only the rules which match on all platforms. Like this, we don't apply a rule two times.

@@ +653,5 @@
>    line-height: 1;
>  }
>  
> +.address-extra-recipients label:not([collapsed]) + label {
> +  margin-left: 5px;

`margin-inline-start`

::: mail/themes/windows/mail/compose/messengercompose.css
@@ +147,5 @@
>  #msgIdentity > html|input.menulist-input {
>    background-color: inherit;
>    color: inherit;
> +  margin-block: 2px;
> +  margin-inline: 0 32px;

This change can be now reverted with the new approach.

Comment 31

[Alessandro Castellani [:aleca]]

Attachment: 1616155-msgidentity.diff

Sweet, thanks for the fixes requested.
I updated everything and launched a try run: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=355dbf53b8adfd0c2e914734c93c78c8e013d893

Can you double check on Windows if everything still looks good?
On Linux is perfect, I'm not testing it on macOS.

Comment 32

[Richard Marti (:Paenglab)]

Comment on attachment 9129294 [details] [diff] [review]
1616155-msgidentity.diff

Yep, looks good. Thanks.

Comment 33

[Alessandro Castellani [:aleca]]

Awesome, and it looks good also on macos.
I'll push it once the try-run ends (if successful).

Comment 34

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/f12bdc4069d5
Keep the msgIdentity field width from growing past the longest available identity address. r=paenglab