Sandip Kamat Reporter
	Description • 11 years ago

The user can - from the browser - share the URL of the page that
the browser is currently pointing to. The URL can be shared with another
NFC enabled device by tapping the devices together.
a) The user selects “Share Web Page” from the browser 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 an URL with you – Accept/Reject” or something similar.
d) Upon accepting, the receiving mobile opens up the browser and goes to the URL.

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

<Acceptance Criteria> (Proposal)
1. User can see an option in menu to share webpages
2. User can share a webpage with others
3. Accepting user can see prompt to accept or not to accpet the webpage url
4. User can see the webpage opening in browser after received sharing url
5. non Firefox OS device with NFC function enable should be tested with ffox device

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

We need feedback from UX: 

How to design the flow? Android does not have (a), and Android shrinks the screen for (b). And, how do we allow users to choose which application to open with the received information? 

Thanks,

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

Hi Kevin,
For (a), I believe it's a general question: Do we need an NFC option in sharing menu? Or follow what Android beam/ S beam has done? In my point of view, to keep android behaviour is a proper idea currently. The benefit of NFC sharing is to skip the long process of sharing items from phones, it would be very bothersome if we add one more step before pairing activated.
For (b), basically it will be the same as Android, but I have an idea to swipe up to transfer the information from one phone to another. The gesture "swipe up" is a metaphor indicates that the information has sent out. We can talk to Ken & Tim about the feasibility.
About the question you talked about how we allow users to open a received information, I suggest the device should auto-select a proper application for the user to open the received information. The only thing we need to consider about is what if the information can be opened on more than one application? My suggestion is to pop out a confirm window to ask the user select one application before open up(temporary or permanently). It would be the same solution we mentioned in the NFC work week last week.

	Francis Lee [:frlee]
	Comment 4 • 11 years ago

hi Sandip,

may i have your opinion regarding comment #3 a)? what UX proposed here is to remove a) from the original user story. 
My opinion is:  it may be redundant to offer user another ways to share URL by NFC, since the tag function is much more intuitive and efficient.
please feel free to let me know if you have any concern.

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

Hi Sandip,
I also have a question for c)
Since the users are putting their phone so closely, I suppose they are pretty sure they are willing to share their URLs.
It would be a redundant step as well...
Plese let me know if you have any thoughts about it :)

	Sandip Kamat Reporter
	Comment 6 • 11 years ago

(In reply to frlee from comment #4)
> hi Sandip,
> 
> may i have your opinion regarding comment #3 a)? what UX proposed here is to
> remove a) from the original user story. 
> My opinion is:  it may be redundant to offer user another ways to share URL
> by NFC, since the tag function is much more intuitive and efficient.
> please feel free to let me know if you have any concern.

No issues, implementation consistent with Android phones is okay.

(In reply to Juwei Huang from comment #5)
> Hi Sandip,
> I also have a question for c)
> Since the users are putting their phone so closely, I suppose they are
> pretty sure they are willing to share their URLs.
> It would be a redundant step as well...
> Plese let me know if you have any thoughts about it :)

I still think users should be given a choice to confirm. what's the UX input here?

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

Hi Sandip,
In UX perspective, We still recog the gesture of pairing the phones together as a confirmation of accepting the URL transfer.
There are some examples that the user doesn't have to re-confirm after paired the device, such as stored-value card, transportation card, and some device with NFC tag.
And here's the attachment of interaction spec v1.0, please have a look.
If you still not convince by me, please let me know :)

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 8 • 11 years ago

As offline discussion, list my concern here:

1. Browser app may not need multiple receiver apps.
2. In multiple receiver apps case, we may re-use web activity picker UI, and currently we don't support 'remember the choice'. Need further discussion with other folks. If we want to support this, it's worthy to have another slide/spec for this feature.
3. On receiver side, if the app isn't opened, the opening transition(default is enlarging the frame from 10% to 100%) would be replaced by:
   (A) Black the screen (fadeIn?)
   (B) App screenshot or icon splash(need confirm) fly from top to bottom and stand straight.
4. Does swipe-up is necessary to share via NFC? I personally think we shall enable sharing using only click and do the flying out animation. Thought?

	Francis Lee [:frlee]
	Comment 9 • 11 years ago

hi juwei,
maybe you should be able to comment on Alive's opinion (comment #8). i'm open for this, as long as a feasible design which provides a reasonable UX can be lock down.

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 10 • 11 years ago

https://bugzilla.mozilla.org/show_bug.cgi?id=894320
https://bugzilla.mozilla.org/show_bug.cgi?id=894676
and this bug seem to have the same mechanism.

Technical detail

I haven't studied API defined in https://bugzilla.mozilla.org/show_bug.cgi?id=674741
But in my imagination:
* User app could register for NFC message.
* System app needs to know NFC pairing is inited.
* System app needs to trigger the NFC message consumer picker, so that we need the filter in NFC API.
* AppWindow shall have a new open/close animation when NFC is ongoing.
* User app needs to do the following work when they are invoked by system app(again system message?)

	Sandip Kamat Reporter
	Comment 11 • 11 years ago

(In reply to Juwei Huang from comment #7)
> Created attachment 811878 [details]
> [NFC] Pairing URL_20130930.pdf
> 
> Hi Sandip,
> In UX perspective, We still recog the gesture of pairing the phones together
> as a confirmation of accepting the URL transfer.
> There are some examples that the user doesn't have to re-confirm after
> paired the device, such as stored-value card, transportation card, and some
> device with NFC tag.
> And here's the attachment of interaction spec v1.0, please have a look.
> If you still not convince by me, please let me know :)

Sounds okay. Thx

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

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

	Jean Gong :jgong
	Comment 13 • 11 years ago

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

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

Basic test cases are in Moztrap now. They were originally added by Eric Chang and modified/extended by me.

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

https://moztrap.mozilla.org/manage/cases/?pagenumber=1&pagesize=20&sortfield=created_on&sortdirection=desc&filter-tag=2289&filter-suite=419

	Wesley Huang [:wesley_huang] (EPM) (NI me)
	Comment 16 • 11 years ago

Ken, 
As the dependent bugs are all RESOLVED FIXED, can we RESOLVE FIX this story and let QA verify?

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

(In reply to Wesley Huang [:wesley_huang] from comment #16)
> Ken, 
> As the dependent bugs are all RESOLVED FIXED, can we RESOLVE FIX this story
> and let QA verify?
No yet, I am going to reopen bug 903250 since there are some problems in the patch of bug 903250.

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

(In reply to Ken Chang[:ken] from comment #17)
> No yet, I am going to reopen bug 903250 since there are some problems in the
> patch of bug 903250.
I file a new bug, bug 969217, instead.

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

Sandip, you have to put this feature in Browser team's backlog. Thanks.

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

(In reply to Ken Chang[:ken] from comment #19)
> Sandip, you have to put this feature in Browser team's backlog. Thanks.
Peter had help this. remove this ni?.

	Alison Shiue
	Comment 21 • 11 years ago

According to UX doc, it looks like device transfer URL via BT. But I observed from testing, URL seems transfer directly via NFC. Can anyone confirm this? Thanks.

	Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]
	Comment 22 • 11 years ago

(In reply to ashiue from comment #21)
> According to UX doc, it looks like device transfer URL via BT. But I
> observed from testing, URL seems transfer directly via NFC. Can anyone
> confirm this? Thanks.

It's done by NFC. https://github.com/mozilla-b2g/gaia/blob/master/apps/browser/js/nfc.js#L63

	Alison Shiue
	Comment 23 • 11 years ago

Yoshi, thanks.  
Hi Juwei, could you please update the scenario for URL sharing on UX docs? Many thanks!

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

Hi all!
Spec updated.

	Sandip Kamat Reporter
	Comment 25 • 11 years ago

(In reply to Juwei Huang from comment #24)
> Created attachment 8408893 [details]
> [NFC] Pairing URL_20140418.pdf
> 
> Hi all!
> Spec updated.

Thanks Juwei. there seems to be a typo in a couple places. URL paring --> URL sharing.

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

Thank you Sandip, spec updated.

	Sandip Kamat Reporter
	Comment 27 • 10 years ago

User story targeted for 2.0

	Wesley Huang [:wesley_huang] (EPM) (NI me)
	Comment 28 • 10 years ago

feature landed so RESOLVED FIXED for QA to test.

	Alison Shiue
	Comment 29 • 10 years ago

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