1779567 - Reversed order of primary street address and extended address after update to 102

Status: RESOLVED FIXED

(Thunderbird :: Address Book, defect, P3)

Description

[Thomas D. (:thomas8)]

Attachment: Screenshot 1: Extended address (2nd field from TB91) before street address

STR

1. In TB 91, create an AB contact card with private and work addresses, and fill both fields for both (extended address):
   priv-address-field1
   priv-address-field2
   work-address-field1 (see screenshot of attachment 9285879 [details])
   work-address-field2

2. Update to 102

3. Display the contact in 102

4. Edit contact in 102

Actual

• compared to TB91, the order of fields is reversed: both in display and edit mode, the second field content is now displayed first as "Extended Address", before the actual Street Address.
• No spacing between private and work address

Expected

• Not 100% sure, but I'd expect that the order of the two fields is maintained as in TB 91, first field first, second field second.
• Starting with "Extended address" looks odd. Not sure if it has any function, more so that apparently we do not allow creating Extended addresses going forward, so it's just showing the legacy fields.
• Perhaps add some spacing between private and work address

Comment 1

[Thomas D. (:thomas8)]

Attachment: Screenshot 2: Reversed order of address fields display in 102

Reversed order also seen in 102 display (extended address before street address)

Comment 2

[Magnus Melin [:mkmelin]]

Extended address should probably be dropped altogether (it's about e.g. apartment number, and where in the address you put that depends on local conventions).

https://datatracker.ietf.org/doc/html/rfc6350

  Experience with vCard 3 has shown that the first two components
  (post office box and extended address) are plagued with many
  interoperability issues.  To ensure maximal interoperability,
  their values SHOULD be empty.

Comment 3

[Thomas D. (:thomas8)]

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

Extended address should probably be dropped altogether (it's about e.g. apartment number, and where in the address you put that depends on local conventions).
https://datatracker.ietf.org/doc/html/rfc6350

Good point. Maybe it's OK if Thunderbird was to merge the two fields upon updating, but even then they would have to be merged in the right order as they appear in TB 91 UI.

Comment 4

[Thomas D. (:thomas8)]

Attachment: Screenshot 1: Original field order in TB 91 - equivalent to `street address` first, then `extended address`

Alex, would reversing the field order to preserve Street Address first, then Extended Address (as in TB 91 UI) be an easy gain here (both for display and edit mode)?

Not sure if merging is a good idea - even though Magnus' comment 2 has a point, but still - merging can always backfire with unhappy users if they relied on separate fields with separate data. After all, we're just preserving Extended address, not actively offering it.

Comment 5

[Thomas D. (:thomas8)]

(In reply to Thomas D. (:thomas8) from comment #4)

Created attachment 9285879 [details]
Screenshot 1: Original field order in TB 91 - equivalent to street address first, then extended address

Alex, would reversing the field order to preserve Street Address before Extended Address (as in TB 91 UI) be an easy gain here (both for display and edit mode)?

Not sure if merging is a good idea - even though Magnus' comment 2 has a point, but still - merging can always backfire with unhappy users if they relied on separate fields with separate data. After all, we're just preserving Extended address, not actively offering it.

Comment 6

[Alessandro Castellani [:aleca]]

This is tricky.

Indeed, I agree with Magnus and what the VCard specs recommend regarding dropping the first 2 fields (pobox and extended address), and letting the user write whatever they want and how they want to format it into a single text area, to solve the majority (if not all) locales variations.

Alex, would reversing the field order to preserve Street Address before Extended Address (as in TB 91 UI) be an easy gain here (both for display and edit mode)?

We shouldn't do that since we would be saving the street address into the extended address, which goes against the specs.
Alongside that, reversing the order only visually would create inconsistency between the stored and viewed data.

The 91 UI was wrong and done arbitrarily without any consistency, and we can't assume users always wrote street address and extended address in the same order (in Italy the apartment goes after the street address, but in Canada is the opposite).

Possible solution

• Merge those fields into the regular street address and never use/expose pobox and extended address fields.
• Don't do anything and let the user change the data if they need it and don't like the order.

IMHO, this is a very minor and marginal issue that doesn't create any real problem other than an initial "uh, the address is reversed".
I'm leaning towards merging everything and guiding users in using the Street Address text area to add all the info they want.

Comment 7

[Anje]

I'm leaning towards merging everything and guiding users in using the Street Address text area to add all the info they want.

I agree with Alessandro - I like the idea of a text field where users could type whatever they require as it covers all bases. But I do have another idea worth considering.

An idea - use a similar design as used when creating a Message Filter.
Use several separate lines where user can add + another line like you can do when creating a message filter
Start of each line has a drop down options.
Drop down list example: number/name, street, address2, address3, address4, city, county, zip/postcode, country
User chooses an option from drop down. You could add additional ones you can think of.
If drop down previously used then grey out/disable from next drop down on next line.

The one aspect no one has mentioned is what if someone wants to print as labels.
Currently, the address book would get exported as csv and people may use MS Excel or OpenOffice equivalent.
How would placing everything in a text file effect the csv file and its impact on label printing .I know this is going beyond what is used in Thunderbird, but as the addresses are being discussed perhaps this potential use could be considered. It's just a thought.

Would my idea of using the 'drop down' options be easily converted into column headers ?
So display in columns would also work.

What do people think of the idea of using a similar design to the 'Message filter' method for creating address?

Comment 8

[Magnus Melin [:mkmelin]]

Attachment: Bug 1779567 - Adjust handling of extended address. r=aleca!,nicolai

Comment 9

[Thomas D. (:thomas8)]

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

Alex, would reversing the field order to preserve Street Address before Extended Address (as in TB 91 UI) be an easy gain here (both for display and edit mode)?

I think we're misunderstanding each other here.
Thunderbird 91 has two separate address line inputs for each address, and they are not independently labelled, but just share the label "Address". Let's call them

• Address Line 1
• Address Line 2

So whatever localized structure users have used, but they surely had a first line and a second line as appropriate for their purposes.
When migrating to 102, we're swapping these two lines (even in Magnus current patch which merges them afasics). WHY?
I don't think we should reverse the order of data as we find it in TB 91. This is far from being a marginal issue, especially if we merge. For large datasets, this can cause loads of manual work of getting the two lines back into the correct (localized) order!

Alongside that, reversing the order only visually would create inconsistency between the stored and viewed data.

This bug is about keeping the TB 91 order of address lines, not reversing it.

The 91 UI was wrong and done arbitrarily without any consistency, and we can't assume users always wrote street address and extended address in the same order (in Italy the apartment goes after the street address, but in Canada is the opposite).

Sorry, but imo that's missing the point. TB 91 UI had a first and a second address line.
We can safely assume that users have filled those in the correct order according to their localized order principles.
We should just maintain that order instead of reversing it, especially if we decide to merge the data.

Possible solution

• Merge those fields into the regular street address and never use/expose pobox and extended address fields.

Merging may be OK (although it's still arguably dataloss), but we must merge in the right order.

• Don't do anything and let the user change the data if they need it and don't like the order.
  IMHO, this is a very minor and marginal issue that doesn't create any real problem other than an initial "uh, the address is reversed".

I disagree, see above.

Comment 10

[Thomas D. (:thomas8)]

Magnus, could you please add a revision summary on D153150 to describe what "Adjust handling of extended address" actually does?

If a TB 91 Address has:
Address:
address line 1 (first input)
address line 2 (second input)

Can you confirm that after merging the two lines for 102, your patch preserves that order, so we'll get the following?
Street Address:
address line 1\n
address line 2

From reading the patch, I believe that you're reversing the order, which imo we shouldn't.

Comment 11

[Magnus Melin [:mkmelin]]

The patch doesn't migrate data behind the lines, but only when the user goes to edit address the pobox and extended address fields are merged into the street address field, in the best way I could think of. There is no data migration behind the lines, because data can also come from sources we don't control, so it must just be handled when encountered.

Thunderbird 91 didn't specify what the two address lines were... so the actual data there will be varying.

Re the "pobox" field - Thunderbird 91 didn't have this, but data from other sources may have it. If found, on edit it will be put as first line of the street address instead.

I read up a bit more on the various formats used in different countries now. I guess you're right, let's not change the order. That will be correct for many, but not all cases. We can't get it fully correct without country specific formatting rules which we don't have.

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/292526378008
Adjust handling of extended address. r=aleca

Comment 13

[Magnus Melin [:mkmelin]]

Comment on attachment 9287617 [details]
Bug 1779567 - Adjust handling of extended address. r=aleca!,nicolai

[Approval Request Comment]
Regression caused by (bug #): ab rewrite
User impact if declined: confusion around address field order. We adjust the data to show in the expected order now.
Testing completed (on c-c, etc.): c-c
Risk to taking this patch (and alternatives if risky): safe

Comment 14

[Wayne Mery (:wsmwk)]

Comment on attachment 9287617 [details]
Bug 1779567 - Adjust handling of extended address. r=aleca!,nicolai

[Triage Comment]
Approved for beta

Comment 15

[Rob Lemley [:rjl]]

Thunderbird 104.0b3:
https://hg.mozilla.org/releases/comm-beta/rev/0158b3521e90

Comment 16

[Wayne Mery (:wsmwk)]

Comment on attachment 9287617 [details]
Bug 1779567 - Adjust handling of extended address. r=aleca!,nicolai

[Triage Comment]
Approved for esr102

Comment 17

[Rob Lemley [:rjl]]

Thunderbird 102.2.0:
https://hg.mozilla.org/releases/comm-esr102/rev/f765194dec37