Special:Search is still broken for Wikidata. The entity selector uses a different/better search. But people still get to Special:Search even if that is not what they want because they click enter too quickly after typing in their search. In this case they never see the entity selector's results. We should disable enter there (at least until the entity selector shows a result).
Version: master
Severity: major
Whiteboard: papercut
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=61948
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Suggester visibility depend on spinner visibility | mediawiki/extensions/Wikibase | master | +5 -3 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T46529 Wikidata search problems (tracking) | |||
| Resolved | thiemowmde | T55476 fix the issue of people not seeing the suggestion in the main search box |
We should avoid that. Locking the "enter" key would make the page appear to be unresponsive for at least a moment. This will cause annoyance as well.
I am not sure about the exact issue that would be worked around by locking the Enter key. Is it about not directly redirecting to a certain item or is it about the overall quality of the search result?
The issue is that people type very quickly and then hit enter. When they hit enter the entity suggester has not shown any result yet. Because of this they get redirected to the search page. The search page gives a much worse experience than the entity suggester. People shouldn't be redirected to the search page unless they explicitly select that in the entity suggester itself.
Hope that is clearer. If not I can show you in the office when I am back.
Sorry, but I have to agree to Henning. Blocking a key is no solution. Sometimes the suggester stuff is delayed for different reasons. If this happens the Enter key will basically be blocked for no reason the user can see or understand.
The Special:Search results aren't that bad as far as I can tell. The high severity and priority of this report seems odd. Maybe this isn't an issue any more and can be closed or at least ranked down a lot? Lydia, do you have an example where the Special:Search result is so much worse than the suggester result?
It isn't about the search result being worse but about people being send to Special:Search who shouldn't go there.
Why not? Isn't being sent to a search results page what you expect when hitting enter in a search field? I'm afraid the description is still unclear. It's describing a solution ("disable enter key") instead of the problem.
Can we close this ticket, please? It is more than half a year old and altough that would not be a major change, I doubt anyone wants to be blamed for having implemented that.
There are far more unobtrusive alternatives to make users aware about suggestions getting loaded; For example, show a placeholder where the list of suggestions would appear when starting to type.
(In reply to Thiemo Mättig from comment #7)
Why not? Isn't being sent to a search results page what you expect when
hitting enter in a search field?
Not if the field used to be have a "Go" button whose functionality was replaced by the use of ENTER.
Not having this on Wikidata makes the user experience inconsistent with other WMF wikis, where I can happily type e.g. "pi"+ENTER and get to the page I want immediately.
(In reply to Helder from comment #9)
Not if the field used to be have a "Go" button
Not sure what you mean. There is no "Go" button in Vector. Special:Search decides if doing a redirect is sufficient or if a results page should be shown. This is neither client nor Wikibase code. This is core.
Not having this on Wikidata makes the user experience inconsistent
Not having what? Inconsistent with what? Can someone (Lydia?) please, please give a real-world example and describe the actual and the expected result?
where I can happily type e.g. "pi"+ENTER and get to the
page I want immediately.
This works fine. Type a page title like "Q123" or "Property:P123" and hit enter fast and you will be redirected to the page. Again, I have to ask what the issue is? Closing this for now per Henning, since there isn't enough information and I doubt there is an issue at all.
(In reply to Thiemo Mättig from comment #10)
(In reply to Helder from comment #9)
Not if the field used to be have a "Go" button
Not sure what you mean. There is no "Go" button in Vector. Special:Search
decides if doing a redirect is sufficient or if a results page should be
shown. This is neither client nor Wikibase code. This is core.
[[meta:Help:Go button]]
https://meta.wikimedia.org/wiki/Help:Go_button
Not having this on Wikidata makes the user experience inconsistent
Not having what?
Not having the feature of going directly to the page instead of Special:Search when hitting ENTER.
Inconsistent with what?
Inconsistent with the behavior of the same field in other WMF wikis.
where I can happily type e.g. "pi"+ENTER and get to the
page I want immediately.This works fine. Type a page title like "Q123" or "Property:P123" and hit
enter fast and you will be redirected to the page. Again, I have to ask what
the issue is? Closing this for now per Henning, since there isn't enough
information and I doubt there is an issue at all.
Are supposed to memorize Q numbers instead of descriptive titles?
Oh wow, this is complicated. I finally understood what Lydia and you expect. The problem is, this can't and will never work, at least not so easily. In Wikibase the Q numbers are the titles. The labels are not titles. Wikibase labels are not unique. MediaWiki page titles are. If you type a MediaWiki page title (e.g. "Q123") which is known to be a (unique) title Special:Search will do a redirect for you. There are many reasons this can't work for labels, especially the fact that labels aren't unique (try to search for "Berlin") and multi lingual.
Sure, we could try to implement some kind of label lookup that does a redirect if only one search result is found. But since there are so many labels and so many duplicates this isn't going to work in most cases and will be counterintuitive in others.
@Lydia: Daniel said this was once discussed at length. Can you post a link to the discussion?
I suggest to keep this "block a key" request closed. (Really, why should we block typing "Q123" if that's what a user wants?) This needs to be discussed somewhere else.
Reopening because we _really_ need to fix this somehow. Maybe blocking the enter key isn't the right way but then let's find something else. Just the other day I was watching people again get sent to Special:Search just because they didn't wait two seconds until suggestions where shown to them. Is there any other solution you can think of for this?
Discussed this some more with Thiemo. As a next step Henning's suggestion to show the suggester with a spinner after typing the first (two?) letters even if there is no result yet seems good.
The feature is live on wikidata.org but it seems there is a bug. The spinner is not shown initially. I investigated and found two possible solutions, see https://gerrit.wikimedia.org/r/#/c/181056/. Pinging @Snaterlicious.
Change 181056 had a related patch set uploaded (by Thiemo Mättig (WMDE)):
Suggester visibility depend on spinner visibility
Change 181056 merged by jenkins-bot:
Suggester visibility depend on spinner visibility