--- 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
You are receiving this mail because:
You are on the CC list for the bug.
Wikibugs-l mailing list