894676 - [B2G][NFC][User Story]: Support sharing of Contacts

Status: VERIFIED FIXED

(Firefox OS Graveyard :: NFC, defect)

Description

[Sandip Kamat]

The user can share content to another NFC enabled device (e.g. Mobile device , tablet, laptop) either directly via NFC or via a BT connection initiated by NFC.1)     The user can select a contact and then share it via NFC to another device by tapping the mobile device with another NFC enabled device. Transfer of contact vcard takes place directly over NFC.
a) The user selects a contact and then selects “Share contact” from a contextual menu.
b) The user taps the device with another NFC enabled device.
c) On the receiving mobile, the device will get a prompt saying “Another device wants to share a contact with you – Accept/Reject” or something similar.
d) Any vcard received is opened up in the contact edit page, so that the user can save it any of the accounts that the user has for PIM service providers.

Comment 1

[Walter Chen[:ypwalter][:wachen]]

1. User can see an option in menu to share contacts
2. When NFC is on and BT is off, user can share contact information with others, and user won't be prompt to enable BT
3. When NFC and BT are on, user can share contact information with others.
4. Accepting user can see prompt to accept or not to accpet the contact information.
5. User should be able to share mutiple contacts at once
****BT doesn't have such support now. Need to discuss with Ken and BT team
6. contacts received should be displayed correctly in receiver's device (no information missing)
7. User can see a contact edit page/list after received the contact information.
8. non Firefox OS device with NFC function enable should be tested with ffox device

PS.**** need BT team input, except multiple contacts, I also want to check for multiple "videos" capabilities

Comment 2

[Eric Chou [:ericchou] [:echou]]

(In reply to Walter Chen from comment #1)
> 1. User can see an option in menu to share contacts
> 2. When NFC is on and BT is off, user can share contact information with
> others, and user won't be prompt to enable BT
> 3. When NFC and BT are on, user can share contact information with others.
> 4. Accepting user can see prompt to accept or not to accpet the contact
> information.
> 5. User should be able to share mutiple contacts at once
> ****BT doesn't have such support now. Need to discuss with Ken and BT team
> 6. contacts received should be displayed correctly in receiver's device (no
> information missing)
> 7. User can see a contact edit page/list after received the contact
> information.
> 8. non Firefox OS device with NFC function enable should be tested with ffox
> device
> 
> PS.**** need BT team input, except multiple contacts, I also want to check
> for multiple "videos" capabilities

Gecko Bluetooth has been capable of letting users share multiple files at a time since bug 817972. Walter, you could try to choose multiple photos and share in Gallery app of the latest Gaia:master and Gecko:m-c.

Comment 3

[Kai-Chih Hu [:khu]]

Based on the discussion with DT during the NFC work week: 

1. We won't need Bluetooth connection. 
2. We only focus on single contact sharing. 
3. We need to open 2 different engineering bugs: one for sending, another for receiving. We need both engineering bugs to be completed for v1.3 together.

Comment 4

[Kai-Chih Hu [:khu]]

4. We only focus on vCard format. In this case, we need to define what version of vCard format needs to be supported. Sandip?

Comment 5

[Kai-Chih Hu [:khu]]

(In reply to khu from comment #4)
> 4. We only focus on vCard format. In this case, we need to define what
> version of vCard format needs to be supported. Sandip?

IMO, we can fit the version we are supporting now. Sandip, what's your take here?

Comment 6

[Sandip Kamat]

Please focus on Vcard format 2.1 for now. That's what we have in current launches.

Comment 7

[Juwei Huang[:juwei]]

Hi Sandip,
I have some questions in the flow:
a) is the same question as sharing video/image via NFC, it would be redundant that we have one more step before physically pairing the devices.

c) is the same question as sharing URL via NFC, it might doesn't need to accept/reject the received Vcad since the users have already taped their device together.

Hope you won't feel too bothersome for my questions:)
Feel free to let me know any thoughts!

Comment 8

[Wilfred Mathanaraj [:WDM]]

Due to the discussion ongoing on this bug on the UI flow this bug is currently on the nice to have list of comms for v1.3

Comment 9

[Sandip Kamat]

(In reply to Juwei Huang from comment #7)
> Hi Sandip,
> I have some questions in the flow:
> a) is the same question as sharing video/image via NFC, it would be
> redundant that we have one more step before physically pairing the devices.

Answered the other bug 894320 as well. Let's keep it tap and share (with shrinking UI).

> 
> c) is the same question as sharing URL via NFC, it might doesn't need to
> accept/reject the received Vcad since the users have already taped their
> device together.

We do need that so users do not accidentally end up accepting entries.

> 
> Hope you won't feel too bothersome for my questions:)
> Feel free to let me know any thoughts!

Comment 10

[Juwei Huang[:juwei]]

Attachment: [NFC] Pairing Vcard_20130930.pdf

Hi Sandip,
It's the same issue as URL sharing, please refer to the comment I replied in bug 894678
And I've made a version without the step accept/reject, please have a look and let me know your opinion :)

Comment 11

[Francisco Jordano [:arcturus] [:francisco]]

Hi folks,

contacts is already working with vcard.

So far we are able to read any format, so you could reuse (it's in the shared folder) that parser, but we just write (yes, we have another component to generate vcard \o/) but in format 4.0

To add a bit of knowledge on how we do the contact share via bluetooth, we generate a vcard file and the send it through the bluetooth interface, in the other end, when we receive a vcard, we call a web activity in contacts that will take care of importing as many contacts as you can find on the vcard file.

Hope that helps :)

Comment 12

[Kai-Chih Hu [:khu]]

Remove blocking-b2g flag from User Story bugs. Use whiteboard to indicate what FxOS version we target.

Comment 13

[Juwei Huang[:juwei]]

Attachment: [NFC] Pairing Vcard_20131118.pdf

Interaction spec updated: access detail view instead of edit mode when receive Vcard.

Comment 14

[ayman maat :maat]

(In reply to Juwei Huang from comment #13)
> Created attachment 8333653 [details]
> [NFC] Pairing Vcard_20131118.pdf
> 
> Interaction spec updated: access detail view instead of edit mode when
> receive Vcard.

Hi Juwei

Thanks for the latest copy of the NFC wireframes. I have two areas that I would like raise:

1) Sending multiple contacts.
I see that there is no facility to use NFC to send multiple contacts at the same time (as we do in BT). Can you confirm if this is a requirement for V1.3 or a forthcoming requirement and if so in which version can we expect to see this functionality?

2) Facebook data
There is no indication in the latest wireframe pack of how we are handling linked and unlinked Facebook contact data. It should be noted that, due to privacy, we do not allow the sharing / exporting of Facebook data that is integrated into the contact list. Facebook data can existing in the contact list in two states:

2.1) unlinked contact
This is a contact in the contact list that is solely comprised of Facebook data. No data from this contact can be shared / exported.

2.2) linked contact
This is a contact in the contact list that is comprised of a combination of Facebook data and data that is either manually entered by the user via FFOS or imported from another source and linked to existing Facebook contact data on the OS. In this situation all data can be sharing / exporting *except* that belonging to Facebook.

- How are you proposing to notify a user that either a whole contact or a sub set of data associated to a contact cannot be shared by NFC. 
- What impact will the the fact that a sub set of data associated to a contact cannot be shared by NFC being that they will not be sending the contact data as displayed on the screen?

Comment 15

[ayman maat :maat]

reference comment 14

Comment 16

[Juwei Huang[:juwei]]

Hi Ayman, thanks for your feedback:)

For 1) I'm sure that we only support one contact share in v1.3. For multiple contacts sharing, it's reasonable for BT. But for NFC, I don't recommend to align the same feature since BT sharing & NFC sharing are under quite different scenarios.
In NFC scenario, the advantage and beautiful part is the immediacy and directness of sharing information by physically putting two phones together without wasting of time for pairing.
If users want to share one contact via NFC, they will put the phone back-to-back together and move up the screen to trigger transfer process. If we apply multi-sharing experience to NFC, I suppose users will keep the back-to-back position until they select their desired contacts and trigger the NFC transfer. It looks like a too-long process for users to transfer files under such position. So I highly recommend to keep NFC transfer as simple as possible, try not to apply any feature that needs more than two steps.


For 2), I apologize that I didn't make a clear description on spec. As for your concern about Facebook privacy issue, I'll double check with Joe (EPM of contact app) about how we manipulate Facebook data. 
However, in the perspective of UX, the privacy of local data is not less important than Facebook data. It would be pointless that users can share local data but cannot share FB data since these data are all display in device and belong to users. It is same as importing data from Gmail or any other servers. Furthermore, if we try to divide contacts as "Facebook-linked" contacts & "Facebook-unlinked" contacts, it would be very confuse & frustrated to users that why some contacts can be shared but some cannot.

BUT, if we are definitely not allow to share FB data under any circumstances, I got two proposals for sharing the solely Facebook-linked data:
1. Invalid to share: tap the device together will not trigger NFC.
2. Fail to share with a toast: The contact is still available to trigger NFC, but it would be fail to transfer with a toast that indicate FB data is not allow to share.
For the contact that combine with Facebook & local data, share the local data only and along with a toast indicates Facebook data is unavailable to share.

Hi Joe, could you provide more information about Facebook data privacy? thanks :)

Comment 17

[Fernando Campo (:fcampo)]

(In reply to Juwei Huang from comment #16)
> BUT, if we are definitely not allow to share FB data under any
> circumstances, I got two proposals for sharing the solely Facebook-linked
> data:
> 1. Invalid to share: tap the device together will not trigger NFC.
> 2. Fail to share with a toast: The contact is still available to trigger
> NFC, but it would be fail to transfer with a toast that indicate FB data is
> not allow to share.
> For the contact that combine with Facebook & local data, share the local
> data only and along with a toast indicates Facebook data is unavailable to
> share.
> 
> Hi Joe, could you provide more information about Facebook data privacy?
> thanks :)

The problem that we have is that Facebook doesn't allow to share CERTAIN information with others (my understanding is that it's part of the agreement we have with them, maybe Jose Manuel Cantera -ni?- can provide more accurate information), including phone and address AFAIK. So this is more a legal restriction than a privacy thing for us (part of FB privacy I guess), and not comparable to sharing info taken from other services, as the data doesn't belong to the user.
So we could get a situation where most of the information we have for a contact is local (name, address, birthday), email comes from gmail import, but phone number is coming from facebook. In that case, we could share everything but the phone (which seems weird).

Comment 18

[Stephany Wilkes]

This appears to be another example of conversation about specs pointing out a need for more detailed requirements and understanding of constraints. Facebook does, as we have known from prior meetings, restrict the information that is shared. That constrains certain designs, and we should be very clear on that before proceeding. User stories are likely also affected.

I think there's enough here to indicate that Comms UX should meet with Comms PM to understand the scope and constraints here before going further with design. 

Also, it is not ideal to have extensive design conversations in Bugzilla, as they tend to get buried or lost in a single bug that others may not see or be able to find. Juwei and Ayman, we must make sure to add this to specs themselves. Jacqueline is lead UX for Comms and isn't even on this bug, for instance, so I'll make sure she's aware of this issue.

Comment 19

[GoodMike]

Yes, I agree with Stephany. I suggest the conversations should go to Comms UX team first on the proper user experience discussion and sync with comms PM on the scope.

Comment 20

[Jose Manuel Cantera]

all the info that comes specifically from FB: email, tel number, photo, address, birthday cannot be shared outside.

Comment 21

[Jean Gong :jgong]

Update whiteboard tag to follow format [ucid:{id}, {release}:p{1,2}, ft:{team-id}]

Comment 22

[Juwei Huang[:juwei]]

Attachment: [NFC] Pairing Vcard_20131202.pdf

Hi all,
UX spec updated.

Comment 23

[(inactive after 6/18) Alive Kuo [:alive]]

Hi,

If we want to implement page.8 item 3., I propose:
(1) Contact registers nfc-manager permission
(2) Contact listens to onpeerfound event and
    1. Remove the onpeerready callback once we're now in facebook contact page.
    2. Add the onpeerready callback once we're now in other contact page.
(3) Contact should remove onpeerready callback once we're in list view.

Comment 24

[Walter Chen[:ypwalter][:wachen]]

https://moztrap.mozilla.org/manage/cases/?pagenumber=1&pagesize=20&sortfield=created_on&sortdirection=desc&filter-tag=2287&filter-suite=419

Comment 25

[Sandip Kamat]

Notes from partner meetings: This user story is mandated for 1.4 release.

Comment 26

[Ken Chang[:kenkai]]

Yes, this is a 1.4+ user story.

Comment 27

[Francisco Jordano [:arcturus] [:francisco]]

Hi folks,

I've been retaking a look to the WF (I know a bit late), but I'm concern about the implementation of the transformation.

Basically, I think with current devices that transformation is gonna be quite chunky, specially with contacts app, since we have to load a lot of DOM (even if we already separated by views, to get there you need to load a lot).

Also, IMHO, wait for > 1.5 version would be good for us, we will have better devices, we will have contacts totally separated and doing that kind of stuff will be way easier.

For me, again IMHO, is to deliver a simple version of the sharing (perhaps a button when we detect the NFC), and evolve to that awesome design when contacts get better performance.

Cheers!
F.

Comment 28

[Francisco Jordano [:arcturus] [:francisco]]

Michal just commented me that this transition is already implemented at system level \o/

Comment 29

[Francisco Jordano [:arcturus] [:francisco]]

Michal, what are your thoughs about this?

Comment 30

[Michał Budzyński (:michalbe)]

So apparently this is implemented on the system level (/shrinking_ui.js), so we will implement nfc sharing as described in the wireframe document. Sorry for misunderstanding, it was my fault.

Comment 31

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

we should not mark feature work with blocking-b2g flag.

Comment 32

[Joe Cheng [:jcheng] (please needinfo)]

features should not block release, remove blocking flag

Comment 33

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

As bug 903245 landed, this user story supposedly can be tested. ni? Walter for early testing.

Comment 34

[Walter Chen[:ypwalter][:wachen]]

I think I will test this with Alison today(4/15)

Comment 35

[Alison Shiue]

Test fail on most up-to-date pvt build (2014/4/14), issue recorded in bug 996527

Comment 36

[Alison Shiue]

Verified on
Gaia      2c6c413ed729d465c52d6c2d5d458e2eee79e956
Gecko     https://hg.mozilla.org/releases/mozilla-aurora/rev/d32649a24965
BuildID   20140714160201
Version   32.0a2