Closed Bug 894678 Opened 7 years ago Closed 6 years ago

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

Categories

(Firefox OS Graveyard :: NFC, defect)

ARM
Linux
defect
Not set

Tracking

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

VERIFIED FIXED
feature-b2g 2.0
tracking-b2g backlog

People

(Reporter: skamat, Assigned: kchang)

References

Details

(Keywords: feature, Whiteboard: [ucid:NFC4, 2.0, ft:RIL])

User Story

[updated to remove accept/reject interactions by user, to make it more seamless]

As a user, I would like to share the browser page (that I am currently on) with another device. The way I would do it is by by tapping 2 NFC enabled devices together while the "sender" device is showing the desired browser page and once it gives our a visual or sensory (vibration), I will swipe to share the page. The "receiver" device will open a browser (or any of apps that user has set up intents to open URLs) page that was received. 

Acceptance Criteria:

1. Device has NFC enabled and upon tapping pairs with another NFC device (vibration) and provides a way to "swipe to share".
2. If the sharing works successfully (or fails), the device will show the appropriate visual or sensory (vibration) indication. (see UX spec)
3. The receiving device will open an appropriate app (browser or other apps with intents to receive URL).
4. This sharing should work with FxOS devices as well as non-FxOS devices (if they support URL sharing).

Attachments

(3 files)

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.
Summary: [B2G] [NFC User Story]: Support sharing of URLs → [B2G][NFC][User Story]: Support sharing of URLs
Blocks: b2g-nfc
Flags: in-moztrap?
QA Contact: wachen
Flags: in-moztrap? → in-moztrap?(wachen)
Whiteboard: [ucid:NFC4]
<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
Whiteboard: [ucid:NFC4] → [ucid:NFC4], [FT:RIL]
Blocks: 903250
Blocks: 903259
Blocks: 903261
No longer blocks: 903261
Depends on: 903261
No longer blocks: 903250
Depends on: 903250
No longer blocks: 903259
Depends on: 903259
Whiteboard: [ucid:NFC4], [FT:RIL] → [FT:RIL, v1.3, ucid:NFC4]
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,
Depends on: webnfc
Depends on: 860907
Depends on: 897312
Depends on: 902051
Whiteboard: [FT:RIL, v1.3, ucid:NFC4] → [FT:RIL, NFCv1.3, ucid:NFC4]
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.
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.
Flags: needinfo?(skamat)
blocking-b2g: --- → 1.3+
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 :)
Depends on: 920882
(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?
Flags: needinfo?(skamat)
Whiteboard: [FT:RIL, NFCv1.3, ucid:NFC4] → [FT:RIL, 1.3:p1, ucid:NFC4]
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 :)
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?
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.
Flags: needinfo?(jhuang)
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?)
Flags: needinfo?(jhuang)
(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
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:NFC4] → [FT:RIL, 1.3:p2, ucid:NFC4]
Keywords: feature
Update whiteboard tag to follow format [ucid:{id}, {release}:p{1,2}, ft:{team-id}]
Whiteboard: [FT:RIL, 1.3:p2, ucid:NFC4] → [ucid:NFC4, 1.3:p2, ft:RIL]
Basic test cases are in Moztrap now. They were originally added by Eric Chang and modified/extended by me.
Flags: in-moztrap?(wachen) → in-moztrap+
Assignee: nobody → kchang
Blocks: b2g-NFC-2.0
Whiteboard: [ucid:NFC4, 1.3:p2, ft:RIL] → [ucid:NFC4, 1.4:p2, ft:RIL]
blocking-b2g: --- → backlog
Whiteboard: [ucid:NFC4, 1.4:p2, ft:RIL] → [ucid:NFC4, 1.4, ft:RIL]
Target Milestone: --- → 1.4 S1 (14feb)
Ken, 
As the dependent bugs are all RESOLVED FIXED, can we RESOLVE FIX this story and let QA verify?
Flags: needinfo?(kchang)
(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.
Flags: needinfo?(kchang)
Depends on: 969217
(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.
Target Milestone: 1.4 S1 (14feb) → 1.4 S2 (28feb)
Depends on: 972791
No longer depends on: 972791
Target Milestone: 1.4 S2 (28feb) → ---
Sandip, you have to put this feature in Browser team's backlog. Thanks.
Flags: needinfo?(sandip.kamat)
Whiteboard: [ucid:NFC4, 1.4, ft:RIL] → [ucid:NFC4, 2.0, ft:RIL]
Depends on: 997599
Depends on: 998111
Depends on: 997606
(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?.
Flags: needinfo?(sandip.kamat)
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.
(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
Yoshi, thanks.  
Hi Juwei, could you please update the scenario for URL sharing on UX docs? Many thanks!
Flags: needinfo?(jhuang)
Hi all!
Spec updated.
Flags: needinfo?(jhuang)
(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.
User Story: (updated)
Thank you Sandip, spec updated.
No longer depends on: 997606
feature-b2g: --- → 2.0
No longer depends on: 997599
User Story: (updated)
User story targeted for 2.0
feature landed so RESOLVED FIXED for QA to test.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Verified on
Gaia      2c6c413ed729d465c52d6c2d5d458e2eee79e956
Gecko     https://hg.mozilla.org/releases/mozilla-aurora/rev/d32649a24965
BuildID   20140714160201
Version   32.0a2
Status: RESOLVED → VERIFIED
Depends on: 1126249
blocking-b2g: backlog → ---
You need to log in before you can comment on or make changes to this bug.