Chris Kreinbring [:CKreinbring] Reporter
	Description • 11 years ago

Description:
After sending a text to a contact with just the name and number with carrier, the carrier name is shown instead of the phone number.

Repro Steps:
1) Update Buri to Build ID: 20131010004001
2) Have a contact with a name, phone number and carrier.
3) Launch the Messaging app.
4) Send an SMS to the contact.
5) Observe the secondary info line below the title.

Actual:
The phone type and carrier is shown.

Expected:
The phone type and number is shown.

Environmental Variables
Device: Buri 1.2 mozilla RIL
Build ID: 20131010004001
Gecko: http://hg.mozilla.org/releases/mozilla-aurora/rev/3f16dc100b1f
Gaia: 51f3c79ea93bb91d3b12e50b49d203a049a94a9b
Platform Version: 26.0a2

Notes:
Repro frequency: 100%
Link to failed test case: https://moztrap.mozilla.org/manage/cases/?filter-id=5030
See attached screenshots

	Rick Waldron [:rwaldron]
	Comment 5 • 11 years ago

This isn't a regression. Please review the explicitly defined rules as provided by Ayman here: https://bugzilla.mozilla.org/show_bug.cgi?id=883911#c4

Specifically citing:

> 1) …a unique string in the <carrier> field and a unique string in the <type> field output:
>	<type>, <carrier>


Which is what is shown in both the OP attachments and my follow attachments

	Jason Smith [:jsmith]
	Comment 6 • 11 years ago

I disagree with the UX proposal cited. Users are less likely to care about the carrier they are sending their SMS to - they certainly do want to know the phone number they are sending their text to. Otherwise, they could make a mistake and potentially send a SMS to the right contact name, but the wrong phone number, because they didn't remember how the type of contact mapped onto a phone number. In fact, the most important information to convey here is the phone number - the other pieces of information are nice to haves at best.

	Stephany Wilkes
	Comment 7 • 11 years ago

Flagging Jacqueline.

	Rick Waldron [:rwaldron]
	Comment 8 • 11 years ago

(In reply to Jason Smith [:jsmith] from comment #6)
> I disagree with the UX proposal cited. Users are less likely to care about
> the carrier they are sending their SMS to - they certainly do want to know
> the phone number they are sending their text to. Otherwise, they could make
> a mistake and potentially send a SMS to the right contact name, but the
> wrong phone number, because they didn't remember how the type of contact
> mapped onto a phone number. In fact, the most important information to
> convey here is the phone number - the other pieces of information are nice
> to haves at best.

You may disagree, but it's not up to us to make this call. NI? Ayman, as he is the one that designed the feature and should provide guidance here.

	Stephany Wilkes
	Comment 9 • 11 years ago

Jacqueline is the lead Mozilla UX person on Comms. She will make the call.

	ayman maat :maat
	Comment 10 • 11 years ago

(In reply to Rick Waldron from comment #8)
> (In reply to Jason Smith [:jsmith] from comment #6)
> > I disagree with the UX proposal cited. Users are less likely to care about
> > the carrier they are sending their SMS to - they certainly do want to know
> > the phone number they are sending their text to. Otherwise, they could make
> > a mistake and potentially send a SMS to the right contact name, but the
> > wrong phone number, because they didn't remember how the type of contact
> > mapped onto a phone number. In fact, the most important information to
> > convey here is the phone number - the other pieces of information are nice
> > to haves at best.
> 
> You may disagree, but it's not up to us to make this call. NI? Ayman, as he
> is the one that designed the feature and should provide guidance here.

...Its not even up to UX to make this call. Displaying carrier has been a hard requirement that has been in place since the very beginning of this project. We are not in a position to change that until the requirement is changed by product.

Marking as invalid. behaviour is aligned to requirements and is as specified.

	Jason Smith [:jsmith]
	Comment 11 • 11 years ago

I don't think that dismisses the fact of why phone number is being shown if the carrier is required to be shown. Please discuss this with product and explain to me exactly why the phone number cannot be shown in the use case specified. As it stands right now, it does not make sense to me why you would not tell user what phone number they are sending a text to.

	Jason Smith [:jsmith]
	Comment 12 • 11 years ago

needinfo on product for comment 11

	Julien Wajsberg [:julienw]
	Comment 13 • 11 years ago

The exact rule is:
* we use carrier if the "carrier" has been filled in, otherwise we use the phone number
* we still use the phone number if the "carrier" has been filled in, but the contact has two numbers with the same "carrier" information

We assumed that as long as the user enters a carrier information for a contact's number, this is what's important for him. If he really wants to know the phone number he can still tap on the header and show the contact's information.

Won't close the bug again but I think exactly like Rick and Ayman here.

	Stephany Wilkes
	Comment 14 • 11 years ago

Flagging Wilfred and Sandip, specifically, to address this more quickly.

	Jason Smith [:jsmith]
	Comment 15 • 11 years ago

Clearing the general needinfo on the product email alias as there's needinfo on the relevant product managers already.

	Jason Smith [:jsmith]
	Comment 16 • 11 years ago

(In reply to Julien Wajsberg [:julienw] (in Paris-Web conference thursday and friday) from comment #13)
> The exact rule is:
> * we use carrier if the "carrier" has been filled in, otherwise we use the
> phone number

This I don't think is a good idea - I can't remember the last time I ever actually cared that about the carrier I was sending my text message to. I care about who I'm sending it and what number it's going to.

> * we still use the phone number if the "carrier" has been filled in, but the
> contact has two numbers with the same "carrier" information

This approach is thinking too scientifically, and less user centric. I think we need to back up and think about what our users are likely to care about vs. not to understand what to display.

> 
> We assumed that as long as the user enters a carrier information for a
> contact's number, this is what's important for him. If he really wants to
> know the phone number he can still tap on the header and show the contact's
> information.

That's not really a good assumption to make. Just because I provide the information doesn't mean I treat it as the most important information to understand. Anyways, I think the above discussion is showing that we're not thinking outside of the box here - ask yourself, what is a user really seeing as the most important information? What's less important? That justifies a UX design decision on what to include vs. not. 

Also - tapping the header isn't an obvious workflow. When I'm typing a text message, I'm going to read what's on the SMS page, not tap around to gather information.

	Rick Waldron [:rwaldron]
	Comment 17 • 11 years ago

(In reply to Jason Smith [:jsmith] from comment #16)
> (In reply to Julien Wajsberg [:julienw] (in Paris-Web conference thursday
> and friday) from comment #13)
> > The exact rule is:
> > * we use carrier if the "carrier" has been filled in, otherwise we use the
> > phone number
> 
> This I don't think is a good idea - I can't remember the last time I ever
> actually cared that about the carrier I was sending my text message to. I
> care about who I'm sending it and what number it's going to.
> 
> > * we still use the phone number if the "carrier" has been filled in, but the
> > contact has two numbers with the same "carrier" information
> 
> This approach is thinking too scientifically, and less user centric. I think
> we need to back up and think about what our users are likely to care about
> vs. not to understand what to display.

FWIW, I actually agree with this and any point that supports always displaying the phone number.

	Jason Smith [:jsmith]
	Comment 18 • 11 years ago

(In reply to Rick Waldron from comment #17)
> FWIW, I actually agree with this and any point that supports always
> displaying the phone number.

Okay, then let's do that. We should implement a fix here then that always displays the phone number, rather than not showing it in certain cases cited above. That's my root concern here, less so of the others of why we would include the carrier in the first place - although it doesn't necessarily hurt to include it, unless there's no visual real estate left. Based on the screenshot seen here though, I think there is definitely room to include the phone number.

	Julien Wajsberg [:julienw]
	Comment 19 • 11 years ago

I thought like you at first but then I learnt to trust our UX designers.

I think that the "carrier" name is badly choosen, and is more like a "text reminder". But I was told this is used a lot in our target countries.

No change should be made without Ayman's approval here anyway. Flagging him then.

	ayman maat :maat
	Comment 20 • 11 years ago

ok Jason so i have a problem here with this thread and the desire to ignore (or redefine) requirements that are defined by user research and alter the implementation based on personal opinion/desire... 

We have a hard requirement which has been in place since before V1 based off the back of user research from the south american market to display the carrier field over and above the phone number. Carrier of contacts phone (apparently) is very important to our end users in these markets as it has an impact on cost when contact is made. Its presence differentiates us, and thats why the design is the way it is.

You are by no means the first person who, without knowledge of the design reasoning, has raised a (personal) issue with displaying the carrier field ...and i very much doubt you will be the last. But until requirements are changed by product I am going to consistently block any move to alter the behaviour of the carrier field.

With reference to comment 10, marking this bug as invalid as behaviour is aligned to requirements and is as specified

adding ni? to Daniel Coloma and Noemi (product at TEF where the requirement originates from) so that they have visibility of this conversation and can contribute if they see fit.

	Julien Wajsberg [:julienw]
	Comment 21 • 11 years ago

Ayman, 2 questions:
* what do you think of having both the carrier information and the phone number ?
* what do you think of renaming the "carrier" label ?

	Jason Smith [:jsmith]
	Comment 22 • 11 years ago

I think I've made it pretty clear that QA isn't going to be okay with the proposed design TEF has for not including the phone number. Without a clear rationale for not including the phone number, I think at this point I'm going to have to escalate up my management chain to get a fix here.

	Jason Smith [:jsmith]
	Comment 23 • 11 years ago

(In reply to ayman maat :maat from comment #20)
> ok Jason so i have a problem here with this thread and the desire to ignore
> (or redefine) requirements that are defined by user research and alter the
> implementation based on personal opinion/desire... 

User research is just one set of data - we have dogfooders and QAs who pick up and use this product daily. If it doesn't make sense to them, then you need to re-evaluate.

> 
> We have a hard requirement which has been in place since before V1 based off
> the back of user research from the south american market to display the
> carrier field over and above the phone number. Carrier of contacts phone
> (apparently) is very important to our end users in these markets as it has
> an impact on cost when contact is made. Its presence differentiates us, and
> thats why the design is the way it is.

That does not make an argument by any means for why phone number shouldn't be displayed. That just argues that the carrier should be there. Anyways, there's always be differing opinions on what a user thinks is important to display when sending a text message, so I don't think that the above rationale always is going to apply globally. It's just too closed off of a view to how this should be designed.

> 
> You are by no means the first person who, without knowledge of the design
> reasoning, has raised a (personal) issue with displaying the carrier field
> ...and i very much doubt you will be the last. But until requirements are
> changed by product I am going to consistently block any move to alter the
> behaviour of the carrier field.

It isn't a personal issue - this is just common sense for how a phone should work. The reporter claimed that the phone number wasn't displaying was a bug and I agree with them. If you've received multiple complaints around this, perhaps there's a missing element of analysis here that not being met in the current design?

> 
> With reference to comment 10, marking this bug as invalid as behaviour is
> aligned to requirements and is as specified

I think the above discussion has made it clear that you can't make a final decision here. Nevertheless, the only way I'm going to get an argument to not include the phone number is to get a real solid reasoning why it shouldn't be there. I see arguments in fact for it, which makes me think that it should still be implemented.

> 
> adding ni? to Daniel Coloma and Noemi (product at TEF where the requirement
> originates from) so that they have visibility of this conversation and can
> contribute if they see fit.

Just so it's clear - you need to get agreement with multiple QAs around why the phone number should or shouldn't be there to resolve this bug. Otherwise, someone whether that be a dogfooder, a QA, etc will file this bug again, as the reporter will see it as not making sense to them.

	Rafael Rebolleda
	Comment 24 • 11 years ago

Hey folks, 

From the Product and UX perspective, and to give a bit of context and rationale:

In our target markets, customers carry around several SIM cards to make the most out of their plans, in terms of valley/peak hours and carrier matching. Thus, knowing which carrier a user is interacting with is of vital importance in their flows in order to save money. I understand that is irrelevant for most of us, according to our carrier plans and economic realities, but we're not the target user. In this context, we went to a great deal of effort back in the day both in engineering and UX to make this happen.

That said, if the info is irrelevant for anyone, they can just ignore the field and will therefore see the beloved number which, fwiw and according to another research carried around dialer, nobody actually recognizes or associates with a contact anyway, but whatever. I agree the editing of contact details could be reworked to emphasize the fact that it is an optional field, so that is something we might take a look as a separate issue.

In any case, this a requirement from Product that comes straight from research and satisfies a clear customer and business case. I can't see how dogfooding experiences, while valuable in general, match against those in this particular context. In any case, as far as QA goes, this is working as devised, agreed, spec'ed and expected.

I will defer marking it as invalid to Daniel Coloma for the sake of diplomacy.

	Jason Smith [:jsmith]
	Comment 25 • 11 years ago

Rafael - I appreciate the rationale. We discussed this a bit more offline between product, QA, and UX. There's general agreement that the carrier should be there. However, there is agreement that at least two of concerns brought up by QA about the phone number's value argues in favor of investigating whether there's value to include the phone number always on composing a message. On that regard, this is not getting flagged as invalid at this point - we're using this bug for investigating including the phone number always in the compose message UI. Let me rework the title to indicate that.

	Rick Waldron [:rwaldron]
	Comment 26 • 11 years ago

(In reply to Jason Smith [:jsmith] from comment #25)
> we're using this bug for investigating including the phone
> number always in the compose message UI. Let me rework the title to indicate
> that.

In the "the compose message UI"? That's different and basically impossible—there's no room. The user will see the number in the search or if they tap on the accepted recipient, but to include it "always in the compose message UI", I don't think that's a reasonable goal.

I don't understand what is wrong with just including the phone number alongside the carrier string? It satisfies everyone's use case...

	Jason Smith [:jsmith]
	Comment 27 • 11 years ago

(In reply to Rick Waldron [:rwaldron][:rick][:rick waldron] from comment #26)
> (In reply to Jason Smith [:jsmith] from comment #25)
> > we're using this bug for investigating including the phone
> > number always in the compose message UI. Let me rework the title to indicate
> > that.
> 
> In the "the compose message UI"? That's different and basically
> impossible—there's no room. The user will see the number in the search or if
> they tap on the accepted recipient, but to include it "always in the compose
> message UI", I don't think that's a reasonable goal.
> 
> I don't understand what is wrong with just including the phone number
> alongside the carrier string? It satisfies everyone's use case...

Ack. My wording wrong here. Meant to say the SMS thread view.

	Jason Smith [:jsmith]
	Comment 28 • 11 years ago

(In reply to Jason Smith [:jsmith] from comment #27)
> (In reply to Rick Waldron [:rwaldron][:rick][:rick waldron] from comment #26)
> > (In reply to Jason Smith [:jsmith] from comment #25)
> > > we're using this bug for investigating including the phone
> > > number always in the compose message UI. Let me rework the title to indicate
> > > that.
> > 
> > In the "the compose message UI"? That's different and basically
> > impossible—there's no room. The user will see the number in the search or if
> > they tap on the accepted recipient, but to include it "always in the compose
> > message UI", I don't think that's a reasonable goal.
> > 
> > I don't understand what is wrong with just including the phone number
> > alongside the carrier string? It satisfies everyone's use case...
> 
> Ack. My wording wrong here. Meant to say the SMS thread view.

And yeah, sticking the phone number alongside the carrier string sounds fine.

	Rick Waldron [:rwaldron]
	Comment 29 • 11 years ago

> Ack. My wording wrong here. Meant to say the SMS thread view.

Ok, thanks for clarifying

> And yeah, sticking the phone number alongside the carrier string sounds fine.

Great, hopefully rafaelrebolleda finds this acceptable as well.

	Julien Wajsberg [:julienw]
	Comment 30 • 10 years ago

Hey Omega,

here is an old bug that would be nice to fix. Can you try to discuss with Rafael about this?

As a summary:
* we currently don't show the phone number if that phone number has a "carrier" information associated; instead we display the carrier. This is done like this because according to user testing, south american users use this information a lot.
* as dogfooding users, we find that not showing the phone number at all is confusing, and we'd like the number to be always displayed, _in addition_ to the carrier information if it's present.

Noemi, maybe you can provide your advice or get some information from inside TEF?

Thanks to you both!

	Noemí Freire (:noemi)
	Comment 31 • 10 years ago

Hi,

As already mentioned by Rafa in comment 24 ("In our target markets, customers carry around several SIM cards to make the most out of their plans, in terms of valley/peak hours and carrier matching. Thus, knowing which carrier a user is interacting with is of vital importance in their flows in order to save money"), for our target markets, carrier info is a MUST. We are not against showing phone number at the same time but in case of any potential conflict (such as the UI one (lack of space) that was raised in the past) the carrier should be the priority.

	Victoria Gerchinhoren [:vicky]
	Comment 32 • 10 years ago

Find atteched visuals indicating how to display the necessary information in the carrier area. Both visual and visual spec.

THanks.

	Julien Wajsberg [:julienw]
	Comment 35 • 10 years ago

Hey Victoria,

this is useful, thanks !

Here is an additional question for you:
* What's the spacing size between the phone number and the carrier information? (and by the way, it looks a little too close for my taste on this screenshot)

	Victoria Gerchinhoren [:vicky]
	Comment 36 • 10 years ago

(In reply to Julien Wajsberg [:julienw] from comment #35)
> Hey Victoria,
> 
> this is useful, thanks !
> 
> Here is an additional question for you:
> * What's the spacing size between the phone number and the carrier
> information? (and by the way, it looks a little too close for my taste on
> this screenshot)

Hi Julien,
The space is just a type space, I have decided to separate it with color instead of a charachter in order to make it more simple, another comma or a bar would have made it a bit cluttered. The separation space wise might seem close, but that's why the text has a different color as well, to make the separation effective.

Thanks!

	Julien Wajsberg [:julienw]
	Comment 37 • 10 years ago

I've put the mentor flag but it's not a very easy bug, because it involves changing how this line is displayed in javascript too. Especially we'll now use several elements instead of only one.

	Oleg Zasypkin [:azasypkin] Assignee
	Comment 38 • 10 years ago

Comment on attachment 8410334 [details]
Visual Spec. SMS  carrier info

Discussed with Victoria offline:

* Phone number should be displayed for all other cases too:
  ** type, number (including the case when contact doesn't have name defined);
  ** type, number carrier;

* As previously we don't display carrier header with phone number if there is no known contact behind it.

* The latest spec for carrier header is located here: https://bug950175.bugzilla.mozilla.org/attachment.cgi?id=8429571;

* If the carrier label is too long, we use ellipsis for it (...).

* The same format should be applied for all places where contact information is displayed (for details see bug 883911):
 ** Thread view header;
 ** Participant view;
 ** Remove participant confirm dialog;
 ** Contact search results;
 ** Participant context menu header.

Also it would be reasonable to fix bug 883911 in the scope of this one.

	Julien Wajsberg [:julienw]
	Comment 40 • 10 years ago

(In reply to Oleg Zasypkin [:azasypkin] from comment #38)
> Comment on attachment 8410334 [details]
> Visual Spec. SMS  carrier info
> 
> Discussed with Victoria offline:
> 
> * Phone number should be displayed for all other cases too:
>   ** type, number (including the case when contact doesn't have name
> defined);

Does that mean we'll have the number twice for unknown contacts ? Once in the title, once in the subheader ?

	Oleg Zasypkin [:azasypkin] Assignee
	Comment 41 • 10 years ago

(In reply to Julien Wajsberg [:julienw] (away until 2nd June) from comment #40)
> (In reply to Oleg Zasypkin [:azasypkin] from comment #38)
> > Comment on attachment 8410334 [details]
> > Visual Spec. SMS  carrier info
> > 
> > Discussed with Victoria offline:
> > 
> > * Phone number should be displayed for all other cases too:
> >   ** type, number (including the case when contact doesn't have name
> > defined);
> 
> Does that mean we'll have the number twice for unknown contacts ? Once in
> the title, once in the subheader ?
For unknown contacts we don't display carrier header at all, but for the known contacts without name we'll have number in both title and subheader.

	Oleg Zasypkin [:azasypkin] Assignee
	Comment 43 • 10 years ago

Comment on attachment 8440334 [details] [review]
GitHub pull request URL

Hey Steve, as we agreed here is the follow-up to bug 963013.

Thanks!

	Oleg Zasypkin [:azasypkin] Assignee
	Comment 44 • 10 years ago

Hey Francesco,

We're moving carrier labels used in SMS app to a single format:

"phone_type, phone_number phone_carrier" (see https://bug950175.bugzilla.mozilla.org/attachment.cgi?id=8429571 for the spec).

Current patch considers the following separators as localizable: 

* between phone_type and phone number (for en-US it's ",\u20");
* between phone_number and phone_carrier (for en-US it's "\u20").

Could you please confirm that we should make these separators localizable?

Thanks!

	Oleg Zasypkin [:azasypkin] Assignee
	Comment 45 • 10 years ago

Hey Vicky,

I'd like to confirm with you whether we still need to support the following case for carrier header (it's supported in SMS app for a long time):

"If for some reason a single contact has two phone numbers with the same type and the same carrier then only "type" and "phone number" is displayed (no carrier info is displayed)."

Is that case still valid?

Thanks!

	Francesco Lodolo [:flod]
	Comment 46 • 10 years ago

Yes, I think it's safer to have them localizable.

	Steve Chung [:steveck]
	Comment 47 • 10 years ago

Comment on attachment 8440334 [details] [review]
GitHub pull request URL

Some small comments on github but it still looks great! Please fix the conflicts before reply from visual and request review again, thanks.

	Victoria Gerchinhoren [:vicky]
	Comment 48 • 10 years ago

(In reply to Oleg Zasypkin [:azasypkin] from comment #45)
> Hey Vicky,
> 
> I'd like to confirm with you whether we still need to support the following
> case for carrier header (it's supported in SMS app for a long time):
> 
> "If for some reason a single contact has two phone numbers with the same
> type and the same carrier then only "type" and "phone number" is displayed
> (no carrier info is displayed)."
> 
> Is that case still valid?
> 
> Thanks!

Hey Oleg,
I think that if there's no constrain around it, we have no need to change it, right? Does this suppose a problem? If not, I would keep the same behavior.

	Oleg Zasypkin [:azasypkin] Assignee
	Comment 49 • 10 years ago

(In reply to Victoria Gerchinhoren [:vicky] from comment #48)
> (In reply to Oleg Zasypkin [:azasypkin] from comment #45)
> > Hey Vicky,
> > 
> > I'd like to confirm with you whether we still need to support the following
> > case for carrier header (it's supported in SMS app for a long time):
> > 
> > "If for some reason a single contact has two phone numbers with the same
> > type and the same carrier then only "type" and "phone number" is displayed
> > (no carrier info is displayed)."
> > 
> > Is that case still valid?
> > 
> > Thanks!
> 
> Hey Oleg,
> I think that if there's no constrain around it, we have no need to change
> it, right? Does this suppose a problem? If not, I would keep the same
> behavior.

Hey Vicky,

There is no problem with it, just wanted to confirm since format has changed. So will keep it.

Thanks!

	Oleg Zasypkin [:azasypkin] Assignee
	Comment 50 • 10 years ago

Comment on attachment 8440334 [details] [review]
GitHub pull request URL

(In reply to Steve Chung [:steveck] from comment #47)
> Comment on attachment 8440334 [details] [review]
> GitHub pull request URL
> 
> Some small comments on github but it still looks great! Please fix the
> conflicts before reply from visual and request review again, thanks.

Thanks for review! I've updated PR with the suggested changes.

Thanks.

	Steve Chung [:steveck]
	Comment 51 • 10 years ago

Some comments given on github. I just got some idea about the api interface, it would be good to know your thought first :)

	Oleg Zasypkin [:azasypkin] Assignee
	Comment 52 • 10 years ago

(In reply to Steve Chung [:steveck] from comment #51)
> Some comments given on github. I just got some idea about the api interface,
> it would be good to know your thought first :)

I've updated PR with the your API suggestion :) Thanks!

	Steve Chung [:steveck]
	Comment 53 • 10 years ago

Comment on attachment 8440334 [details] [review]
GitHub pull request URL

It looks great, r=me and please squash your commits before merging, thanks!

	Oleg Zasypkin [:azasypkin] Assignee
	Comment 54 • 10 years ago

(In reply to Steve Chung [:steveck] from comment #53)
> Comment on attachment 8440334 [details] [review]
> GitHub pull request URL
> 
> It looks great, r=me and please squash your commits before merging, thanks!

Thanks for review! Squashed and waiting for Travis and Try.

	Oleg Zasypkin [:azasypkin] Assignee
	Comment 55 • 10 years ago

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

	Shally Li（leave from Mozilla）
	Comment 56 • 10 years ago

This issue has been successfully verified on Flame 2.1.
See attachment: verified_1.png and verified_2.png
Reproducing rate: 0/5

Flame 2.1 build:
Gaia-Rev        db2e84860f5a7cc334464618c6ea9e92ff82e9dd
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/211eae88f119
Build-ID        20141126001202
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141126.033519
FW-Date         Wed Nov 26 03:35:30 EST 2014
Bootloader      L1TC00011880