--- Comment #11 from MZMcBride <> ---
(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., 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.

You are receiving this mail because:
You are on the CC list for the bug.
Wikibugs-l mailing list

Reply via email to