AU_LINUX_GECKO_ICS_STRAWBERRY.01.01.00.019.184 Firefox os v1.1 Mozilla build ID:20130806071254 DEFECT DESCRIPTION: While composing a MMS the overall message size is not indicated/shown. REPRODUCING PROCEDURES: Customer Impact Statement:While composing a MMS the overall message size is not indicated/shown. EXPECTED BEHAVIOUR: The overall message size should indicated/shown. ASSOCIATE SPECIFICATION: TEST PLAN REFERENCE: TOOLS AND PLATFORMS USED: USER IMPACT: high REPRODUCING RATE: 5/5 For FT PR, Please list reference mobile's behavior:

when you attach pictures, the size will show. do you mean something else?

(In reply to Joe Cheng [:jcheng] from comment #1) > when you attach pictures, the size will show. do you mean something else? Yes, I think customer means the overall message size, which is included all attached pictures and words in a MMS.

This is implemented as specified, therefore asking to Ayman what he thinks. I think it's a reasonable request. For example, we could display the message size where the string "MMS" is displayed, or maybe instead of "MMS" (having the message size would imply we're writing a MMS).

(In reply to Julien Wajsberg [:julienw] from comment #3) > This is implemented as specified, therefore asking to Ayman what he thinks. > > I think it's a reasonable request. For example, we could display the message > size where the string "MMS" is displayed, or maybe instead of "MMS" (having > the message size would imply we're writing a MMS). Showing message size is a perfectly reasonable request, and was actually present in a very early version of the wireframes ...but i was asked to remove it. I think the request to remove was because size of message had no relation to cost of message and so was considered fairly irrelevant. nevertheless i will resurrect it. we cannot replace 'MMS' with 'size' as an indication of being in MMS state as we can go into MMS state without attachments (messages over 1350 char or thereabouts if i am not mistaken) Will knock up some wireframes and attach to this bug. leaving needinfo to me as a marker to me to post wireframes here.

Ayman: just a thought here, but I think that the decision to do this is really in your and product's hands. You/we can actually decide that it's a WONTFIX. Wilfred, who should decide such things for the Messages app ? Who is actually our product owner ? Is it you ?

Though I agree we don't have relation between size and price of MMS it would still be a smaller useful feature. Given with v1.3 we want to close off a lot of the outstanding MMS features it would be good to get the wire frames done and this completed as part of v1.3 MMS work.

1.3 => not koi. Adding it to scrumbugs

i koi? it so we can review this in our call on Tuesdays. if we find this is something we want to do for sure we will add to the right meta bug to be kept in visibility.

i dont see a value in adding a message size. We display the image size when its being added to the message but the overall message size adds no value to the user.

see Android snapshot. As we known,300k is the recommend max. size defined by SPEC.

(In reply to xiupinglong from comment #10) > Created attachment 793349 [details] > Screenshot_2013-08-21-11-51-31.png > > see Android snapshot. > As we known,300k is the recommend max. size defined by SPEC. Yes we are aware that Android delivers both the maximum size of a MMS message as well as the amount of room currently taken by the attachments, and therefore the amount of space left. However from a UX perspective, what does this actually mean to the end user? 1) Cost of sending MMS is not based on K size of MMS. So the total volume of K being sent in relation to the max volume of K that can be sent is not a piece of information that is sensitive/important/useful to the end user in this case. 2) There is no indication of file size when the user is selecting (for example) a picture from the list of pictures. So in the attached example where there is 77k of space left there is no way for an end user to make an 'upfront' decision about which file to attach to this message at the point of selection and thus avoid the 'file to large message' error message. So again the total volume of K space left is not a piece of information that is important/useful to the end user. 3) I believe we automatically compress the pictures when they are attached to the MMS… and I believe we compress again pictures that are already attached when another picture is attached. If this is the case Total volume of K available or the size of a file is (if we were to show it) information that is misrepresenting itself when show… as the total volume of K available is probably more than shown (due to the pending compression of already attached files upon addition of another file) and the file size of files that can be attached is not so as it will be compressed when attached. For these reasons, and several more, from a UX perspective there is currently no end user Value in showing the message size during composition, and therefore its proposed inclusion would create unnecessary noise on the interface. Nevertheless I am happy to listen to further pragmatic reasoning for displaying message size that has not been considered so feel free to post if anyone wishes.

(In reply to ayman maat :maat from comment #11) > 3) I believe we automatically compress the pictures when they are attached > to the MMS… and I believe we compress again pictures that are already > attached when another picture is attached. yep, you're perfectly right, we're doing this :)