Closed Bug 894320 Opened 7 years ago Closed 6 years ago

[B2G][NFC][User Story]: Support sharing of Image/Video content

Categories

(Firefox OS Graveyard :: NFC, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(feature-b2g:2.0, tracking-b2g:backlog)

VERIFIED FIXED
feature-b2g 2.0
tracking-b2g backlog

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
Component: General → NFC
Blocks: b2g-nfc
It it similar to Android Beam?
http://en.wikipedia.org/wiki/Android_Beam
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.
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
Duplicate of this bug: 894679
Summary: [B2G] [NFC User Story]: Support sharing of Image/Video content → [B2G][NFC][User Story]: Support sharing of Image/Video content
Flags: in-moztrap?
QA Contact: wachen
Flags: in-moztrap? → in-moztrap?(wachen)
Whiteboard: [ucid:NFC5]
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)
Also, is it better to divide large user stories into small ones since there are lots of big user stories in NFC? :P
(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.
(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).
(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)
(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.
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
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!
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)
(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!
(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.
(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.
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.
<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
(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.
Whiteboard: [ucid:NFC5] → [ucid:NFC5], [FT:RIL]
Moving NI to Sandip
Flags: needinfo?(ffos-product) → needinfo?(skamat)
Blocks: 903252
Blocks: 903253
Blocks: 903259
Blocks: 903261
No longer blocks: 903261
Depends on: 903261
No longer blocks: 903253
Depends on: 903253
No longer blocks: 903252
Depends on: 903252
Depends on: 855961
No longer blocks: 903259
Depends on: 903259
Whiteboard: [ucid:NFC5], [FT:RIL] → [FT:RIL, ucid:NFC5]
Whiteboard: [FT:RIL, ucid:NFC5] → [FT:RIL, v1.3, ucid:NFC5]
Depends on: webnfc
Depends on: 860907
Depends on: 897312
Depends on: 902051
Whiteboard: [FT:RIL, v1.3, ucid:NFC5] → [FT:RIL, NFCv1.3, ucid:NFC5]
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" :-))
Flags: needinfo?(skamat)
blocking-b2g: --- → 1.3+
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)
Hi Sandip, 
Comment 23 flags to wrong mail, sorry.
Flags: needinfo?(sandip.kamat) → needinfo?(skamat)
Depends on: 920882
Flags: needinfo?(skamat)
(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.
Whiteboard: [FT:RIL, NFCv1.3, ucid:NFC5] → [FT:RIL, 1.3:p1, ucid:NFC5]
Hi Sandip, thanks for your answering:)
Hi all,
The interaction spec has uploaded, please refer to attachment, thanks!
No longer depends on: 855961
Blocks: b2g-nfc-ux
No longer blocks: b2g-nfc
Remove blocking-b2g flag from User Story bugs. Use whiteboard to indicate what FxOS version we target.
blocking-b2g: 1.3+ → ---
Whiteboard: [FT:RIL, 1.3:p1, ucid:NFC5] → [FT:RIL, 1.3:p2, ucid:NFC5]
Keywords: feature
update the dependency from the duplicated one to the original one.
Depends on: 903305
No longer depends on: 903259, 929352
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]
Assignee: nobody → kchang
Blocks: b2g-NFC-2.0
Whiteboard: [ucid:NFC5, 1.3:p2, ft:RIL] → [ucid:NFC5, 1.4:p2, ft:RIL]
blocking-b2g: --- → backlog
Whiteboard: [ucid:NFC5, 1.4:p2, ft:RIL] → [ucid:NFC5, 1.4, ft:RIL]
Target Milestone: --- → 1.4 S1 (14feb)
many bugs found in today's build. will file bugs against
Depends on: 972726
Target Milestone: 1.4 S1 (14feb) → 1.4 S2 (28feb)
Target Milestone: 1.4 S2 (28feb) → ---
Depends on: 966921
Whiteboard: [ucid:NFC5, 1.4, ft:RIL] → [ucid:NFC5, 2.0, ft:RIL]
No longer depends on: 966921
Close this bug. To let QA start verify this feature.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
(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)
User Story: (updated)
feature-b2g: --- → 2.0
Flags: needinfo?(whuang)
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)
Spec updated.
Hi Arno,
We do have notification when the transfer failed, please check the last screen of page 7.
Flags: needinfo?(jhuang)
Verified on
Device    Flame 
Gaia      2e5636e852a9354a5f8072b179cf16f72647cfd6
Gecko     https://hg.mozilla.org/mozilla-central/rev/8bd92dc9ef59
BuildID   20140608160201
Version   32.0a1
Status: RESOLVED → VERIFIED
blocking-b2g: backlog → ---
You need to log in before you can comment on or make changes to this bug.