Last modified: 2014-01-03 19:15:45 UTC
The "Disable search suggestions" user preference should be removed from MediaWiki core. It's rarely used and provide more interface clutter and code complexity than any benefit it might provide. This should be an easy bug to resolve; marking it with the Bugzilla keyword accordingly.
I would like to prepare a patch for this bug. Please assign the same to me.
Change 99163 had a related patch set uploaded by 01tonythomas: Removed "Disable search suggestions" from Mediawiki Preference https://gerrit.wikimedia.org/r/99163
Change 99163 merged by jenkins-bot: Removed "Disable search suggestions" from Mediawiki Preference https://gerrit.wikimedia.org/r/99163
Please revert this. The preference would easily fit in "Display options" and I have not seen any data about your claim that it is rarely used. Within a few days of removal, four people have already said that they want this feature back, https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29#AJAX_suggestions_now_mandatory.3F https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29#Searching_showing_.27suggestions.27_all_of_a_sudden and this is of the people who know enough to go to the Village Pump. Moreover there are gripes about this (https://support.mozilla.org/en-US/questions/970986) on other sites.
I posted here before finding the data (https://www.mediawiki.org/wiki/Requests_for_comment/Core_user_preferences). 112 users out of 40,000 is quite small but accessibility and web standards need to be more important than popularity. Did you think about the fact that anyone in the English speaking world sees a list full of American topics simply by pressing "u"?
Dude, I ALSO want the AJAX search suggestions removed. I was doing pretty fine... until the AJAX suggestions took over. I DO NOT want my results dictated by A MACHINE. I'd like this "bug" reverted.
Thanks for all those reviews. I have contacted @MZMcBride on the same. Lets hear from him, about the same. Sorry for all those inconvenience caused by the way.
(In reply to comment #5) > I posted here before finding the data > (https://www.mediawiki.org/wiki/Requests_for_comment/Core_user_preferences). > 112 users out of 40,000 is quite small but accessibility and web standards > need to be more important than popularity. Can you please clarify what you mean by "accessibility and web standards"? > Did you think about the fact that anyone in the English speaking world sees a > list full of American topics simply by pressing "u"? The suggestions are based on the number of incoming links, as I recall. (Someone should double-check this.) If you have a suggestion for a better means of ranking/providing suggestions, please file a separate bug report. It may also make sense to file a bug report about limiting when suggestions trigger (i.e., displaying suggestions with only a single letter of input may be a bit too sensitive). (In reply to comment #6) > Dude, I ALSO want the AJAX search suggestions removed. I was doing pretty > fine... until the AJAX suggestions took over. I DO NOT want my results > dictated by A MACHINE. Unfortunately this comment makes no sense to me. Search results are always programmatically generated, no? Can you please clarify what you mean here?
(In reply to comment #8) > (In reply to comment #5) > > I posted here before finding the data > > (https://www.mediawiki.org/wiki/Requests_for_comment/Core_user_preferences). > > 112 users out of 40,000 is quite small but accessibility and web standards > > need to be more important than popularity. > > Can you please clarify what you mean by "accessibility and web standards"? You've read the Village Pump discussion, but to repeat with less cruft, the suggestion box covers up the "Search" and "Go" buttons with the monobook skin. Some people were saying that these buttons are not needed but Redrose64 pointed out that they help avoid a bug in firefox >= 25.0. Also, unlike a search *history* box, a search *suggestion* box is not a web standard. This is why Wikipedia, YouTube, Google and every other site using suggestions cannot have them rendered in a user's native theme. Uniformity of the desktop experience is a divisive topic and this alone is enough of a reason to opt out of search suggestions. One problem with this argument is that if the suggestion box is disabled, the history box would also cover the "Search" and "Go" buttons in monobook. However, this box will disappear more quickly unless the user has recently searched for just about everything on Wikipedia. > The suggestions are based on the number of incoming links, as I recall. > (Someone should double-check this.) If you have a suggestion for a better > means > of ranking/providing suggestions, please file a separate bug report. It may > also make sense to file a bug report about limiting when suggestions trigger > (i.e., displaying suggestions with only a single letter of input may be a bit > too sensitive). An option to set the number of characters sounds preferable to what we have now. But only because I would set it to 999 and make it so I never see suggestions. Wouldn't this bloat the code more than putting the option back? Even if there is an unbiased algorithm deciding how it is done, the suggestion feature is one of the many things that chips away from the neutrality of Wikipedia. Microsoft gets free advertising when you press "x". Google gets free advertising when you press "y". If I want to read about politics in my country and type "Justin Trudeau", on the way I am inadvertently reminded of "Justin Timberlake" and "Justin Bieber". I have read the other preferences that are marked for death and I have not been able to find many complaints about them. People seem to feel more strongly about disablesuggest. Ironically, the feature itself promotes crowd-sourcing from the majority. So the types of people who turn it off are naturally the types of people who think populism should not dictate what preferences we keep.
I'll keep on saying it: We want the ability to turn off the AJAX search suggestions again. We DON'T want to see what Connor Behan describes where, if you want to search for Justin Trudeau, you get OTHER Justins. We don't want Machine-dictated stuff. Give us the choice again. Thanks!
(In reply to comment #9) > You've read the Village Pump discussion, but to repeat with less cruft, the > suggestion box covers up the "Search" and "Go" buttons with the monobook skin. When entering data, most input systems seem to have a more efficient means (return key, for example) of submitting the input. As also noted on the village pump, hitting the escape key, etc. can re-reveal the go and search buttons, though I agree that this is a valid Monobook bug and should probably be filed separately (if a separate bug doesn't exist already). > Also, unlike a search *history* box, a search *suggestion* box is not a web > standard. This is why Wikipedia, YouTube, Google and every other site using > suggestions cannot have them rendered in a user's native theme. Uniformity of > the desktop experience is a divisive topic and this alone is enough of a > reason to opt out of search suggestions. No, I'm sorry, but this is a nonsense argument. The nature of browser rendering is that everyone's experience will be slightly different based on countless factors for the same site (e.g., en.wikipedia.org). It'll be even more diverse across multiple sites (Wikipedia, YouTube, etc.). It's always been this way. > One problem with this argument is that if the suggestion box is disabled, the > history box would also cover the "Search" and "Go" buttons in monobook. Yep, this should be filed as a separate bug as it affects everyone using Monobook (myself included). I imagine there's already a relevant bug report somewhere around here, though. > An option to set the number of characters sounds preferable to what we have > now. But only because I would set it to 999 and make it so I never see > suggestions. Wouldn't this bloat the code more than putting the option back? Sorry, I didn't mean a per-user option here. I meant a global option. Is it ever correct for suggestions to appear when a user has only typed "J"? We may want to wait until the user has typed three or more characters for all users (though we'll then hit edge cases like whether suggestions should reveal if a user types "A "...). This would be filed as a separate bug report, however. > Even if there is an unbiased algorithm deciding how it is done, the > suggestion feature is one of the many things that chips away from the > neutrality of Wikipedia. Microsoft gets free advertising when you press "x". > Google gets free advertising when you press "y". If I want to read about > politics in my country and type "Justin Trudeau", on the way I am > inadvertently reminded of "Justin Timberlake" and "Justin Bieber". There are ways to improve the overall search suggestion algorithm, the (delay) until it shows, how many characters until it shows, etc. And we can consider scrapping the entire feature, if it's really as damaging to neutrality as you suggest (though I think that argument is a bit flawed). However, in all of these cases, I do not think adding a per-user on/off switch really helps matters. We should either fix or kill the feature for everyone. > I have read the other preferences that are marked for death and I have not > been able to find many complaints about them. People seem to feel more > strongly about disablesuggest. I don't think the response has been particularly strong. > Ironically, the feature itself promotes crowd-sourcing from the majority. So > the types of people who turn it off are naturally the types of people who > think populism should not dictate what preferences we keep. Probably true. :-) But when we look at code and interface complexity versus requiring that the few users who want to hide these easily can (using per-user CSS or JS), I don't really buy the argument for an additional checkbox here. If you want to hide them, by all means, please do. But most people seem to either not care or like them, so I don't think an additional checkbox is warranted.
(In reply to comment #10) > I'll keep on saying it: We want the ability to turn off the AJAX search > suggestions again. We DON'T want to see what Connor Behan describes where, if > you want to search for Justin Trudeau, you get OTHER Justins. If you search for "Justin Trudeau" on the English Wikipedia, you'll reach <https://en.wikipedia.org/wiki/Justin_Trudeau>. If that isn't working, please file a separate bug report. If you begin typing in "Justin", you'll be given a list of the most relevant suggestions for which "Justin"-related page you want (Justin Timberlake, Justinian I, Justin Bieber). If you type in "Justin Tr", you'll get "Justin Trudeau" as your first suggestion, it looks like. If you want to turn off search suggestions, just hide them for your account (see below). > Give us the choice again. Thanks! You already have the choice of hiding any part of the interface that you'd like to. For example, I personally hide the Wikipedia logo and many of the sidebar sections and the footer (here's a recent screenshot of my browser: <http://i.imgur.com/nsqQEQf.png>). You can easily hide the search suggestions for your personal account using custom CSS or JavaScript. If you need help, you can post to [[m:Tech]] (the global technical village pump) or consult the English Wikipedia's village pump (linked above).
I'll chime in because design was tagged in this bug but the only part of it that seems design related is the desire to simplify preferences, which i think is a great goal. As many have said, the number of users that have even interacted with this preference is negligible. Some of their rational is curious ("advertising for celebrities") as a means of disabling it. People who do not want this feature because it requires javascript are probably likely to disable javascript sitewide through their browsers. While the argument that on extremely slow connections or computers this could "Slow down the experience" could possibly be valid, It does not slow down you ability to enter and execute a search query. If a user types a query and hits enter or the search icon, the search is executed immediately, whatever the search suggestion box is doing seems to have no effect on immediately executing the search. So in general I'm fine with removing this, I don't care if its now or when we do a total overhaul of the preferences, but its probably easier to just do it now.
(In reply to comment #13) > People who do not want this feature because it requires javascript are probably > likely to disable javascript sitewide through their browsers. I disagree. The 112 people who used this option would have no reason to if they actually disabled javascript. And having javascript enabled is the only way people noticed immediately when suggestions became mandatory. I for one like the talk page notifier and the ability to roll over citations. By keeping controversial features like the visual editor optional, Wikipedia has been an ideal site for those who value Javascript used sparingly... until now. > While the argument that on extremely slow connections or computers this could > "Slow down the experience" could possibly be valid, It does not slow down you > ability to enter and execute a search query. It does slow down your ability to enter it. On my 1GHz machine, the letters I type show up after a slight lag compared to < 1.22 MediaWikis. This is especially noticable after "hiding but not disabling" the suggestions via CSS.
Conner I don't know that we have a 1Ghz machine to test that on, thankfully we have users like you who can tell us what the system does on machines like that. Performance certainly isn't something we want to sacrifice there. Two things, can you let us know if other sites like google for instance which have type ahead have similar slow down issues while typing? 2nd can you log a separate bug that when type-ahead search is enabled that it causes lags or hangs for you when typing? that seems best tackled as a separate bug rather than part of this one.
[I messed up the quoting above] First, I need to say that the algorithm is not my issue. People who dislike non-neutral and non-standard suggestions will continue to dislike them whether they trigger after one character or three. Therefore I am not the right person to file bugs about the algorithm itself. Leave that to someone who actually likes the suggestion feature. (In reply to comment #11) > When entering data, most input systems seem to have a more efficient means > (return key, for example) of submitting the input. As also noted on the > village pump, hitting the escape key, etc. can re-reveal the go and search > buttons, though I agree that this is a valid Monobook bug and should probably > be filed separately (if a separate bug doesn't exist already). One should not have to do extra work to click these buttons. The separate one is bug 13941 and has been open for five years. If you or another dev can decide upon the best way to fix that, we should do that as soon as possible. Then my list of arguments against mandatory search suggestions will go down from about 10 to 9. > No, I'm sorry, but this is a nonsense argument. The nature of browser > rendering is that everyone's experience will be slightly different based on > countless factors for the same site (e.g., en.wikipedia.org). It'll be even > more diverse across multiple sites (Wikipedia, YouTube, etc.). It's always > been this way. It's a perfectly valid argument. Yes, after the days of ftp and usenet, the web experience has involved many sites with a different look and feel. And despite this, certain UI widgets like radio buttons, checkboxes, drop-down lists and text boxes (where there is no need for them to differ between sites) have been standardized by HTML tags like "input". When a website switches from these to custom AJAX widgets that do the same thing, users are absolutely correct to say that this is a functionality regression. It would be too hard for me to solve this problem on YouTube, Google, etc. I save my battles for the sites developed by small, reasonable teams that I respect. Wikipedia is using browser rendered widgets wherever possible. The suggestion box below the search box is the only example on the entire site (and one of the few examples on the web) of a native widget "spawning" a non-native one. It is this juxtaposition that really hurts aesthetics. > And we can consider scrapping the entire feature, if it's really as damaging > to neutrality as you suggest (though I think that argument is a bit flawed). > However, in all of these cases, I do not think adding a per-user on/off switch > really helps matters. We should either fix or kill the feature for everyone. Well this would certainly decrease code bloat wouldn't it? If killing the feature is on the table, I would first invert the option so that users have to specifically enable suggestions to see them. Then another dataset could be used to make sure there isn't a huge blowback. Would it help to move suggestions into a gadget? If suggestions were removed from the core, I would gladly write a gadget for users who don't mind sacrificing a bit of neutrality in exchange for faster searches. > Probably true. :-) But when we look at code and interface complexity versus > requiring that the few users who want to hide these easily can (using > per-user CSS or JS), I don't really buy the argument for an additional > checkbox here. I don't think this is a solution. If you hide suggestions with CSS, the "autocomplete" attribute is still off. This means that no search history shows up like it used to. This strange behaviour of the search box is a constant reminder of the fact that you are using a hack to fix something. I'm sure JS can be used to turn "autocomplete" back on, but using one JS hack to undo another would slow down the experience even more. Speaking of a slower experience, when I was typing searches into Wikipedia with the CSS applied, there was a noticeable time delay for letters to show up. This is because suggestions were still refining themselves when they were invisible. And just to make sure I wasn't hallucinating, I tried something else. Holding down the backspace button to erase a search doesn't work right away with invisible suggestions. You have to release the button before you see any letters disappear.
(In reply to comment #15) > Conner I don't know that we have a 1Ghz machine to test that on, thankfully > we have users like you who can tell us what the system does on machines like > that. Performance certainly isn't something we want to sacrifice there. Two > things, can you let us know if other sites like google for instance which have > type ahead have similar slow down issues while typing? 2nd can you log a > separate bug that when type-ahead search is enabled that it causes lags or > hangs for you when typing? that seems best tackled as a separate bug rather > than part of this one. Done, it's bug 59172. All other sites with suggestions cause the delay while typing.
(Copying from bug 13941 comment 7) The objection to the user preference is that the default behavior should be sane without the need to add user interface clutter. Most visitors don't have user preferences and most users never set their user preferences. If there's a reason that people can't stand these suggestions, we should find a way to either remove them or improve them. Letting users opt out is sometimes a valid position to take, but it's generally a last resort, given the constraints and context (i.e., how most visitors experience the site and how most users interact with it). And we can generally allow opting out without re-adding the user interface clutter, via user JS and CSS subpages. For limited cases, this solution works really well. I think this is one of those cases.
(In reply to comment #16) > It's a perfectly valid argument. Yes, after the days of ftp and usenet, the > web experience has involved many sites with a different look and feel. And > despite this, certain UI widgets like radio buttons, checkboxes, drop-down > lists and text boxes (where there is no need for them to differ between sites) > have been standardized by HTML tags like "input". When a website switches from > these to custom AJAX widgets that do the same thing, users are absolutely > correct to say that this is a functionality regression. Only if the AJAXified widget introduces actual regressions, of course. AJAX, like anything else, can be misused. But if we assume good faith, we can imagine that most programmers write additional code of this nature to add features/benefit to the user experience. Any regressions need to be weighed against actual benefit (cost–benefit analysis is a part of any code). > Well this would certainly decrease code bloat wouldn't it? If killing the > feature is on the table, I would first invert the option so that users have > to specifically enable suggestions to see them. I don't think killing the option is realistically on the table. I think most users like the suggestions (or at least don't mind them). We could survey a random sample of users to get better data on the matter. For better or worse, we currently rely largely on anecdotal evidence and general best practices when deciding matters of this nature (reducing user interface clutter, reducing code complexity). > I don't think this is a solution. If you hide suggestions with CSS, the > "autocomplete" attribute is still off. This means that no search history > shows up like it used to. This is browser-level search history, right? Doesn't this drop-down also obstruct the buttons? (And potentially introduce privacy concerns, no?)
(In reply to comment #18) > (Copying from bug 13941 comment 7) > > The objection to the user preference is that the default behavior should be > sane without the need to add user interface clutter. Most visitors don't have > user preferences and most users never set their user preferences. If there's > a reason that people can't stand these suggestions, we should find a way to > either remove them or improve them. Letting users opt out is sometimes a > valid position to take, but it's generally a last resort, given the constraints > and context (i.e., how most visitors experience the site and how most users > interact with it). And we can generally allow opting out without re-adding > the user interface clutter, via user JS and CSS subpages. For limited cases, > this solution works really well. I think this is one of those cases. The last resort is warranted when there is a sharp disagreement over which behaviour is sane. But I should see how my gadget proposal goes before I do more arguing: https://en.wikipedia.org/wiki/Wikipedia:Gadget/proposals#Disable_AJAX_search_suggestions I will start telling people from the Village Pump discussion unless there's a way to turn on the gadget for everyone who had disablesuggest before.
(In reply to comment #19) > I don't think killing the option is realistically on the table. I think most > users like the suggestions (or at least don't mind them). So there is not a single dev who minds them? Next time there is an election for the WMF board, I will try to find out the various opinions about AJAX features and let that decide my vote. > This is browser-level search history, right? Doesn't this drop-down also > obstruct the buttons? (And potentially introduce privacy concerns, no?) It obstructs the buttons but not as often. It is easy to clear the history or set it to clear automatically. And users can also do "incognito mode" so I don't see how there are privacy concerns.
