1777780 - No dedicated 'Department' field under 'Organization Properties' in new address book, unpredictable two-column display for multi-line 'Organization' in horizontal view

Status: RESOLVED FIXED

(Thunderbird :: Address Book, defect, P1)

Description

[Christian Riechers]

In the old Address Book, in addition to the 'Organization' field, there was also a 'Department' field, which doesn't exist in the new UI. Department is important in corporate world, therefore the lack of a proper Department field is a showstopper for corporate users.

Even though existing 'Department' information from the old address book is carried over to the new address book, it get's all mixed up with the 'Organization' field. I.e. there are now two lines in the 'Organization' field. The first one is the 'Department' information, and the second one is the actual 'Organization' information. This looks awkward.

Using tabular view one can turn on a 'Department' column header, and surprisingly, the 'Department' information is shown properly there. But the real problem is the lack of a proper 'Department' field which can also be edited.

Instead, in the new address book there is a 'Role' field which did not exist in the old address book. The 'Role' field is completely useless for me, and it seems somewhat redundant with the 'Title' field. Beyond that, changes to the 'Role' field are not saved after editing.

Ideally the useless 'Role' field would be replaced with the 'Department' field, which would restore the status of the old address book.

I really wish I'd understand the rationale behind the changes being made in the new address book, and why Organization related information simply wasn't kept as in the old address book.

Comment 1

[Thomas D. (:thomas8)]

Thanks Christian, and sorry for the inconvenience.

I agree with you that the current design around Department vs. Organization is inherently flawed and unpredictable.
If I enter a two lines as an organization, the first one will show in Department column, and the second one will show in Organization column. Yet the user has no way of predicting that, and if anything, would probably expect the other way round (main organization first, department second).

Tentatively marking as P2/S2 because we should fix this before users start working around this by reversing the order of lines in the Organization field and then we end up in even bigger trouble.

Imo we really need to split out the department field cleanly as a separate field in the Organizational Properties section.

Comment 2

[Thomas D. (:thomas8)]

Attachment: Screenshot 1: Multiline value for 'Organization' gets split across two columns in horizontal view

Multiline value for 'Organization' gets split across two columns in horizontal view.
Showing a single field in two columns is unexpected, and there are no hints in the edit UI.
How it will get split between the two columns is unpredictable for the users, and if anything, the split should probably be the other way round.

Comment 4

[Magnus Melin [:mkmelin]]

The fields we have are mapping to the vCard spec (it has Title, Role, Org) - https://datatracker.ietf.org/doc/html/rfc6350#section-6.6
I'm sure there were good reasons to spec it like this. Anyway, we interoperate with other data source so fields need to line up well with what data we get and what data we produce.

The best way to fix this, flexibly might be to add placeholder to the field, so it's clear how to fill it in to get the expected result.

Comment 5

[Magnus Melin [:mkmelin]]

I'll take this.

Unfortunately there's a bit of bugs here: the order is wrong. The highest org part should be first, not in reverse.

Comment 6

[Magnus Melin [:mkmelin]]

Attachment: Bug 1777780 - Fix Organization Properties: correct ordering and add placeholder to describe what goes where. r=aleca,darktrojan

The ordering was wrong: RFC 6350 has the ORG value as e.g.
ORG:ABC, Inc.;North American Division;Marketing

I don't think we can fix this without without new strings.

Comment 7

[Magnus Melin [:mkmelin]]

Another issue is that the cardinality of these properties is "*" == "One or more instances per vCard MAY be present.". We can only have one of them now... But that would be something for another bug.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/e99903aac797
Fix Organization Properties: correct ordering and add placeholder to describe what goes where. r=aleca

Comment 9

[Alessandro Castellani [:aleca]]

Little test failure: https://treeherder.mozilla.org/jobs?repo=comm-central&selectedTaskRun=P_usGDcjSneHx9lngVXLow.0

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/ba3662065b3f
follow-up - fix test expectation. rs=me DONTBUILD

Comment 11

[Rob Lemley [:rjl]]

Regarding potential esr102 uplift, currently 5/10 of our top ten (non-en_US) locales have translated the five additional strings. I can check that again for 102.4.0 and see if that's improved at all.

There's a commit from bug 1772119 (test code) that needs to be uplifted first.

Comment 12

[Magnus Melin [:mkmelin]]

Comment on attachment 9288614 [details]
Bug 1777780 - Fix Organization Properties: correct ordering and add placeholder to describe what goes where. r=aleca,darktrojan

[Approval Request Comment]
Regression caused by (bug #): new ab
User impact if declined: department field confusion
Testing completed (on c-c, etc.): c-c
Risk to taking this patch (and alternatives if risky): fairly safe

Comment 13

[Wayne Mery (:wsmwk)]

Comment on attachment 9288614 [details]
Bug 1777780 - Fix Organization Properties: correct ordering and add placeholder to describe what goes where. r=aleca,darktrojan

[Triage Comment]
approved for beta

Comment 14

[Daniel Darnell [:dandarnell]]

Thunderbird 106.0b4:
https://hg.mozilla.org/releases/comm-beta/rev/f3667d4bc116
https://hg.mozilla.org/releases/comm-beta/rev/adb8ad05dae9

Comment 15

[Wayne Mery (:wsmwk)]

Comment on attachment 9288614 [details]
Bug 1777780 - Fix Organization Properties: correct ordering and add placeholder to describe what goes where. r=aleca,darktrojan

[Triage Comment]
Approved for esr102

Comment 16

[Daniel Darnell [:dandarnell]]

Thunderbird 106.0b5:
https://hg.mozilla.org/releases/comm-beta/rev/02610e6800d2
https://hg.mozilla.org/releases/comm-beta/rev/99c99d63628d

Backed out:
https://hg.mozilla.org/releases/comm-beta/rev/f607c05b596b75670249b3eff59430e28a53fc2d
https://hg.mozilla.org/releases/comm-beta/rev/b241de7c6a2f4f1c49657e0d7bcad04c0ca84293

Comment 17

[Rob Lemley [:rjl]]

Thunderbird 102.3.3:
https://hg.mozilla.org/releases/comm-esr102/rev/3dfd43ae97e1
https://hg.mozilla.org/releases/comm-esr102/rev/afeec21c1fcc