[Discussion] Remaining contact fields to be added

[Bnyro]

Describe your suggested feature

This issue is for discussing about which remaining fields that have not yet been added should be added in the future. There are no plans to support everything possible, the plan is only to support the most important fields, due to two reasons:

1. Efforts and maintainability per field, as each field needs to be implemented for VCards, local contacts and device contacts separately
2. UX: The goal is to keep everything easy to overview and not scare users with lots of available fields when creating a new contact.

The two remaining fields which might be important coming into my mind are the Organization field, and the Website field. If anyone has other suggestions, or opinions about these two categories, feel free to share your opinion below. Thanks!

Other details

No response

Acknowledgements

• [X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open issue.
• [X] I have written a short but informative title.
• [X] I will fill out all of the requested information in this form.

[dngray]

My thoughts would be that the app should support the ones that are available in com.android.contacts. I'd like to be able to replace that quite old app with this one at some point.

That app has a useful feature, whereby when ORG is set it will show as a company. It is useful to be able to sort companies from contacts at companies. It would also be good if it supported the other items in the DataItem.java constructor.

I'd also look at StructuredNameDataItem.java. You'll see it extends DataItem to include phonetic names. This is useful when you have someone with a foreign sounding name and you want to make sure you pronounce it right when talking to them.

[Bnyro]

As I already said, I don't plan to add all of these fields for the reasons I mentioned above. Many fields are only used very rarely, thus I personally don't aim to add all of them. If anyone wants to take the efforts and create a PR, I'd appreciate it, but I'll limit the remaining ones I'm going to add to two or three, the most important ones, as I personally have never used any that are currently not supported by CY.

[dngray]

If anyone wants to take the efforts and create a PR, I'd appreciate it,

As long as it would be accepted, but yes, I think in general you don't want users to have to have multiple apps managing contacts. I think this app would appeal to users who are looking for a modern replacement to com.android.contacts and likely those are going to be people not using Google's replacements.

Likewise, its not complicating the issue because the ones that are not set simply don't show when adding a contact unless you hit "More fields", which might be worth implementing.

[matchboxbananasynergy]

This might be better in a dedicated issue, as it's not directly related to which fields Connect You should add, but I was thinking:

On top of the few important fields that Connect You can add primary support for, what about another field called "other" or "misc"? The way it would work is that when you import something that's not explicitly supported as a field, it would go under that field.

What this achieves is that it retains all the information one may have accumulated when they're importing contacts, without necessarily requiring Connect You to support every single field.

Is that feasible/desirable?

[dngray]

Personally I'd just support the ones that com.android.contacts, once you've added one, and people can see how that was done, its easy to add others. Another thing to remember is people who use Gmail/Workspace in a business sense often do fill in those other fields, otherwise your contacts become a huge mess very quickly.

When you're dealing with a lot of people in foreign offices/countries and you don't want to say their name wrong, the Phonetic name is an excellent one to have. I use that one actually quite regularly so I don't say Indian names wrong.

ORG is a non-starter, I wouldn't even use an app that didn't show that. I would implement other fields in OrganizationDataItem.java too. Department is especially useful in large organizations.

IM, is nice if you want to put someone's Matrix ID there or something like that. You can set a custom protocol. Relation a lot of old people in my family use because they forget stuff, especially when you know a lot of people, and there's partners and things like that you don't know so well.

[matchboxbananasynergy]

I do see what you're saying. While I do think that com.android.contacts realistically has a lot of outdated stuff (AIM, for crying out loud?!!), the concern here is people moving their contacts over from other apps, in which case we don't want information to be lost by using Connect You.

That said, I also understand Bnyro's point of view about maintainability and the effort it would take to correct implement everything for Connect You's purposes. I do want to ask: would the effort to support those fields be a one-time thing, or a recurring headache? If it's the latter, it's probably not a good idea.

Regarding UX, while I understand that many choices can be jarring, I think that the UI can be designed in such a way where most of the information on the contact creation screen is obstructed and revealed only when the user specifically taps on something, so I think that can be worked around.

[dngray]

outdated stuff (AIM, for crying out loud?!!),

It's really just a generic IM type, with some standard types and a custom one, which can be whatever the user wants. You could put Telegram name in there or whatever you choose. If you really want just only implement the custom one.

the concern here is people moving their contacts over from other apps, in which case we don't want information to be lost by using Connect You.

It shouldn't be, but it just won't be visible.

Bnyro's point of you about maintainability and the effort it would take to correct implement everything for Connect You's purposes.

it is minimal, effort, once implemented, just implement some of the major ones, and you'll get a PR with the rest.

I do want to ask: would the effort to support those fields be a one-time thing, or a recurring headache? If it's the latter, it's probably not a good idea.

One time thing.

[matchboxbananasynergy]

I decided to approach this differently. Instead of looking at com.android.contacts, which is essentially code that has remained mostly untouched for years at this point, I decided to look at Google's official Contacts app (com.google.android.contacts). Looking at the fields that this contacts app contains may give us an overview of what people actually use in a contacts app nowadays, which is what I think Connect You should aim to emulate.

Here's what fields it contains when you try to create a new contact:

By default, without uncollapsing anything:

• First Name
• Surname
• Company
• Phone (with various labels)
• Email (with various labels)
• Significant date (with various labels)

Hidden by a toggle next to "First name":

• Name prefix
• Middle Name
• Name suffix

Hidden under a "more fields" button:

• Phonetic surname
• Phonetic middle name
• Phonetic first name
• Nickname
• Department
• Title
• Address (with various labels)
• Website
• Related person (with various labels)
• SIP
• Notes
• Label (which lets you create a custom label)

If Connect You is to support "everything", this is the "everything" I think it should support, not what was considered important contact information years ago (as is the case for the fields in the AOSP contacts app).

On a related note regarding UX, I can definitely say that even though the list above may seem like a lot, the way Google Contacts implements these fields looks absolutely sleek and not scary at all (because the more specific stuff isn't visible by default, and doesn't get in the way).

@Bnyro How technical would one would have to be to implement these additional fields? I'm fairly certain I wouldn't be able to do it, but I may be mistaken.

[dngray]

I decided to approach this differently. Instead of looking at com.android.contacts, which is essentially code that has remained mostly untouched for years at this point

It hasn't changed because it doesn't need to, so yeah.

On a related note regarding UX, I can definitely say that even though the list above may seem like a lot, the way Google Contacts implements these fields looks absolutely sleek and not scary at all (because the more specific stuff isn't visible by default, and doesn't get in the way).

That's pretty much all the ones except ImDataItem, which is basically the same as "Label (which lets you create a custom label)", they work in basically the same way.

[Bnyro]

@Bnyro How technical would one would have to be to implement these additional fields? I'm fairly certain I wouldn't be able to do it, but I may be mistaken.

The UI, the systems contact API and Vcard support are probably very doable since the code is already well structured and adding a field can be done by looking at how it works for the other fields, however what I fear is making database migrations with Room for the in-app contacts.

[jonaharagon]

I use the Organization/Company field and the Nickname field (because it overrides the displayed name in most apps) very extensively in my contacts, and couldn't live without both myself.

I will also add that I use the Company field both in my regular contacts (to remember where I met people) and in contacts where only the Company field is set (i.e. no First/Last Name), and in that case I'd expect it to show up as a "business contact" like @dngray mentioned.

[Tobias-Lauerbach]

Edit: obsolete:

Label / Groups

Personally (as mentioned in #59) I would appreciate the Label (Contact Groups) field. Because it is a bit more versatile than the Organization field because it is better implemented in other services you might sync your contacts with, for example Nextcloud, and it could give you a way to sort your Contacts. You would also be able to give a person multiple Labels, which makes it easier to organize because you don't have to decide for one. (I know that the sorting would make it more effort to implement, but would make a big usability difference) What do you think about Label vs. Organization if you leave aside the need to change all the existing Contacts for switching? @jonaharagon @dngray Would that also be an option for your use case?

Messenger contacts

It's really just a generic IM type, with some standard types and a custom one, which can be whatever the user wants. You could put Telegram name in there or whatever you choose. If you really want just only implement the custom one.

The only other thing I have a use for is the option to add a Messenger ID / “account name” to the appropriate contact. (for example: ThreemaID or Instagram username) Personally, I don't have an idea or preference for the implementation. And the 'Label' is much more impotent in my use case, and the messenger ID. I also think it is something you might just put in the Notes and also be no problem. (which would lower the importance significantly more)

For the Implementation I agree, that more than two or three would clutter the list and then a prioritization is needed which should be shown by default and which in under a “more”-Option while editing. In the viewing list, I think all information given in the contact should be shown.

[jonaharagon]

That doesn't solve at least one use-case (non-person organization contacts). Supporting standard fields like ORG is also important if you are using Connect You as a replacement for the standard contacts app, because other apps (dialers, etc.) already integrate natively with those fields, because vCard has been around for 20+ years.

That being said, labels would still be good; I just don't see it as an either/or situation.

[dngray]

The only other thing I have a use for is the option to add a Messenger ID / “account name” to the appropriate contact. (for example: ThreemaID or Instagram username)

Instagram would be of type "Website" most likely, least that is where I put things like Twitter etc.

But yes the IM type while it had the AIM type, it also had a "custom" which is basically insert whatever you want and then the ID. I'm pretty sure Threema has a numerical number.

[Tobias-Lauerbach]

Instagram would be of type "Website" most likely, least that is where I put things like Twitter etc.

Yes with web based usernames that would work

But yes the IM type while it had the AIM type, it also had a "custom" which is basically insert whatever you want and then the ID. I'm pretty sure Threema has a numerical number.

Threema has an ID which has a combination of letters and numbers. As I sad I have no real technical knowledge of the IM Type and it was just an example for a way to implement it, it is possible that there are better ways, and I also would be OK with it, if I just need to write it in the notes section.

[Bnyro]

The app now supports organizations, nicknames and websites. Thus, what's not currently supported are the IM field and relations, which I currently don't plan to support as I don't see any use case for them, instead the note field should be used. Thanks to everyone sharing their opinions here, I do really appreciate getting all that feedback.

[matchboxbananasynergy]

The app now supports organizations, nicknames and websites. Thus, what's not currently supported are the IM field and relations, which I currently don't plan to support as I don't see any use case for them, instead the note field should be used. Thanks to everyone sharing their opinions here, I do really appreciate getting all that feedback.

What happens when someone imports a VCF file that does include the missing properties though? Does that information just not populate? I would personally still advocate for feature parity with Google's contacts app, but we definitely have progress here :)

[Bnyro]

What happens when someone imports a VCF file that does include the missing properties though? Does that information just not populate? I would personally still advocate for feature parity with Google's contacts app, but we definitely have progress here :)

Unsupported information is currently not being imported and thus lost when exporting the imported contacts. Your previously mentioned solution to move everything into the notes field might be an idea for the future, however as far as I know Vcards don't support the IM field anyways, not sure about the relations field though.