796824 - [Settings] need a way to display tri-state call waiting status

Status: RESOLVED FIXED

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

Description

[GH to BZ]

[GitHub issue by hsinyi on 2012-10-02T02:31:56Z, https://github.com/mozilla-b2g/gaia/issues/5611]
The original discussion was on https://bugzilla.mozilla.org/show_bug.cgi?id=795255. 

In brief, we found that  two states (true or false) are not enough to accurately show the call waiting status, we need one more state.  

Currently, the value of *ril.callwaiting.enabled being true* means that we ask the carrier to enable call waiting service, and it succeeds. So we are sure the service is enabled and we keep *ril.callwaiting.enabled* true. Similarly, *ril.callwaiting.enabled = false* means the service is disabled and we are sure about this, too. 

However, it may fail when we send the request to the carrier.  In this case, there might be a problem with synchronizing the settings DB and the real carrier service status. We are unable to get the service status from the carrier, so the platform will set 'ril.callwaiting.enabled' to "null" (neither true nor false). 

Please note,  here "null" doesn't mean we should disable the setting control, it does mean we cannot provide the operator status, but user can still try to set the key. So settings app needs a way to distinguish this situation.

@jcarpenter @etiennesegonzac

Comment 1

[Josh Carpenter [:jcarpenter]]

Thanks for flagging, hsinyi. I have asked Rafa from TEF UX to chime in for interaction design input. He will be taking over Dialer UX duties from Ayman, who is currently on paternity leave.

Comment 2

[Josh Carpenter [:jcarpenter]]

Also flagging for Larissa, who created Settings UX.

Comment 3

[Rafael Rebolleda]

I guess we should alert the user that we couldn't do it at this time, the real state may be unknown and it's worth trying again (maybe a [LATER] [TRY AGAIN] dialog) The user will probably try to set it again and we get another chance to give real, trusted feedback.

At some point, an unknown-state indicator of sorts is unavoidable, I guess.

Larissa, we can have a chat about this if you want.

Comment 4

[Larissa Co [:lco]]

How long is the delay before the user gets a message back that setting call waiting has failed?

I bring this up because this isn't a setting that users expect to fail sometimes (unlike connecting to Wi-Fi, where there's some understanding that the device may fail to connect). My concern is that the user will set call waiting and leave settings immediately. This scenario would require a different kind of design and messaging than if the user was still on the phone settings page.

Comment 5

[Dietrich Ayala (:dietrich)]

Etienne says the worse case is that you have call waiting disabled but you think you have it enabled, which is bad - blocking+.

Comment 6

[Dietrich Ayala (:dietrich)]

Assigning to LCO for UX.

Comment 7

[Larissa Co [:lco]]

I'll update the spec and add a link soon, but here's the interaction I'm thinking about in case we fail to confirm the call waiting state:

1. The user gets an Alert that says something like "Call Waiting preference cannot be changed at this time due to difficulties communicating with the carrier. Try again later."(but less jargon-y.)

2. The button text should say "OK" (If we let them try again and it doesn't work, it would be annoying a second time)

3. The state of the setting should remain what it was before the user tried to change it to an unverified state.

I think we should use an alert because this message is important enough not to disappear without the user noticing, as a banner text would. There's no way for the user to realize that we failed to set the preference, and any indicator in the Settings app would be too hidden. Also, this is probably a case that doesn't happen very often, so I'm ok interrupting the user if it does happen.

Comment 8

[Larissa Co [:lco]]

Er... I take it back. After trying to design this and looking at precedents, I'm going with a Banner instead. I think it'll be enough of a notification, as long as the state of the setting goes back to the verified state.

Comment 9

[Larissa Co [:lco]]

Spec uploaded (v11): http://people.mozilla.com/~lco/Settings_B2G/Release_1_Specs/R1_Connectivity_v11.pdf

See pg. 28.

Comment 10

[Larissa Co [:lco]]

Dietrich, can you please assign to the engineer who'll work on this? The spec is finished.

Comment 11

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Larissa Co from comment #10)
> Dietrich, can you please assign to the engineer who'll work on this? The
> spec is finished.

Sorry for not giving feedback about the ux design earlier. I have some concerns. I hope I understand the spec correctly. In p.28, settings app should set the setting value back to the previous value (or the opposite value), right? If yes, there might be problems.

Let's think about the situation: when the phone is just turned on, the default call waiting status in the settings DB is "true", for example. So, we (the platform) reads the value in DB and try to ask carrier to enable call waiting status. For some reason, it fails. According to the spec, the value will be set to 'false' because the app thinks 'the opposite' is the verified one. The problem is, first, we cannot guarantee the current state is false because this is the first setting after booting and we don't get anything from the carrier.

Also, it may cause a "loop" issue. Assume that the setting has been set back to "false" due to the failure. Then what would happen? We try to ask the carrier to disable call waiting status --> it fails --> settings app set the value back to true --> ask carrier but it fails --> ... ... 

Though this issue (setting failure) may not happen very often (well, I doubt...), when it happens, it might last for a while. In this situation, the settings will look crazy, and the platform will also request carrier again, again and again....

Comment 12

[Larissa Co [:lco]]

Hi Hsin-Yi, 

I hope I'm not misunderstanding your comment as well. From what I gather, you might have the opposite understanding as mine. This is the behavior I was thinking we would have:

1. Call waiting is OFF. The user switches it to ON.
2. We send a signal to the carrier, but we don't know if they received it or not.
3. We show the error banner to the user, and we move the Call waiting switch back to OFF (the previous, last-verified state). This should happen right in the settings app, accompanying the banner, so that the user understands why the switch changed state.
4. The UI switch is now always OFF until we can contact the carrier and verify that call waiting is ON. 


Scenario 1: The carrier did receive the signal and in actuality Call Waiting is now ON, even if the switch says it's OFF.
* This is what the user wanted to change it to anyway, so he gets the benefit of having the setting actually changed.
* Yes, this is weird because it doesn't match the reality of the setting, but greying out the setting (i.e. adding a 3rd state to the setting) doesn't really add any further clarity about whether the setting is on or off either anyway.
* At some point in time, we try to query the carrier for its current state, and change the UI to reflect that state (without informing the user).

Scenario 2: The carrier DID NOT receive the signal and Call Waiting is still OFF
* In this case, the state matches the switch, so there's not confusion.

I hope this prevents the loop that you're talking about. Let me know if it doesn't! (also, I seriously hope this bug isn't going to be widespread. It sounds very painful.)

Comment 13

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Hi Larissa,

Thanks for the detailed response. You understood me quite well, but I would like to provide more "platform implementation details/difficulties" to help you know more about my concerns. :)

Actually, most tricky points happen at the moment of 'booting'. So, please imagine the situation when you read the followings ;-) Please also keep in mind that when the phone just boots, we don't have any trusted response from carrier. I.e, the known carrier response is 'null', but we might have the last, verified setting value stored in database (in your example, is 'OFF'). 

1) When booting (carrier response: null, stored setting: OFF), the underlying platform reads the setting value and finds it different from the carrier response, the platform asks carrier to set call waiting to OFF. 

Note that, here, user doesn't switch the setting. This is still the phone 'initialization' process.

Then, the platform is notified by carrier that it fails in setting. *Technically*, we can only detects "the failure" but still have no idea about "the actual call waiting status." So, the carrier response remains 'null.' 

Now, if we take 'switch' suggestion, i.e. change the setting to 'ON', then the platform detects the setting changes, reads the new setting and compares the new setting with the carrier response. Since the carrier response is still 'null', the platform asks the carrier ... ... 

If the carrier responds "successful", the carrier response gets updated and falls into chime with the setting value. The initial setting process stops here. And the 'switch' suggestion works for setting failure afterwards. 

But if the carrier responds "false" here... switch the value to OFF --> ask carrier --> fails (response remains null) --> switch to ON --> ... ... 
'switch b/w two-state' causes a problem.
That's why we (platform developers) didn't take this solution eventually and decided to provide tri-state back to UI. Now, what we lack is a good way to display and interpret the tri-state information to user.

(In reply to Larissa Co from comment #12)
> 
> Scenario 1: The carrier did receive the signal and in actuality Call Waiting
> is now ON, even if the switch says it's OFF.
> * This is what the user wanted to change it to anyway, so he gets the
> benefit of having the setting actually changed.
> * Yes, this is weird because it doesn't match the reality of the setting,
> but greying out the setting (i.e. adding a 3rd state to the setting) doesn't
> really add any further clarity about whether the setting is on or off either
> anyway.

Yes, I totally agree that displaying 'null' can't actually provide more info. I don't insist we must display 'null' to user (I think banner is a good idea). I just want to share my concern that UI needs finding a better way to handling 'tri-state' info sent from the underlying platform. And please don't just switch b/w true-false as I explained above. :)

I do hope I express myself clear enough this time, and do appreciate your patience for this loooooong comment ;-) If you need more viewpoints from platform developers, you can reach me on irc #b2g (my id is hsinyi). Thanks again!

Comment 14

[Larissa Co [:lco]]

Ok, we're spending too much time on this issue for something that is hopefully a corner case. Will anyone be in complete disagreement if we just:

1. display the fail banner
2. grey out the call waiting toggle (make sure it's neither on or off)
3. Only make the toggle active again when we finally make contact with the carrier to confirm its state?

Also, it seems from Hsin-Yi's last comment that this is something that might occur when the phone boots, not necessarily only when the user attempts to modify the setting in the settings app. So call waiting might fail even if the user isn't trying to modify it? That seems like it's going to be really confusing for the user. (If this is true, we may need to tweak the banner message)

Comment 15

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Larissa Co from comment #14)
> Ok, we're spending too much time on this issue for something that is
> hopefully a corner case. Will anyone be in complete disagreement if we just:
> 
> 1. display the fail banner
> 2. grey out the call waiting toggle (make sure it's neither on or off)
> 3. Only make the toggle active again when we finally make contact with the
> carrier to confirm its state?
> 

I don't have more comments here.

> Also, it seems from Hsin-Yi's last comment that this is something that might
> occur when the phone boots, not necessarily only when the user attempts to
> modify the setting in the settings app. So call waiting might fail even if
> the user isn't trying to modify it? 

Yes, in the initialization process when the phone boots.

> That seems like it's going to be really
> confusing for the user. (If this is true, we may need to tweak the banner
> message)

Comment 16

[Dietrich Ayala (:dietrich)]

P3 (bug fix, must fix for release). Thanks for hammering out the solution here.

Comment 17

[Dietrich Ayala (:dietrich)]

And then nothing happened for a month :)

Un-assigning Larissa because I don't think she's doing the engineering work for this.

Who's going to be implementing this, and when?

Comment 18

[Hsin-Yi Tsai (she/her) [:hsinyi]]

I set the assignee to default because I'm not familiar with Gaia implementation at all. We could probably find a Gaia person to take care of this. Thank you.

Comment 19

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Larissa Co from comment #14)
> Ok, we're spending too much time on this issue for something that is
> hopefully a corner case. Will anyone be in complete disagreement if we just:
> 
> 1. display the fail banner

A banner won't help since it is not possible to show the banner is the application is not foreground

> 2. grey out the call waiting toggle (make sure it's neither on or off)

'neither on or off' What does it means? It should be empty?

Comment 20

[Evelyn Hung]

Arthur has discussed this issue with Hsin-Yi, I believe him can follow up the discussion here and finish the implementation. :-)

Comment 21

[Arthur Chen [:arthurcc][inactive after 6/30]]

Hi Larissa,

After discussed with Hsin-Yi, if the query to the current state of Call Waiting fails, the state remains unknown until we query it again. Hisn-Yi has concerns on doing the query in the background automatically because it might lead to endless query and more power consumption. To have a better timing of querying the state, we have the following proposal:

- If the state is unknown, we simply do nothing. 
- We query the state from the carrier when users enter settings panel and want to check/set the state.

If you are fine with the proposal,
   - What to display during the unknown state? (grayed out or showing a busy cursor?)
   - What to do if the query fails again? (query again until users leave the settings page or ?)

Thanks in advance!

(In reply to Larissa Co from comment #14)
> Ok, we're spending too much time on this issue for something that is
> hopefully a corner case. Will anyone be in complete disagreement if we just:
> 
> 1. display the fail banner
> 2. grey out the call waiting toggle (make sure it's neither on or off)
> 3. Only make the toggle active again when we finally make contact with the
> carrier to confirm its state?
> 
> Also, it seems from Hsin-Yi's last comment that this is something that might
> occur when the phone boots, not necessarily only when the user attempts to
> modify the setting in the settings app. So call waiting might fail even if
> the user isn't trying to modify it? That seems like it's going to be really
> confusing for the user. (If this is true, we may need to tweak the banner
> message)

Comment 22

[Larissa Co [:lco]]

Hi Arthur,

If it's not too much work then, here are the tweaks I would suggest to your proposal:

> - If the state is unknown, we simply do nothing. 

OK with me.

> - We query the state from the carrier when users enter settings panel and
> want to check/set the state.

Makes sense.

> 
> If you are fine with the proposal,
>    - What to display during the unknown state? (grayed out or showing a busy
> cursor?)

Could we remove the switch altogether and replace it with a warning icon? Tapping the warning icon could bring up an Alert explaining the situation to the user. The Alert would have the option to "Check Again" (check state again) or to dismiss the dialog.

If this makes sense to you, I can mock up what the Alert would look like.

>    - What to do if the query fails again? (query again until users leave the
> settings page or ?)

Why don't we query only when the user re-enters the settings page or taps on "Check Again" per my proposal above?


Forget about banner notifications, as per Vivien's point. 

This is isn't a perfect solution since it requires the user to go to the Settings page to discover the problem, but I'm ok with it since it's not a major issue (hopefully).

Comment 23

[Arthur Chen [:arthurcc][inactive after 6/30]]

It sounds good. Please provide the mock up.

And one minor thing is that the query takes time ( < 1sec). What to show during the query? Still the warning icon?

Comment 24

[Arthur Chen [:arthurcc][inactive after 6/30]]

Hi Larissa,

Please ignore my previous comment because we've just realized that the query state function does not work in Brasil. The only method we have is the set function. I made minor tweaks to the proposal as the following:

- If the state is unknown, we simply do nothing.  (same)
- Display a warning icon when users enter the settings panel.  (same)
- Tapping the warning icon brings up an Alert with a checkbox requesting the call waiting state and the option to dismiss.

Comment 25

[Larissa Co [:lco]]

(In reply to Arthur Chen from comment #24)
> Hi Larissa,
> 
> Please ignore my previous comment because we've just realized that the query
> state function does not work in Brasil. The only method we have is the set
> function. I made minor tweaks to the proposal as the following:
> 
> - If the state is unknown, we simply do nothing.  (same)
> - Display a warning icon when users enter the settings panel.  (same)
> - Tapping the warning icon brings up an Alert with a checkbox requesting the
> call waiting state and the option to dismiss.

Ok, that's fine with me. Mocks coming soon. Sorry for the delay :)

Comment 26

[Larissa Co [:lco]]

Attachment: Call Waiting Mocks

See the attached file for the wireframes. Visual design folks, can you provide us with an icon for this case? We might already have some kind of informational icon that we can use. 

Arun and I are slightly worried that a "hazard triangle" icon as is present in these wireframes would be a little too alarming. We'd like something that's a bit more moderate, so feel free to specify one.

Comment 27

[Patryk Adamczyk [:patryk] UX]

Attachment: Final Icon

Comment 28

[Patryk Adamczyk [:patryk] UX]

Attachment: Visual Design Mock Up

Evaluating various designs, we felt that is iconography was clearest in meaning. Something is wrong with callwaiting after all, but we kept the colours down, so it wasn't too alarming.

We tried other icons like circles with exclamation marks, but they just looked like "info" nothing is wrong.

Comment 29

[Arthur Chen [:arthurcc][inactive after 6/30]]

Attachment: Mocks

What I am thinking is as the attachement. There should be a check box for users to set the call waiting state in the Alert since we are unable to fetch the state from carriers in Brasil. Press OK to set the state again. The state remains unknown when pressing cancel.

Comment 30

[Anshul]

Hsin-Yi and Arthur, like Android we should query for call waiting status when user enters the settings app and update the call waiting status correctly. If it fails (like in Brazil) we can show the alert icon you guys are planning to do. 

Also, I am not if there is a need of setting the call waiting on bootup. Since in Android call waiting is queried whenever user enters the setting app, the user would always see the correct call waiting value. Setting call waiting on bootup is failing a GCF test case that we are currently investigating.

Comment 31

[Arthur Chen [:arthurcc][inactive after 6/30]]

The proposal does not require users setting call waiting on bootup. It simply provides a way for users to do the setting after the alert icon shows up.

Comment 32

[Anshul]

Arthur, just to confirm, are you saying that you guys are considering removing the functionality to set the call waiting on bootup (Moz RIL currently does that), which is what I am also looking for?

Comment 33

[Arthur Chen [:arthurcc][inactive after 6/30]]

Anshul, our original intention is to avoid users manually setting call waiting on bootup, which is not the case you mentioned. And if setting call waiting on bootup in background fails the GCF test, we can remove the functionality.

Comment 34

[Anshul]

Arthur, I have confirmed that setting call waiting on bootup in the background does fail the GCF test case so it is a good idea to remove that. And so like Android, it would be a good idea to query for call waiting when user enters the settings app to always reflect the correct call waiting status as seen by the network. If querying fails or setting fails we can use the state of null to reflect the unknown state and display the alert icon already being discussed in this thread.

Comment 35

[Arthur Chen [:arthurcc][inactive after 6/30]]

Thanks for the prompt reply. Hsin-Yi will help to remove the functionality. I will do the UI work after the UX design finalized.

Comment 36

[Larissa Co [:lco]]

(In reply to Arthur Chen from comment #29)
> Created attachment 690256 [details]
> Mocks
> 
> What I am thinking is as the attachement. There should be a check box for
> users to set the call waiting state in the Alert since we are unable to
> fetch the state from carriers in Brasil. Press OK to set the state again.
> The state remains unknown when pressing cancel.

If the user sets the state in this dialog, there's no guarantee that the state will be set, right? Then we might get into a loop where the user keeps trying to set call waiting and it keeps failing. I was thinking that adding the switch might be too heavy; I feel like it's ok to just query the state every time the user visits the settings page. 

What do you think?

Comment 37

[Arthur Chen [:arthurcc][inactive after 6/30]]

We have no "query state" function. The only function we have is "set state". If we simply display the Alert when the state is unknown, the user will never have a chance to set the state (it always shows a warning icon). Or we simply set the state to false after the users close the Alert?

Comment 38

[Anshul]

Can we add the query state function just like Android has?

Comment 39

[Larissa Co [:lco]]

Ok, I think I understand the issue better now :) I would prefer to add a query state function, but if that's not feasible given the time we have, let's just use what Arthur's suggested in comment 29.

A couple of tweaks to the message: 

"The device is currently unable to communicate with the carrier. Try setting the preference again." 

<Set> <Cancel>

(Instead of "OK", let's try to be a little more descriptive by using "Set")

Comment 40

[Dietrich Ayala (:dietrich)]

Are the requirements clear enough for implementation to move forward here?

Comment 41

[Arthur Chen [:arthurcc][inactive after 6/30]]

Yes, I think it is clear for implementation.

Comment 42

[Arthur Chen [:arthurcc][inactive after 6/30]]

Attachment: Link to https://github.com/mozilla-b2g/gaia/pull/7172

Hi Evelyn, could you help to review this pull request? Thanks!

Comment 43

[Arthur Chen [:arthurcc][inactive after 6/30]]

Attachment: Screenshot of Alert

Hi Larissa, the final look of Alert is as the attachment. Please let me know if any modification is needed. Thanks!

Comment 44

[Evelyn Hung]

Comment on attachment 695434 [details]
Link to https://github.com/mozilla-b2g/gaia/pull/7172

r=me, r+ with comment addressed. Thank you.

Comment 45

[Arthur Chen [:arthurcc][inactive after 6/30]]

Fixed.
https://github.com/mozilla-b2g/gaia/commit/db37310f130722ebf6432bfa1120b7e81350b542

Evelyn, thanks for reviewing.

Pike, the following l10n ids were added:
- confirmCallWaitingTitle
- confirmCallWaitingDesc
- set

Comment 46

[Axel Hecht [:Pike]]

Please CC me if you're addressing me?

Wondering, why was crash-reports-description-3-start changed? There's removed trailing whitespace.

Comment 47

[Arthur Chen [:arthurcc][inactive after 6/30]]

Sorry, I thought I just need to set the keyword for localization. 

The whitespace was removed automatically by my text editor. Does it affect localization?

Comment 48

[Axel Hecht [:Pike]]

Any string change you do affects the code, and the localizations.

You probably want to revert to an editor that respects the code your fellow hackers wrote, and revert the change to that string.

I *think* that trailing whitespace is significant in the parser that gaia uses, though it's skipped in gecko's builtin.

Comment 49

[Arthur Chen [:arthurcc][inactive after 6/30]]

Attachment: Link to https://github.com/mozilla-b2g/gaia/pull/7265

Alex, thank you for pointing out the problem. I've created a pull request to fix it.

Evelyn, could you help review the change? Thanks!

Comment 50

[Evelyn Hung]

Comment on attachment 696916 [details]
Link to https://github.com/mozilla-b2g/gaia/pull/7265

:Pike, is it okay to update the string by another commit instead of reverting the original(merged) commit?

Comment 51

[Axel Hecht [:Pike]]

Comment on attachment 696916 [details]
Link to https://github.com/mozilla-b2g/gaia/pull/7265

Yep, that's OK to land as is.

Comment 52

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

https://github.com/mozilla-b2g/gaia/commit/36ea27a4acf4c676174173497899f722ab1dc615

Comment 53

[Larissa Co [:lco]]

LGTM. Thanks for landing :)