963531 - NFC: To move implementation of NFC UX from the system app to the various apps interacting with the NFC API.

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: NFC, defect)

Description

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

This is mentioned by Jonas, Junichi-san and Konno-san.

Jonas' opinion is why should we have different UX between writing data to a NFC Tag and a NFC Peer device.

Junichi-san and Konno-san's opinion is it's *NOT* a smooth UX behavior since user has to do the swipe against the other phone. We could just tap the other device and they could start doing some P2P data exchange.

As this should be a UX bug, however I file this at Gecko part first to keep track of it.

Comment 1

[Ken Chang[:kenkai]]

(In reply to Yoshi Huang[:allstars.chh][:yoshi] from comment #0)
> As this should be a UX bug,
Indeed, this is a UX design consideration. ni? Juwei.
Juwei, we are thinking current UX design is too complicate for shrinking UI. What do you say?

Comment 2

[Juwei Huang[:juwei]]

To clarify the questions, there are 2 different NFC scenario : 1. Transfer files to another device (NFC peer) 2. Read/write a NFC tag 
These two behaviour should not be the same since one is an activity that need one side to initiate the action, another is to receive a tag info which is unnecessary having a confirmation. (In terms of writing data to NFC tag, I haven't seen any user cases.... could anyone provide more information? such as bug no. or user story)
Generally the NFC sensor will be physically placed on the back of mobile phones, which means every time when the users want to transfer files to each other, they have to put their phone back-to-back together, so there would be little chance to do active file transferring by one hand.
I guess Junichi-san & Konno-san's concern are about the behaviour to using two hands rather than one hand to complete transferring action, which is bad, I understand. 
However, the behaviour still need an "initiate" action to decide which phone is going to transfer the file, otherwise the two phone would both transfer files to each other, which is not reasonable and not match our user story.
I got some ideas such as shaking phone to initiate file transferring, somehow it depends on whether the device has G-sensor or not. Current design is a relatively stable version for NFC pairing, but any other ideas would be very welcome:)

Comment 3

[Ken Chang[:kenkai]]

Jonas, what is your opinion?

Comment 4

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I don't think we should use the shrinking UI no. It's not at all clear to users that there's a security decision involved. Also, if we think there are security issues with an app using the P2P NFC protocols, then why wouldn't there be security issues with apps writing to NFC tags?

The fact that we are using a privileged API for NFC access seems like enough of a security guard to me.


I do agree that we still need some UI for deciding which phone should initiate a transfer. But I think we should leave that UI up to the app. A simple box that pops up and asks "click to transfer this picture to other phone" seems enough to me.

We could also enable an nfc app which would show up in the "share" webactivity menu. So a user could click "share" from any app and select "tap to phone" from the webactivity menu. This would launch an nfc-sharing app. The app would then automatically send whatever file was shared as soon as it detects that a P2P connection has been established. The app could even displaying a message to the user saying "hold your phone back-to-back with another nfc enabled phone" with a little animation while waiting for the P2P connection to be established.

This has the advantage that it's much more discoverable than the shrinking UI.


What exact UI we want to use is up to the UX team. However the UI should be implemented by the various apps. I don't think we should build the shrinking-ui into the platform.

Comment 5

[arno]

As Juwei pointed out, there always needs to be a UI to avoid unintended sharing of information. If A wants to share something with B and B happens to be running something in the foreground that can be shared, B needs to be prompted for consent. Whatever the UI looks like, it should appear when the two phones are close to each other and needs to be removed when either the user confirms the sharing or the phones are removed from one another. The latter will also require new API (to signal that the other phone was removed). This requires more logic to be handled by the application. I also wonder from a UX perspective if it is good that every application can design their own UI. How do the module owners for browser, dialer, contacts, etc plan to handle this? IMHO it makes more sense to handle this consistently for all apps in the platform. I also don't understand Jonas' suggestion on a "NFC sharing app". What if another (third-party) app also offers to share NFC data? Then you would have two entries in the sharing menu making things more confusing for the user. This could also be a potential security problem if a third-party app can intercept NFC data this way.

Comment 6

[Garner Lee]

This is a more general question: is there a list of a set of consistent widgets or modal dialog boxes user level applications can use already? Examples: file dialogs, modals, error messages, etc.

> I also don't understand Jonas' suggestion on a "NFC sharing app". What if another (third-party) app also offers to share NFC data? 
I think he means the certified status required for current apps should be enough (no 3rd party by nature of the current permissions).

Isn't the "NFC Sharing App" the nfc-manager system app right now? That is, swap Shrink UI for a generalized/skinnable "Sharing APP/UI widget".

Comment 7

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

The reason that I want to leave it up to applications to implement their own UI is so that they can innovate and create something better than what we can think of.

Do we not have an API for when a P2P connection is lost? That definitely seems like something that we should add no matter what. We should keep the API as generic as possible.

The idea of an NFC app is as follows.

1. Create and preinstall an app named "Tap to Share".
2. This app would be a "hidden" app, i.e. it does not show up on the homescreen. (This is a
   capability we already have in B2G)
3. This app should enumerate as being able to handle the "share" webactivity in its manifest.
4. When the app receives a "share" webactivity it displays a message which instructs the user to
   hold up the phone to another phone which supports NFC.
5. When the app detects a P2P connection, it immediately sends the file it received through the
   "share" webactivity.

Now suddenly all apps which supports sharing supports sharing also through NFC.

A variation of the above can be done by combining with the bluetooth sharing app. 

There is no way that an other app can unknowingly to the user intercept an NFC message. The user would have to install an app which is named "Tap to Share" or "Share through NFC" and then select that when sharing. Unlikely something that the user would do accidentally.

I don't think we need to actually implement the above. It's intended to be an example of the type of UIs that can be built if we leave it up to apps to decide what UI to display.

Comment 8

[arno]

we do forward the "technology lost" event to the app. What I meant is that right now the app does not need to react to it. It is basically a no-op since the platform handles the UI.

The question of the UI boils down to what UX elements should be handled by the platform. The status bar and notifications are handled by the platform and it would probably not be a good idea to support innovation by letting apps decide how to handle this. For me the NFC beam functionality should also have one consistent UI across different apps. But if you prefer to let the app decide on the UI then that is what we'll do.

We need to decide the API that supports this. Right now the NFC events are routed to the foreground application. The model of a "NFC sharing app" that gets triggered by a WebActivity would change this significantly. Although this bug is about the UI, perhaps we should shift the discussion on what the NFC sharing API should look like.

Comment 9

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I absolutely think that the UI should be up to the application. Do keep in mind that people will hopefully build things other than sharing over NFC.

What UX our apps implement I'm happy to defer to the UX team. And like I said, the idea of an NFC app which implements the "share" webactivity was more intended as an example of the type of UI that I want applications to be able to build. It's not something that I strongly feel that we need to build right now.

Comment 10

[Ken Chang[:kenkai]]

Juwei, what do you think for Joans' suggestion?

Comment 11

[Juwei Huang[:juwei]]

I do not consider shrinking UI as a security process but an active confirmation instead, like what Arno said. And in UX perspective, I highly recommend NOT to leave apps decide their own UI since users might confuse by various ways to access NFC activity. We should provide a consistent UI for NFC sharing otherwise it will be no pattern at all for users to find out where they can activate it. That's why I defined a general behaviour, which is shrinking UI, for NFC two-device-pairing pattern.

And I do agree with Jonas that shrinking UI may not easy to discover since there's no any "share" menu indicates users to share via NFC. However, in UX perspective, the most valuable part of NFC sharing is the person you want to share file with is right next to you which means you can skip all the complicated pairing process (ex. BT) and share the file directly & physically to the person who sits beside you. So I do not recommend using the same path as BT to pair the device.

As a conclusion, let's stick to shrinking UI for two-devices pairing scenario at the moment and if there's any further requirement of having the second way to let users pairing device, we could consider it as a new requirement/user story in the future roadmap.

Comment 12

[Tomoaki Konno]

I think that shrinking UI may be prepared as default. However, it should be better to allow applications to change the UI since the applications would be able to decide initiation for data transfer without a user operation by their specific protocol. To realize such behaviour, an event handler like “onpeerfound” (NOT onpeeready) just for establishing a session should be prepared between 2 peers.

e.g.
*if default,
mozNFC.onpeerfound = shrinkingUI () {…};

*if an app prefers to other UI etc,
mozNFC.onpeerfound = appUI () {…};

Comment 13

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

If UX decision is to stick with the shrinking UI, then I'm totally fine with that.

I still think that the UI should be up to the application though. Both to enable use cases other than sharing (for example games), and to enable applications to innovate on UIs.

For our internal apps we could write a JS-library which implements the shrinking UI and share between our apps. That way 3rd party apps that want to provide the same UI can simply use that library too.

Comment 14

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

(In reply to Juwei Huang from comment #11)
> And I do agree with Jonas that shrinking UI may not easy to discover since
> there's no any "share" menu indicates users to share via NFC. However, in UX
> perspective, the most valuable part of NFC sharing is the person you want to
> share file with is right next to you which means you can skip all the
> complicated pairing process (ex. BT) and share the file directly &
> physically to the person who sits beside you. So I do not recommend using
> the same path as BT to pair the device.

I think you might misunderstand the UI I was describing. The UI would simply be:

1. User presses "share" button in gallery app
2. User selects "tap to share" in WebActivities menu
3. User sees a page that says "tap your phone to another phone in order to share"
4. User holds his/her phone against another phone
5. Pictures is automatically sent

No need to do any manual pairing.

Comment 15

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

Hi Juwei,
I heard we had the consensus on NFC shrinking UI. Can you point us to the latest revision of UX doc?
For 1.5, assuming the browser app will be replaced by system browser, are we going to update the flow?

Comment 16

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Note that this bug is about API changes. That does not need to mean that we need to make any UX changes. It'd just means that we'd move the code to implement the current UX from the system app to the various apps that interact with the NFC API.

Comment 17

[Ken Chang[:kenkai]]

Change the summary. If I am wrong, please correct me.

Comment 18

[Garner Lee]

For the system to allow an app to securely launch an webapp owned ShrinkUI, we'd need make sure that:

1) The system still enforce permissions to the underlying NFC DOM APIs, and verify the currently associated app: It has a valid DOM, NFCTag, NFCPeer object (sessionToken + manifestURL). This should already be the case.

2) The user can be made to easily understand any app can launch the UI. As user code, the system can't prevent the shared assets from being used in a incorrect or malicious manner.
 --> Maliciousness is prevented largely by #1, but at the system level. The App requires permissions to get a NFC DOM object first anyway, so the call flow should still be natural.

Anything I missed?

Comment 19

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

We're already relying on 1) in order to prevent harm to readable/writable tags. I don't think relying on it for P2P connections makes a big difference.

So basically I think it's fine security-wise if we simply fire the needed events indicating that a P2P connection is available to the current front-most app if that app has permission to use nfc.

Comment 20

[Garner Lee]

I'm putting in Bug 961687 as a (loose) dependency.

Comment 21

[Ben Francis [:benfrancis]]

I just discovered this bug...

(In reply to Jonas Sicking (:sicking) from comment #4)
> I don't think we should use the shrinking UI 
...
> I think we should leave that UI up to the app. 
...
> We could also enable an nfc app which would show up in the "share"
> webactivity menu. So a user could click "share" from any app and select "tap
> to phone" from the webactivity menu. This would launch an nfc-sharing app.
> The app would then automatically send whatever file was shared as soon as it
> detects that a P2P connection has been established. The app could even
> displaying a message to the user saying "hold your phone back-to-back with
> another nfc enabled phone" with a little animation while waiting for the P2P
> connection to be established.

FWIW I strongly agree with this approach and tried to suggest it to people at the beginning. What we have now looks a bit like a rip off of Android, I think having an NFC sharing app accessed via a web activity is much more consistent with the way other sharing works on Firefox OS and is more discoverable.

> What exact UI we want to use is up to the UX team. However the UI should be
> implemented by the various apps. I don't think we should build the
> shrinking-ui into the platform.

Also agree. I was told to land the browser patches for an MWC demo, I didn't realise we would actually ship with this! Though I'm not sure how easy it would be to implement the shrinking UI inside the browser app itself. If we took the approach of an NFC sharing app there would be no work involved for the browser app at all because we already have a share button which would launch the necessary web activity.

Comment 22

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

I want to summarize what should be done in order to reach the same UX but let app take the decision.
1. App should know onpeerfound event
1a. A mechanism to let only foreground active app to receive the event.
(Problem: with nfc or nfc-manager permission should we use?)
2. App should have a way to shrink itself or let system app to shrink when it gets onpeerfound and it thinks, ok now we could pair.
3. When user clicks the app, app use NFC sendNDEF api to perform any transition or animation it wants at the same time.
4. App stops shrinking.

Comment 23

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

(In reply to Alive Kuo [:alive][NEEDINFO!][5/11-5/15@MV] from comment #22)
> 2. App should have a way to shrink itself or let system app to shrink when
> it gets onpeerfound and it thinks, ok now we could pair.

Apps already have the ability to do this using CSS. No need to do it through the system app. I'd rather have that complexity in the individual apps.

> 3. When user clicks the app, app use NFC sendNDEF api to perform any
> transition or animation it wants at the same time.
> 4. App stops shrinking.

Same for these.

I definitely agree that it's some amount of work for apps to do this. But I'd rather have that complexity in apps than in the system app. We can always write a library that helps apps implement this UI.

Comment 24

[Ben Francis [:benfrancis]]

(In reply to Jonas Sicking (:sicking) from comment #23)
> I definitely agree that it's some amount of work for apps to do this. But
> I'd rather have that complexity in apps than in the system app. We can
> always write a library that helps apps implement this UI.

Or an NFC sharing app like the Bluetooth sharing app that the other apps can call via a share activity? It seems odd to me that every app has to implement NFC sharing but not sharing by Bluetooth or email for example.

I'm not sure that apps trying to shrink themselves is going to work out brilliantly, but we could try it.

Comment 25

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

One of the reasons I want to move the shrinking UI from the system app to apps themselves is that that would allow us to do things like the bluetooth sharing app which works over a "share" webactivity.

As things stand how *all* apps are *forced* to use a shrinking UI because it's imposed on them by the system. By moving the UI implementation to apps they can choose to implement a different UI if they want to.

Comment 26

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

adding dependency on Bug 1109495 as this would help us more smoothly migrate to new API.