@bmansurov we have a different behavior on everyone else?? where do we show the spinner for regular users?

@Nirzar, compare https://en.m.wikipedia.org/wiki/Book vs https://en.m.wikipedia.org/wiki/Book?mobileaction=beta.

@bmansurov wait.. the recent changes we did to remove the flickr from auto suggest weren't deployed for everyone?

Nope, beta only.

@bmansurov hmm i thought we deployed it to everyone. can we change this task to deploy it for everyone instead of feature flagging? cc @ovasileva can confirm after the break.

Sounds good. Feel free to update the description as you see fit.

@bmansurov description updated.

Any reason this is still in beta? Any concerns about moving this to stable that would make it more than a 2 pointer?

why is this in beta? i thought we shipped it

Any technical blockers @bmansurov ...?

In T153973#3081617, @Jdlrobson wrote:

Any technical blockers @bmansurov ...?

None that I know of.

As I side note, from the original task:

This is a minor change to current behavior and we would like to see how it improves the experience. if we see value in it we can invest more time.

@Nirzar, did we see value in the new experience? If yes, how did we measure?

@Nirzar, did we see value in the new experience? If yes, how did we measure?

as this is a minor change. and not a feature we wouldn't be spending resourcing in evaluating the user value formally. this change is purely based on design principles, best practices, and judgement from design.

@Nirzar, your comment brings up a good point: Why was this feature not built into stable from ground up, do you remember? This is a good time to come to an agreement on when to enable features in beta and in stable. It will help us developers craft a solution depending on the expectations from the designer and PO.

Good point. Maybe we can have some norms around that. There are obviously things that need to go to stable directly but reason we said "feature flag everything" is because we are thinking of any features of bigger UI changes. now those two terms have ambiguity in them so we need norms around what to call a change. maybe create buckets and have different deployment strategy for each buckets.

Let me create a doc and share with the team.

In T153973#3085654, @bmansurov wrote:

@Nirzar, your comment brings up a good point: Why was this feature not built into stable from ground up, do you remember? This is a good time to come to an agreement on when to enable features in beta and in stable. It will help us developers craft a solution depending on the expectations from the designer and PO.

The code was introduced by @bmansurov in rEMFR4c64c8c8d6bd: Beta: Improve `search` experience as part of T137068 which Sam edited back in June 2016 to say MFBeta only. We can only assume there was a reason for adding this beta requirement. I'm not sure it's necessary to work out why now, it was probably meant as a short term test and we did a bad job at seeing it through to completion. Instead let's focus on writing clearer tasks upfront which document our decisions and reasoning.

In T153973#3085700, @Nirzar wrote:

Good point. Maybe we can have some norms around that. There are obviously things that need to go to stable directly but reason we said "feature flag everything" is because we are thinking of any features of bigger UI changes. now those two terms have ambiguity in them so we need norms around what to call a change. maybe create buckets and have different deployment strategy for each buckets.

We do have norms. We agreed to feature flag everything and we now add acceptance criteria to create tasks for follow up work as part of sign off, something we didn't have back in June 2016.

Are those norms cover the justification this card to be in beta and then stable? Baha's question will also get answered with that.

My point is there probably was justification for putting this in beta but it was not recorded so lost in history. I am hopeful now the team has improved since then in how it approaches work this will not happen again.

With respect to this task this looks good for estimation and implementation.

I'll tag it for next sprint, I think we can make space

Change 347636 had a related patch set uploaded (by Jdlrobson):
[mediawiki/extensions/MobileFrontend@master] Deploy flicker free search

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

@Nirzar - do we want to show the loading animation still?

@ovasileva after 2s gap?

Is this how the spinner should show?

Just checking as it's not clear from the description and that's how it's implemented...

New patch is up. I also did a follow up as I don't like the fact the SearchOverlay is using global events.

@Jdlrobson can we center align the spinner?

the mock is here > https://phabricator.wikimedia.org/T137068

in the mock, there's no keyboard but expected behavior is spinner center aligns with the viewport

rEMFR8721d8a9e4d9: Deploy flicker free search works as expected but the spinner isn't center aligned yet so I've just +1'd it.

Horizontal alignment has been taken care of.

Change 347636 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@master] Remove beta specific search behavioural changes

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

@ABorbaWMF with regards to QA, I hope the above test plan makes sense?

A spinner should only show when the search is taking longer than 2s. You can simulate this by disabling your internet connection before carrying out a search.

@ABorbaWMF: The developer tools of a lot of modern browsers also let you simulate arbitrary delays in the network connection. BrowserStack definitely has these tools enabled.

Tested on https://en.wikipedia.beta.wmflabs.org

Appears to be fixed.