First explainer draft for Contacts Share API #844
Conversation
diekus
changed the title
|
|
||
| * `id`: unique id for the contact. | ||
| * `firstName`: Contact's first name(s). | ||
| * `displayPicture`: url to the display picture of the contact. |
There was a problem hiding this comment.
For versatility (and consistency with the ContactInfo object) what about a Blob instead of a url?
There was a problem hiding this comment.
Yes, that was a consideration I thought about. I left it as url thinking in having a blob url with the image. I will explicitly call out the blob part in the explainer.
| * `firstName`: Contact's first name(s). | ||
| * `displayPicture`: url to the display picture of the contact. | ||
| * `lastName`: Contact's last name(s). | ||
| * `rank`: integer that defines the rank or precedence that a contact has in the list. This could be used by the platform to display top contacts first. |
There was a problem hiding this comment.
Reading the Windows API I see they expose a 'rank' field much like this, but the Android equivalent takes a simpler approach of requiring the provided list of contacts to be ordered in terms of rank (without there being an explicit rank field). Though it's not called out, I expect the Windows side may also give preference to the first provided contact over the last provided contact (when no rank is specified).
What about starting with the simpler approach of just declaring the Contacts list as ordered by rank, and then in the future if a need for more complex ranking arises (e.g. 2 contacts sharing a rank, or bigger gaps in rank), the API can be expanded to take an optional 'rank'.
| #### Contact detailed fields | ||
|
|
||
| * `id`: unique id for the contact. | ||
| * `firstName`: Contact's first name(s). |
There was a problem hiding this comment.
A firstName/lastName split only makes sense in some parts of the world, so typically we try for more generic options. What about starting with only a required 'name' field, and then additional optional variants could be added in the future if needed.
For some context to reference:
The existing Contact web standard, simply has a 'Name' field.
https://w3c.github.io/contact-picker/#contacts-manager
The Android equivalent of this API uses a ShortLabel and LongLabel.
https://developer.android.com/training/sharing/direct-share-targets
The Windows version supports FirstName and LastName, but also supports DisplayName(Override), HonorificNamePrefix/Suffix, MiddleName, Name, Nickname, YomiFamilyName, and YomiGivenName (and a slew of accessors for having the OS smartly select and combine these for you).
https://learn.microsoft.com/en-us/uwp/api/windows.applicationmodel.contacts.contact?view=winrt-26100
| * `displayPicture`: url to the display picture of the contact. | ||
| * `lastName`: Contact's last name(s). | ||
| * `rank`: integer that defines the rank or precedence that a contact has in the list. This could be used by the platform to display top contacts first. | ||
| * `phones`: list of strings that represent phone numbers. |
There was a problem hiding this comment.
For consistency with the ContactInfo object, what about 'tels'. Or maybe naming these singularly, and simply accepting a list?
'tel'
'email'
|
|
||
| ### Registering the Contact as a share target for the installed app | ||
|
|
||
| TODO: investigate how this works on the native side |
There was a problem hiding this comment.
Based on the Windows and Android versions, it seems like the appropriate approach would be a new ShareTargetParams member. Potentially contacts as an array of contact IDs?
https://w3c.github.io/web-share-target/#sharetargetparams-and-its-members
typo fix. thanks Thomas! Co-authored-by: Thomas Steiner <tomac@google.com>
typo fix. thanks Thomas! Co-authored-by: Thomas Steiner <tomac@google.com>
|
|
||
| ## Introduction | ||
|
|
||
| For modern web applications like social networks and instant messaging, contacts are a fundamental part of the app itself. These contacts are specfic to the application, but the platform/OS can benefit from exposing them in different people related surfaces. Contact Sharing for installed web applications allows web apps to surface contacts in relevant UX on the underlying OS. One example can be sharing. Different platforms have different share UX, and some of these UXs include a list of frequent contacts that make sharing content faster with people the user interacts with frequently. |
There was a problem hiding this comment.
It would be great to include some of the thoughts on other non-share ways these contacts will be leveraged to see how well this API design will meet those needs. In particular I'm wondering about how an app should be indicating it supports (or doesn't support) a particular way for this information to be leveraged. (e.g. Should including a telephone number implicitly mean this app supports making phone calls to it? What about supporting making phone calls, but not supporting as a Share target, because you're only a Phone app? etc.)
Creates the folder in MSEdge Explainers that hosts the Contacts Share API.