Update Loop buttons & state (color, name, visibility...) in contact details when a branding/UX decision is taken

RESOLVED FIXED in Firefox OS v2.0

Status

RESOLVED FIXED
5 years ago
4 years ago

People

(Reporter: oteo, Assigned: jmcf)

Tracking

unspecified
2.1 S1 (1aug)
ARM
Gonk (Firefox OS)
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:2.0+, b2g-v2.0 fixed, b2g-v2.1 fixed)

Details

(Whiteboard: ft:loop)

Attachments

(2 attachments, 2 obsolete attachments)

54.85 KB, image/png
Details
191 bytes, text/html
arcturus
: review+
Details
(Reporter)

Description

5 years ago
Still under discussion the 1.0 Mobile Loop client branding, and it seems that the decision wil not be made before the 2.0 Feature Landing (June 9th)

So after that date and after landing Bug 988392 - Allow Loop to be added to the contact details, probably, we will need to update the name of the aplication or some colors or fonts in the Loop buttons included in the contact details.

This bug is for tracking these possible branding updates.
(Reporter)

Updated

5 years ago
Blocks: 988279
(Reporter)

Updated

5 years ago
Assignee: nobody → borja.bugzilla

Comment 1

4 years ago
We won't have the name ready for the 9th.
Can we although land the attached design and just change the "Loop" string into whatever the end-up deciding for the name (I am hearing it won't be too long to reach a decision on that front)?

Also please confirm the following is OK:
* If Loop is not installed, the "Loop" headline and the buttons are not shown
* If the contact has an MSISDN but no e-mail, an e-mail but no MSISDN or both an MSISDN and an e-mail the Loop buttons are show with the "Loop" headline as per the screenshot below
* If the contact has no MSISDN and no e-mail then no buttons are shown (and no Loop headline)
Flags: needinfo?(oteo)

Comment 2

4 years ago
Created attachment 8433163 [details]
contact card.png

Comment 3

4 years ago
> * If the contact has no MSISDN and no e-mail then no buttons are shown (and
> no Loop headline)

I'm actually recommending to show the buttons, but disabled. Not a big issue anyway. For the record, that particular conversation is happening in the original bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=988392#c14
(Reporter)

Comment 4

4 years ago

(In reply to Romain Testard [:RT] from comment #1)
> We won't have the name ready for the 9th.
> Can we although land the attached design and just change the "Loop" string
> into whatever the end-up deciding for the name (I am hearing it won't be too
> long to reach a decision on that front)?

Sure, that's the reason I created this bug, in order to address these issues. Once the decision is made I will request 2.0? in this bug.

> Also please confirm the following is OK:
> * If Loop is not installed, the "Loop" headline and the buttons are not shown
> * If the contact has an MSISDN but no e-mail, an e-mail but no MSISDN or
> both an MSISDN and an e-mail the Loop buttons are show with the "Loop"
> headline as per the screenshot below
> * If the contact has no MSISDN and no e-mail then no buttons are shown (and
> no Loop headline)

Francisco has requested ni to Carrie in bug 988392 to confirm is she agrees with Rafa's suggestion or not. Whatever UX or Product guys decide is ok for me and feasible. Just let's know in bug 988392
Flags: needinfo?(oteo)
Summary: Update Loop buttons (color, name...) in contact details when a branding decision is taken → Update Loop buttons & state (color, name, visibility...) in contact details when a branding/UX decision is taken
Hi Carrie!

Regarding the improvements to the UI for showing the actions related with Loop, we would like to know your suggestions & proposal about where to add this info and how.

Currently the scenario we have implemented is:
- If 'Loop' is not installed: buttons are not shown in any scenario
- If 'Loop' is installed, buttons are shown but:
 + If no email/phone number: buttons are disabled
 + If email/phone number: buttons are enabled

The goal is to show to the user that a new feature is enabled with Firefox OS, and that's why we show them as disabled/enabled instead of hidding them or not. Currently we are adding this as a separate section after the phone/email if available, or in the top of the list if no phone/email is available.

This is just for making easy the way of discovering the new feature, and let the user to wonder what it is and how to use it.

Having a Contact without email or phone number is not a common scenario, but I agree we should handle it properly.

Do you have any proposal about where to add this info and how? Thanks a lot! 谢谢!
Flags: needinfo?(cawang)
Hi Romain,
Regarding the branding, we would need to know asap colors, final naming... in order to update then properly within Contact Details view. Do you know if there is any update about this? Thanks!
Flags: needinfo?(rtestard)

Comment 7

4 years ago
(In reply to Borja Salguero (this week part-time in Gaia) [:borjasalguero] from comment #6)
> Hi Romain,
> Regarding the branding, we would need to know asap colors, final naming...
> in order to update then properly within Contact Details view. Do you know if
> there is any update about this? Thanks!

Per my comment above we won't have naming ready for the 9th but hopefully by end of next week.
Flags: needinfo?(rtestard)
copy my comments from bug 829820

My suggestion is:

1. If there is no email and no MSISDN, we remove the buttons. 
2. If one of the email or the MSISDN exists, we show the buttons.
3. If both the email and the MSISDN exist, we show the buttons.


In addition, I still think we shall move these two buttons above the email section but underneath the phone numbers section so that the similar actions will be close to each other (normal calls/ audio/ video calls).

Thanks!
Flags: needinfo?(cawang)

Comment 9

4 years ago
marking bug that it might have late localization string for the Product name, if that name is determined before 6/20 at the string localization cut-off date.
Keywords: late-l10n

Updated

4 years ago
Whiteboard: ft:loop
Depends on: 988392

Updated

4 years ago
feature-b2g: --- → 2.0
Borja could you estimate when this will be ready?
Flags: needinfo?(borja.bugzilla)
Target Milestone: --- → 2.0 S4 (20june)
(Reporter)

Comment 11

4 years ago
We need first a decision from Product team about the branding, name of the application :(
I think there's one more important question, and this involves all products, not just Firefox OS.

Is "Loop" (or whatever its name will be), going to be localizable or a brand name? "Find My Device" and "Firefox Accounts" are localizable for example.

Does this bug require more strings than just the product name?
Hi Francisco,
I'm tied to Product decision to implement this. Once I have all the info, this is a one-day-patch.

As Francesco suggested, we need to clarify first the final name, if this is going to be localizable, and other details related with branding (as colors, icon if needed...).

Romain, any update on this?
Flags: needinfo?(borja.bugzilla) → needinfo?(rtestard)
This is still work in progress on the marketing side, I needinfo Arcadio who can provide an accurate target date.
Flags: needinfo?(rtestard) → needinfo?(alainez)
(In reply to Francesco Lodolo [:flod] from comment #12)
> I think there's one more important question, and this involves all products,
> not just Firefox OS.
> 
> Is "Loop" (or whatever its name will be), going to be localizable or a brand
> name? "Find My Device" and "Firefox Accounts" are localizable for example.
> 
> Does this bug require more strings than just the product name?

I think this is the first I'm hearing about something called Loop. Can someone catch me up a bit?

My gut says that this will be localized as we don't want to create too many new brand names, but I can't say for sure until I have more details.

Thanks.
(In reply to Matej Novak [:matej] from comment #15)
> I think this is the first I'm hearing about something called Loop. Can
> someone catch me up a bit?

You're not alone, I discovered it the other day when it landed on Firefox Nightly.
https://wiki.mozilla.org/Loop

My understanding is that Loop is a WebRTC video chat client for Firefox browsers and OS.

Comment 17

4 years ago
Hello, Arcadio. I am on the Firefox OS UX team and keeping an eye on the visual refresh across the OS. I am working with QA and release to understand when this work might land. Do you have any update? Thank you!

And Francesco, you are correct. :)
(Reporter)

Updated

4 years ago
Target Milestone: 2.0 S4 (20june) → 2.0 S5 (4july)

Updated

4 years ago
blocking-b2g: --- → 2.0?
keep the nomination until we get the marketing decision firmed.
By that time we will know more clearly what the expected behavior should be.
This is feature work, which already has the right flag set here, so I'm clearing the nom.
blocking-b2g: 2.0? → ---

Comment 20

4 years ago
Hi Everyone, 

Shell asked me to jump in here and give Everyone the latest update on the naming process. 

Internally we have narrowed the names to 2 - 3 names. These names have received preliminary clearance from Legal and are now being fully vetted. We expect to have a recommendation from Legal by July 3. 

Next steps from here are as follows:
- July 3 - Review recommendation from Legal
- July 7 - Present final names to Chris Beard and team leads
- July 8 - 11 - Present final name select to TEF/TokBox
- July 11 - Final name complete

This dates may slip pending on the broader team's availability but we understand we're up against the wall. 

The Name
- It will follow current product nomenclature: Firefox [Something]
- The name will not be translated; it will always be written in English like Firefox Sync
- In the UI we may present in-language prompts for the user to follow like "Say hello with [something]"

Thanks for your patience, Everyone. Please reach out to me by Vidyo or email or IRL if you have questions. 

Arcadio
Flags: needinfo?(alainez)

Updated

4 years ago
Keywords: late-l10n
(Reporter)

Updated

4 years ago
Target Milestone: 2.0 S5 (4july) → 2.0 S6 (18july)

Comment 21

4 years ago
Arcadio update: down to a final name. Legal doing a final review (another one) of a trademark registration in Europe by internal and external counsel feel that our recommended name poses low risk and should be available.  Internal legal will have a final legal recommendation by Wednesday, July 9.  Internally we have covered the project leads through a formal presentation.  No objects from partner on the previous list.  need final exec approval before adding.
(In reply to alainez from comment #20)
> Hi Everyone, 
> 
> Shell asked me to jump in here and give Everyone the latest update on the
> naming process. 
> 
> Internally we have narrowed the names to 2 - 3 names. These names have
> received preliminary clearance from Legal and are now being fully vetted. We
> expect to have a recommendation from Legal by July 3. 
> 
> Next steps from here are as follows:
> - July 3 - Review recommendation from Legal
> - July 7 - Present final names to Chris Beard and team leads
> - July 8 - 11 - Present final name select to TEF/TokBox
> - July 11 - Final name complete
> 
> This dates may slip pending on the broader team's availability but we
> understand we're up against the wall. 
> 
> The Name
> - It will follow current product nomenclature: Firefox [Something]
> - The name will not be translated; it will always be written in English like
> Firefox Sync
> - In the UI we may present in-language prompts for the user to follow like
> "Say hello with [something]"
> 
> Thanks for your patience, Everyone. Please reach out to me by Vidyo or email
> or IRL if you have questions. 
> 
> Arcadio
Hi,
May I know the latest update?
Flags: needinfo?(alainez)

Comment 23

4 years ago
Hi Everyone, 

We received final name approval from legal late last week. 

The name we cleared is: Firefox Hello

We will use this in English and will not localize it. 

Our next steps for this week is to present to and inform the execs but we have the support of Pete Scanlon, the team leads and legal so we're in a good place. 

We're scheduling time to present to the execs this week. I think we're there.

arcadio
Flags: needinfo?(alainez)
(Reporter)

Comment 24

4 years ago
(In reply to alainez from comment #23)
> Hi Everyone, 
> 
> We received final name approval from legal late last week. 
> 
> The name we cleared is: Firefox Hello
> 
> We will use this in English and will not localize it. 
> 
> Our next steps for this week is to present to and inform the execs but we
> have the support of Pete Scanlon, the team leads and legal so we're in a
> good place. 
> 
> We're scheduling time to present to the execs this week. I think we're there.
> 
> arcadio

Thanks Arcadio, so can we go ahead with this bug? 
Otherwise, let's know when you have the final confirmation
Flags: needinfo?(alainez)

Updated

4 years ago
Duplicate of this bug: 1013989
(Reporter)

Comment 26

4 years ago
(In reply to Carrie Wang [:carrie] from comment #8)
> copy my comments from bug 829820
> 
> My suggestion is:
> 
> 1. If there is no email and no MSISDN, we remove the buttons. 
> 2. If one of the email or the MSISDN exists, we show the buttons.
> 3. If both the email and the MSISDN exist, we show the buttons.
> 
> 
> In addition, I still think we shall move these two buttons above the email
> section but underneath the phone numbers section so that the similar actions
> will be close to each other (normal calls/ audio/ video calls).
> 
> Thanks!


Hi Carrie,
just one doubt, in case of a contact with only e-mail, where do you want the Loop(Firefox Hello better) buttons? Above or below the e-mail section?

Thanks
Flags: needinfo?(cawang)

Comment 27

4 years ago
Hello Everyone!

We have received final approval for Firefox Hello.

We are good to go. 

Thanks everyone for being so patient!! We ended up in a really great place with the name. 

Arcadio
Flags: needinfo?(alainez)
Hi Maria, 

I'd suggest the loop button should be above the email button. Thanks!
Flags: needinfo?(cawang)
(Assignee)

Comment 29

4 years ago
Created attachment 8458574 [details]
21865.html
Attachment #8458574 - Flags: review?(francisco)
Comment on attachment 8458574 [details]
21865.html

Code wise, LGTM, left some minor nit in github.

Problem is that unit tests are failing, specially the ones for webrtc:

https://tbpl.mozilla.org/?rev=bf80ac49d7cfaf4343960819092328743c64ff85&tree=Gaia-Try

gaia-unit-tests TEST-UNEXPECTED-FAIL | communications/contacts/test/unit/webrtc-client/webrtc_client_test.js | WebRTC Client integration If WebrtcClient & no email/phone, buttons are disabled | WebrtcClient is not defined
ReferenceError: WebrtcClient is not defined
gaia-unit-tests TEST-UNEXPECTED-FAIL | communications/contacts/test/unit/webrtc-client/webrtc_client_test.js | WebRTC Client integration "after each" hook | WebrtcClient is not defined
ReferenceError: WebrtcClient is not defined
gaia-unit-tests TEST-UNEXPECTED-FAIL | system/test/unit/lockscreen_window_manager_test.js | system/LockScreenWindowManager Handle events LockScreen request to unlock with activity detail | it didn't construct 
the activity while the request denote to do it: expected false to be true


Just retrigger the job, but we should investigate.
Attachment #8458574 - Flags: review?(francisco)
(Assignee)

Updated

4 years ago
Assignee: borja.bugzilla → jmcf
(Assignee)

Comment 31

4 years ago
Comment on attachment 8458574 [details]
21865.html

addressed comments on GH. The reported test failures corresponded to another revision of the PR, thus now let's wait for TBPL verdict that should be green

thanks!
Attachment #8458574 - Flags: review?(francisco)
Comment on attachment 8458574 [details]
21865.html

tbpl green!

Thanks Jose!
Attachment #8458574 - Flags: review?(francisco) → review+
(Assignee)

Comment 33

4 years ago
https://github.com/mozilla-b2g/gaia/commit/1bb6310e2030b261253d0bb3774d6fa95087474b
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED

Comment 34

4 years ago
Jose, why is the string exposed to localizers if it's not supposed to be localized?

Also marking this as late-l10n, as folks probably want this for the 2.0 branch.
Flags: needinfo?(jmcf)
Keywords: late-l10n
(Assignee)

Comment 35

4 years ago
just in terms of flexibility. Imagine that the name changes in the future. That will allow us to change it without actually modifying the JS code. 

thanks
Flags: needinfo?(jmcf)

Comment 36

4 years ago
So, if the name changed, you'd had to change the js code to pick up a new string ID.

If anything, that name should probably be in brand.properties, which also has the benefit that it's not localizable in official builds.
(Assignee)

Comment 37

4 years ago
ok, I can understand if you think that change is worth it, please file a new bug and I will deal with it

Updated

4 years ago
Blocks: 1040737
Hi folks,

I prefer to backout this change and on Monday we land the correct solution for anyone.
We won't need to ask twice for approval, will be easier.

Result of the backout:

https://github.com/mozilla-b2g/gaia/commit/e3eec08b7f286fbd56119d93b23cf98c9fd21a02
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Reporter)

Updated

4 years ago
Duplicate of this bug: 1040737
(Assignee)

Comment 40

4 years ago
Created attachment 8459420 [details]
21977.html
Attachment #8458574 - Attachment is obsolete: true
Attachment #8459420 - Flags: review?(francisco)
(Assignee)

Updated

4 years ago
Attachment #8459420 - Flags: feedback?(l10n)

Comment 41

4 years ago
Comment on attachment 8459420 [details]
21977.html

flod commented on the PR about a unneeded change to an l10n file. Also, the unofficial branding is exposed to l10n, which is OK for master, but for 2.0, we'd need to work around that.
Attachment #8459420 - Flags: feedback?(l10n) → feedback+
Comment on attachment 8459420 [details]
21977.html

Taking into account the suggestions by :pyke.

Also I think we should notice that the brand 'Firefox Hello' won't be translatable
Attachment #8459420 - Flags: review?(francisco) → review+
(Assignee)

Comment 43

4 years ago
https://github.com/mozilla-b2g/gaia/commit/a9571e2d230a95771b3dba4bc226fa36c386776f
Status: REOPENED → RESOLVED
Last Resolved: 4 years ago4 years ago
Resolution: --- → FIXED
(Reporter)

Comment 44

4 years ago
Nominating to 2.0, as perhaps it's a little late for the approval (2.0 Code Complete) and we need to show the correct name (Firefox Hello) in the the contact details.

Jason, let me know if I am wrong and I still have to ask for approval, thanks!
blocking-b2g: --- → 2.0?
Flags: needinfo?(jsmith)

Comment 45

4 years ago
The patch we have comes with changes to two files exposed to localizers, contacts.en-US.properties and unofficial/branding.en-US.properties.
(In reply to Maria Angeles Oteo (:oteo) from comment #44)
> Nominating to 2.0, as perhaps it's a little late for the approval (2.0 Code
> Complete) and we need to show the correct name (Firefox Hello) in the the
> contact details.
> 
> Jason, let me know if I am wrong and I still have to ask for approval,
> thanks!

Agreed we need this for 2.0, but I think this should go through approval, especially given the concern raised in comment 45.
Flags: needinfo?(jsmith)
(Reporter)

Comment 47

4 years ago
(In reply to Axel Hecht [:Pike] from comment #45)
> The patch we have comes with changes to two files exposed to localizers,
> contacts.en-US.properties and unofficial/branding.en-US.properties.

Hi Axel, you are right, contacts.en-US.properties has been changed by mistake (two extra white spaces added, nothing else). Do you think this is gonna trouble to localizers, if so, let's know and we will fix this issue before asking for approval.
Flags: needinfo?(l10n)

Comment 48

4 years ago
I expect localizers to complain, yeah.
Flags: needinfo?(l10n)
(In reply to Axel Hecht [:Pike] from comment #48)
> I expect localizers to complain, yeah.

Hi,

Axel, will it work for you if I backout the last commit and commit it back without any changes in contacts.en-US.properties?
Flags: needinfo?(l10n)

Comment 50

4 years ago
That still doesn't address the problem that the unofficial branding has a new string.
Flags: needinfo?(l10n)
(Reporter)

Comment 51

4 years ago
(In reply to Axel Hecht [:Pike] from comment #50)
> That still doesn't address the problem that the unofficial branding has a
> new string.

Yes, but that's something we need to live with due to the late decision on the branding.
Right, we didnt have the final naming till past week, so there is no much we can do here.

If everyone agree will proceed with comment 49

Comment 53

4 years ago
The decision was allowed to be late based on the promise that it wouldn't come with string changes.

There is stuff we can do, too. One possible hack would be to hard-code the string in branding.ini, instead of branding.en-US.properties.
(In reply to Axel Hecht [:Pike] from comment #53)
> The decision was allowed to be late based on the promise that it wouldn't
> come with string changes.
> 
> There is stuff we can do, too. One possible hack would be to hard-code the
> string in branding.ini, instead of branding.en-US.properties.

Sounds good, but recently I've read in the mailing list that we would like to get ride of the .ini files:

https://groups.google.com/forum/#!topicsearchin/mozilla.dev.gaia/locales.ini/mozilla.dev.gaia/K38ucraKX1k

It's a plan that could affect this hack?
Flags: needinfo?(l10n)
Replacement of .ini file is eventually targeting master, this hack would be only for 2.0 to avoid breaking string freeze, so I don't see any possible issue between the two of them.
Flags: needinfo?(l10n)
(Assignee)

Comment 56

4 years ago
backed out to solve the pending l10n issues

https://github.com/mozilla-b2g/gaia/commit/cd50cb6ddeb430ddaf43e4fcf5774b9d262a8cf3
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 57

4 years ago
(In reply to Axel Hecht [:Pike] from comment #48)
> I expect localizers to complain, yeah.

Oh my God, I thought you had more important things to complain on
(Assignee)

Comment 58

4 years ago
Anyone can point me in the right direction about the branding.ini hack? I have added the string there and nothing works. 

thanks
(Assignee)

Comment 59

4 years ago
(In reply to Jose Manuel Cantera from comment #58)
> Anyone can point me in the right direction about the branding.ini hack? I
> have added the string there and nothing works. 
> 
> thanks

I have tried different options, including

webRtcClientName = Firefox Hello

@import url(branding/branding.en-US.properties)

[ar]
@import url(branding/branding.ar.properties)

[fr]
@import url(branding/branding.fr.properties)

[zh-TW]
@import url(branding/branding.zh-TW.properties)

and that does not work.
(Reporter)

Updated

4 years ago
Flags: needinfo?(l10n)

Comment 60

4 years ago
Hrm. Maybe that's stuff in the ini logic we removed in the refactor.

What will work is using a non-localized .properties file like /locales/loop.brand.properties, no en-US in the file name.

Or just hard code the string in the code. Both depend on how non-officially-branded powered-by devices should treat the feature.
Flags: needinfo?(l10n)
(Assignee)

Comment 61

4 years ago
(In reply to Axel Hecht [:Pike] from comment #60)
> Hrm. Maybe that's stuff in the ini logic we removed in the refactor.
> 
> What will work is using a non-localized .properties file like
> /locales/loop.brand.properties, no en-US in the file name.
> 
> Or just hard code the string in the code. Both depend on how
> non-officially-branded powered-by devices should treat the feature.

We will hard code. These minor issues are diverting us from our target which is landing asap
(In reply to Axel Hecht [:Pike] from comment #60)
> Hrm. Maybe that's stuff in the ini logic we removed in the refactor.

Yes, this is correct.
(Assignee)

Comment 63

4 years ago
Created attachment 8460186 [details]
22033.html
Attachment #8459420 - Attachment is obsolete: true
Attachment #8460186 - Flags: review?(francisco)
Attachment #8460186 - Flags: review?(francisco) → review+
Taking for 2.0 for loop
blocking-b2g: 2.0? → 2.0+
Removing late-l10n as the name won't have to be localized.
Keywords: late-l10n
Jose,

should we mark this as fixed?
Flags: needinfo?(jmcf)
(Assignee)

Comment 67

4 years ago
https://github.com/mozilla-b2g/gaia/commit/01d86c8cc615658694b114ca5711763efc4ef205
Status: REOPENED → RESOLVED
Last Resolved: 4 years ago4 years ago
Flags: needinfo?(jmcf)
Resolution: --- → FIXED
(Reporter)

Updated

4 years ago
feature-b2g: 2.0 → ---
status-b2g-v2.0: --- → affected
status-b2g-v2.1: --- → fixed
Target Milestone: 2.0 S6 (18july) → 2.1 S1 (1aug)
You need to log in before you can comment on or make changes to this bug.