Ken Chang[:kenkai] Assignee
	Description • 11 years ago

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

	Sotaro Ikeda [:sotaro]
	Comment 1 • 11 years ago

It it similar to Android Beam?
http://en.wikipedia.org/wiki/Android_Beam

	Garner Lee
	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.

	Walter Chen[:ypwalter][:wachen]
	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?

	Walter Chen[:ypwalter][:wachen]
	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

	Sandip Kamat
	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.

	Sandip Kamat
	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.

	arno
	Comment 8 • 11 years ago

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.

	arno
	Comment 9 • 11 years ago

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

	Ken Chang[:kenkai] 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.

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

	Thomas Zimmermann [:tzimmermann] [:tdz]
	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

	Casey Yee
	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!

	Casey Yee
	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)

	Thomas Zimmermann [:tzimmermann] [:tdz]
	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!

	Ken Chang[:kenkai] 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.

	Casey Yee
	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.

	Garner Lee
	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.

	Walter Chen[:ypwalter][:wachen]
	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

	Thomas Zimmermann [:tzimmermann] [:tdz]
	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.

	Peter Dolanjski [:pdol]
	Comment 21 • 11 years ago

Moving NI to Sandip

	Sandip Kamat
	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" :-))

	Juwei Huang[:juwei]
	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.

	Juwei Huang[:juwei]
	Comment 24 • 11 years ago

Hi Sandip, 
Comment 23 flags to wrong mail, sorry.

	Sandip Kamat
	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.

	Juwei Huang[:juwei]
	Comment 26 • 11 years ago

Hi Sandip, thanks for your answering:)
Hi all,
The interaction spec has uploaded, please refer to attachment, thanks!

	Kai-Chih Hu [:khu]
	Comment 27 • 11 years ago

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

	John Hu [:johnhu][:johu][:醬糊小弟]
	Comment 28 • 11 years ago

update the dependency from the duplicated one to the original one.

	Jean Gong :jgong
	Comment 29 • 11 years ago

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

	Walter Chen[:ypwalter][:wachen]
	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.

	Walter Chen[:ypwalter][:wachen]
	Comment 31 • 11 years ago

many bugs found in today's build. will file bugs against

	Ken Chang[:kenkai] Assignee
	Comment 32 • 11 years ago

Close this bug. To let QA start verify this feature.

	Sandip Kamat
	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?

	arno
	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)?

	Juwei Huang[:juwei]
	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.

	Alison Shiue
	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