894678 - [B2G][NFC][User Story]: Support sharing of URLs

Status: VERIFIED FIXED

(Firefox OS Graveyard :: NFC, defect)

Description

[Sandip Kamat]

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.

Comment 1

[Walter Chen[:ypwalter][:wachen]]

<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

Comment 2

[Kai-Chih Hu [:khu]]

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,

Comment 3

[Juwei Huang[:juwei]]

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.

Comment 4

[Francis Lee [:frlee]]

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.

Comment 5

[Juwei Huang[:juwei]]

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 :)

Comment 6

[Sandip Kamat]

(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?

Comment 7

[Juwei Huang[:juwei]]

Attachment: [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 :)

Comment 8

[(inactive after 6/18) Alive Kuo [:alive]]

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?

Comment 9

[Francis Lee [:frlee]]

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.

Comment 10

[(inactive after 6/18) Alive Kuo [:alive]]

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

Comment 11

[Sandip Kamat]

(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

Comment 12

[Kai-Chih Hu [:khu]]

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

Comment 13

[Jean Gong :jgong]

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

Comment 14

[Walter Chen[:ypwalter][:wachen]]

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

Comment 15

[Walter Chen[:ypwalter][:wachen]]

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

Comment 16

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

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

Comment 17

[Ken Chang[:kenkai]]

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

Comment 18

[Ken Chang[:kenkai]]

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

Comment 19

[Ken Chang[:kenkai]]

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

Comment 20

[Ken Chang[:kenkai]]

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

Comment 21

[Alison Shiue]

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.

Comment 22

[Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]]

(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

Comment 23

[Alison Shiue]

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

Comment 24

[Juwei Huang[:juwei]]

Attachment: [NFC] Pairing URL_20140418.pdf

Hi all!
Spec updated.

Comment 25

[Sandip Kamat]

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

Comment 26

[Juwei Huang[:juwei]]

Attachment: [NFC] Pairing URL_20140428.pdf

Thank you Sandip, spec updated.

Comment 27

[Sandip Kamat]

User story targeted for 2.0

Comment 28

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

feature landed so RESOLVED FIXED for QA to test.

Comment 29

[Alison Shiue]

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