It’s rare that I get feedback like this about a feature I owned for a decade.
1) The vast majority of users have only one contact-sync account, so it’s not an issue for them, merge works fine
2) For users that have multiple contact-sync accounts, they almost never want a feature to silently choose one account’s contact and delete the other account’s contact. So linking is really what these users want if the contacts live in different accounts.
It’s interesting feedback that a combined “link or merge” command would be what you’d expect. That’s a reasonable request; in my day we generally steered clear of combining destructive operations (merging) with non-destructive (linking).
I was more focused on the fact that the macOS implementation of “look for duplicates” is pretty broken; there’s a decent iOS implementation we never got around to migrating to macOS.
Don't get me wrong, I don't have an issue with linking. I think that's the correct solution.
In fact, it's kinda the only solution unless you can push info upstream, and you shouldn't assume you have those privileges or even know their data structure. But that doesn't matter because what the user cares about is how the information is displayed.
It is primarily a display issue. No deletions needed
The critical issue is I, the user, can't identify if these two contacts are in the same address book or not. The only way I can find this out is to guess and check. I have to guess the address book and then search that name, then repeat. That's not a reasonable solution nor does it scale. It's trivially solvable too. Just tell the user what address book a contact belongs to!
That's what leads to the confusion. All the program is telling me is that there are two contacts with the same name, nickname, phone number, and birthday. But the contacts differed on email and notes. The UI feedback tells me "Apple doesn't know how to do a trivial database query" not "Apple doesn't want to destructively merge these contacts because they are in different address books." That is actually not an obvious thing and I chased multiple other issues first. This is especially bad because in my calendar I had 3 entries for this person's birthday and 3 contacts. 2 were linked to my iCloud address book and 1 to Google (by ctrl clicking on the date, but maybe (in hindsight) that's not actually accurate). I somehow got it down to two, which resulted in 4 birthdays on my calendar! That actually created a false flag because now the icons showed as of 1 was from google and now 3 from iCloud, with all 3 no longer linking to a contact. The feedback the programs are giving me is "Apple can't merge tables", right? Or at least that's a reasonable interpretation.
I think theres a relatively simple solution to this. 1) indicate on the contact card which address book the contact belongs to. 2) "Find duplicates" queries across address books. Present the option "link contacts" instead of "merge". It's obviously reasonable that a user would want this as you have that capability for a reason. I honestly think "merge" could be "link" in most cases, because depending on the data structure those will be equivalent (you reference a node. That node has children pointing to the different tables). I agree, you shouldn't delete data, but there's also likely no reason to (yes delete if you have duplicate pointers pointing to the same object unless these pointers are aliases)
The same idea applies to calendar events. I missed a ton of events when I first switched to an iPhone because I'll look at my calendar and see 3 copies of "Columbus Day" and 1 "Indigenous People's Day" (Apple does both!) and not what I had scheduled for 10am. The only solution I have is to disable the holiday tables from my Google calendar and outlook. Effectively that's "deleting" data. This looks like a fine solution but those calendars aren't identical. As a user I want the union. I want deduplication. Because who wants redundant information? It's clearly not something the user is intending (at least in this case). That's going to be true for things like birthdays too (which I'd be happy to import). Apple doesn't even distinguish that as a separate table for my Google calendar so I'm stuck with dupes.
Effectively it is a display issue. As a user that's what's critical to me because that's what makes the program useful. As a programmer, yeah, I care about details but my tech illiterate parents don't.
1) The vast majority of users have only one contact-sync account, so it’s not an issue for them, merge works fine
2) For users that have multiple contact-sync accounts, they almost never want a feature to silently choose one account’s contact and delete the other account’s contact. So linking is really what these users want if the contacts live in different accounts.
It’s interesting feedback that a combined “link or merge” command would be what you’d expect. That’s a reasonable request; in my day we generally steered clear of combining destructive operations (merging) with non-destructive (linking).
I was more focused on the fact that the macOS implementation of “look for duplicates” is pretty broken; there’s a decent iOS implementation we never got around to migrating to macOS.