Closed Bug 1777780 Opened 2 years ago Closed 2 years ago

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

Categories

(Thunderbird :: Address Book, defect, P1)

Thunderbird 103

Tracking

(thunderbird_esr102+ fixed, thunderbird104 affected, thunderbird106 fixed)

RESOLVED FIXED
107 Branch
Tracking Status
thunderbird_esr102 + fixed
thunderbird104 --- affected
thunderbird106 --- fixed

People

(Reporter: chriechers, Assigned: mkmelin)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [TM:102.4.0])

Attachments

(2 files)

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.

See Also: → 1777749
Blocks: tb102found

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.

Severity: -- → S2
Priority: -- → P2
Summary: no 'Department' field for 'Organization' related information in new address book → No dedicated 'Department' field under 'Organization Properties' in new address book, unpredictable two-column display for multi-line 'Organization' 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.

Blocks: 1771576
See Also: 1777749

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.

Priority: P2 → P1

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.

Assignee: nobody → mkmelin+mozilla
Status: NEW → ASSIGNED

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.

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

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.

Target Milestone: --- → 105 Branch
Target Milestone: 105 Branch → 107 Branch

Pushed by alessandro@thunderbird.net:
https://hg.mozilla.org/comm-central/rev/e99903aac797
Fix Organization Properties: correct ordering and add placeholder to describe what goes where. r=aleca

Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/ba3662065b3f
follow-up - fix test expectation. rs=me DONTBUILD

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

Attachment #9288614 - Flags: approval-comm-esr102?
Attachment #9288614 - Flags: approval-comm-beta?

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

Attachment #9288614 - Flags: approval-comm-beta? → approval-comm-beta+
Whiteboard: [TM:102.4.0]

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

Attachment #9288614 - Flags: approval-comm-esr102? → approval-comm-esr102+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: