1535503 - Smaller message headers area and implement "add field" button

Status: RESOLVED DUPLICATE of bug 440377

(Thunderbird :: Theme, enhancement)

Description

[Alessandro Castellani [:aleca]]

Attachment: write.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:65.0) Gecko/20100101 Firefox/65.0

Expected results:

This is a proposal I'd like to discuss.

I'd like to propose the addition of an Add field button in the compose message header area. This button is to improve the discoverability of the action of adding multiple To, CC, BCC, Reply-To: fields.

Right now, we're visualizing three total rows for those fields, and we allow the addition of extra fields by hitting "enter" once an email address has been written in the current field.

This action doesn't feel very intuitive, and it took me a couple of extra seconds to figure it out. Having a button with a descriptive tooltip could improve this action and remove the road block a first time user could face.

With that button, we could could also potentially remove the three rows, allowing the header to shrink substantially. The header would then grow to allow more rows until a predefined max-height, which will then activate the scrollable area.

Comment 1

[Wayne Mery (:wsmwk)]

I concur. A couple weeks ago I set mail.compose.addresswidget.numRowsShownDefault - finally tired of so many default rows after 10+ years of usage.

And it would deal with Bug 734683 - Provide UI for adding more recipients than lines provided by default
Could this also be in scope? Bug 1078277 - Write new message To field disappears if numRowsShownDefault is set too low

Comment 2

[Magnus Melin [:mkmelin]]

Some thoughts:

• it's likely not so nice to have the addressing pane change size.
• if you only have one row or so, some users won't figure out where "the other addresses" went, since they would scroll out of view

What would the button actually do? Just add a new line?

I think the addressing widget should be severely modernized, but we don't have enough time for it until after 68, I think (it's very prime ui and would need more testing than we can expect to get before that). We should drop the unmodern one-row-per-recipient and make the recipients kind of tags/bubbles with x-marks to remove. Like most of other email app do it. Bug 440377.

Comment 3

[Wayne Mery (:wsmwk)]

True - the entire thing needs an overhaul, which can't happen for at least another year. (plus we know how old Bug 440377 is)

it's likely not so nice to have the addressing pane change size.

Is this only bad in relation to your second point about scrolling when more addresses are added?

I must say I love having gained space with the hidden pref. This buys a lot of real estate that users don't know is possible. So rather than totally ditch the idea how about :

• change the default to two lines
• would it be trivial to make address lines dynamically expand to max 3 lines as more addresses are added?

Comment 4

[Magnus Melin [:mkmelin]]

I think it was a few years back when we changed it from 4 to 3 rows and added the hidden pref you're using now. IIRC, people didn't like having just 2 rows. I think the problem is that if you're unaware of how it works, you don't get the mental image that there are more addresses hidden up there unless you have at least 2 rows with addresses above the current input line.

Having the space move around is likely not nice, even with less lines.

Not too concerned with the screen real estate in this case, as I think compose has more room than it needs. (Even web mails tend to pop up writing in a small window, it just looks nicer.)

Comment 5

[Alessandro Castellani [:aleca]]

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

it's likely not so nice to have the addressing pane change size.

I don't see this as a problem or something that could disrupt the user experience.
It's pretty standard in every other email clients that the header area expands to accommodate the user action of adding more recipients.
Some common implementations also include an auto-collapsing feature which will shrink the header area once the user stops typing addresses, and visually turns all the recipients into inline tags.

What would the button actually do? Just add a new line?

Yes, it would trigger the same method that adds a new line when you hit Enter on your keyboard after writing an address on the last line.

I think the addressing widget should be severely modernized...

Totally agree with this.
If you want, I can do some mock-ups to start visually exploring possible solutions. Let me know what would be the timeline for this and how much time do you think I could dedicate to it.

Comment 6

[Richard Marti (:Paenglab)]

You could also try MRC Compose https://addons.thunderbird.net/thunderbird/addon/mrc-compose, compatible with TB 60, as how it could look.

Comment 7

[Alessandro Castellani [:aleca]]

Attachment: write-modern.jpg

Here's a quick mock-up for a possible modernization of the new message header.
Possible approaches and behaviors explained as followed:

1. Initial state
   The user only adds an email in the To field and doesn't need to add any other recipient. The ability to activate other fields come from clicking on the Cc, Bcc, and Reply-To links located to the right of the To field.
   If the user is editing/writing addresses inside the To field, the completed addresses are rendered as "pills" with a delete icon to quickly remove them.
   Once the user removes the focus from that field, all the To addresses are listed as simple text.

2. Filling extra fields
   The user clicked on Cc and Bcc, those link disappear and the new fields turn visible.
   In this case, the message header should grow to allow the user to edit and fill up these fields without the necessity of scrolling within a container with limited height.
   The completed addresses are rendered as "pills" with a delete icon.
   We could also potentially allow a drag&drop action to move those pills from a field to another.

3. Fields lose focus
   Once the user completed filling those fields, and the focus moves to the message body, we could automatically collapse those extra fields and leave only the To field visible, visualizing only the To recipients as text, and a count recap for the extra Cc and Bcc fields.
   If the user clicks on the To field again, the message header should return to the status of screen 2.

Comment 8

[Magnus Melin [:mkmelin]]

That looks nice indeed, and that's the direction I'd rather see us moving!
The only part I'm unsure about is if it's worth perusing directly since there's fairly little time for polish to 68.

Comment 9

[Alessandro Castellani [:aleca]]

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

The only part I'm unsure about is if it's worth perusing directly since there's fairly little time for polish to 68.

It's totally fine for me to put this in the back-burner and tackle it later to target TB 69 or 70, depending on other priorities.
Up to you.

Comment 10

[Wayne Mery (:wsmwk)]

Attachment: TB compose.png

I'm not a manager but I list some pros for going ahead:

• I suspect this code is fairly self contained
• there probably are not addons mucking with this space
• it is a top user request
• you possibly kill two or three birds with one stone - gain space, modernize the UI and satisfy a top user request

potential cons:

• time
• will this be complicated by autocomplete and accessibility factors?

And I'd like to push back on an earlier notion regarding the current UI and screen real estate ...

Not too concerned with the screen real estate in this case, as I think compose has more room than it needs. (Even web mails tend to pop up writing in a small window, it just looks nicer.)

Nicer shouldn't trump everything?

In general I think Magnus' conclusion about compose having more room than it needs is overly slimpified. Some points below, which I will acknolwdge not all represent the average user case and should be accomodated, but this is my use case :

• if I have replied to a posting, I normally don't care about changing the recipients, so I don't need to see them all
• if I have created a posting, then I have typed in the recipients and know what I typed in, so I don't need to see them all unless I have made a mistake or need to delete one
• I would guess at least 50% of average correspendence involves only one address line (for me probably more than 80% of correspondence)
• two lines in the address UI gets me three lines of message body (see area in red box)0
• not everyone uses the default DPI for the screen size/resolution - mine is at 125%, at highest resolution 1600x900 on a largish 15.6" laptop screen
• in a new profile, at my 125% screen increase, the non-body part of the 900px compose window takes 270px, almost 1/3 of the window.