Address sub-fields in Contacts

expert

#1

Bringing this here as the Github issue has been locked for non-collaborators.

@DeepDiver1975: You said:

There is only one field in the vcard: address.
We either add an address or we don't.
There is no separate Po Box field

There is a place for the PO Box. The ADR line includes seven, semicolon separated components, the first of which is the PO Box. You already referenced RFC 6350 section 6.3.1in the Github issue, which specifies the format.


#2

The issue is we see it is really about layout of the address field, as it appears in the UI.
Currently there is a letter box (postbox) field appearing.
This is required for personal users (or storing corporate addresses) in many countries.
In many others it is not required.
Indeed, the address field is a single field in CardDAV, with multiple components.

The resolution would be threefold:
1) To change address field layout depending upon the users country (as per https://github.com/owncloud/contacts/issues/462 )
2) To amend the address field layout if a User changes the 'country' for a specific contact
3) Offer an alternative 'type' of address - POBox - in addition to home, work, other (unspecified). So contacts in all countries CAN have the postbox layout, without being required to. When the 'type' is changed to 'POBox', then the PO Box field appears.

One bit of major work would be getting the UPC postal descriptions into a file. We would be happy to do this.


#3

The issue of how an address is presented when viewing contacts, compared with the required (sub-)fields of a vCard could be neatly addressed (sorry) by introducing an Edit mode for Contacts.

The UI could then format the contact's address in a concise and presentable way, conforming to country norms, if necessary, without any conflict with RFC requirements. The UI presentation could also provide a nicely formatted LABEL field in the vCard.

Additionally, it could then be possible to highlight and copy a complete address for other uses, which is not possible at the moment.


#4

Absolutely. We suggested this. Github contacts issue #459

However, jancborchardt commented on the main issue on github:

@olantrust
we do not want to introduce a separate read/edit mode since it’s an
unnecessary distinction. If at all, we could make the items appear as if
they are read-only (remove the border around the text fields) and have
them appear on hover, and editable on click. Basically like we do for
the name/lastname input.


#5

I know, but we plebs were locked out of the issue. The UI for Contacts is just horrible.

Edit:
Sorry, I confused two different issues. #255 was locked. Yes, I agree with your summary in #459, but I expect it to be either ignored or dismissed as already decided.


#6

Well, those involved with design and usability ideas are as important as developers.
We appreciate the issue was locked @DeepDiver1975, to bring discussion on to here
However, It is disheartening that the issue is only being discussed by there, developers, having said to move here, and we are locked out.


#7

@DeepDiver1975
What do you think of the issue I raised at #459 - view/edit mode?

Janborchardt thinks it is too much clutter. I think having editable fields viewed when simply browsing contacts is way more clutter.

The way Zimbra does it, showing only fields that are entered in view mode, is much less cluttered, and easier to find information.
And it prevents accidental editing when only browsing (which is generally how a contacts app is used).
Jan suggests an alternative, but

If that edit/view mode was introduced, I would still strongly urge the changes in #462 - having the layout change per country provided for the contacts address (and a default one of the User's country).


#8

Yes, of course they are and I agree (with the design devs) that their work cannot be added as an afterthought.

But at the moment, they are discussing in a vacuum, without considering what the users think.