+++ This bug was initially created as a clone of Bug #1770844 +++

Alex, could you (ask someone to) land a couple of strings for this just in case?

• Display name [label/tooltip]
• Display name (click to edit) [tooltip]
• ?
  We might need those either as a label or as a tooltip. P1 because of strings needed.

Wayne and I have been looking at the new Display name implementation. More precisely, we were actively looking for it on existing contacts with a generated default display name, and for a long time failed to find it. We then started playing with the different list orders between First Last, Last, First, and Display Name. There might be a bit of newness at play, but somehow the user experience of this has remained confusing. Display name would seem present in unexpected and undiscoverable ways, and absent where it's expected. The problems are intertwined and not easy to describe. Let me try.

STR:

• in AB, have cards like the following:
  • First: John
  • Last: Doe
  • Display: Johnny
• Click Change the list order (icon next to search bar)
• Choose between the following sorting options:
  • First Last (FL)
  • Last, First (L,F)
  • Display name

Problem 1: Custom Display Name not shown in card display with First Last or Last, First

Actual: For sorting modes FL and L,F, the card won't show the Display name unless you go to Edit mode.

Expected:

• for FL:

  John Doe

  Display Name: Johnny
• for L,F:

  Doe, John

  Display Name: Johnny
• for Display Name:

  Johnny

  Display Name: Johnny (?)

Rationale:
Display name is used both for display in message and when writing to the contact, so it would seem important enough to display that even if user currently uses a sort order not based on display name, i.e. FL or L,F (which looks like a very worthwhile scenario).

Problem 2: Can't discover that Display name is editable

Actual:
There is near-zero discoverable indication that in Edit mode, the display name is editable.

Possible improvements (also depending on solution for problem 3)

• Permanent field border in edit mode
• Field border on hover in edit mode
• Add Display Name field label
• Tooltip: Display name (click to edit)
• Icon to focus Display Name field for editing
• ?

The solution for problem 2 relates to problem 3.

Problem 3: Surprising change of contact title when switching to Edit mode (with FL or L,F sorting)

Actual:
Looking at my list using L,F, the name in the list shows as Doe, John.
Likewise, the name on the displayed card shows Doe, John as a title.
When changing to Edit mode, suddenly the card title changes, and becomes Johnny (the custom display name). This seems confusing. The card title should remain consistent even when editing. Display name should be shown as a separate field (maybe below the title based on the selected order, FL vs. L,F).

Expected:

• Title should always display according to the chosen format/order for consistency between the list, the displayed card, and the card in edit mode.
• Display name should be shown separately, probably below the title.

Display name

We already have this string.

Display name (click to edit)

This would be just a wrong string to have.
There's nothing to land here from a string POV, and also we can't. The string freeze deadline passed so no more string changes.

For sorting modes FL and L,F, the card won't show the Display name unless you go to Edit mode.

If the user wants to list by first or last name, polluting the list with the display name doesn't make sense since the user is not interested in that at all.

There is near-zero discoverable indication that in Edit mode, the display name is editable.

Improvements to the display name field are coming in bug 1717632.

When changing to Edit mode, suddenly the card title changes, and becomes Johnny (the custom display name). This seems confusing. The card title should remain consistent even when editing. Display name should be shown as a separate field

Yup, I will address also this in bug 1717632.

Taking this as I'm splitting my work in smaller patches so we can review them quickly.
This is a quick overview of the action plan.

EDIT VIEW

• The Contact Name and Display Name should be separate.
• The Contact Name is not editable as it's handled by the "Name" fields (first, last, prefix, etc).
• When the user changes the "Name" fields, the Contact Name should reflect those changes .
• The Display Name field is underneath the Contact Name and it should be independently editable from the Contact Name.

LIST VIEW

• When the sort list is changed between first, last, display name view option, the selected contact should also be refreshed.

CONTACT VIEW

• Even if the "preferred display name" is checked, always show both Contact Name and Display Name.
• Include all fields of the name in the Contact Name (prefix, middle, suffix).

The Display Name field is underneath the Contact Name and it should be independently editable from the Contact Name.

The old address book used to fill a display name when you add first and last, if the display name was empty.
For contacts created from emails - probably the vast majority - note that you usually only have the displayname that was taken from the mail header.
There seems to be some oddness atm in that if I add first and last name to an address without displayname, on the top of the page next to the image, I still only get the email address - and no name at all showing.

Yeah, it's pretty broken now.
I'm taking care of it with the following workflow:

• The "Contact Name" (What you see in the Edit and View mode in the header) will be automatically updated if the user writes a Display Name.
• If the user doesn't write any Display Name, the "Contact Name" will be composed by all fields of the name component (prefix, first, middle, last, suffix), or Last name first if the user has that pref checked.

(In reply to Alessandro Castellani [:aleca] from comment #2)

Taking this as I'm splitting my work in smaller patches so we can review them quickly.
This is a quick overview of the action plan.

EDIT VIEW

• The Contact Name and Display Name should be separate.
• The Contact Name is not editable as it's handled by the "Name" fields (first, last, prefix, etc).
• When the user changes the "Name" fields, the Contact Name should reflect those changes .
• The Display Name field is underneath the Contact Name and it should be independently editable from the Contact Name.

This sounds good to me.

(In reply to Alessandro Castellani [:aleca] from comment #4)

• The "Contact Name" (What you see in the Edit and View mode in the header) will be automatically updated if the user writes a Display Name.

Does this change the separation of display name as planned in your comment 2? I would suspect that this recreates some of the problems mentioned in comment 0. A bit hard to tell in the abstract.
I'm not sure, but I would expect the following:

• Contact Name and Display name are always distinct and shown both in View mode and Edit mode.
• Contact Name (the card title) always matches the pattern chosen for the list: FL, L,F, or Display name. Imo it's a bit strange when the name selected in the list isn't matching the title (Contact Name) of the card. Maybe for Display Name sort pattern (hence then shown in the Contact Name), and only when viewing a contact, we could have Real Name: prefix F M L suffix (instead of Display name) below the Contact Name, so that we avoid showing display name twice, and always show all the name data also in View Mode.

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/51105e478b12
Rebuild the display name as FN component and make it behave consistently alongside the N component. r=darktrojan,henry

Looks good in daily. Thanks

Comment on attachment 9279031 [details]
Bug 1771824 - Rebuild the display name as FN component and make it behave consistently alongside the N component. r=darktrojan,henry

[Approval Request Comment]
Regression caused by (bug #):
User impact if declined:
Testing completed (on c-c, etc.): landed a week ago
Risk to taking this patch (and alternatives if risky): no

Comment on attachment 9279031 [details]
Bug 1771824 - Rebuild the display name as FN component and make it behave consistently alongside the N component. r=darktrojan,henry

[Triage Comment]
Approved for beta

Thunderbird 102.0beta6:
https://hg.mozilla.org/releases/comm-beta/rev/c69d7fb68596