1183617 - Implement updated design of 'Import' and 'Add new contact' buttons

Status: RESOLVED FIXED

(Hello (Loop) :: Client, defect, P1)

Description

[Mike de Boer [:mikedeboer]]

As the acceptance criteria in bug 1179210 states:

 - "Import" and "Add new contact" button layout refresh

For the visual design spec, please check out the ones attached to bug 1179210.

Comment 1

[Andrei Oprea [:andreio]]

Attachment: Implement updated design of contact buttons

Comment 2

[Andrei Oprea [:andreio]]

Attachment: Implement updated design of contact buttons

Comment 3

[Andrei Oprea [:andreio]]

Attachment: Buttons with line break

Comment 4

[Andrei Oprea [:andreio]]

Attachment: Buttons without line break

Comment 5

[Andrei Oprea [:andreio]]

I've attached 2 screenshots of the buttons (with and without line break). Depending on the length of the strings the buttons might look different. How should be handle this?

Comment 6

[Sevaan Franks [:sevaan]]

Deferring to Vicky.

Comment 7

[Victoria Gerchinhoren [:vicky]]

(In reply to Andrei Oprea [:andreio] from comment #5)
> I've attached 2 screenshots of the buttons (with and without line break).
> Depending on the length of the strings the buttons might look different. How
> should be handle this?

Andrei, this solution is OK for an edge case, but in general we'll advocate for the minimal copy for buttons, it is not good practice to have long text in buttons. On the other hand the rest of the UI I think it is WIP, right? Thanks!

Comment 8

[Mark Banner (:standard8)]

(In reply to Victoria Gerchinhoren [:vicky] from comment #7)
> (In reply to Andrei Oprea [:andreio] from comment #5)
> > I've attached 2 screenshots of the buttons (with and without line break).
> > Depending on the length of the strings the buttons might look different. How
> > should be handle this?
> 
> Andrei, this solution is OK for an edge case, but in general we'll advocate
> for the minimal copy for buttons, it is not good practice to have long text
> in buttons.

We need to remember that localised languages can't always cope with minimal copy (what's minimal in one language isn't always in every language), therefore we need to be happy with the design for both.

Comment 9

[Victoria Gerchinhoren [:vicky]]

(In reply to Mark Banner (:standard8) from comment #8)
> (In reply to Victoria Gerchinhoren [:vicky] from comment #7)
> > (In reply to Andrei Oprea [:andreio] from comment #5)
> > > I've attached 2 screenshots of the buttons (with and without line break).
> > > Depending on the length of the strings the buttons might look different. How
> > > should be handle this?
> > 
> > Andrei, this solution is OK for an edge case, but in general we'll advocate
> > for the minimal copy for buttons, it is not good practice to have long text
> > in buttons.
> 
> We need to remember that localised languages can't always cope with minimal
> copy (what's minimal in one language isn't always in every language),
> therefore we need to be happy with the design for both.

yes, I am aware of that, that's why I gave the OK. But it is also important to try to keep the buttons text clear and short (for instance if you're already in the contacts list, you don't need to write "import contact" when "import" is enough). When this is not possible, the 2 lines are OK as an edge case.

Comment 10

[Andrei Oprea [:andreio]]

Attachment: Implement updated design of contact buttons

Comment 11

[Andrei Oprea [:andreio]]

Comment on attachment 8636836 [details] [diff] [review]
Implement updated design of contact buttons

This just adds the style for the buttons and moves them in the right place. The margins/positioning are not correct but I expect that to be handled in bug 1183636.

Comment 12

[Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 8636836 [details] [diff] [review]
Implement updated design of contact buttons

Review of attachment 8636836 [details] [diff] [review]:
-----------------------------------------------------------------

r=dmose, assuming you put this up for ui-review and land it at the same time as the tab footer patch.

Comment 13

[Andrei Oprea [:andreio]]

https://hg.mozilla.org/integration/fx-team/rev/7f50f6fe0f3d

Comment 14

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/7f50f6fe0f3d

Comment 15

[Mark Banner (:standard8)]

Attachment: Backout for Aurora (42)

Approval Request Comment
[Feature/regressing bug #]: FF Hello Visual Refresh, backout patch 3 of 5
[User impact if declined]: Partial refresh implementation landed for 42, but is now being completed for 43 and isn't suitable for uplift. Hence, the current partially done 42 has bad layouts and an incomplete design change.
[Describe test coverage new/current, TreeHerder]: Code has unit tests
[Risks and why]: Low - reverting to the previous version.
[String/UUID change made/needed]: None. Any string changes were not backed out.

Comment 16

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

I'm guessing this means no QA verification is needed here anymore.

Comment 17

[Mark Banner (:standard8)]

(In reply to Florin Mezei, QA (:FlorinMezei) from comment #16)
> I'm guessing this means no QA verification is needed here anymore.

Its only being backed out of 42, but I'm not sure verification was really needed anyway being almost purely just changing the layout of the UI.

Comment 18

[Sylvestre Ledru [:Sylvestre]]

Mark, could you open a new bug for the backout?
Otherwise, this bug is going to be confusing.
Thanks

Comment 19

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8658615 [details] [diff] [review]
Backout for Aurora (42)

managed in bug 1203454