Closed
Bug 894678
Opened 11 years ago
Closed 10 years ago
[B2G][NFC][User Story]: Support sharing of URLs
Categories
(Firefox OS Graveyard :: NFC, defect)
Tracking
(feature-b2g:2.0, tracking-b2g:backlog)
VERIFIED
FIXED
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.
Updated•11 years ago
|
Summary: [B2G] [NFC User Story]: Support sharing of URLs → [B2G][NFC][User Story]: Support sharing of URLs
Updated•11 years ago
|
Flags: in-moztrap?
QA Contact: wachen
Updated•11 years ago
|
Flags: in-moztrap? → in-moztrap?(wachen)
Updated•11 years ago
|
Whiteboard: [ucid:NFC4]
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
Updated•11 years ago
|
Whiteboard: [ucid:NFC4] → [ucid:NFC4], [FT:RIL]
Assignee | ||
Updated•11 years ago
|
Assignee | ||
Updated•11 years ago
|
Assignee | ||
Updated•11 years ago
|
Updated•11 years ago
|
Whiteboard: [ucid:NFC4], [FT:RIL] → [FT:RIL, v1.3, ucid:NFC4]
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,
Updated•11 years ago
|
Whiteboard: [FT:RIL, v1.3, ucid:NFC4] → [FT:RIL, NFCv1.3, ucid:NFC4]
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.
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.
Flags: needinfo?(skamat)
Updated•11 years ago
|
blocking-b2g: --- → 1.3+
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 :)
Depends on: 906579
No longer depends on: 860907
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?
Flags: needinfo?(skamat)
Updated•11 years ago
|
Whiteboard: [FT:RIL, NFCv1.3, ucid:NFC4] → [FT:RIL, 1.3:p1, ucid:NFC4]
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 :)
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?
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.
Flags: needinfo?(jhuang)
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?)
Updated•11 years ago
|
Flags: needinfo?(jhuang)
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
Assignee | ||
Updated•11 years ago
|
Blocks: b2g-nfc-ux
No longer depends on: 897312
No longer depends on: 902051
No longer depends on: 906579
Comment 12•11 years ago
|
||
Remove blocking-b2g flag from User Story bugs. Use whiteboard to indicate what FxOS version we target.
blocking-b2g: 1.3+ → ---
Updated•11 years ago
|
Whiteboard: [FT:RIL, 1.3:p1, ucid:NFC4] → [FT:RIL, 1.3:p2, ucid:NFC4]
Comment 13•11 years ago
|
||
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]
Comment 14•11 years ago
|
||
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+
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
Updated•11 years ago
|
Assignee: nobody → kchang
Blocks: b2g-NFC-2.0
Whiteboard: [ucid:NFC4, 1.3:p2, ft:RIL] → [ucid:NFC4, 1.4:p2, ft:RIL]
Updated•11 years ago
|
blocking-b2g: --- → backlog
Whiteboard: [ucid:NFC4, 1.4:p2, ft:RIL] → [ucid:NFC4, 1.4, ft:RIL]
Target Milestone: --- → 1.4 S1 (14feb)
Comment 16•11 years ago
|
||
Ken, As the dependent bugs are all RESOLVED FIXED, can we RESOLVE FIX this story and let QA verify?
Flags: needinfo?(kchang)
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.
Flags: needinfo?(kchang)
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.
Updated•11 years ago
|
Updated•11 years ago
|
Target Milestone: 1.4 S1 (14feb) → 1.4 S2 (28feb)
Updated•11 years ago
|
Target Milestone: 1.4 S2 (28feb) → ---
Assignee | ||
Comment 19•11 years ago
|
||
Sandip, you have to put this feature in Browser team's backlog. Thanks.
Flags: needinfo?(sandip.kamat)
Updated•11 years ago
|
Blocks: browser-chrome-mvp
Updated•11 years ago
|
Whiteboard: [ucid:NFC4, 1.4, ft:RIL] → [ucid:NFC4, 2.0, ft:RIL]
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?.
Flags: needinfo?(sandip.kamat)
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.
(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•11 years ago
|
||
Yoshi, thanks. Hi Juwei, could you please update the scenario for URL sharing on UX docs? Many thanks!
Flags: needinfo?(jhuang)
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.
User Story: (updated)
Updated•11 years ago
|
feature-b2g: --- → 2.0
Reporter | ||
Updated•10 years ago
|
User Story: (updated)
Comment 28•10 years ago
|
||
feature landed so RESOLVED FIXED for QA to test.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Comment 29•10 years ago
|
||
Verified on Gaia 2c6c413ed729d465c52d6c2d5d458e2eee79e956 Gecko https://hg.mozilla.org/releases/mozilla-aurora/rev/d32649a24965 BuildID 20140714160201 Version 32.0a2
Status: RESOLVED → VERIFIED
Updated•10 years ago
|
blocking-b2g: backlog → ---
tracking-b2g:
--- → backlog
You need to log in
before you can comment on or make changes to this bug.
Description
•