1025517 - [Homescreen] Search bar text box not centered vertically in container

Status: RESOLVED FIXED

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

Description

[Diego Marcos [:dmarcos]]

Attachment: searchTextBoxNotCentered.jpg

The magnifying glass is not vertically centered either inside the text box. See attached image.

Comment 1

[Cristian Rodriguez (:crdlc)]

Attachment: It seems fixed

Comment 2

[Cristian Rodriguez (:crdlc)]

Currently the bug is invalid, in the past obviously it made sense, closing

Comment 3

[Diego Marcos [:dmarcos]]

The magnifying is still not vertically centered.

Comment 4

[Cristian Rodriguez (:crdlc)]

Comment on attachment 8441332 [details]
It seems fixed

Peter, please what is not centered here?

Comment 5

[Diego Marcos [:dmarcos]]

Attachment: firefoxSearchBox.jpg

The magnifying glass is not centered inside the text box. This is the firefox search box.

Comment 6

[Diego Marcos [:dmarcos]]

In the firefox search box the magnifying class is clearly centered vertically

Comment 7

[Cristian Rodriguez (:crdlc)]

I want to know the Peter's opinion because this implementation was approved by him see bug 1016822 comment 27

Comment 8

[Kevin Grandon :kgrandon]

Can you please put a reason when unblocking? I was using the vhomescreen.next bug as a bucket for everything that would make it nicer, this is possibly one of those.

Comment 9

[Peter La]

Hey Diego,

It was a design choice to reduce the length of the handle and center the icon on the circle (so that the circular part of the magnifying glass is concentric with the circle shape from the right end of outer pill shape).

Comment 10

[Diego Marcos [:dmarcos]]

The search box is still not centered in container. Attaching new image

Comment 11

[Diego Marcos [:dmarcos]]

Attachment: searchBarStillNotCentered.png

Comment 12

[Peter La]

Hey Diego, that is also by design so that it looks more balanced in the 'at rest' state in terms of spacing above and below the search pill.  In particular, this balances the gap between the top of the pill and the status bar icons, and the gap below the pill.

I am, however, considering removing the search box rectangle altogether, since it's interacting in a bad way with the scroll bar currently (and there isn't an easy workaround there).

Comment 13

[Diego Marcos [:dmarcos]]

We can play with CSS and when the box is in resting position at the top you reduce the the top margin/padding but when it's in "elastic over scrolling" mode you add that top margin so the box looks centered. I don't mind helping to polish this if nobody wants to jump on it.

Comment 14

[Kevin Grandon :kgrandon]

Unfortunately we don't have good overscroll events that we can hook into yet :-/

I think the best option here is to consider removing the background backdrop of the search bar for 2.0. In 2.1 this is being moved to the system and should be less of a problem.

Comment 15

[Peter La]

Diego, I'm going to investigate some options for this.  And look into centering the icon as well, as I've gathered some opinions from my team and some think it feels uncentered.  At first I thought it'd be cool to center on the circular elements, but I can see the other point of view as well.

Will try to post something soon.

Comment 16

[Diego Marcos [:dmarcos]]

I really appreciate that you tried to solve the design problem by thinking differently. I just misunderstood it. Vertical align can be tricky. Even Apple has issues. Look at the iOS search bar (attached picture). I still don't understand the logic for the vertical alignment. The cursor is not centered, the magnifying glass either, the lower case glyphs either, the upper cases either (same color squares have the same size).

Comment 17

[Diego Marcos [:dmarcos]]

Attachment: iosSearchBar.jpg

Comment 18

[Peter La]

Hi Diego.  Thanks for the example.  One thing to keep in mind when considering centering is that actual centering (like what you have called out in your iOS screenshot) vs centering based on the visual 'mass' or 'weight' of a particular shape are two different things.  Centering should be based on the latter, or visual weight, and sometimes that is open to interpretation.

After getting some feedback from my team mates, we've decided to center the search icon differently.  See next comments for spec + new icon asset.

Note, I did try to get rid of the rectangle beneath the search input field pill shape, but this would force me to lower the pill so that it has more breathing room next to the status bar.  This is a non-starter for 2.0 though as it would affect the full screen search layout.  We will revisit cleaning this up in 2.1 and 2.2.

Comment 19

[Peter La]

Attachment: Search Icon Positioning Spec

Please use the new assets I'm attaching in the next comment.

Note that as usual, the icon labelled 2x is actually 1.6875x (qHD).  We'll need to address this inconsistency later in one pass.

Comment 20

[Peter La]

Attachment: SearchIconAssets.zip

All 5 sizes included.

Comment 21

[Peter La]

ni'ing Diego as a reminder.  Hope you still have time to look at this, and thanks for caring about the details!

Comment 22

[Cristian Rodriguez (:crdlc)]

Attachment: New implementation

Is it ok? Thanks

Comment 23

[Cristian Rodriguez (:crdlc)]

Attachment: Github pull request

Thanks Vivien for taking a look here

Comment 24

[Peter La]

Comment on attachment 8447025 [details]
New implementation

Hi Cristian, great work as usual!

It looks perfect in terms of vertical position.  Horizontal position needs to move to the LEFT by about 1px before I can uireview+.

Thanks!

Comment 25

[Diego Marcos [:dmarcos]]

It looks great to me. I would love the screen of the flame to be brighter. Your design would shine much more.

Comment 26

[Cristian Rodriguez (:crdlc)]

Attachment: 1px to left

Comment 27

[Peter La]

Comment on attachment 8447846 [details]
1px to left

Perfect, thank you!

Comment 28

[Cristian Rodriguez (:crdlc)]

Merged in master:

https://github.com/crdlc/gaia/commit/e739f26df07420a5d2db5cabd24f7c5dc0553405

Comment 29

[Cristian Rodriguez (:crdlc)]

Comment on attachment 8447031 [details]
Github pull request

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): no regression
[User impact] if declined: visual improvement
[Testing completed]: no needed, ux+, changed the search icon in the rocketbar
[Risk to taking this patch] (and alternatives if risky): null
[String changes made]: no

Comment 30

[bhavana bajaj [:bajaj]]

Comment on attachment 8447031 [details]
Github pull request

Approving the low rick css change keeping the ux-review that's granted on the change.

Comment 31

[Kevin Grandon :kgrandon]

2.0: https://github.com/mozilla-b2g/gaia/commit/136066c8f00a599bbcfc9f66ca3db7c365338089

Comment 32

[Pavel Ivanov [:ivanovpavel][:pivanov] UX]

Hey guys,
just want to ask if we use 3.375x image like this one:
https://github.com/mozilla-b2g/gaia/blob/master/apps/verticalhome/style/images/search_icon.png

the size need to be integer, right? but the size here is 2rem if I calculate right 2*3.375=6.75rem or 67.5px and we don't want this, right?

Sorry if I'm wrong

Comment 33

[Kevin Grandon :kgrandon]

(In reply to Pavel Ivanov [:ivanovpavel] from comment #32)
> Hey guys,
> just want to ask if we use 3.375x image like this one:
> https://github.com/mozilla-b2g/gaia/blob/master/apps/verticalhome/style/
> images/search_icon.png
> 
> the size need to be integer, right? but the size here is 2rem if I calculate
> right 2*3.375=6.75rem or 67.5px and we don't want this, right?

I don't think the size needs to be integer? We have several 2.25x images for example. We were provided quite a few 3.375x images, I think because maybe due to the anticipation of full HD speced things. Although it currently looks like only the homescreen/grid code contains them.

Comment 34

[Pavel Ivanov [:ivanovpavel][:pivanov] UX]

Hey Kevin ... may not be expressed properly sorry for that ... I mean that if we have for example 24x24 image size ... and we will have this one:
@1x will be 24x1 = 24px
@2x will be 24*2 = 48px
@2.25x will be 24*2.25 = 54px
@3.375x will be 24*3.375 = 81px

Everything looks good

but if we have 30x30 image size the result will be:
@1x will be 30x1 = 30px
@2x will be 30*2 = 60px
@2.25x will be 30*2.25 = 67.5px
@3.375x will be 30*3.375 = 101.25px

and I'm not sure that `67.5px` and `101.25px` are good numbers for pixels or maybe I'm wrong?

Comment 35

[Kevin Grandon :kgrandon]

I think we have loads of fractional sized images and styles all around the OS. I wouldn't worry about it unless someone brings something up, then let's do an audit. A quick grep found hundreds of pixel usage with decimals across gaia.

Comment 36

[Elie]

Attachment: 009.png

This issue has been successfully verified on Flame 2.1:
Gaia-Rev        dbaf3e31c9ba9c3436e074381744f2971e15c7bf
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/ebce587d2194
Build-ID        20141203001205
Version         34.0
Device-Name     flame
FW-Release      4.4.2