In Bug 894323 is the original user story for reading NFC tags. But now given that we allow privilege app can read the tag by itself(with ontagfound), we need to update the user story as well, because if the privilege NFC app is in the foreground while tapping the tag, (for example, tag with URL), it could be possible that the privilege app could handle this tag by itself without redirecting to System app, in that case Browser won't be launched.

[Blocking Requested - why for this release]: Original UX is out-dated.

ni? for Juwei for the UX. Before 2.2 branch, when an NFC Tag is detected, the event (System message) will be dispatched to System app, and System app will do the vibration. Now in v2.2 branch and current master, *if the foreground app can handle the event*, then the event will NOT be re-directed to System app, which means in that case no vibration will be happened. Is this still okay with UX? From original UX design document, it seems not mentioning 'vibration', also it doesn't mention the detail if the 3rd party app could handle the NFC event. Tapping another NFC device will have similar problem, I'll file a bug if we need to seperate tag and peer cases.

Proposing this to be feature-b2g:3.0

Hi Yoshi, Thank you for your explanation! From UX perspective, I still strongly prefer "vibrate" when the device receive things from NFC tag. It is a sign whether people would know if the device really detect NFC tag or not, otherwise people won't got any feedback and it's also inconsistent with the normal NFC transfer (like p2p sharing) Is there any other way to vibrate the phone? Let me know, Thank you!

(In reply to Juwei Huang from comment #4) > Hi Yoshi, > Thank you for your explanation! Hi Juwei I will try to add the vibration. But can you update the UX document? Because even in the original UX (Bug 894323) it doesn't mention 'vibration'.

(In reply to Juwei Huang from comment #4) > From UX perspective, I still strongly prefer "vibrate" when the device > receive things from NFC tag. Also to confirm, you mean 'Our system should do the vibration, not the app itself', right? For app, it could do whatever it wants when it detects an NFC tag or device, but our system still have to do the vibration, is my understanding correct? Thanks.

(In reply to Yoshi Huang[:allstars.chh] from comment #5) > (In reply to Juwei Huang from comment #4) > > Hi Yoshi, > > Thank you for your explanation! > Hi Juwei > > I will try to add the vibration. > > But can you update the UX document? > Because even in the original UX (Bug 894323) it doesn't mention 'vibration'. Also you propably need to update the UX for reading URL/vcards as well. In v2.2 branch, if the foreground app could handle the URL or vcards stored in that tag, it will be possible that the app could process it directly without redirecting to System app, which means Browser or Contacts won't be launched.

I'll check the engineering effort and file bugs, but ni? for Vincent and Wesley to see if we need this add this feature in v2.2

For me this is a new feature and I would say let's not add new feature at this moment. I agree with that vibration experience defined by UX. For 2.2 as workaround, we rely on privilege app to handle.

(In reply to Yoshi Huang[:allstars.chh] from comment #7) > (In reply to Yoshi Huang[:allstars.chh] from comment #5) > > (In reply to Juwei Huang from comment #4) > > > Hi Yoshi, > > > Thank you for your explanation! > > Hi Juwei > > > > I will try to add the vibration. > > > > But can you update the UX document? > > Because even in the original UX (Bug 894323) it doesn't mention 'vibration'. > > Also you propably need to update the UX for reading URL/vcards as well. > In v2.2 branch, if the foreground app could handle the URL or vcards stored > in that tag, it will be possible that the app could process it directly > without redirecting to System app, which means Browser or Contacts won't be > launched. Hi Yoshi, Do you mean that people may get the contact but contact app won't open up immediately?

(In reply to Juwei Huang from comment #10) > Hi Yoshi, > Do you mean that people may get the contact but contact app won't open up > immediately? If the foreground app can handle vcards, yes. Otherwise foreground app should tell Gecko it cannot process this content and Gecko will re-dispatch it to System app, which will launch Contacts app.

(In reply to Juwei Huang from comment #4) > Hi Yoshi, > Thank you for your explanation! > > From UX perspective, I still strongly prefer "vibrate" when the device > receive things from NFC tag. It is a sign whether people would know if the > device really detect NFC tag or not, otherwise people won't got any feedback > and it's also inconsistent with the normal NFC transfer (like p2p sharing) > Is there any other way to vibrate the phone? > Let me know, > Thank you! Other than "vibrate", does it make sense to allow use to select the action when reading a tag. We can have options such as "vibrate" and "sounds".... The question is should we allow application developer to decide the action when reading a tag or it's limited by system app.

(In reply to Vincent Chang[:vchang] from comment #12) > > Other than "vibrate", does it make sense to allow use to select the action > when reading a tag. We can have options such as "vibrate" and "sounds".... > The question is should we allow application developer to decide the action > when reading a tag or it's limited by system app. I prefer we file a seperate bug for this.

ni? for Juwei again for no response in 2 weeks.

Spec updated. I only update the "vibration" part, because from ux perspective on comment 11, I highly recommend that opening contact app when users receive vcard, otherwise users won't know if they really receive the contact or not. Same situation as URL. If URL cannot be opened while reading a URL tag, it won't be make any sense....