Closed
Bug 894676
Opened 11 years ago
Closed 11 years ago
[B2G][NFC][User Story]: Support sharing of Contacts
Categories
(Firefox OS Graveyard :: NFC, defect)
Tracking
(feature-b2g:2.0, tracking-b2g:backlog)
VERIFIED
FIXED
People
(Reporter: skamat, Assigned: kchang)
References
Details
(Keywords: feature, Whiteboard: [ucid:NFC3, 2.0, ft:RIL, ft:comms])
User Story
As a user, I would like to share a contact entry with another NFC enabled device (e.g. Mobile device , tablet, laptop). The experience needs to be pretty seamless without having to do much device setup (other than NFC turning ON which is a pre requisite for this case) Acceptance Criteria: 1. with the device NFC set to ON, the act of tapping the devices (with a desired content open on the sending device) should prompt appropriate UX action to share the content. (in this case, contact) 2. There needs to be a visual (or sensory) indication to the user to confirm success or failure. 3. The partner agreements (contracts) for sharing contacts must be respected. (share only allowed info) 4. The sharing should work with FxOS based as well as non FxOS based devices in both directions.
Attachments
(3 files)
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.
Updated•11 years ago
|
Summary: [B2G] [NFC User Story]: Support sharing of Contacts → [B2G][NFC][User Story]: Support sharing of Contacts
Updated•11 years ago
|
Flags: in-moztrap?
QA Contact: wachen
Updated•11 years ago
|
Flags: in-moztrap? → in-moztrap?(wachen)
Updated•11 years ago
|
Whiteboard: [ucid:NFC3]
Comment 1•11 years ago
|
||
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
Flags: needinfo?(echou)
Updated•11 years ago
|
Whiteboard: [ucid:NFC3] → [ucid:NFC3], [FT:RIL]
Comment 2•11 years ago
|
||
(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.
Flags: needinfo?(echou)
Assignee | ||
Updated•11 years ago
|
Assignee | ||
Updated•11 years ago
|
Assignee | ||
Updated•11 years ago
|
Updated•11 years ago
|
Whiteboard: [ucid:NFC3], [FT:RIL] → [FT:RIL, v1.3, ucid:NFC3]
Comment 3•11 years ago
|
||
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•11 years ago
|
||
4. We only focus on vCard format. In this case, we need to define what version of vCard format needs to be supported. Sandip?
Flags: needinfo?(skamat)
Updated•11 years ago
|
Whiteboard: [FT:RIL, v1.3, ucid:NFC3] → [FT:RIL, NFCv1.3, ucid:NFC3]
Comment 5•11 years ago
|
||
(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?
Reporter | ||
Comment 6•11 years ago
|
||
Please focus on Vcard format 2.1 for now. That's what we have in current launches.
Flags: needinfo?(skamat)
Updated•11 years ago
|
blocking-b2g: --- → 1.3+
Comment 7•11 years ago
|
||
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!
Flags: needinfo?(skamat)
Depends on: 906579
No longer depends on: 860907
Comment 8•11 years ago
|
||
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
Blocks: comms_1.3_targeted
Reporter | ||
Comment 9•11 years ago
|
||
(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!
Flags: needinfo?(skamat)
Updated•11 years ago
|
Whiteboard: [FT:RIL, NFCv1.3, ucid:NFC3] → [FT:RIL, 1.3:p1, ucid:NFC3]
Comment 10•11 years ago
|
||
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•11 years ago
|
||
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 :)
Assignee | ||
Updated•11 years ago
|
Blocks: b2g-nfc-ux
No longer depends on: 897312
No longer depends on: 902051
No longer depends on: 906579
Comment 12•11 years ago
|
||
Remove blocking-b2g flag from User Story bugs. Use whiteboard to indicate what FxOS version we target.
blocking-b2g: 1.3+ → ---
Updated•11 years ago
|
Whiteboard: [FT:RIL, 1.3:p1, ucid:NFC3] → [FT:RIL, 1.3:p2, ucid:NFC3]
Comment 13•11 years ago
|
||
Interaction spec updated: access detail view instead of edit mode when receive Vcard.
Comment 14•11 years ago
|
||
(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 16•11 years ago
|
||
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 :)
Flags: needinfo?(jhuang) → needinfo?(jcheng)
Comment 17•11 years ago
|
||
(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).
Flags: needinfo?(jmcf)
Comment 18•11 years ago
|
||
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•11 years ago
|
||
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.
Updated•11 years ago
|
Flags: needinfo?(jcheng)
Comment 20•11 years ago
|
||
all the info that comes specifically from FB: email, tel number, photo, address, birthday cannot be shared outside.
Flags: needinfo?(jmcf)
Comment 21•11 years ago
|
||
Update whiteboard tag to follow format [ucid:{id}, {release}:p{1,2}, ft:{team-id}]
Whiteboard: [FT:RIL, 1.3:p2, ucid:NFC3] → [ucid:NFC3, 1.3:p2, ft:RIL]
Comment 23•11 years ago
|
||
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•11 years ago
|
||
https://moztrap.mozilla.org/manage/cases/?pagenumber=1&pagesize=20&sortfield=created_on&sortdirection=desc&filter-tag=2287&filter-suite=419
Flags: in-moztrap?(wachen) → in-moztrap+
Updated•11 years ago
|
Assignee: nobody → kchang
Whiteboard: [ucid:NFC3, 1.3:p2, ft:RIL] → [ucid:NFC3, 1.4:p2, ft:RIL]
Updated•11 years ago
|
Blocks: 1.4-comms-committed
blocking-b2g: --- → 1.4?
Assignee | ||
Updated•11 years ago
|
Blocks: 1.4-RIL/Net/Conn
Assignee | ||
Updated•11 years ago
|
No longer blocks: 1.4-RIL/Net/Conn
Reporter | ||
Comment 25•11 years ago
|
||
Notes from partner meetings: This user story is mandated for 1.4 release.
Updated•11 years ago
|
Whiteboard: [ucid:NFC3, 1.4:p2, ft:RIL] → [ucid:NFC3, 1.4, ft:RIL]
Target Milestone: --- → 1.4 S1 (14feb)
Comment 27•11 years ago
|
||
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.
Flags: needinfo?(aymanmaat)
Comment 28•11 years ago
|
||
Michal just commented me that this transition is already implemented at system level \o/
Comment 29•11 years ago
|
||
Michal, what are your thoughs about this?
Flags: needinfo?(aymanmaat) → needinfo?(mbudzynski)
Comment 30•11 years ago
|
||
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.
Flags: needinfo?(mbudzynski)
Comment 31•11 years ago
|
||
we should not mark feature work with blocking-b2g flag.
blocking-b2g: 1.4+ → backlog
Comment 32•11 years ago
|
||
features should not block release, remove blocking flag
blocking-b2g: backlog → ---
Updated•11 years ago
|
Whiteboard: [ucid:NFC3, 1.4, ft:RIL] → [ucid:NFC3, 1.4, ft:RIL, ft:comms]
Updated•11 years ago
|
Target Milestone: 1.4 S1 (14feb) → 1.4 S2 (28feb)
Updated•11 years ago
|
No longer blocks: 1.4-comms-committed
Updated•11 years ago
|
Target Milestone: 1.4 S2 (28feb) → ---
Comment 33•11 years ago
|
||
As bug 903245 landed, this user story supposedly can be tested. ni? Walter for early testing.
Status: NEW → RESOLVED
Closed: 11 years ago
Flags: needinfo?(wachen)
Resolution: --- → FIXED
Updated•11 years ago
|
Whiteboard: [ucid:NFC3, 1.4, ft:RIL, ft:comms] → [ucid:NFC3, 2.0, ft:RIL, ft:comms]
Comment 34•11 years ago
|
||
I think I will test this with Alison today(4/15)
Flags: needinfo?(wachen) → needinfo?(ashiue)
Comment 35•11 years ago
|
||
Test fail on most up-to-date pvt build (2014/4/14), issue recorded in bug 996527
Updated•11 years ago
|
Flags: needinfo?(ashiue)
Updated•11 years ago
|
blocking-b2g: --- → backlog
Reporter | ||
Updated•10 years ago
|
User Story: (updated)
Updated•10 years ago
|
feature-b2g: --- → 2.0
Comment 36•10 years ago
|
||
Verified on Gaia 2c6c413ed729d465c52d6c2d5d458e2eee79e956 Gecko https://hg.mozilla.org/releases/mozilla-aurora/rev/d32649a24965 BuildID 20140714160201 Version 32.0a2
Status: RESOLVED → VERIFIED
Updated•10 years ago
|
blocking-b2g: backlog → ---
tracking-b2g:
--- → backlog
You need to log in
before you can comment on or make changes to this bug.
Description
•