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.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| MediaWiki Widgets: Add new SearchInputWidget | mediawiki/core | master | +188 -1 |
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?
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.
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.
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.
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
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.
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).
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.