813682 - [SMS] Indicator of number of SMS to be sent

Status: VERIFIED FIXED

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

Description

[Beatriz Rodríguez [:brg]]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20100101 Firefox/16.0
Build ID: 20121024073032

Steps to reproduce:

There is no indication to know how many SMS are going to be sent



Expected results:

SMS are not free, user should be able to know how many SMS are going to be sent before indeed sending them.
This issue has a big impact in the customer bill.

Comment 1

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

How much detailed info do you want to show on screen? There was also a discussion on web-api[1] for this. Existing SMS applications have several numbers shown, not each of them, usually combination of two:

1) Total segments to send: already have with getNumberOfMessagesForText().
2) Chars available per segment: depending on data code scheme, this might be 140/70. It might also vary with concatenation involved.
3) Chars already input in current segment.
4) Chars remains available in current segment. 

[1]: https://groups.google.com/d/topic/mozilla.dev.webapi/P7Uq8RW-caw/discussion

Comment 2

[Beatriz Rodríguez [:brg]]

(In reply to Vicamo Yang [:vicamo][:vyang] from comment #1)
> How much detailed info do you want to show on screen? There was also a
> discussion on web-api[1] for this. Existing SMS applications have several
> numbers shown, not each of them, usually combination of two:
> 
> 1) Total segments to send: already have with getNumberOfMessagesForText().
> 2) Chars available per segment: depending on data code scheme, this might be
> 140/70. It might also vary with concatenation involved.
I will add the possibility of 160 characters when using default 7bit :-)
> 3) Chars already input in current segment.
> 4) Chars remains available in current segment. 
There is other bug to follow the chars counter #813689
> 
IMHO, the best option will be to offer '4/1'. We will fix both issues with it.

> [1]:
> https://groups.google.com/d/topic/mozilla.dev.webapi/P7Uq8RW-caw/discussion
I will include this comment in this list so everyone could be aware of it. But I think we should follow the discussion in only one place to avoid any misunderstanding.

Comment 3

[Alex Keybl [:akeybl]]

Mass Modify: All un-milestoned, unresolved blocking-basecamp+ bugs are being moved into the C3 milestone. Note that the target milestone does not mean that these bugs can't be resolved prior to 12/10, rather C2 bugs should be prioritized ahead of C3 bugs.

Comment 4

[Dietrich Ayala (:dietrich)]

Why are we blocking in this? This is not in the original requirements, and doesn't seem like something we'd hold the release for.

Comment 5

[Daniel Coloma:dcoloma]

This will definitely block the release and OB approval, the number of SMSs that are going to be concatenated impact the user bill and hence it is a potential source of customer complaints. Can you make it bb+ again?

Comment 6

[Chris Lee [:clee]]

Also required for certification requirements.  Marked blocking.

Comment 7

[Steve Chung [:steveck]]

Because this feature is not in the original scope at first ,we need both gecko and UX changes before gaia input. It will take at least a week to make this feature complete.

Hi Borja
if you have no resource on it, you can assign these related issues(813682,813686 and 813689) to me and I can discuss the detail with Vicamo first. 

Hi, Casey,
Since latest wireframe does not include this feature, could you (or other UX devs responsible for SMS app) update the wireframe to display this indicator and other information? Thanks.

Comment 8

[Borja Salguero [:borjasalguero]]

Cool! I think that we could work together on it, so Im gonna reset to default. I will talk with Ayman for updating the wireframe and with UX Team for getting the visual spec. Thanks for your support Steve! ;)

Comment 9

[Steve Chung [:steveck]]

Np Borja, so Vicamo and I will start the gecko and gaia change first, and you can review or fix the patch if the solution doesn't totally match the requirement since the UX is on your side, thanks.

Comment 10

[ayman maat :maat]

Attachment: SMS : message composer handling multiple SMS packets

Hi all

attached is page 17 of newly released wireframe pack HTML5_SMS_20121212_R2S1_V8.0 to illustrate the proposed solution to this bug.

I have gone through this proposition with Borja and there is an acknowledgement that, from a technical PoV, there is a possibility we may not be able to update the 'number of characters left in SMS packet' in time with the user typing on the keyboard. If this is indeed the case let me know so we can adjust the solution around when it is appropriate to display this figure.

Steve for Visual Design purposes the architecture delivered here will hold true irrespective of any technical constraints around the display of 'number of characters left in SMS packet'. So a designer can start work ASAP

RFI request to Steve to assign visual design resourse.

Comment 11

[steve]

Visual design has been assigned. Vicky.

Comment 12

[Steve Chung [:steveck]]

Hi Ayman,
Thanks for your wireframe update, Here is some quick feedback:

1. Based on https://bugzilla.mozilla.org/show_bug.cgi?id=813686 requirement, do we need any notification if user reach the maximum number of sms packets to send or we can just ignore the input while reaching the limitation?

2. In annotation 1, is this message sent by system notification or just a simple banner created by sms app?

3. In annotation 2, it says the counter displayed after the user enters the second SMS packet. Is there no need to display in first SMS packet?

4. In annotation 1, if we delete the input characters to reduce the sms packets from 2 to 1, do we need to show the notification?

Comment 13

[ayman maat :maat]

(In reply to Steve Chung from comment #12)
> Hi Ayman,
> Thanks for your wireframe update, Here is some quick feedback:
> 
> 1. Based on https://bugzilla.mozilla.org/show_bug.cgi?id=813686 requirement,
> do we need any notification if user reach the maximum number of sms packets
> to send or we can just ignore the input while reaching the limitation?

A notification when the user has reached the maximum number of SMS packets would help them to understand that they have reached their limit rather than just removing the users ability to input. So I would prefer to implement that if possible. 

A message stating: 'max message length reached' would suffice

> 2. In annotation 1, is this message sent by system notification or just a
> simple banner created by sms app?

In my mind it is simply a banner created by the SMS app. But i am open to whatever implementation is easier / more practical for development

> 3. In annotation 2, it says the counter displayed after the user enters the
> second SMS packet. Is there no need to display in first SMS packet?

No there is no need to display the counter whilst the user is in first SMS packet for the following reasons:

1) We reduce visual noise on the screen and improve communication by not displaying the counter when the user is within the first packet. 

2) Users will always be in the first packet when they start a message. The really important thing to communicate, to raise end users awareness of, is when they cross the boundary into the second packet. The banner message gives temporary notification of change of state, the appearance of the counter gives 'permanent' notification of change of state. if we display the counter whilst in the first packet we reduce its prominence as it is on the screen all the time and so the user gets accustomed to its presence and so its message: 'you are now beyond the 1st SMS packet' is reduced.

> 4. In annotation 1, if we delete the input characters to reduce the sms
> packets from 2 to 1, do we need to show the notification?

yes please

Comment 14

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

This will be fixed by my patch in bug 813689. Stealing.

Btw the patch does not show the new notification banner since this is the only place where this will be done for an application and not the system.

Comment 15

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

https://github.com/mozilla-b2g/gaia/commit/79dbf7ad802727151a8989274c5a6e41e194d424

Comment 16

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

The thing you built into Gaia is incomplete. SMS segmentation relates several thing and can't be done like this. Not all ASCII character are in GSM 7 Bit default alphabet, '`'(\x60) is an example. And not all characters in default alphabet take one septets only, '~'(\x7e) takes two. There are also rules for multipart messages which are also ignored in your implementation.

Comment 17

[Borja Salguero [:borjasalguero]]

This one was implemented here https://bug813689.bugzilla.mozilla.org/attachment.cgi?id=693927 ... This is the first new that I have of this code, and it's already merged. Steve was working on it... probably we must revert the patch and wait a new implementation based on Vicamo's work in Backend.

Comment 18

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

I believe this could be done in a followup bug. No need to reopened an old bug. If this implementation is buggy that's fine, let's tune it but not by reopening old bugs. The only thing that needs to be changed is the way characters / messages is calculated afaict.

Comment 19

[Deepa Subramanian]

The characters / messages is calculated verified on unagi build id:  20130103070201