Closed Bug 883911 Opened 9 years ago Closed 8 years ago

[SMS][MMS] Update all occurrences of "Type ? Carrier ? Number" strings to same format

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:-)

RESOLVED FIXED
blocking-b2g -

People

(Reporter: rwaldron, Assigned: rwaldron)

References

Details

Attachments

(4 files)

Attached image contact search results
Please provide a consistent, app-wide format for displaying the "Type ? Carrier ? Number" strings. Once provided, all strings will be updated and tests modified to prove conformance.

Requesting leo? because there are too many ad hoc changes made across different bugs and no single point where the change has been declared, resulting in inconsistency across the app.
Attached image group participants view
Attached image participant activated
Attached image recipient removal
Flags: needinfo?(vpg)
Flags: needinfo?(aymanmaat)
Assignee: nobody → waldron.rick
Blocks: 880624
Hi Rick

Actually we do have a consistent format / algorithm for the presentation of 'Type / Carrier / Number' strings. It has been in place long before V1.0. Unfortunately the problem is the on-boarding process into this project has not been optimal for the propagation of knowledge. 

The information you seek is as follows:

If for a single contact we have:

1) …a unique string in the <carrier> field and a unique string in the <type> field output:
	<type>, <carrier>
	
2) …no content in the <carrier> field output:
	<type>, <phone number>

3) …two phone numbers that have exactly the same content in the <type> field and in the <carrier> field output:
	<type>, <phone number>

4) …no content in the <type> field output:
	<phone number>


In terms of Visual Treatment the wireframes are just representational. The Visual Design is the specification for Visual Treatment. So for example in the wireframes you will see the separator is a bar '|' but in visual design it is a comer ','. in this situation Visual Design is King.

Just referring to your attachments.

attachment 763619 [details] and attachment 763623 [details]
For these two follow the Visual Design guidelines and use the appropriate building block. If an appropriate building block is not available contact Victoria to seek her guidance.

attachment 763617 [details]
annotation 03 details a phone number that belongs to a 'Contact that is in the group message but not in the users contact list'. It is therefore not covered by points 1 to 4 above

If you need any more guidance or clarification NeedInfo me anytime.
Flags: needinfo?(aymanmaat)
Flags: needinfo?(vpg)
Does this truly block the leo+ bug 880624? There was some back and forth in that bug.
Flags: needinfo?(waldron.rick)
Flags: needinfo?(dietrich)
Alex, my hope had been that the spec would be updated with a final word.
No longer blocks: 880624
Flags: needinfo?(waldron.rick)
Triage- removing leo? as this doesnt really block anything at the moment.
blocking-b2g: leo? → ---
Duplicate of this bug: 886729
Duplicate of this bug: 888134
Victoria, should this block the 1.1 release ?
blocking-b2g: --- → leo?
Flags: needinfo?(vpg)
Hi Julien,
 
This is not blocking from a Visual Design point of view.

This decision of changing "|" to "," was taken due to a localization bug you reported or you commented in. From an UX perspective, this is an important issue to solve due to consistency matters. We need to provide a consistant way of displaying this kind of information so it's not misunderstood by the user.
Flags: needinfo?(vpg)
I think it was initially because of consistency between all apps, not only in Sms, and this information was shown like this in other apps.
Triage confirms blocking-.
blocking-b2g: leo? → -
Flags: needinfo?(dietrich)
(In reply to Julien Wajsberg [:julienw] from comment #12)
> I think it was initially because of consistency between all apps, not only
> in Sms, and this information was shown like this in other apps.


Confirm; for example, the Dialer app displays something like "mobile | 9995551234"
Victoria,

coming back here, do you think we can take the visual refresh as an opportunity to try and get some consistency here?

Thanks !
Flags: needinfo?(vpg)
(In reply to Julien Wajsberg [:julienw] from comment #15)
> Victoria,
> 
> coming back here, do you think we can take the visual refresh as an
> opportunity to try and get some consistency here?
> 
> Thanks !

I wouldn't mind, but just affraid that if we do block refresh with fixes that are not really part of the refresh it will put the refresh in danger. 

But for consistency we should fix this issue. I have been told a while ago that the use of "|" was discarded for localization issues, so we moved towards the comma ",". I would go for the comma.
Flags: needinfo?(vpg)
So that means we should use the comma for all cases, right?

Note that in Bug 931119 we're making the separator localizable (in the messages app at least, but this could be done elsewhere), so I don't think the localization issues should be taken into account as all separators will be able to be changed.
Flags: needinfo?(vpg)
OK, great for other cases, but unless we feel the separator is better, I would go for the comma. 
Let's go for the comma then.
Flags: needinfo?(vpg)
Was resolved in the scope of bug 925404.

Master: https://github.com/mozilla-b2g/gaia/commit/3aaf653afdbcc41daf565886ce4d3228264259f2

Demo can be seen here:
https://wiki.mozilla.org/Gaia/SMS/Scrum/3#bug_925404:_Always_include_the_phone_number_in_the_SMS_Thread_UI.2C_even_if_the_carrier_is_known

Description os this bug is different from bug 925404, so don't mark it as DUPLICATE.
Status: NEW → RESOLVED
Closed: 8 years ago
OS: Mac OS X → Gonk (Firefox OS)
Hardware: x86 → ARM
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.