Page MenuHomePhabricator

Over-ride the "zebra marquee" pending styling in Special:Search so that it's inconsistent with the rest of the interface, but consistent with every other full text search the user has likely used.
Closed, ResolvedPublic

Description

Last time Special:Search was converted to OOUI, typing something in the search box became an extremely annoying experience because the background of the text area was constantly occupied by a marquee of coloured zebra stripes moving very quickly.

I see no purpose for such a thing while I type, so please make sure there is no such thing next time.

Related Objects

StatusAssignedTask
ResolvedEsanders
OpenNone
OpenNone
OpenNone
ResolvedMarkTraceur
Resolvedmatmarex
Resolvedmatmarex
Resolvedmatmarex
OpenNone
OpenNone
OpenNone
Resolved Jdlrobson
Resolvedmatmarex
Resolvedmatmarex
OpenNone
OpenNone
ResolvedEsanders
DuplicateNone
ResolvedTTO
ResolvedJayprakash12345
Resolvedmatmarex
OpenNone
ResolvedFlorian
ResolvedFlorian

Event Timeline

Nemo_bis created this task.Nov 12 2015, 7:24 AM
Nemo_bis updated the task description. (Show Details)
Nemo_bis raised the priority of this task from to Normal.
Nemo_bis assigned this task to Florian.
Nemo_bis added subscribers: matmarex, violetto, Danny_B and 9 others.
Restricted Application added a project: Discovery. · View Herald TranscriptNov 12 2015, 7:24 AM

This is by design I think. An indication, that the form is looking for suggestions (which can probably take a longer time, e.g. if your internet connection is very slow), seems reasonable for me. I'm not sure, if we should make a difference to other LookupElements used in MediaWiki (or extensions), like VE?

Jdforrester-WMF renamed this task from Don't have a zebra marquee in Special:Search to Over-ride the "zebra marquee" pending styling in Special:Search so that it's inconsistent with the rest of the interface.Nov 16 2015, 11:12 PM
Jdforrester-WMF set Security to None.

Re-titled to be clear what this is asking. I'd imagine this will be declined, but it's @Volker_E's call I guess.

EBernhardson added a comment.EditedNov 16 2015, 11:27 PM

I can't think of any other full text search interface I've used that gives a visual notification that the auto-complete api call is pending. In my mind (as a non-designer) the marquee makes sense in a location where the primary goal is to complete a title, such as VisualEditor. Special:Search on the other hand, where title searches are done simply because we don't have anything better to offer, doesn't seem like as good of a use case.

EBernhardson renamed this task from Over-ride the "zebra marquee" pending styling in Special:Search so that it's inconsistent with the rest of the interface to Over-ride the "zebra marquee" pending styling in Special:Search so that it's inconsistent with the rest of the interface, but consistent with every other full text search the user has likely used..Nov 16 2015, 11:29 PM

I've made the title slightly more neutral

Where can I see a prototype of what this would look like?

I've put the last version of the patch on http://cirrus-browser-bot.wmflabs.org/wiki/Special:Search

This will disappear the next time a patch is uploaded to Cirrus and the bot runs though.

I've put the last version of the patch on http://cirrus-browser-bot.wmflabs.org/wiki/Special:Search

This will disappear the next time a patch is uploaded to Cirrus and the bot runs though.

I notice that on that page, the input field is marked as "required". Causing an unexpected red "error"-outline when the field is left empty. The current page in prod doesn't do that, which seems preferable?

Yeah, that was T106946, there's a config option now to disable validation in that field.

I've put the last version of the patch on http://cirrus-browser-bot.wmflabs.org/wiki/Special:Search

Hmm, yes, that does seem like it needs some work to me. The diagonal loader flickering on and off on every keystroke is odd when you're on a low-latency connection, and is not consistent with similar search experiences elsewhere. However, I'm not convinced that undermining our standardisation efforts is the right course here. What are our other options?

I'm not sure, what a designer would say. The default for an input with auto completion is a loading animation, to indicate, that some suggestions are loading. But I agree, that it could be confusing to users using this for a search field. I'm not sure, if there are other use cases for an input field with auto completion, but without a loading animation. If so, it would make sense to implement a configuration to turn it off. If not, it would result in a "special case" for the search input field, which would break (like mentioned by @Deskana, if I understand him correctly) the goal of a standardization.

Almost nobody would consider a full search text field (mainly) an autocompletion thingy, so there is no risk they'll feel an inconsistency.

Change 255436 had a related patch set uploaded (by Florianschmidtwelzow):
TitleInputWidget: Add an option to disable visually pending state

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

An alternative lower-weight styling (like a rotating dots symbol in the right?) might work better?

@EBernhardson Please put a screenshot here as well, the example environment at http://cirrus-browser-bot.wmflabs.org/wiki/Special:Search doesn't seem to have it any more.

Deskana moved this task from Needs triage to Search on the Discovery board.Dec 29 2015, 10:29 PM
matmarex closed this task as Resolved.Mar 3 2016, 8:24 PM
matmarex removed a project: Patch-For-Review.

Change 255436 merged by jenkins-bot:
MediaWiki Widgets: Add new SearchInputWidget

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

Why does this widget use the opensearch endpoint instead of the prefixsearch? From what I can see you get the same results, but the search is less configurable (e.g. we can't request images in JSON).

Restricted Application added a project: Discovery-Search. · View Herald TranscriptOct 9 2017, 9:22 AM
EBernhardson added a comment.EditedOct 10 2017, 7:32 PM

opensearch has been the default since before anyone on the team working on search. I believe the primary difference is this endpoint uses caching by default for not-logged in users which alleviates traffic levels and provides quicker responses, especially with shorter queries (which are the most expensive to run). I don't see any particular reason we have to use it, frontend should be able to provide appropriate requests to allow caching with the prefix api.