Closed Bug 980861 Opened 7 years ago Closed 7 years ago

[Cost Control] Alarm should be notified when user configures "when use is above" or "when balance is below"

Categories

(Firefox OS Graveyard :: Gaia::Cost Control, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(b2g-v2.0 fixed)

VERIFIED FIXED
1.4 S4 (28mar)
Tracking Status
b2g-v2.0 --- fixed

People

(Reporter: lolimartinezcr, Assigned: mai)

Details

(Whiteboard: burirun1.4-1)

Attachments

(3 files)

3.41 MB, video/3gpp
Details
46 bytes, text/x-github-pull-request
salva
: review+
Details | Review
46 bytes, text/x-github-pull-request
salva
: review+
Details | Review
Attached video VID_0005.3gp
Tested 
Hamachi
Plaform versioin 30.0a1
Build ID: 20140306163928
Git commit: 6781459a
Reproducible:100%

Prerequisites:
Prepaid SIM card with balance

STR:
1) Tap usage
2) Tap settings
3) Tap in "When balance is below" and write any amount greater than the balance
4) Tap "done" button

Actual result:
User can't  see a notification of alarm. Only when user taps "Update" button in device or when opens again usage application, device receives an notification an show different colour in balance. (see attached video)

Expected result:
User can see a notification of alarm

Alarm should be receive when it is configured?? "UXwanted"
Whiteboard: burirun1.4-1
Summary: [Alarm] Alarm should be notified when user configures "when use is above" or "when balance is below" → [Cost Control] Alarm should be notified when user configures "when use is above" or "when balance is below"
QA Wanted to check behavior on 1.3.
Keywords: qawanted
Hi,
it is the current behaviour (on v1.3 branch, the same occurs). The
balance info is always updated by sms, either by a user request or
automaticaly, by an application request. When the user configures a balance
limit, the application does not know if the balance info is completely
updated. For this reason, the application waits for the first balance
sms received to confirm the correct balance and in that moment, launches
the notification balance alert.

The question here, is wether current behaviour is correct.
Flags: needinfo?(aymanmaat)
(In reply to marina rodríguez [:mai] from comment #2)
> Hi,
> it is the current behaviour (on v1.3 branch, the same occurs). The
> balance info is always updated by sms, either by a user request or
> automaticaly, by an application request. When the user configures a balance
> limit, the application does not know if the balance info is completely
> updated. For this reason, the application waits for the first balance
> sms received to confirm the correct balance and in that moment, launches
> the notification balance alert.
> 
> The question here, is wether current behaviour is correct.

i would have to pass this question to Rafa as he has more CC knowledge.
Flags: needinfo?(aymanmaat) → needinfo?(hello)
removing the qawanted keyword per comment 2
Keywords: qawanted
(In reply to marina rodríguez [:mai] from comment #2)
> Hi,
> it is the current behaviour (on v1.3 branch, the same occurs). The
> balance info is always updated by sms, either by a user request or
> automaticaly, by an application request. When the user configures a balance
> limit, the application does not know if the balance info is completely
> updated. For this reason, the application waits for the first balance
> sms received to confirm the correct balance and in that moment, launches
> the notification balance alert.
> 
> The question here, is wether current behaviour is correct.

Hi Marina

I would say there are two things here:

Firstly directly addressing the bug from a UX PoV the current behaviour is not acceptable as notification of going over balance limit is critical to usage. Users would expect notification the moment that they are over limit even if it is due to their configuration of the CC app… and the time lag between configuration an notification demonstrated in attachment 8387511 [details] introduces a very high risk of human error (error being that the user inadvertently continues to spend money when they are actually over their balance limit because the app has not notified them). 

What are our options for fixing this? is it possible to make the latest known balance available to the app at the point of configuring and what would be the overhead for doing this?

Secondly I would have expected the app to use the phones notification system to proactively inform the user that they are over their limit. However viewing the video in attachment 8387511 [details] it seems that the app is not using the phones notification system and that the user has to open the app to be informed of status. Is that so? (i cannot test this myself as i do not have the necessary SIM card)

ni? to Marina
removing ni? to rafa as i am addressing it here.
Flags: needinfo?(hello) → needinfo?(mri)
Hi Ayman,
In your opinion, what's the best way to resolve this? Sending a notification immediatly, asking for a balance actualization,...

Regarding the second point, the application sends a phone notification system when receive the first balance update sms, because of the app is sure the info to check the balance limit it's the correct. For this reason, you can not see the notification on the video.

Regards,
Mai
Flags: needinfo?(mri)
(In reply to marina rodríguez [:mai] from comment #6)
> Hi Ayman,
> In your opinion, what's the best way to resolve this? Sending a notification
> immediatly, asking for a balance actualization,...

In the event that the figure input is greater than the current balance I would expect a minimum of two things to immediately happen when the user selects the ‘Done’ CTA @ 00:25 in attachment 8387511 [details]

1) the visual prevention of the balance to alter and be presented as it is @ 00:39 
2) the user to receive notification that they have gone over their balance

what would be our effort overhead to achieve this?
Assignee: nobody → mri
Attached file patch v1.0
Hi Salva, 
do you mind review the patch?
Regards
Attachment #8394634 - Flags: review?(salva)
Comment on attachment 8394634 [details] [review]
patch v1.0

Sorry but before reviewing I need some clarifications.
Attachment #8394634 - Flags: review?(salva)
I think there is a misinterpretation here. Ayman, please notice this threshold is not a limit. It is just a reminder of going under (not above). The user will receive a notification once his credit is going under the threshold,

Despite I think when the user set the threshold above his current credit, the application should react and change the colors and I consider this as a bug, I'm not sure about triggering the notification as it's a little bit strange to set a minimum reminder and be warned just after setting the threshold.

What do you think, mister?
Flags: needinfo?(aymanmaat)
(In reply to Salvador de la Puente González [:salva] from comment #10)
> I think there is a misinterpretation here. Ayman, please notice this
> threshold is not a limit. It is just a reminder of going under (not above).
> The user will receive a notification once his credit is going under the
> threshold,
> 
> Despite I think when the user set the threshold above his current credit,
> the application should react and change the colors and I consider this as a
> bug, I'm not sure about triggering the notification as it's a little bit
> strange to set a minimum reminder and be warned just after setting the
> threshold.
> 
> What do you think, mister?

Thanks for the clarification Salva, that was my misinterpretation. 

I am still of the opinion that in this event a minimum of two things should immediately happen when the user selects the ‘Done’ CTA @ 00:25 in attachment 8387511 [details]

1) the visual prevention of the balance to alter and be presented as it is @ 00:39 
2) the user to receive notification that they have gone *below* their balance limit

...after all the situation in this scenario is that the credit it below the limit defined by the user and the system should respond and inform the user of this promptly.
Flags: needinfo?(aymanmaat)
Agree. So let's assume as valid this patch. Marina, please, ask for my review again.
Comment on attachment 8394634 [details] [review]
patch v1.0

Salva, could you review the patch?
Attachment #8394634 - Flags: review?(salva)
Comment on attachment 8394634 [details] [review]
patch v1.0

Working perfectly. Thank you Mai.
Attachment #8394634 - Flags: review?(salva) → review+
Master: 71153c442555cfa4f3adf2c8312983d837abc2ae
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Backed out of master due to lint failures. Your R+ still stands, please submit and land the pull request with the lint errors fixed assuming travis is green. Travis log:

Running jshint...

apps/costcontrol/js/views/balance.js: line 134, col 7, 'sendBalanceThresholdNotification' is not defined. (ERROR)

apps/costcontrol/js/views/balance.js: line 144, col 7, 'sendBalanceThresholdNotification' is not defined. (ERROR)

https://github.com/mozilla-b2g/gaia/commit/5ae2df02e30bda2ae04830d6e181ecf31ff38817
Status: RESOLVED → REOPENED
Flags: needinfo?(mri)
Resolution: FIXED → ---
Please wait for a green travis before landing. This is slowing down the project every time we have to back out people who had a red pull request.
I´m sorry for the inconvenience.
When i merge this pr the travis was green, I think the problem is produced by the automatic rebase. 
I'll prepare another pr fixing the jshint errors.
Flags: needinfo?(mri)
Attached file patch v1.1
Fixed the JSHINT error on balance_view.js
Comment on attachment 8397439 [details] [review]
patch v1.1

first patch with the jshint fix for balance.js
Attachment #8397439 - Flags: review?(salva)
Comment on attachment 8397439 [details] [review]
patch v1.1

Sorry, my fault. I should have notice it.
Now is green. :)
Attachment #8397439 - Flags: review?(salva) → review+
Master: 08346114559d9de86fff94dcc656538a5331b9f5
Status: REOPENED → RESOLVED
Closed: 7 years ago7 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.4 S4 (28mar)
Today's (4/2) 1.4 build and not working:
Device: Hamachi
BuildId: 20140402094724
Gaia: b8e6e61
Gecko: 6bfa4cb
Platform version: 30.0a2
Tested and working
Hamachi
1.5
Gecko 404219c
Gaia 2b8464
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.