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

RESOLVED FIXED in B2G C4 (2jan on)

Status

P1
major
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: Firefox_Mozilla, Assigned: steveck)

Tracking

unspecified
B2G C4 (2jan on)
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

(blocking-basecamp:-, b2g18+ fixed, b2g18-v1.0.0 wontfix, b2g18-v1.0.1 fixed)

Details

(Whiteboard: [triaged: 1/24], interaction, [UX-P3])

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
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"
(Reporter)

Updated

6 years ago
Severity: normal → major
This doesn't look security sensitive to me.
Group: core-security

Comment 2

6 years ago
By design, we will have a number for text amount after it's over 144 (which is the maximum amount of an English message).
Status: UNCONFIRMED → RESOLVED
blocking-basecamp: --- → ?
Last Resolved: 6 years ago
OS: All → Gonk (Firefox OS)
Hardware: All → ARM
Resolution: --- → INVALID
blocking-basecamp: ? → ---

Comment 3

6 years ago
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.
blocking-basecamp: --- → ?
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
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: INVALID → ---
Daniel, could you confirm if this is a certification requirement or not ?

Thanks.
Flags: needinfo?(dcoloma)
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
Triage: BB+, P1 - potential cert blocker and also very important for market that is cost sensitive
blocking-basecamp: ? → +
Priority: -- → P1
Target Milestone: --- → B2G C4 (2jan on)
(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.
blocking-basecamp: + → ?
Daniel, please renominate if required for certification
blocking-basecamp: ? → -
tracking-b2g18: --- → +
(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.
Flags: needinfo?(dcoloma)
(Assignee)

Updated

6 years ago
Duplicate of this bug: 823437
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.
Flags: needinfo?(dscravaglieri)
(Assignee)

Updated

6 years ago
Assignee: nobody → schung
Whiteboard: [triaged: 1/24]
(Assignee)

Comment 13

6 years ago
Hi Ayman,
Based on comment #10, do you have any suggestion or refinement about current SMS counter UX? Thanks.
Flags: needinfo?(dscravaglieri) → needinfo?(aymanmaat)

Comment 14

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

Updated

6 years ago
Whiteboard: [triaged: 1/24] → [triaged: 1/24], interaction, [UX-P3]
(Assignee)

Comment 15

6 years ago
Created attachment 710555 [details]
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.
Attachment #710555 - Flags: review?(fbsc)
(Assignee)

Comment 16

6 years ago
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
Attachment #710555 - Flags: approval-gaia-v1?
We'll approve this once it has been r+'d.
status-b2g18: --- → affected
status-b2g18-v1.0.0: --- → wontfix
Attachment #710555 - Flags: review?(fbsc) → review+
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago6 years ago
Resolution: --- → FIXED
Already reviewed and landed in master
Comment on attachment 710555 [details]
Patch for refine the message counter display timing

Approving low risk fix that improves the UX of SMS.
Attachment #710555 - Flags: approval-gaia-v1? → approval-gaia-v1+
status-b2g18-v1.0.1: --- → affected
Batch edit: Bugs still affected on b2g18 after 2/13 merge to v1.0.1 branch are affected on v1.0.1 branch.
v1-train: 984f41115b62c717aaf2f268c8c31462104a64d3
v1.0.1: c74078f8e65edaeb05d83e779be133e5ba301d09
status-b2g18: affected → fixed
status-b2g18-v1.0.1: affected → fixed
You need to log in before you can comment on or make changes to this bug.