824542 - [Open_][SMS]No character count shows when editing a message.

Status: RESOLVED FIXED

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

Description

[Firefox_Mozilla]

User Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11

Steps to reproduce:

1. Launch Message application.
2. Edit a new message.
3. Input characters in edit area.


Actual results:

Although inputting characters is ok, no character count shows. User cannot get the information how many characters he has input for the message.


Expected results:

The character count should show for user.

Build Information:
gecko:   	 revision="3cbade1974968bb1e0fbb0c3386239715244a7a7"
gaia: 	 	 revision="aab72f365d73f624ede32b522f27d072c409e42e"
gonk-misc:   revision="654358494ba601a46ef9838debc95417ae464cc6"
dalvik:      revision="ca1f327d5acc198bb4be62fa51db2c039032c9ce"
librecovery: revision="e1bd90051c9e937221eb1f91c94e3cde747311a7"
moztt:       revision="6ee1f8987ef36d688f97064c003ad57849dfadf2"
external/jsmin:    revision="cec896f0affaa0226c02605ad28d42df1bc0e393"
external/opensans: revision="b5b4c226ca1d71e936153cf679dda6d3d60e2354"
device/qcom/b2g_common/mozilla-b2g: revision="41c17a6abfd5f488ec99d9aa246f5b07583403c7"

Comment 1

[Andrew McCreight [:mccr8]]

This doesn't look security sensitive to me.

Comment 2

[Al Tsai [:atsai]]

By design, we will have a number for text amount after it's over 144 (which is the maximum amount of an English message).

Comment 3

[isabelrios]

Renominating this bug. It is not clear what's happening for Spain, here the maximum amount is 160 chars. Will the counter appear when changing from 160 to 161? 
It is important to have the number of characters and also when changing from one message to the second one.

Comment 4

[David Palomino [:dpalomino]]

Hi, 

We think that could be an important issue. Carriers require this, as users are very sensitive to costs associated to SMS, and they try to avoid the sending of concatenated SMS. 

Bug reopened for discussing it during triage. 

Thanks, 
David

Comment 5

[David Scravaglieri [:scravag]]

Daniel, could you confirm if this is a certification requirement or not ?

Thanks.

Comment 6

[David Palomino [:dpalomino]]

Hi, 

Just a suggestion, I think a good solution could be to have something like: 

a) Case 1: Editing a message, only one single message (no concatenation limit reached)
        >> counter_chars
           |-> just a counter for the number of chars written

b) Case 2: Editing a message, more than one message (concatenation limit reached)
        >> counter_chars/counter_msg
           |-> a counter for the number of chars written
           |-> and also a counter for the number of messages to be sent

Daniel is on holidays right now, I think this would be a certification requirement. I'd suggest to include it as a certification requirement. 

Thanks!
David

Comment 7

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

Triage: BB+, P1 - potential cert blocker and also very important for market that is cost sensitive

Comment 8

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

(In reply to Joe Cheng [:jcheng] from comment #7)
> Triage: BB+, P1 - potential cert blocker and also very important for market
> that is cost sensitive

Why is it a cert blocker? If I read the bug issue it seems like the issue is about not having always a character counter.

There is one once you go past 160 characters (depending on the encoding it could be less). If this one is not enough for certification/user cost sensitive information please block again on this bug.

Comment 9

[David Scravaglieri [:scravag]]

Daniel, please renominate if required for certification

Comment 10

[Daniel Coloma:dcoloma]

(In reply to David Scravaglieri [:scravag] from comment #9)
> Daniel, please renominate if required for certification

The discussion has diverged that much since the beginning that let me clarify what should be a certification blocker:

 The user must be informed about the amount of SMSs that are going to be concatenated when that amount is more than 1 (Note that the amount of chars per SMS depends on the encoding). 
 
 For concatenated SMSs (messages that require more than 1 SMS because of its length) the user must be informed about the amount of chars that are still available in the SMS before requiring a new one to be concatenated.

 When the maximum size of an SMS is reached, user must be informed about it. 

Anything else is a nice to have.

Comment 12

[Borja Salguero [:borjasalguero]]

Agree with Daniel & Vivien. Currently we have a counter and it shows info when you exceed the limit for the first message and  the number of messages that you are going to send, and we are following the specs from UX.
David, probably we should reduce the severity and milestone for this one, because currently we have a counter and it's working! And this bug sounds as an improvement.

Comment 13

[Steve Chung [:steveck]]

Hi Ayman,
Based on comment #10, do you have any suggestion or refinement about current SMS counter UX? Thanks.

Comment 14

[ayman maat :maat]

(In reply to Steve Chung from comment #13)
> Hi Ayman,
> Based on comment #10, do you have any suggestion or refinement about current
> SMS counter UX? Thanks.

Hey there Steve

Referencing...
wireframe pack: HTML5_SMS_20121212_R2S1_V8.0
page: 17
annotation: 02 and 03

It would seem to me that Dev has followed the specification exactly, so there is no problem there.

However referencing comment #10 "For concatenated SMSs (messages that require more than 1 SMS because of its length) the user must be informed about the amount of chars that are still available in the SMS before requiring a new one to be concatenated." 

With that in mind I would say that an extension to what i specified and an enhancement in UX would be to count down the last ten characters in the first SMS packet before the user moves to the second SMS packet. 

Let me know if you require any further clarification.

Comment 15

[Steve Chung [:steveck]]

Attachment: Patch for refine the message counter display timing

It's a simple and low-risk patch and user could have better use experience while composing the message.

Comment 16

[Steve Chung [:steveck]]

Comment on attachment 710555 [details]
Patch for refine the message counter display timing

NOTE: If blocking-basecamp+ is set, just land it for now.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): feature
User impact if declined: It would be nice to notify the use while the end of the first message, not until the second message concatenated.
Testing completed: The result should be the same as #813689
Risk to taking this patch (and alternatives if risky): None

Comment 17

[Lukas Blakk [:lsblakk] use ?needinfo]

We'll approve this once it has been r+'d.

Comment 18

[Maria Angeles Oteo (:oteo)]

Already reviewed and landed in master

Comment 19

[Lukas Blakk [:lsblakk] use ?needinfo]

Comment on attachment 710555 [details]
Patch for refine the message counter display timing

Approving low risk fix that improves the UX of SMS.

Comment 20

[Lukas Blakk [:lsblakk] use ?needinfo]

Batch edit: Bugs still affected on b2g18 after 2/13 merge to v1.0.1 branch are affected on v1.0.1 branch.

Comment 21

[John Ford [:jhford] CET/CEST Berlin Time]

v1-train: 984f41115b62c717aaf2f268c8c31462104a64d3
v1.0.1: c74078f8e65edaeb05d83e779be133e5ba301d09