Closed Bug 1535503 Opened 1 year ago Closed 1 year ago

Smaller message headers area and implement "add field" button

Categories

(Thunderbird :: Theme, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 440377

People

(Reporter: aleca, Assigned: aleca)

Details

(Keywords: ux-efficiency)

Attachments

(2 files, 1 obsolete file)

Attached image write.png (obsolete) —

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.

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

Assignee: nobody → alessandro
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

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.

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?

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

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

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

Attached image 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.

Attachment #9051155 - Attachment is obsolete: true

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.

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

Attached image 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.
Keywords: ux-efficiency
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → DUPLICATE
Duplicate of bug: 440377
You need to log in before you can comment on or make changes to this bug.