Change 282404 had a related patch set uploaded (by Bmansurov):
WIP: Beta: UI debt fixes

https://gerrit.wikimedia.org/r/282404

@Nirzar, do we also need to style the search box inside the search overlay?

Never mind, I see the mocks above.

yes!

@Nirzar Is one of the mocks showing the :focus state of the input?

@Nirzar, you can see it in action at http://reading-web-staging.wmflabs.org/wiki/1

Some problems that came out during review.

1. I expect this to go through the beta channel first to allow us to assess the design before pushing it but we haven't written this in the description. Should we?

2. @Nirzar how should this impact other overlays? It seems strange that the header of the editor/talk/languages/notifications is different from the header of search - for example notifications on tablet:

If these should be different they should be documented in the code with reasoning to avoid confusion later on about when to use the gray background and when not too.

3. Also as @Volker_E points out we have no focus state for this search. Given we don't have one for the current design, this is not a regression, but for the purpose of accessibility, it would be good to tackle this in a later patchset/task if we can.

I expect this to go through the beta channel first to allow us to assess the design before pushing it but we haven't written this in the description. Should we?

This is a very minor fix which improves the usability based on very very basic graphic design principals. if it was anything more than that i would avoid such rollout.

how should this impact other overlays? It seems strange that the header of the editor/talk/languages/notifications is different from the header of search - for example notifications on tablet:

Actually it doesn't it's not strange. In any chrome, designers have been using the titlebar to expose searchfields. it's a norm by now.
plethora of examples > http://pttrns.com/search?q=search
the titlebar space is reserved for titles or search bar if it suits the case

Also as @Volker_E points out we have no focus state for this search. Given we don't have one for the current design, this is not a regression, but for the purpose of accessibility, it would be good to tackle this in a later patchset/task if we can.

definitely, since we are also thinking about this bar on desktop. I can put up a mock right away which uses our style guide.

This is a very minor fix which improves the usability based on very very basic graphic design principals. if it was anything more than that i would avoid such rollout.

Be careful with your words. By telling me this "is a very minor fix" you've already set my alarm bells ringing :). When we tinker with such important things we risk regressions on the thousands of devices we work with. It has been an unwritten team norm that all changes (non bug fixes) go through beta. I think we should continue with this. If we don't like this we should talk about it as a team and revisit in retrospective.

how should this impact other overlays? It seems strange that the header of the editor/talk/languages/notifications is different from the header of search - for example notifications on tablet:

Actually it doesn't it's not strange. In any chrome, designers have been using the titlebar to expose searchfields. it's a norm by now.
plethora of examples > http://pttrns.com/search?q=search
the titlebar space is reserved for titles or search bar if it suits the case

I don't follow. My corner isn't with the titlebar space being reserved (we've always done this) but it is with the inconsistency that the title bar is still white for overlays and gray for search. In the link you post the colour/design looks consistent for all the examples.

Thanks in advance for helping me come to a shared understanding with you.

Be careful with your words. By telling me this "is a very minor fix" you've already set my alarm bells ringing :). When we tinker with such important things we risk regressions on the thousands of devices we work with. It has been an unwritten team norm that all changes (non bug fixes) go through beta. I think we should continue with this. If we don't like this we should talk about it as a team and revisit in retrospective.

I will stand by my words, *It is* a minor change. it consists of background color and bounding box for search box. users do not care about what goes behind the code. if we can't change such simple things on our website without causing bugs, I do not know what we can do to improve our products.

as far as beta goes, this is not a feature but improved treatment of a UI element. I will let @dr0ptp4kt take that call, I'm fine with beta if that's the norm.

the search in the language overlay is inconsistent from the global search. Is this intentional?

Modal windows can have different titlebars than base chrome. modal windows come on top of the basic chrome and it helps to differentiate between the layers.

new chrome header is gray, the close icon is more bold to that of talk and languages

This keeps changing from talk to search and its a UI consistency caused by idk what.. its there on production. It would be amazing to see this get fixed. it changes if you load the notification panels once. its reproducible bug

Good conversation. I will stop development until we come to an agreement.

Please post to the beta channel on the production cluster first. I agree it's low risk, so a week in the beta channel seems like plenty of time.

I've created the follow on task for deployment to the stable channel on the prod cluster at T134894: Ship refreshed search bar to stable channel mobile web and guesstimated that would happen in sprint 73.

@Nirzar would you be okay making the close 'X' a back arrow instead?

If I understand correctly, the implicit :focus state is the same circle 'x' that's already there for clearing the search box as before.

@Nirzar would you be okay making the close 'X' a back arrow instead?

We currently only use the back arrow for the editor. The editor is the inconsistent one here in my opinion (see T73203 - awaiting feedback from a designer).

This keeps changing from talk to search and its a UI consistency caused by idk what.. its there on production. It would be amazing to see this get fixed. it changes if you load the notification panels once. its reproducible bug

You're right. I've updated T131931

Just a note, currently the change is 58 lines added, 39 removed. Although cosmetically minor it is not minor from a code perspective. We don't have any rules written down for what goes into beta first we only have this. I'm fine revisiting this to avoid these discussions later. I'd be more confident with this change were we better at signing off/testing and have a dedicated QA but none of those are true and I'd rather not be the one SWATing follow ups when this hits production.

@Nirzar do you want to see it in action? http://reading-web-staging.wmflabs.org/wiki/1?mobileaction=beta

@bmansurov the width of the field changes after focus. the width should be till the edge of screen (with the same padding as left) and if the notification icon is there, it should push it on left.

Change 282404 merged by jenkins-bot:
Beta: Enhanced search bar

https://gerrit.wikimedia.org/r/282404

@bmansurov Just checked on reading web staging. we need to fix the padding to be 15px each like shown here.

@bmansurov

1. the title bars for other modal windows should remain white.
2. on focus the whole field moves up by 1 px.

@Nirzar I've created a task for #2 (T134987) which is the current behavior in production. A patch for the other fixes is coming.

Change 288193 had a related patch set uploaded (by Bmansurov):
Search boxes fixes

https://gerrit.wikimedia.org/r/288193

@bmansurov the background color is the one we used while on the friday work session. i was hoping to get that color into our color guide by now but it did not happen.

because i don't want to bring inconsistency lets use

.header-container {

background-color:#f2f2f2 or f5f5f5 > whichever is in existing variables;

}

sorry about missing it earlier.

Change 288193 merged by jenkins-bot:
Search boxes fixes

https://gerrit.wikimedia.org/r/288193

*SIGNED OFF* from design

I've submitted a patch and pulled the above task to code review. Hope no one objects given it's a regression.

@Nirzar please can you sign off?