947139 - [DSDS][Message] Send message via default SIM

Status: VERIFIED FIXED

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

Description

[Wilfred Mathanaraj [:WDM]]

As a user when I  tap the  button "Send" in the Messaging App I want to send via the default SIM

Acceptance Criteria:

AC1: I dont want to see any options to select subscription options

Comment 1

[Julien Wajsberg [:julienw]]

I think this is already the current behavior, right?

Is this story only existing to check that the behavior is still right after 1.4?

Comment 2

[Julien Wajsberg [:julienw]]

Maybe the only question: is what we call here the "default" SIM actually the "active" SIM? I mean, say:
* say SIM 1 is your currently active SIM, let's say it's the default one
* you receive a MMS on SIM2
* you press "download"
* when the dialog pops up, you agree to switch to SIM2

Then what? Is SIM2 the new default SIM? I mean, if I send the next message, will it be sent through this SIM. I think this would actually makes sense if the user stays on the same thread, but not if he navigates away, though I think this distinction is not really planned.

Ayman, I think this is a question for you.

Comment 3

[Julien Wajsberg [:julienw]]

On the UX wireframes, it's describred that we need to put the active SIM id in the send button. So we need new VD to do this correctly.

Comment 4

[Julien Wajsberg [:julienw]]

Attachment: FFOS_MessagesAppCommsApp_DSDS_V1.4_20140128_V3.0.pdf

UX reference, page 7

Comment 5

[ayman maat :maat]

(In reply to Julien Wajsberg [:julienw] from comment #2)
> Maybe the only question: is what we call here the "default" SIM actually the
> "active" SIM? I mean, say:
> * say SIM 1 is your currently active SIM, let's say it's the default one
> * you receive a MMS on SIM2
> * you press "download"
> * when the dialog pops up, you agree to switch to SIM2
> 
> Then what? Is SIM2 the new default SIM? I mean, if I send the next message,
> will it be sent through this SIM. I think this would actually makes sense if
> the user stays on the same thread, but not if he navigates away, though I
> think this distinction is not really planned.
>
> Ayman, I think this is a question for you.

I am following the DSDS guidelines produced by Carrie. I think it would be better if she addressed this as the behaviour has to be consistent across the device. ni? to carrie to address

Comment 6

[Carrie Wang [New account: [e-mail]]]

Given that we don't do temporary auto-switch (MMS) for users, if the user taps "OK" on the confirm window of switching SIM, the primary SIM will be switched to the other SIM in settings (which means the SIM indication on button will be changed as well). Thanks!

Comment 7

[Julien Wajsberg [:julienw]]

So Carrie, I think we need to use always the same words. You're using "primary" here, whereas comment 0 says "default". And to be fair I'd rather say "active", because this is closer to the reality.

But thanks, this is clear now.

So this bug is about changing the button's title.

Comment 8

[José Vittone]

Attachment: DSDS.sms_0000_DSDS-1-line.png

Visuals and visual specs related to DSDS.

Comment 9

[José Vittone]

Attachment: DSDS.sms_0003_DSDS-multiple-lines.png

Comment 10

[José Vittone]

Attachment: DSDS.SMS-MMS.Inbox.png

Comment 11

[José Vittone]

Attachment: DSDS.SMS-MMS.message_time.png

Comment 12

[José Vittone]

Attachment: DSDS.SMS-MMS.sim_picker.png

Comment 13

[José Vittone]

Attachment: SPEC_DSDS.SMS.compose.png

Comment 14

[José Vittone]

Attachment: SPEC_DSDS.SMS.inbox.png

Comment 15

[José Vittone]

Attachment: SPEC_DSDS.SMS.sim_picker.png

Comment 16

[José Vittone]

Attachment: SPEC_DSDS.SMS.thread.png

Comment 17

[José Vittone]

Attachment: icon-long-tap-indicator.zip

Comment 18

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

features should not block release, remove blocking flag

Comment 19

[Wilfred Mathanaraj [:WDM]]

it needs QA work to confirm nothing is broken plus "always ask" type option is supported.

Comment 20

[Julien Wajsberg [:julienw]]

I'm separating the "always ask" part to bug 974315, because it will need the UI from bug 947140 done first.

This bug will be only about updating the button's title.

Comment 21

[Julien Wajsberg [:julienw]]

José, just to be sure here:

in attachment 8374272 [details], I just want to confirm that the one-line composer must be slightly higher when the SIM information is displayed. Should it be higher also when we don't see the SIM information, or should we keep it as it is now in this case?

Comment 22

[José Vittone]

Hi Julien, good question. We should keep it as it is now only for this case. If there is no SIM info, it should not be higher.

Comment 23

[Paul Yang [:pyang] (away)]

https://moztrap.mozilla.org/manage/cases/?pagenumber=1&pagesize=20&sortfield=created_on&sortdirection=desc&filter-tag=2537
Moztrap+

Comment 24

[Julien Wajsberg [:julienw]]

Carrie, Ayman, just want to mention that SMS and MMS do not use the same option. That especially means that we'll possibly change the value shown ("SIM1", "SIM2") when the message type is changed from SMS to MMS or MMS to SMS, if the configured default SIM is different. Is that expected from you?

Comment 25

[Carrie Wang [New account: [e-mail]]]

Hi Julien, 

For MMS, I think this is a really big issue. If we switch the option for users when they are composing a MMS, which means the SIM indication on the send button will show Data's primary SIM and users can long-tap it to switch the SIM for sending a specific MMS (and then data connection will switch back to the default SIM). However, for now, we can't do one-time switch for data connection. If they want to switch data SIM, the setting in SIM manager should be changed as well (remember the MMS retrieve flow in 1.3?). Hence, the whole on-the-fly SIM switch logic will be broken.  
 
I'd suggest that the option (send button) we use for MMS can be the same with SMS. Although MMS is sent via data connection, the users may still have the concept that the message will be sent via this "phone numbers". In this way, if the primary SIM for message is different from the one for data connection, we can adopt the same flow as MMS retrieve in 1.3 (pop up a confirm window to tell users that we are gonna switch the data connection to the other SIM and they can switch it back in SIM manager).

This is my point of view from the general DSDS guideline, but I'd like to hear Ayman's suggestion on it from APP owner side. Thanks! :)

Comment 26

[Julien Wajsberg [:julienw]]

>  If they want to switch data SIM, the setting in SIM manager should be changed as well (remember the MMS retrieve flow in 1.3?). 

Yep, it's the same setting anyway.

Your proposal makes sense to me (even if that makes the feature more complicated to code ;) ). If we go that way, I feel we need to change the wording in the Settings' SIM manager page though, because it's clearly said that the "Data" setting is used for "MMS" (which is a technical reality). What do you think?

Comment 27

[ayman maat :maat]

(In reply to Julien Wajsberg [:julienw] from comment #24)
> Carrie, Ayman, just want to mention that SMS and MMS do not use the same
> option. That especially means that we'll possibly change the value shown
> ("SIM1", "SIM2") when the message type is changed from SMS to MMS or MMS to
> SMS, if the configured default SIM is different. Is that expected from you?

Unfortunately the problem of default message SIM not being the same as default data SIM and us not having a temporary data switch is why i was previously pushing to get the temporary data switch implemented as a priority. It would instantly solve this and several other DSDS IxD problems which are bubbling away. 

The problem with the solution you are prescribing is as follows:

**PRERETIREMENT**
p1) SIM1 is set to send message
p2) SIM2 is set to data

**PATH**
1) Open either new message composer or existing message thread
2) Follow any path that switches the message in composition from SMS to MMS 
3) indication on CTA is switched from SIM1 to SIM2 to facilitate the sending of the MMS

The problem with this solution is:
3.1) User orientation and cognitive load - 
The user is not informed why the CTA has switched from SIM1 to SIM2 and we are relying on them to understand (understand the difference between MMS and SMS) and remember (remember that they have set data setting - possibly some time ago) in order for them to comprehend why this switch has taken place. That requires a level of intimacy with the phone that I would propose only a significant number of upper intermediate and expert users would have.

3.2) MMS must be sent from SIM1 - 
The user might only want the MMS to be sent from SIM1, however the CTA label changing behaviour implies to the user that it can only be sent from SIM2. Again in terms of user recovery from this cul-de-sac (i.e. the user enabling the sending of the MMS via SIM1) we come to the orientation and cognitive loading issue outlined in 3.1

3.2) Remove long press option  
When the CTA label is changed from SIM1 to SIM2 we would also have to remove the log press behaviour from the CTA as the user cannot send from SIM1 so it makes no sense to maintain it. Again removing this functionality introduces similar usability implications as outlined in 3.1 as well as compounding the issue detailed in 3.2 for users who have less expertise than upper intermediate.  

Therefore as is, I cannot recommend this proposition.
 

(In reply to Carrie Wang [:carrie] from comment #25)
> Hi Julien, 
> 
> For MMS, I think this is a really big issue. If we switch the option for
> users when they are composing a MMS, which means the SIM indication on the
> send button will show Data's primary SIM and users can long-tap it to switch
> the SIM for sending a specific MMS (and then data connection will switch
> back to the default SIM). However, for now, we can't do one-time switch for
> data connection. If they want to switch data SIM, the setting in SIM manager
> should be changed as well (remember the MMS retrieve flow in 1.3?). Hence,
> the whole on-the-fly SIM switch logic will be broken.  

We also should avoid permanently changing the default data SIM like this for further reason that no other DSDS device I am aware of behaves this way. Therefore we are potentially providing a UX that sits outside of the establish cognitive model that the end user has and so increase the risk of error (them not realising that Data has been permanently switched) which, due to data switching from one SIM to the other leads to detrimental cost implications for the user…. and those cost implications will potentially not be come apparent to the user until they either run out of credit early (on pre pay) or receive their bill (on post pay) which in both instances does not look good.

> I'd suggest that the option (send button) we use for MMS can be the same
> with SMS. Although MMS is sent via data connection, the users may still have
> the concept that the message will be sent via this "phone numbers". In this
> way, if the primary SIM for message is different from the one for data
> connection, we can adopt the same flow as MMS retrieve in 1.3 (pop up a
> confirm window to tell users that we are gonna switch the data connection to
> the other SIM and they can switch it back in SIM manager).
> 
> This is my point of view from the general DSDS guideline, but I'd like to
> hear Ayman's suggestion on it from APP owner side. Thanks! :)

If I am interpreting what Carrie is proposing i would say that this is the only option that fits within the currently defined DSDS framework. For clarity this is how understand the proposition:

**PRERETIREMENT**
p1) SIM1 is set to send message
p2) SIM2 is set to data

**PATH**
1) Open either new message composer or existing message thread
2) Follow any path that switches the message in composition from SMS to MMS 
3) Indication on send CTA remains as SIM1
4) Long press behaviour on CTA remains
5) Tap to select ‘Send’
5.1) Present the user with a dialogue informing them that they are trying to send an MMS Via SIM1 but data is set to SIM2 and that if they ‘continue’ Data will be permanently switch data from SIM2 to SIM1.
5.1.1) Select ‘continue’ (or appropriately worded CTA) in dialogue described in 5.1. 
	- Data is permanently switched from SIM2 to SIM1
	- MMS is sent via SIM1
	- User has to navigate to SIM manager in order to switch data back from SIM1 to SIM2
5.1.2) Select ‘cancel’ (or appropriately worded CTA) in dialogue described in 5.1. 
	- dialogue described in 5.1 is closed
	- user is returned to the view they launched the dialogue described in 5.1 from
6) Long press ‘Send’ CTA
	- Present user with SIM options
7) Select SIM1 in SIM options dialogue
7.1) Present the user with a dialogue informing them that they are trying to send an MMS Via SIM1 but data is set to SIM2 and that if they ‘continue’ Data will be permanently switch data from SIM2 to SIM1.
7.1.1) Select ‘continue’ (or appropriately worded CTA) in dialogue described in 5.1. 
	- Data is permanently switched from SIM2 to SIM1
	- MMS is sent via SIM1
	- User has to navigate to SIM manager in order to switch data back from SIM1 to SIM2
7.1.2) Select ‘cancel’ (or appropriately worded CTA) in dialogue described in 5.1. 
	- dialogue described in 5.1 is closed
	- user is returned to the view they launched the dialogue described in 7 from


Am I interpreting that correctly?

..Either way we should, however, get that Temporary Data Switch implemented as a matter of priority.

Comment 28

[ayman maat :maat]

ni? to carrie regarding point 1 to 7.1.2 in comment 27

Comment 29

[Julien Wajsberg [:julienw]]

Attachment: SIM manager's page to support the discussion

Comment 30

[Carrie Wang [New account: [e-mail]]]

Hi guys, 

Summarize some points from these comments.

1. Providing automatic data switch should be our high priority (totally agree with this!). 
2. If we can't make it in 1.4, the compromised solution would be adopting the SMS CTA for MMS, and if the primary SIM of SMS is different from the one for data connection, then a confirm window will pop up to inform users and ask for permanent switch for them when they try to send a MMS from SMS's primary SIM. 
3. We shall then change the description for Data setting in SIM manager. I'd suggest "Internet connection and Marketplace payments will be set to" (I don't think users will understand what A-GPS is).

Comment 31

[Julien Wajsberg [:julienw]]

I don't see the automatic data switch happening for 1.4 given our deadline and the strict rules.

So let's do 2 and 3, I'm fine with this. I'll file a bug for Settings for 3.

Comment 32

[Julien Wajsberg [:julienw]]

Filed bug 976576.

Comment 33

[Julien Wajsberg [:julienw]]

Taking but I'm not sure I'll be able to start today (probably more tomorrow) so feel free to take it back from me if you see no update.

Comment 34

[Julien Wajsberg [:julienw]]

Some early work at https://github.com/julienw/gaia/compare/947139-send-default-sim

Comment 35

[Julien Wajsberg [:julienw]]

Pushed a new version, containing the commit for Bug 981711.

What's left:
* implementation of the confirm switch for comment 30, point 2: should be quite quick
* doing the CSS right: I'm not that good but I surely hope to have a first patch tomorrow.

Comment 36

[Julien Wajsberg [:julienw]]

Pushed a new version.
* still not the updated CSS
* has the confirm switch, but the switch itself should be differently (sadly found that only at the end of the day)

Comment 37

[Julien Wajsberg [:julienw]]

Pushed a new version:
* CSS looks fine now. Note: there seems to be a driver issue on the Fugu that makes the top of the send button's background have a line, I could reproduce with a simple testcase (bug 982712) but this looks to be a driver issue because I didn't reproduce with the Peak. Didn't investigate much more than this.
* started refactoring some things so that it will be easier to integrate the Dialer's CallButton work.

I also discussed with Ayman about how to give feedback while we switch the SIM for the data connection, for sending a MMS. This will be done in a follow-up (to be filed), but the idea is to have a modal with a cancel button.

Comment 38

[Julien Wajsberg [:julienw]]

(In reply to Julien Wajsberg [:julienw] from comment #37)

> * started refactoring some things so that it will be easier to integrate the
> Dialer's CallButton work.

Some notes about this: I'll get the serviceId as parameter of MessageManager's sendSMS and sendMMS; MessageManager will handle switching the MMS serviceId.

I'm not sure yet if I'll do more than this now, probably not given the time constraints we have.

Comment 39

[Julien Wajsberg [:julienw]]

Attachment: github PR

Hey Steve,

Would be nice if you had some time to give an early feedback on this patch.

It's now fairly complete, but I didn't test it on the device since the latest refactoring.

Be careful, there are 2 commits in the pull request because I cherry-picked the patch for bug 981711, so please only review the commit for this bug 947139.

Thanks!

Comment 40

[Doug Sherk (:drs) (inactive)]

I'm working on top of these changes so I figured I'd point out that the current SIM indicator doesn't seem to be updated when I change my settings. I poked around and didn't see SettingsListener anywhere. Just a note, I know you're still working on this :)

Comment 41

[Julien Wajsberg [:julienw]]

Yep Doug, that's what I said in https://github.com/mozilla-b2g/gaia/pull/17139#discussion-diff-10546915 :)

I figured that if we integrate Dialer's CallButton we'll get this for free and so I didn't want to do it here :)

We don't use SettingsListener but we do use mozSettings.addObserver in [1]. We should use SettingsListener though because we basically replicated its functionality.

[1] https://github.com/mozilla-b2g/gaia/blob/master/apps/sms/js/settings.js#L76

Comment 42

[Julien Wajsberg [:julienw]]

Comment on attachment 8390123 [details] [review]
github PR

Hey Francisco,

I think this is ready for a review now.

Thanks!

Comment 43

[Francisco Jordano [:arcturus] [:francisco]]

Comment on attachment 8390123 [details] [review]
github PR

Great work Julienne!

Please merge once travis is green :)

Comment 44

[Julien Wajsberg [:julienw]]

Travis Green !

master: 29a990ac0347c057ef6998cb42e4548768a18559

thanks !

Comment 45

[Jason Smith [:jsmith]]

Flagging checkin-needed for backout - this causes a very bad regression in the SMS app when sending any type of MMS in bug 983858.

Comment 46

[Ryan VanderMeulen [:RyanVM]]

Sorry, this doesn't backout cleanly. Gonna need somebody familiar with this code to do it :(

Comment 47

[Jason Smith [:jsmith]]

Argh. Okay. I'll discuss this with the comms team on Monday.

Comment 48

[Eric Chang [:ericcc] [:echang]]

Works fine with this
Gaia      d2651c13d6370d62bf833b31c7e2e5f054510136
Gecko     c8a17e25111585c0eebb829f8208190ea432c71e
BuildID   20140318053055
Version   30.0a1