[DSDS][Message] Send message via default SIM

VERIFIED FIXED in 1.4 S3 (14mar)

Status

Firefox OS
Gaia::SMS
P1
normal
VERIFIED FIXED
4 years ago
4 years ago

People

(Reporter: WDM, Assigned: julienw)

Tracking

unspecified
1.4 S3 (14mar)
x86
Mac OS X
Dependency tree / graph
Bug Flags:
in-moztrap +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [ucid:, 1.4, ft:comms])

Attachments

(13 attachments)

(Reporter)

Description

4 years ago
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
Summary: [DSDS] Send message via default SIM → [DSDS][Message] Send message via default SIM
Blocks: 942446

Updated

4 years ago
Flags: in-moztrap?(pyang)
(Assignee)

Comment 1

4 years ago
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?
Flags: needinfo?(wmathanaraj)
(Assignee)

Comment 2

4 years ago
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.
Flags: needinfo?(aymanmaat)
Whiteboard: [needs UX]
(Assignee)

Comment 3

4 years ago
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.
Whiteboard: [needs UX] → [needs UX][needs VD]
(Assignee)

Comment 4

4 years ago
Created attachment 8368585 [details]
FFOS_MessagesAppCommsApp_DSDS_V1.4_20140128_V3.0.pdf

UX reference, page 7

Comment 5

4 years ago
(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
Flags: needinfo?(aymanmaat) → needinfo?(cawang)
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!
Flags: needinfo?(cawang)
(Assignee)

Comment 7

4 years ago
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

4 years ago
Created attachment 8374266 [details]
DSDS.sms_0000_DSDS-1-line.png

Visuals and visual specs related to DSDS.

Comment 9

4 years ago
Created attachment 8374268 [details]
DSDS.sms_0003_DSDS-multiple-lines.png

Comment 10

4 years ago
Created attachment 8374269 [details]
DSDS.SMS-MMS.Inbox.png

Comment 11

4 years ago
Created attachment 8374270 [details]
DSDS.SMS-MMS.message_time.png

Comment 12

4 years ago
Created attachment 8374271 [details]
DSDS.SMS-MMS.sim_picker.png

Comment 13

4 years ago
Created attachment 8374272 [details]
SPEC_DSDS.SMS.compose.png

Comment 14

4 years ago
Created attachment 8374273 [details]
SPEC_DSDS.SMS.inbox.png

Comment 15

4 years ago
Created attachment 8374274 [details]
SPEC_DSDS.SMS.sim_picker.png

Comment 16

4 years ago
Created attachment 8374275 [details]
SPEC_DSDS.SMS.thread.png

Comment 17

4 years ago
Created attachment 8374277 [details]
icon-long-tap-indicator.zip
features should not block release, remove blocking flag
blocking-b2g: 1.4+ → ---
Whiteboard: [needs UX][needs VD] → [ucid:, 1.4, ft:comms][needs UX][needs VD]
(Reporter)

Comment 19

4 years ago
it needs QA work to confirm nothing is broken plus "always ask" type option is supported.
Flags: needinfo?(wmathanaraj)

Updated

4 years ago
Whiteboard: [ucid:, 1.4, ft:comms][needs UX][needs VD] → [ucid:, 1.4, ft:comms][needs UX]

Updated

4 years ago
Whiteboard: [ucid:, 1.4, ft:comms][needs UX] → [ucid:, 1.4, ft:comms]
(Assignee)

Updated

4 years ago
Blocks: 974315
(Assignee)

Comment 20

4 years ago
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.
(Assignee)

Comment 21

4 years ago
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?
Flags: needinfo?(vittone)

Comment 22

4 years ago
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.
Flags: needinfo?(vittone)

Comment 23

4 years ago
https://moztrap.mozilla.org/manage/cases/?pagenumber=1&pagesize=20&sortfield=created_on&sortdirection=desc&filter-tag=2537
Moztrap+
Flags: in-moztrap?(pyang) → in-moztrap+
(Assignee)

Comment 24

4 years ago
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?
Flags: needinfo?(cawang)
Flags: needinfo?(aymanmaat)
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! :)
Flags: needinfo?(cawang)
(Assignee)

Comment 26

4 years ago
>  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?
Flags: needinfo?(cawang)

Comment 27

4 years ago
(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.
Flags: needinfo?(aymanmaat)

Comment 28

4 years ago
ni? to carrie regarding point 1 to 7.1.2 in comment 27
(Assignee)

Comment 29

4 years ago
Created attachment 8380635 [details]
SIM manager's page to support the discussion
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).
Flags: needinfo?(cawang)
(Assignee)

Comment 31

4 years ago
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.
(Assignee)

Comment 32

4 years ago
Filed bug 976576.
Depends on: 976576
(Assignee)

Updated

4 years ago
Assignee: nobody → felash
(Assignee)

Comment 33

4 years ago
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.
No longer depends on: 976576
Target Milestone: --- → 1.4 S3 (14mar)
(Assignee)

Comment 34

4 years ago
Some early work at https://github.com/julienw/gaia/compare/947139-send-default-sim
(Assignee)

Comment 35

4 years ago
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.
(Assignee)

Comment 36

4 years ago
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)
(Assignee)

Comment 37

4 years ago
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.
(Assignee)

Comment 38

4 years ago
(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.
(Assignee)

Comment 39

4 years ago
Created attachment 8390123 [details] [review]
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!
Attachment #8390123 - Flags: feedback?(schung)
Blocks: 947140
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 :)
(Assignee)

Comment 41

4 years ago
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
(Assignee)

Comment 42

4 years ago
Comment on attachment 8390123 [details] [review]
github PR

Hey Francisco,

I think this is ready for a review now.

Thanks!
Attachment #8390123 - Flags: feedback?(schung) → review?(francisco.jordano)
Comment on attachment 8390123 [details] [review]
github PR

Great work Julienne!

Please merge once travis is green :)
Attachment #8390123 - Flags: review?(francisco.jordano) → review+
(Assignee)

Comment 44

4 years ago
Travis Green !

master: 29a990ac0347c057ef6998cb42e4548768a18559

thanks !
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED

Updated

4 years ago
Depends on: 983858
Flagging checkin-needed for backout - this causes a very bad regression in the SMS app when sending any type of MMS in bug 983858.
Keywords: checkin-needed
Sorry, this doesn't backout cleanly. Gonna need somebody familiar with this code to do it :(
Flags: needinfo?(jsmith)
Keywords: checkin-needed
Argh. Okay. I'll discuss this with the comms team on Monday.
Flags: needinfo?(jsmith)
Keywords: verifyme
Works fine with this
Gaia      d2651c13d6370d62bf833b31c7e2e5f054510136
Gecko     c8a17e25111585c0eebb829f8208190ea432c71e
BuildID   20140318053055
Version   30.0a1
Status: RESOLVED → VERIFIED
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.