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.

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

(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.

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.

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

(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?

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

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!

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

(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!

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 :)

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 :)

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

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

(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?

reference comment 14

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 :)

(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).

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.

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.

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

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

Hi all, UX spec updated.

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.

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

Yes, this is a 1.4+ user story.

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.

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

Michal, what are your thoughs about this?

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.

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

features should not block release, remove blocking flag

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

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

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

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