Why do we have the second search field? we don't have it if JS is enabled

In T136244#2328769, @Nirzar wrote:

Why do we have the second search field? we don't have it if JS is enabled

I can't remember why but I think this was Zero related and requested by Adam because search wasn't so noticeable. I don't think we need this any longer.. thoughts?

@dr0ptp4kt and @Deskana need to talk about this bug and work out which team needs to work on this bug which seems high priority.

I can't remember why but I think this was Zero related and requested by Adam because search wasn't so noticeable. I don't think we need this any longer.. thoughts?

we just made it noticeable :) I don't see the point of having two.

I'll need to go back through my notes on this. There was a general discoverability problem on some grade C devices as I recall, but there was also interplay with W0.

Okay, I think I found this. It wasn't Wikipedia Zero specific as I see it, although it came out of the Wikipedia Zero team with an emphasis on Opera Mini. https://trello.com/c/blWoHdk8/1-5-improve-special-search-for-lower-end-device-users and https://trello.com/c/dnFtPXLs/15-show-did-you-mean-search-suggestion-on-resourceloader-capable-devices-when-present .

In case you can't access Trello, here was some background. Does any of this hold anymore?

For the ResourceLoader-impaired ("RLI") UAs, #search actually needs to be displayed to make their experience more functional, but the contained .mw-search-formheader and .mw-search-createlink within #search still need to be hidden even for these RLI UAs - this must be done by CSS, with search.less being a sensible place to do so. In effect, this leaves behind #mw-search-top-table, which contains #powerSearchText (very helpful in case the RLI user tapped the magnifying glass without having entered a search term of any sort) and, equally powerful, .searchdidyoumean.

But, if #search is displayed for RLI UAs by means of search.less, that means that ResourceLoader-capable ("RLC") UAs will also see #search. Given that RLC UAs already have a pretty functional search experience by means of #searchInput, I agree with you that it doesn't make a lot of sense to focus the cursor inside #searchText for these RLC users - after all, the overlay spawned from #searchInput should preclude the RLC users from having a blank search. But I still do think that .searchdidyoumean is extremely helpful for these RLC users - although it's "impossible" for the RLC user to have an empty search in #searchInput and to be on Special:Search, it is certainly possible that the RLC user's search has no corresponding full text results - often due to mistyping. So I created 'Show "Did you mean?" search suggestion on ResourceLoader-capable devices, when present'

I believe the clause "but with the search form on that page hidden" refers to the notion that if the CSS always shows #search for the no/low-JS devices, then it's the duty of JavaScript executed by ResourceLoader to restore the UI to the typical rendered state for UAs that are ResourceLoader-capable as of today, prior to this patch. I think there are more complex reasons for the suppression of advanced search, etc., but I believe the suppression of "Did you mean?" was just a collateral consequence. Hence why I'm asking for, at least, "Did you mean?" to be reinstated for the low/no-JS users. I'm going to add a card to the Q2 backlog requesting that "Did you mean?" is restored even for the ResourceLoader-capable devices based on @maryanapinchuk's recommendation on this comment trail.

Here were the original acceptance criteria:

• If user has JS and they have no search query entered, focus search field (#searchInput)
• If user has JS and they search with query or full-text search, use top-loaded JS to hide search form (#search). For example, if the user enters a term in the search header, and clicks Search [] Within Pages from the overlay, they should be taken to Special:Search, but with the search form on that page hidden.
• If no JS, always show search form (#search)
• Always hide .mw-search-formheader (advanced search options)
• Get Adam Baso to sign off on the final result if possible
• Make search icon show up in correct location even on small phones with no JS

Post hoc note: the first acceptance criteria was for when the user tapped on the magnifying glass instead of entering the search field and typing text, which we had heard was a common behavior and as I recall the data suggested was a real phenomenon.

@Nirzar, so I think the scenario we were trying to account for was the ResourceLoader-impaired (e.g., Opera Mini) user tapping the search icon in the top right part of the screen and just getting a page with nothing in it indicating what to do next, like this. How do you want to handle that these days?

This looks like a mobile only issue with the search that is on there, removing the search backlog tag.

For non Javascript browser and Opera mini specific it seems that we waste space by displaying the search field twice in the result page (both in the top menu and then again first on the page):

It's the same thing right or do we have specific functionality?

Ooops that's the same for all users, maybe we can fix it for all then :)

Is this is still stalled? Is this something reading or discovery are going to fix?

Reading Web should update MobileFrontend. @Nirzar, what UX would you propose here for these compression proxy browsers when they tap the search icon but haven't entered any search text? See T136244#2472626 for rationale of the existing approach for compression proxy browsers.

@dr0ptp4kt
it's in design backlog :( haven't gotten around working on it yet.

@Nirzar can this be resolved?

Per T140490 (about toolbar) also checked the Search page itself. Input text still overlaps the magnification icon.

(Opera Mini on iPhone, using the "Opera Mini" maximised mode).

The top right search icon will be fixed soon (see T140490).
The OOjs UI issue needs its own bug T164214.
This task is about the search experience overall and I believe it can be resolved given the UI redesign was addressing fundamental problems rather than UI bugs.

Nirzar can we mark as resolved?

@Jdlrobson are those the only 2 UI bugs?