https://bugzilla.wikimedia.org/show_bug.cgi?id=52812
--- Comment #16 from Connor Behan <connor.be...@gmail.com> --- [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. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
