862764 - [MMS][User Story] When sending MMS, need to notify user to turn on the data connection if they use share APN and data connection off.

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::SMS, defect, P2)

Description

[Gene Lian (I already quit Mozilla)]

It'd be better to automatically turn on the Data Connection when the FFOS attempts to send an MMS, instead of popping up a prompt to ask user to manually do that.

Comment 1

[Alex Keybl [:akeybl]]

Sorry, errant leo+

Jaime - can you help weigh this against the user impact of unexpected data usage? We suspect this will likely be blocking-b2g:-

Comment 2

[Lukas Blakk [:lsblakk] use ?needinfo]

Some questions:
* Do any other features auto-enable data?
* Do we have user-facing notification already existing for this scenario?
* Was this part of the plan for v1.1 MMS implementation?

Gordon and Casey will dig in deeper on this and report back, leaving the nom for now.

Comment 3

[Gordon Brander :gordonb]

More questions:

* What is the contract with the user? Do they expect data to be used? (e.g. is MMS used primarily for sending pictures, video, etc?)
* How often do you need data on when using MMS? 30% of the time? 80%?
  If infrequently, asking is probably wise. If frequently, asking becomes a frustration.

Comment 4

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

According to the comment 24 from Dylan Oliver in bug 840076, this is not v1.1 feature.

Comment 5

[Dylan Oliver [:doliver]]

Triage: new feature request, not blocking leo.

Comment 6

[Stephany Wilkes]

Adding Gordon on needinfo for tracking, since he's helping out on this with Casey. Clearing the needinfo for Jaime.

Comment 7

[Casey Yee]

MMS requires a mobile data connection to work.

It would be quite annoying to have to manually switch on your data just to send a messages and turn it off again after your done sending.   Besides this, most users are also not aware that MMS requires a data connection to work, so it may be confusing when they are prompted to turn on data.

When we switch On the data connection we should prevent background applications from leaking data by allowing only data to pass through the MMS APN only.   Data leakage may be a issue in cases where the carrier uses the same APN for both Data and MMS.   

AFAIK, other OS's will automatically switch on data temporarily to send MMS messages.


(In reply to [e-mail] from comment #2)
> Some questions:
> * Do any other features auto-enable data?

Just MMS.

> * Do we have user-facing notification already existing for this scenario?

That is the fall-back if we cannot get data to turn on temporarily to enable MMS to work.   This makes for some pretty bad UX though.   

> * Was this part of the plan for v1.1 MMS implementation?

No this was not.   

(In reply to Gordon Brander :gbrander from comment #3)
> More questions:
> 
> * What is the contract with the user? Do they expect data to be used? (e.g.
> is MMS used primarily for sending pictures, video, etc?)

Generally speaking No.   MMS is usually billed on a per message basis and is delivered using a separate APN so there is no data usage billed.


> * How often do you need data on when using MMS? 30% of the time? 80%?
>   If infrequently, asking is probably wise. If frequently, asking becomes a
> frustration.

All the time.  MMS requires mobile data to be turned on to send or receive data.

Comment 8

[Stephany Wilkes]

Clearing Gordon on needinfo as Casey seems to have covered it.

Comment 10

[Maria Angeles Oteo (:oteo)]

We need to prioritize this bug and flag it as leo+. 

As JA has explained in bug 879780 when the carrier does not share the same APN for data and for MMS traffic (as it happens in Spain and many Latam countries) the data connection for MMS traffic must be set up automatically without user interaction.

Right now, this is not happennig because when the device uses the same APN for data calls and for MMS service the RIL doesn't set up the data call when sending (before sending it actually) a MMS message.

I/Gecko   (  595): -@- MmsService: acquire: buffer the MMS request and setup the MMS data call.
I/Gecko   (  595): -*- RadioInterfaceLayer: Setup secondary APN type mms which goes through default APN.
I/Gecko   (  595): -*- RadioInterfaceLayer: Data call settings: nothing to do.

In fact, if the user has not enabled data calls before we bail out at [1] and therefore the MMS cannot be sent.

[1] https://mxr.mozilla.org/mozilla-central/source/dom/system/gonk/RadioInterfaceLayer.js#1267

Comment 11

[Dietrich Ayala (:dietrich)]

Talked in triage - blocking+ to address the *problem*, which is that the user doesn't know why sending doesn't work.

The bug summary is overly proscriptive. There is a lot of risk in automatically turning on data - many use-cases where the user can get hurt by it. I'm worried that we don't have the time left in 1.1 to make this change in a safe way.

Instead, for v1.1 we should address the problem in the most minimal way possible: Alert the user that data is not turned on.

Comment 12

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

Ayman, how do you think below use case.
1. We send an MMS with no data connection off with share APN.
2. Show an error on the bubble message and pop up an alert to ask user turn on the data connection.
3. If send successfully, pop up an alert to ask user turn off the data connection.

Thanks

Comment 13

[ayman maat :maat]

(In reply to Chia-hung Tai [:ctai :ctai_mozilla :cht] from comment #12)
> Ayman, how do you think below use case.
> 1. We send an MMS with no data connection off with share APN.
> 2. Show an error on the bubble message and pop up an alert to ask user turn
> on the data connection.
> 3. If send successfully, pop up an alert to ask user turn off the data
> connection.
> 
> Thanks

I don't like it one bit because it is a really clunky protracted interaction with an unnecessarily high risk of end user error. 

Basically this is the user is flow you are prescribing if the users tries to send an MMS with data connection off:

1)  Compose and send MMS with data connection turned off
2)  Message errors upon sending and the user is presented with a full screen messages informing them that they 'must turn on their data connection in order to send the message'. The message will have a single CTA - 'OK'
4)  Upon selecting 'OK' the user is presented with the message thread and their last outgoing message in 'error' state. 

<human error point 1> At this point the user has to know where to find the Data Connection switch

5)  User selects 'home' button and is presented with the whatever home screen they were looking at when they entered the application
6)  User navigates home screen to find Settings icon
7)  User selects settings icon
8)  User selects 'Cellular and Data'
9)  User selects Data Connection to turn it on
10) User presses the home button (this is presuming the user does not user the power user path - which is what long press on the home button is in order to view a list of open applications)
11) User selects the the messages app icon and is presented with the message thread with the outgoing message in error state 
12) User selects the outgoing message in error state and is presented with a full screen messages informing them that 'the message could not be sent. Try again?'. The message will have two CTAs - 'cancel' and 'OK'
13) User selects ok
14) User is presented with the message thread with the resent message in send state 

<human  error point 2> The user could navigate away from the app at this point whilst the message is in send state meaning that any subsequent in app messages will be missed

15) (presuming the message is successfully sent and the end user has not left the messages app) the thread is overlaid with a message informing them that they 'should turn off their data connection'. The message will have a single CTA - 'OK'
16) User selects OK

<human  error point 3> To protect the user we are relying on them to act upon the message detailed in 15) immediately and not be distracted / interrupted be anything else in their digital or physical environment

17)  User selects 'home' button and is presented with the home screen they were on in step 11)
18)  User selects settings icon
19)  User selects 'Cellular and Data'
20)  User selects Data Connection to turn it off ...and goes to lie down, exhausted with the effort they have just expended



Nevertheless point 1) to 14) (minus point 8) parallels the experience of the intermediate user (no shortcuts taken due to limitation of knowledge / confidence) if 'flight mode' is activated. This is due to the fact that we do not have any alert screens in building blocks that deep link into settings.

In view of this, and with reference to comment 11, i think what you proscribe in comment 12 is the only design path open to us. 

This bug does however put another point to the argument that we should be reviewing and looking to improve the alerts and error messaging behavior / dialogues as a horizontal across all the apps in V1.2

Comment 14

[Dietrich Ayala (:dietrich)]

Ayman, thanks for the detailed analysis.

Can you be more specific in fewer words with your recommendation?

Eg: "use a toast to notify the user that the data connection must be enabled in order to send a message."

Recommending the string to use would also be appreciated, thanks!

Comment 15

[Steve Chung [:steveck]]

Hi Ayman,
I think it's doable that we can turn on the data connection directly in message app if we change the message app manifest. Could we popup a confirm dialog that user to notify user that we can't send mms without data network and click ok here could enable the network? The behavior should be the same after sending and user can close the connection directly from dialog(or is it necessary to popup a dialog to remind user after message sent?).

Comment 16

[Ignacio Barandalla]

Hi all,

The comments from Casey Yee are exactly what the MMS user and the mobile operator expects. MMS users don't know that to send/receiving a message you are a packet switched (PS) connection. Remember that MMS was built for users that were used to SMS (that do not use PS connections, but only Circuit Switched ones), in a world without flat data rates for PS. 

That is why MMS uses the PS data but completely transparently to the user. And that is why MMS uses a different APN, or the same APN but with a special consideration for the traffic that goes through the MMS Center: that traffic is not charged "per byte" (per volume). Instead, it is charged by event: sent message. Please note that this was created as a kind of "flat rate" for a message, to avoid that the user would need to worry about the size of the message, and to simplify the pricing communication to the customer.

Please note also that PS data can be very expensive for users without a flat rate, and particularly for users with prepaid plans.

Therefore, showing any message to the user about data being turned on to send a multimedia message would be very confusing and worrying. The user would indeed complain and call the customer attention number, claiming that the operator is already charging 1 message and on top of it now the customer is going to be charged for the data! Before approving a device with this MMS implementation, I am afraid that the operators may prefer to deactivate MMS until it works transparently.

You can try it in an Android phone: disable data, then send an MMS to yourself: you will send it and receive it without any icon or popup appearing about data. Not even the "transmitting/receiving data appears"! This is because the "disable data" switch does not disable the MMS APN. The only switch that disables it is of course the flight mode.

I hope this helps to clarify the importance of this implementation.

Comment 17

[ayman maat :maat]

canceling need info and referencing comment 16 where definitive requirements for functionality are detailed.

Comment 18

[Vicamo Yang [:vicamo][:vyang]]

I totally agree with you, and that's why I had bug 782513 comment 12 9 months ago.  But there are two things in concern:

1. how much time do we still have?
2. fix this in Mozilla RIL doesn't follow it's also fixed in shipped devices.

For me, I only need a clear answer for 1).

Comment 19

[Beatriz Rodríguez [:brg]]

(In reply to Dietrich Ayala (:dietrich) from comment #11)
> 
> Instead, for v1.1 we should address the problem in the most minimal way
> possible: Alert the user that data is not turned on.
I am sorry to say that this behaviour will block the certification process. As it has been commented, MMS should be sent without any additional confirmation from the user side because they are tariffied separately from data tariff.

Comment 20

[José Antonio Olivera Ortega [:jaoo]]

I've been poking around this issue and comparing behaviors between Android and B2G. AOSP works in the same way, I mean, there is no any request to the user asking for enabling data calls before sending the MMS message when data calls are disabled. If data calls are disabled AOSP doesn't bring up the networking interface for sending the message. On the other hand I managed to have a try with another device on Android (this device is certified by Telefonica and customized for Telefonica subscribers). I ran the same test (send a MMS message with data calls disabled) and I was managed to send the MMS. So both B2G and AOSP right now have the same behavior when sending a MMS message without enabling data calls (the message is not sent) and there is no any alert informing the user or asking for enabling data calls. On the other hand It seems the carrier might customize the MMS messaging process and allow to send MMS messages even when data calls are disabled. It confirms what Ignacio commented in comment #16 and I guess we should allow this kind of customization in B2G as well otherwise we could have a certification blocker here. Thoughts?

Comment 21

[José Antonio Olivera Ortega [:jaoo]]

(In reply to José Antonio Olivera Ortega [:jaoo] from comment #20)
> I've been poking around this issue and comparing behaviors between Android
> and B2G. AOSP works in the same way, I mean, there is no any request to the
> user asking for enabling data calls before sending the MMS message when data
> calls are disabled. If data calls are disabled AOSP doesn't bring up the
> networking interface for sending the message. On the other hand I managed to
> have a try with another device on Android (this device is certified by
> Telefonica and customized for Telefonica subscribers). I ran the same test
> (send a MMS message with data calls disabled) and I was managed to send the
> MMS. So both B2G and AOSP right now have the same behavior when sending a
> MMS message without enabling data calls (the message is not sent) and there
> is no any alert informing the user or asking for enabling data calls.

Let me clarify this a bit. The MMS is not sent in B2G because both APNs for data and for MMS service have the same APN name. So B2G assumes this is a shared APN right now.

> On the
> other hand It seems the carrier might customize the MMS messaging process
> and allow to send MMS messages even when data calls are disabled. It
> confirms what Ignacio commented in comment #16 and I guess we should allow
> this kind of customization in B2G as well otherwise we could have a
> certification blocker here. Thoughts?

Comment 22

[Beatriz Rodríguez [:brg]]

(In reply to José Antonio Olivera Ortega [:jaoo] from comment #20)
> I've been poking around this issue and comparing behaviors between Android
> and B2G. AOSP works in the same way, I mean, there is no any request to the
> user asking for enabling data calls before sending the MMS message when data
> calls are disabled. If data calls are disabled AOSP doesn't bring up the
> networking interface for sending the message. On the other hand I managed to
> have a try with another device on Android (this device is certified by
> Telefonica and customized for Telefonica subscribers). I ran the same test
> (send a MMS message with data calls disabled) and I was managed to send the
> MMS. So both B2G and AOSP right now have the same behavior when sending a
> MMS message without enabling data calls (the message is not sent) and there
> is no any alert informing the user or asking for enabling data calls.
Thanks a lot for the investigation.
> On the
> other hand It seems the carrier might customize the MMS messaging process
> and allow to send MMS messages even when data calls are disabled. It
> confirms what Ignacio commented in comment #16 and I guess we should allow
> this kind of customization in B2G as well otherwise we could have a
> certification blocker here. Thoughts?
Yes, we need a mechanism to allow the customization of sending MMS (without asking user confirmation) when data is disable for specific countries/carriers. This is a blocker for launching.

Comment 23

[Noemí Freire (:noemi)]

Hi,

Bug 883746 and Bug 883772 have been opened in order to offer full coverage (customized) to MMS behavior when data off without asking for user's confirmation

Comment 24

[Alex Keybl [:akeybl]]

New feature, so milestoned for QE3 (6/24). Also leo+'d and milestoned bug 883772.

Comment 26

[Noemí Freire (:noemi)]

Just clarifying that the expected behavior for TEF when data off is that MMS will be transparently sent (without user interaction), no matter whether mms (apn, usr,pwd) is equal to data (apn,usr, pwd) or whether user is in roaming or not. Notice that it will block certification process.

Comment 27

[Fabien Cazenave [:kaze]]

To be consistent with the rest of our features, we should not enable the Data connection without requesting it to the user — especially if this is likely to be an extra cost.

However, given our timeframe and if we can come up with a list of providers that don’t charge extra fees to send MMS attachments, we could add an `mmsAutoConnect' attribute to our operator_variant.xml database for those providers. This attribute would be assumed to be false by default (= do not send any MMS attachment if the data connection is off).

For the cases where `mmsAutoConnect' is false we’ll need a simpler UX to quickly enable data connection (at least temporarily, to send MMS attachments). I had a talk with Ayman about that yesterday, he’ll get back with wireframes soon — but maybe we could address this operator_variant solution first, and open another bug for the `mmsAutoConnect == false' case.

Comment 28

[José Antonio Olivera Ortega [:jaoo]]

(In reply to Fabien Cazenave [:kaze] from comment #27)
> To be consistent with the rest of our features, we should not enable the
> Data connection without requesting it to the user — especially if this is
> likely to be an extra cost.

By default B2G must not send the MMS message when data calls are disabled.

> However, given our timeframe and if we can come up with a list of providers
> that don’t charge extra fees to send MMS attachments, we could add an
> `mmsAutoConnect' attribute to our operator_variant.xml database for those
> providers. This attribute would be assumed to be false by default (= do not
> send any MMS attachment if the data connection is off).

I like this solution, thanks kaze!. The operator variant logic basically sets some carrier-specific settings. It reads the MCC/MNC codes in the SIM and stores in the setting database the setting values for the carrier. For the TEF case (and for other carriers as well) we would set 'mmsAutoConnect' to true and the MMS RIL plumbing would allow to send the MMS message even if data calls are disabled. We would achieve to be fully customizable as It's requested by the certification process.

The feedback from Vicamo and/or Ken Chang would be appreciate! Thanks in advance guys.

We would need to file a bug for adding this support on the gaia side and work in bug 883746 for the gecko part. I would be happy to help here.
 
> For the cases where `mmsAutoConnect' is false we’ll need a simpler UX to
> quickly enable data connection (at least temporarily, to send MMS
> attachments). I had a talk with Ayman about that yesterday, he’ll get back
> with wireframes soon — but maybe we could address this operator_variant
> solution first, and open another bug for the `mmsAutoConnect == false' case.

Comment 29

[Fabien Cazenave [:kaze]]

(In reply to José Antonio Olivera Ortega [:jaoo] from comment #28)
> By default B2G must not send the MMS message when data calls are disabled.

Agreed, thanks for rephrasing.

> the MMS RIL plumbing would allow to send the MMS message even if
> data calls are disabled.

That would be pretty neat! I’d much prefer to handle this in the RIL side, too.

Comment 30

[ayman maat :maat]

Attachment: HTML5_SMS-MMSUserStoryProposal_20130625_Data Connection_V0.1.pdf

This flow is a sketch proposal for how we could handle scenarios where the end user has to manually accept the opening of the data connection. (in most scenarios data connection will be silently opened and closed in the background, nevertheless we have a requirement to also consider manual opening of the connection as well)

The aim of the UX in the flow is to minimise user interaction by only having them 'accept' the temporary opening of the data connection and it automatically closing once the 'send' process has finished (whether send is successful or not)

N.B. this flow is not a specification. I will produce a full specification for it once is thas been validated by Fabien.

..NeedInfo to Fabien to give his feedback on the feasibility / achievability of this flow and any aspects of it that require clarification / amendment.

Comment 31

[Ken Chang[:kenkai]]

(In reply to José Antonio Olivera Ortega [:jaoo] from comment #28)
> 
> The feedback from Vicamo and/or Ken Chang would be appreciate! Thanks in
> advance guys.
> 
It makes sense to me. I updated some ideas on bug 883746.

Comment 32

[Vicamo Yang [:vicamo][:vyang]]

(In reply to Ken Chang from comment #31)
> (In reply to José Antonio Olivera Ortega [:jaoo] from comment #28)
> > The feedback from Vicamo and/or Ken Chang would be appreciate! Thanks in
> > advance guys.
> > 
> It makes sense to me. I updated some ideas on bug 883746.

"If" optionally enabling MMS connection during data off is a must, having that preference in operator_variant.xml makes sense for me, too.

Comment 33

[Ken Chang[:kenkai]]

The solution of sending MMS when data isn't enable is provided on the patch of bug 884829. They have same root cause.
So this issue will only be happened in having customization item.
Ctai, please help this issue.

Comment 34

[Ken Chang[:kenkai]]

Oops! I think this need Gaia's help. Steve, please help.

Comment 35

[Steve Chung [:steveck]]

ok, may I know which key in ril.mms will be utilized in apn operatorvariant?

Comment 36

[Steve Chung [:steveck]]

Hi Ayman, just want to confirm one thing: Do we need to trigger send behavior before connection prompt confirm? If we send the message before confirm, we will put the message in the error status first. when message will resend the message when user click open connection, and left the message in error status if user click cancel. If we send the message after user confirm, message will be sent only after user click confirm and message will not be saved in database if click cancel. The wireframe seems apply the later one, but just want to confirm the behavior again because it might related to some gecko change for the first implementation.

Comment 37

[Tony Chung [:tchung]]

need testcases for late feature

Comment 38

[Steve Chung [:steveck]]

Ayman, sorry for one more question: Should we connect/disconnect the data connection for user? Open the connection is easy, but it's hard to determine when should be disconnected. If user downloads other file or update while connection is open for sending mms, should we disconnect right after the message sent? How about we just notify user that the data connection should be open for mms message sending?

Hi Beatriz, Chia-hung and I are discussing about the necessity for have a configurable key in apn for popup a notification. Could we just apply this notification mechanism for all the share apn case no matter how the mms charged in each individual case? Thanks.

Comment 39

[Beatriz Rodríguez [:brg]]

(In reply to Steve Chung from comment #38)
> Ayman, sorry for one more question: Should we connect/disconnect the data
> connection for user? Open the connection is easy, but it's hard to determine
> when should be disconnected. If user downloads other file or update while
> connection is open for sending mms, should we disconnect right after the
> message sent? 
Yes, connection for sending the MMS must be closed right after sending the MMS.
>How about we just notify user that the data connection should
> be open for mms message sending?
The expected behavior for TEF when data off is that MMS will be transparently sent (without user interaction), no matter whether mms (apn, usr,pwd) is equal to data (apn,usr, pwd) or whether user is in roaming or not. Notice that it will block certification process.
> 
> Hi Beatriz, Chia-hung and I are discussing about the necessity for have a
> configurable key in apn for popup a notification. Could we just apply this
> notification mechanism for all the share apn case no matter how the mms
> charged in each individual case? Thanks.
I am sorry to say no, this is not accepted in certification. The MMS should be sent in transparent way for our target countries.

Comment 40

[ayman maat :maat]

(In reply to Steve Chung from comment #36)
> Hi Ayman, just want to confirm one thing: Do we need to trigger send
> behavior before connection prompt confirm? If we send the message before
> confirm, we will put the message in the error status first. when message
> will resend the message when user click open connection, and left the
> message in error status if user click cancel. If we send the message after
> user confirm, message will be sent only after user click confirm and message
> will not be saved in database if click cancel. The wireframe seems apply the
> later one, but just want to confirm the behavior again because it might
> related to some gecko change for the first implementation.

The intention behind the design is the latter. That the message will be sent if the user selects the 'open' CTA in wireframe '2. data connection closed dialogue'. If the user clicks the 'cancel' CTA the intention is that they will be returned back to the screen from which they triggered '2. data connection closed dialogue' in exactly the same state it was in before it was triggered. 'Cancel' should not trigger and 'save' or 'discard' behaviour

Comment 41

[ayman maat :maat]

.... sorry i mean 'Cancel' should not trigger *ANY* 'save' or 'discard' behavior. it should simple close '2. data connection closed dialogue' layer.

Comment 42

[ayman maat :maat]

(In reply to Steve Chung from comment #38)
> Ayman, sorry for one more question: Should we connect/disconnect the data
> connection for user? Open the connection is easy, but it's hard to determine
> when should be disconnected. If user downloads other file or update while
> connection is open for sending mms, should we disconnect right after the
> message sent? How about we just notify user that the data connection should
> be open for mms message sending?

As Beatriz states : Connection for sending the MMS must be closed right after sending the MMS.

Comment 43

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

Summary current situation since this bug already change the background from original post by Gene. 
After Bug 884829 landed, the current behaviour of FX OS is you can send/receive MMS no mater data connection is on/off. That is also what TEF want.
Now Leo need two flags to customize this kind of behaviours for other operators(not TEF...).
There are two bugs for receiving MMS(bug 884739) and for sending MMS(bug 883746).
So the bug should be turned to this "when we are not allowed people to send MMS when data connection off(in bug 883746), what is the behaviour should we have?"
According to current UX design by Ayman(see https://bugzilla.mozilla.org/attachment.cgi?id=767095), FX OS will pop up a dialogue to ask USER turn on the data. From Comment 42 Connection for sending the MMS must be closed right after sending the MMS.

Comment 44

[Wayne Chang [:wchang]]

Removing leo+ on this after further discussions with partners.

Comment 45

[Julien Wajsberg [:julienw]]

Hey Joe, should this bug be closed now?

Comment 46

[Joe Cheng [:jcheng] (please needinfo)]

sure let's close it. if needed in the future, please file a new bug. thanks