Closed
Bug 894320
Opened 11 years ago
Closed 11 years ago
[B2G][NFC][User Story]: Support sharing of Image/Video content
Categories
(Firefox OS Graveyard :: NFC, defect)
Tracking
(feature-b2g:2.0, tracking-b2g:backlog)
VERIFIED
FIXED
People
(Reporter: kchang, Assigned: kchang)
References
Details
(Keywords: feature, Whiteboard: [ucid:NFC5, 2.0, ft:RIL])
User Story
As a user, I would like to share an image or a video and share it seamlessly to another NFC enabled mobile device by tapping the mobile. Acceptance Criteria: 1. Device has NFC enabled and upon tapping devices, pairs with another NFC device and provides a UX to share. 2. Tapping may causes NFC to initiate a BT pairing with the other device (so sharing via BT), but that process will be seamless (no need any user interaction.) 3. If the sharing works successfully (or fails), the device will show the appropriate visual or sensory (vibration) indication. (see UX spec) 4. The receiving device will open an appropriate app to receive that content. 5. This sharing should work with FxOS devices as well as non-FxOS devices (if they support URL sharing).
Attachments
(2 files)
The user can select an image or a video and share it to another NFC enabled mobile device by tapping the mobile. a) The user can select an image/video and select “Share image or video” from the contextual menu. b) Tapping another device (while trying to share an image or video) causes NFC to initiate a BT pairing with the other device. c) The image/video content is shared via BT (OPP/OBEX?) d) If BT is turned off, the device will prompt the user to turn on BT. Once the user turns on BT, the BT pairing will take place
Assignee | ||
Updated•11 years ago
|
Component: General → NFC
Comment 2•11 years ago
|
||
Setup WiFi/BT file transfer via NFC, and transfer media P2P over faster temporary secondary connection. Current solutions seem incompatible, based on the android beam description above. Concerning currently implemented code, if a specific mime-type can be defined on a "SmartPoster Action" NDEF formatted message, then it's possible with some extra code from the NFC perspective (ndefPush). The combination with a negotiated BT or WiFi based connection will need some discussion.
Assignee | ||
Updated•11 years ago
|
Summary: [User story][NFC]Share the image/video to another NFC enabled mobile device by tapping the mobile. → [B2G] [NFC User Story]: Support sharing of Image/Video content
Updated•11 years ago
|
Summary: [B2G] [NFC User Story]: Support sharing of Image/Video content → [B2G][NFC][User Story]: Support sharing of Image/Video content
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:NFC5]
Comment 4•11 years ago
|
||
Ken, one question for you. What do you mean by tapping the mobile? Can you be more specific in user story? Maybe "connecting to another NFC enabled device" is suitable?
Flags: needinfo?(kchang)
Comment 5•11 years ago
|
||
Also, is it better to divide large user stories into small ones since there are lots of big user stories in NFC? :P
Comment 6•11 years ago
|
||
(In reply to Walter Chen from comment #5) > Also, is it better to divide large user stories into small ones since there > are lots of big user stories in NFC? :P Walter, Larger user stories like this can be divided into smaller ones and this bug will be tracking them as a meta bug.
Comment 7•11 years ago
|
||
(In reply to Walter Chen from comment #4) > Ken, one question for you. What do you mean by tapping the mobile? Can you > be more specific in user story? Maybe "connecting to another NFC enabled > device" is suitable? tapping is a common phrase used for NFC use cases. "Connecting to ..." has different connotations.
I wanted to offer some general comments regarding NFC that hopefully will help to tighten the user stories. NFC (Near Field Communication) is only intended for short ranges up to 2, 3 inches (unlike its cousin RFID that operates over several feet). The idea of NFC is that "an action in the real world triggers an action in the virtual world." An action in the real world could be to hold an NFC-enabled phone close to a passive NFC tag or holding two NFC-enabled phones close to each other. Sometimes this is referred to as "tapping" that also highlights the briefness of the interaction. Holding two phones next to each other is usually referred to as Peer-to-Peer (Android calls this "Beam"). Another important principle of NFC is the so-called 'frictionless setup': the user should not have to configure anything for something to happen. Unlike Bluetooth, NFC does not require any pairing. The action that is triggered in the 'virtual world' is dependent on the data that is exchanged during an NFC-interaction. There is an emerging data format called NDEF (NFC Data Exchange Format) that roughly speaking contains a message type and a payload. A message type could be "smart poster" and the payload the URI. The message type is used at the receiver to automatically trigger the (virtual) action (e.g., a tag containing a smart poster URI will launch the browser; a tag containing a phone number will automatically launch the dialer). The idea is that every application defines its own type and the OS will use this type to dispatch incoming messages to the appropriate application (e.g., via MozActivity). Note that NFC tags have very limited storage capacity (a common tag such as the Mifare Ultralight C has only 192 bytes of storage). This means that an image can typically not stored on a tag; only the URI to an image that is stored somewhere else.
(In reply to Ken Chang from comment #0) Some remarks to Ken's initial post: a NFC tag can only store very little data. Images or videos need to be stored somewhere else (e.g., an external web server) and what is exchanged via NFC is the URI. It might be possible to exchange Bluetooth pairing information via NFC and do the actual data transfer via Bluetooth. The origin of a NFC message can either be a (passive) tag that is attached somewhere (e.g., next to a painting) or another phone (Beam/P2P). If there is only one application on the receiving side that can handle an incoming message (e.g., phone number) the appropriate application will be launched immediately (e.g., dialer). If two or more applications handle the same message type, the "Application Chooser" dialog should appear. On the sending side: the application currently in the foreground will determine the content to be sent (e.g., if the browser is in the foreground, a URI will be sent; if Contacts is in the foreground, a VCARD will be sent). To trigger the beam/P2P operation, the user should explicitly authorize the sending through some action (Android will 'shrink' the UI to indicate that a message is about to be sent. The user has to approve by tapping on the screen).
Assignee | ||
Comment 10•11 years ago
|
||
(In reply to Walter Chen from comment #5) > Also, is it better to divide large user stories into small ones since there > are lots of big user stories in NFC? :P Here is the video for reference. http://www.youtube.com/watch?v=fKNlfJ7YiCM.
Flags: needinfo?(kchang)
Comment 11•11 years ago
|
||
(In reply to Ken Chang from comment #10) > Here is the video for reference. > http://www.youtube.com/watch?v=fKNlfJ7YiCM. Note that the sharing shown in this video is done by a third-party app call File Expert: https://play.google.com/store/apps/details?id=xcxin.filexpert In the video NFC is used to configure an ad-hoc connection between two phones via Bluetooth. Looking at the current description of File Expert, they seem to have switched from Bluetooth to Wifi Direct. I would like to know if the user stories should only cover the core NFC functionality or also that of third party apps. I wonder if we shouldn't focus on NFC API but leave it to web developers to develop apps that make use of this API.
Comment 12•11 years ago
|
||
Hi, In our NFC discussion on July 25, Dimi presented some ideas on the implementation of various use cases, including this one. As far as I understand, sharing an image via NFC currently means that the user selects 'Share via NFC' in the UI and the actual transfer is done over a Bluetooth connection. The steps roughly are that - the user selects 'Share via NFC', - he/she connects the devices by tapping, - both devices do connection hand-over to Bluetooth, - the data is transfered via Bluetooth, and - EOT. During the discussion I mentioned that this seems complicated and 'upside down'. I also see the problem of selecting the correct channel during hand-over, such as - How do we select between WIFI, Bluetooth, and maybe other data channels? Devices probably need to tell each other. - What to do if the other peer does not support our data channels? - How do we handle failures on the data channel? - If we display error messages, wouldn't it be confusing to the user to receive a Bluetooth error message when he/she selected NFC for transmission? Instead I'd propose the following scheme where - the user selects 'Share via Bluetooth', - the phone shows a Bluetooth pairing dialog were the user has the option of pairing devices via NFC, - it transfers the data to the paired device, and - EOT. Basically we'd turn this bug into a special case of bug 894672. This solves a good part of the technical problems I mentioned above (i.e., data channel discovery), is less effort to implement, and also more transparent to the user. Best regards Thomas
Comment 13•11 years ago
|
||
Just researching this feature from a UX perspective and have a few questions and comments to add to the discussion. (In reply to Thomas Zimmermann [:tzimmermann] [:tdz] from comment #12) .. snip .. > As far as I > understand, sharing an image via NFC currently means that the user selects > 'Share via NFC' in the UI and the actual transfer is done over a Bluetooth > connection. The steps roughly are that > > - the user selects 'Share via NFC', > - he/she connects the devices by tapping, > - both devices do connection hand-over to Bluetooth, > - the data is transfered via Bluetooth, and > - EOT. From what I see in tutorials, it looks like there is no "pairing" step at all for the user to initiate a transfer nor is there a way to select which type of connection the transfer happens over. The only thing that is needed is for NFC and Android Beam (or S-beam in the case of Galaxy models) to be turned On and the phones placed back to back to initiate the transfer. On android devices with NFC/Beam/S-beam enabled: - sharing user opens gallery image, web page or contact to transfer. - Phones are put back-to-back. - A UI is displayed on transmitting phone and a "Tap to send" dialogue is displayed. - the data is transferred. You can see this work here: Android Beam: http://www.youtube.com/watch?v=cwU4TvQEq0g S-beam: http://www.youtube.com/watch?v=MItjKitDUlI The UX for both these are very much similar. > During the discussion I mentioned that this seems complicated and 'upside > down'. I also see the problem of selecting the correct channel during > hand-over, such as > > - How do we select between WIFI, Bluetooth, and maybe other data channels? > Devices probably need to tell each other. Android beam works using Bluetooth. S-beam works using Wifi for faster file transfers. It is proprietary and works with Samsung devices only. We need to decide what devices/OS's we want to be compatible with. Some details on compatibility here: http://android.stackexchange.com/questions/26509/whats-the-difference-between-android-beam-vs-s-beam > - What to do if the other peer does not support our data channels? > - How do we handle failures on the data channel? > - If we display error messages, wouldn't it be confusing to the user to > receive a Bluetooth error message when he/she selected NFC for transmission? > The whole point of NFC is to avoid any of these sort of failures. > Instead I'd propose the following scheme where > > - the user selects 'Share via Bluetooth', > - the phone shows a Bluetooth pairing dialog were the user has the option > of pairing devices via NFC, > - it transfers the data to the paired device, and > - EOT. We should follow the existing UX patterns that other phones with NFC beam capabilities have. Thanks!
Comment 14•11 years ago
|
||
Flagging product for information on what compatibility we are expecting for NFC sharing. Android Beam? Samsung S-beam? Both Android Beam + Samsung S-beam, or just FirefoxOS only. (see Comment 13 for details of differences)
Flags: needinfo?(ffos-product)
Comment 15•11 years ago
|
||
(In reply to Casey Yee [:cyee] from comment #13) Hi Casey, Thanks for your detailed reply. From the current discussion it wasn't clear to me that we're going to use Android Beam or some similar technology. Great if we can avoid the mentioned problems this way. Best regards Thomas > Just researching this feature from a UX perspective and have a few questions > and comments to add to the discussion. > > (In reply to Thomas Zimmermann [:tzimmermann] [:tdz] from comment #12) > .. snip .. > > As far as I > > understand, sharing an image via NFC currently means that the user selects > > 'Share via NFC' in the UI and the actual transfer is done over a Bluetooth > > connection. The steps roughly are that > > > > - the user selects 'Share via NFC', > > - he/she connects the devices by tapping, > > - both devices do connection hand-over to Bluetooth, > > - the data is transfered via Bluetooth, and > > - EOT. > > From what I see in tutorials, it looks like there is no "pairing" step at > all for the user to initiate a transfer nor is there a way to select which > type of connection the transfer happens over. The only thing that is needed > is for NFC and Android Beam (or S-beam in the case of Galaxy models) to be > turned On and the phones placed back to back to initiate the transfer. > > On android devices with NFC/Beam/S-beam enabled: > - sharing user opens gallery image, web page or contact to transfer. > - Phones are put back-to-back. > - A UI is displayed on transmitting phone and a "Tap to send" dialogue is > displayed. > - the data is transferred. > > > You can see this work here: > Android Beam: http://www.youtube.com/watch?v=cwU4TvQEq0g > S-beam: http://www.youtube.com/watch?v=MItjKitDUlI > > The UX for both these are very much similar. > > > During the discussion I mentioned that this seems complicated and 'upside > > down'. I also see the problem of selecting the correct channel during > > hand-over, such as > > > > - How do we select between WIFI, Bluetooth, and maybe other data channels? > > Devices probably need to tell each other. > > Android beam works using Bluetooth. > > S-beam works using Wifi for faster file transfers. It is proprietary and > works with Samsung devices only. > > We need to decide what devices/OS's we want to be compatible with. > > Some details on compatibility here: > http://android.stackexchange.com/questions/26509/whats-the-difference- > between-android-beam-vs-s-beam > > > - What to do if the other peer does not support our data channels? > > - How do we handle failures on the data channel? > > - If we display error messages, wouldn't it be confusing to the user to > > receive a Bluetooth error message when he/she selected NFC for transmission? > > > > The whole point of NFC is to avoid any of these sort of failures. > > > Instead I'd propose the following scheme where > > > > - the user selects 'Share via Bluetooth', > > - the phone shows a Bluetooth pairing dialog were the user has the option > > of pairing devices via NFC, > > - it transfers the data to the paired device, and > > - EOT. > > We should follow the existing UX patterns that other phones with NFC beam > capabilities have. > > Thanks!
Assignee | ||
Comment 16•11 years ago
|
||
(In reply to Thomas Zimmermann [:tzimmermann] [:tdz] from comment #12) > - How do we select between WIFI, Bluetooth, and maybe other data channels? > Devices probably need to tell each other. Firefox OS only supports BT w/ OPP in current stage. Also, if we use WIFI or other data channels, we need to have other data transfer protocols(ex. FTP). > - What to do if the other peer does not support our data channels? Good question. But I suppose most of phones support BT w/ OPP. > - How do we handle failures on the data channel? > - If we display error messages, wouldn't it be confusing to the user to > receive a Bluetooth error message when he/she selected NFC for transmission? > > Instead I'd propose the following scheme where > > - the user selects 'Share via Bluetooth', > - the phone shows a Bluetooth pairing dialog were the user has the option > of pairing devices via NFC, > - it transfers the data to the paired device, and > - EOT. Is it appropriate for users to have the option, 'Share via Bluetooth'? Users don't care about which technology is used for sharing video/image. The better method is that we help users to select the best technology to share files. So I deem that Gecko have to provide a common NFC sharing webAPI for Gaia and decide which technology(but now we can only use BT w/ OPP) is the best one for this share.
Comment 17•11 years ago
|
||
(In reply to Ken Chang from comment #16) > Is it appropriate for users to have the option, 'Share via Bluetooth'? Users > don't care about which technology is used for sharing video/image. The > better method is that we help users to select the best technology to share > files. > So I deem that Gecko have to provide a common NFC sharing webAPI for Gaia > and decide which technology(but now we can only use BT w/ OPP) is the best > one for this share. I agree completely with this. The whole point of NFC pairing is to free users from making these kind of choices.
Comment 18•11 years ago
|
||
I would also suggest the reciever (if FirefoxOS) will can potentially auto download with a cancel button (with preview if possible), and possibly allow really advanced users to switch transfer protocols if that is something people want. Presumably if a user is already holding out the phone/NFC device, the receiver has some reason to believe they want the media.
Comment 19•11 years ago
|
||
<Acceptance Criteria> (Proposal) 1. User can see an option in menu to share image/video 2. When NFC and BT are on, user can share single and multiple images/videos 3. When NFC is on and BT is off, user would be prompt for enabling BT and then user can share single or multiple image/video 4. non Firefox OS device with NFC function enable should be tested with ffox device
Comment 20•11 years ago
|
||
(In reply to Casey Yee [:cyee] from comment #17) > (In reply to Ken Chang from comment #16) > > > Is it appropriate for users to have the option, 'Share via Bluetooth'? Users > > don't care about which technology is used for sharing video/image. The > > better method is that we help users to select the best technology to share > > files. > > So I deem that Gecko have to provide a common NFC sharing webAPI for Gaia > > and decide which technology(but now we can only use BT w/ OPP) is the best > > one for this share. Hi Casey, > I agree completely with this. The whole point of NFC pairing is to free > users from making these kind of choices. I don't oppose this idea, but it might not be so easy in practice. We had a meeting yesterday, and I was told that Android Beam only transmits the pairing information between two devices via NFC. Using this information, a regular Bluetooth pairing step is performed. Beam does not make the transfer process more robust against errors or failures. This means that the points I raise in comment 12 still apply.
Updated•11 years ago
|
Whiteboard: [ucid:NFC5] → [ucid:NFC5], [FT:RIL]
Assignee | ||
Updated•11 years ago
|
Assignee | ||
Updated•11 years ago
|
Assignee | ||
Updated•11 years ago
|
Assignee | ||
Updated•11 years ago
|
Updated•11 years ago
|
Whiteboard: [ucid:NFC5], [FT:RIL] → [FT:RIL, ucid:NFC5]
Updated•11 years ago
|
Whiteboard: [FT:RIL, ucid:NFC5] → [FT:RIL, v1.3, ucid:NFC5]
Updated•11 years ago
|
Whiteboard: [FT:RIL, v1.3, ucid:NFC5] → [FT:RIL, NFCv1.3, ucid:NFC5]
Comment 22•11 years ago
|
||
Prefer to be compatible with NFC + BT (V/s NFC + Wifi-direct) given where we are at from the device specs perspective. If that means we are feature-wise compatible with Android Beam, that's ok. I assume S-beam compatibility would involve more proprietary code for automatic Wifi pairing etc. (Btw, We may call it "Firefox beam" or just "fire" :-))
Updated•11 years ago
|
Flags: needinfo?(skamat)
Updated•11 years ago
|
blocking-b2g: --- → 1.3+
Comment 23•11 years ago
|
||
Hi Sandip, Base of the discussion above, I got a few questions about the flow: a) The user can select an image/video and select “Share image or video” from the contextual menu. I think it's redundant for the user to make the selection in the beginning (same question as URL) Can we transfer information directly while the users tapping their phones together? d) If BT is turned off, the device will prompt the user to turn on BT. Once the user turns on BT, the BT pairing will take place Can we auto-turn on BT while transferring data and turn off automatically when it finish? Which means the user don't really necessary to go setting page and turn on BT in order to transfer image/video via NFC. I hope the behaviour is continuous and not being interrupted by BT setting. It would be wired when the users try to transfer information via NFC and there's a BT setting pops out in between the flow.
Flags: needinfo?(sandip.kamat)
Comment 24•11 years ago
|
||
Hi Sandip, Comment 23 flags to wrong mail, sorry.
Flags: needinfo?(sandip.kamat) → needinfo?(skamat)
Depends on: 906579
No longer depends on: 860907
Updated•11 years ago
|
Flags: needinfo?(skamat)
Comment 25•11 years ago
|
||
(In reply to Juwei Huang from comment #23) > Hi Sandip, > Base of the discussion above, I got a few questions about the flow: > > a) The user can select an image/video and select “Share image or video” from > the contextual menu. > I think it's redundant for the user to make the selection in the beginning > (same question as URL) > Can we transfer information directly while the users tapping their phones > together? > Yes. Agree. I answered that in email but the comment 0 can't be edited. We are aiming an experience that users are already familiar with from the current market devices. > d) If BT is turned off, the device will prompt the user to turn on BT. Once > the user turns on BT, the BT pairing will take place > Can we auto-turn on BT while transferring data and turn off automatically > when it finish? Which means the user don't really necessary to go setting > page and turn on BT in order to transfer image/video via NFC. I hope the > behaviour is continuous and not being interrupted by BT setting. > It would be wired when the users try to transfer information via NFC and > there's a BT setting pops out in between the flow. If we can do it transparently with no user interruption that will work. The BT icon should show up for the duration to inform the user of its being active.
Updated•11 years ago
|
Whiteboard: [FT:RIL, NFCv1.3, ucid:NFC5] → [FT:RIL, 1.3:p1, ucid:NFC5]
Comment 26•11 years ago
|
||
Hi Sandip, thanks for your answering:) Hi all, The interaction spec has uploaded, please refer to attachment, thanks!
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 27•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:NFC5] → [FT:RIL, 1.3:p2, ucid:NFC5]
Comment 29•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:NFC5] → [ucid:NFC5, 1.3:p2, ft:RIL]
Comment 30•11 years ago
|
||
https://moztrap.mozilla.org/manage/cases/?pagenumber=1&pagesize=20&sortfield=created_on&sortdirection=desc&filter-tag=2288&filter-suite=419 Still modifying, but main test cases are in.
Flags: in-moztrap?(wachen) → in-moztrap+
Updated•11 years ago
|
Assignee: nobody → kchang
Blocks: b2g-NFC-2.0
Whiteboard: [ucid:NFC5, 1.3:p2, ft:RIL] → [ucid:NFC5, 1.4:p2, ft:RIL]
Updated•11 years ago
|
blocking-b2g: --- → backlog
Whiteboard: [ucid:NFC5, 1.4:p2, ft:RIL] → [ucid:NFC5, 1.4, ft:RIL]
Target Milestone: --- → 1.4 S1 (14feb)
Updated•11 years ago
|
Updated•11 years ago
|
Target Milestone: 1.4 S1 (14feb) → 1.4 S2 (28feb)
Updated•11 years ago
|
Target Milestone: 1.4 S2 (28feb) → ---
Updated•11 years ago
|
Whiteboard: [ucid:NFC5, 1.4, ft:RIL] → [ucid:NFC5, 2.0, ft:RIL]
Assignee | ||
Comment 32•11 years ago
|
||
Close this bug. To let QA start verify this feature.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Comment 33•10 years ago
|
||
(In reply to Ken Chang[:ken] from comment #32) > Close this bug. To let QA start verify this feature. Are there any bugs open from QA verification? Can they be tracked under dependent bugs for this user story?
Flags: needinfo?(whuang)
Updated•10 years ago
|
User Story: (updated)
Updated•10 years ago
|
feature-b2g: --- → 2.0
Flags: needinfo?(whuang)
Comment 34•10 years ago
|
||
Juwei: can you please comment on the UI for a failed transfer? Right now the difference is only with the way the "sliding UI" is animated and that can easily be missed. Also, there is probably a typo in the last screenshot of the failed scenario (right now it reads "file transfer complete"). Since the sharing functionality makes use of the Bluetooth Transfer app, would it make more sense to use its UX (show notifications on success/failure)?
Flags: needinfo?(jhuang)
Comment 35•10 years ago
|
||
Spec updated. Hi Arno, We do have notification when the transfer failed, please check the last screen of page 7.
Flags: needinfo?(jhuang)
Comment 36•10 years ago
|
||
Verified on Device Flame Gaia 2e5636e852a9354a5f8072b179cf16f72647cfd6 Gecko https://hg.mozilla.org/mozilla-central/rev/8bd92dc9ef59 BuildID 20140608160201 Version 32.0a1
Status: RESOLVED → VERIFIED
Blocks: 1127764
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
•