Last modified: 2014-05-13 18:32:59 UTC
The new Ajax-based prefix-search incorporated into standard Mediawiki yields a kind of dynamic box of choices *below* the search field. With most skins, it obscures the GO + SEARCH buttons, which makes klicking them a bit complicated. Suggestions: 1) place buttons elsewhere. 2) open the list *above* the search field. (Some browsers do that likely automagically when the search field is at, or close to, the lower egde of the current viewport or window)
or 3) Move the search box to upper-right corner of the page in monobook. This would enable a wider search field, more vertical space for the drop down box, and wouldn't obscure the buttons (since they would be to the right of the box).
This is the same behavior as known browsers' native autosuggest UI. [Note that the "at bottom of window" issue is separate and unrelated, and should be treated separately.]
Please see http://en.wikipedia.org/wiki/MediaWiki_talk:Sidebar#Search_and_go_buttons_above_search_form and the related discussion section just above it. I suggest putting the 'go' and 'search' buttons above the sidebar search form. Since the suggestion menu drops down it would no longer block the buttons. I looked at Internet Explorer, Firefox, Opera, and Google Chrome. Their auto-suggest menus do not block search buttons. The same is true for the Google toolbar. In some cases their search forms and address-bar search forms do not have search buttons. One searches by clicking the enter key. If anyone needs further input from me please ask at http://en.wikipedia.org/wiki/User_talk:Timeshifter. I rarely check the inbox for the throwaway email address used here for bugzilla.
In the past, going five years without fixing this has not been such a big deal. This is because monobook users have been able to disable search suggestions. Now that bug 52812 has been committed, the option to disable it is gone and the CSS hacks people recommend in their place are not adequate. It is definitely time for someone to fix this. I can think of four ways: 1. Move the Search and Go buttons in monobook. This will upset some monobook users (including me) who enjoy the current layout. It might violate the GNOME Human Interface Guidelines (which have nothing to do with WMF but are still something to think about). The act of searching takes place AFTER entering the search string. Therefore, putting the button above the box or to the left of it would only be appropriate for an RTL localization. 2. Disable search suggestions for the monobook skin. This will upset some monobook users who say that they like it. In the discussion (http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#AJAX_suggestions_now_mandatory.3F), [[User:Killondude]], [[User:NtheP]] and [[User:PiRSquared17]] have identified themselves as such users. 3. Restore the option to disable search suggestions. This will make everyone happy except the developers pushing for a cleaner preferences page. I suspect that they couldn't care less about the option itself. What they actually don't want to do is set the precedent that nothing can be removed (if we make an exception for you, we'll have to make an exception for everyone). 4. Have no search suggestions in the core and implement them as a gadget. I don't know of any effort to clean up the gadget page. Plus anonymous IP editors who like suggestions might be encouraged to get an account which is a good thing. Would this make developers happy? If so, I will write it.
This bug fails to address one question: *why* is this a bug? The bug title basically answers the question, "what happens [when you click on the search bar and start writing]?" but not why it's considered problematic. Let's be clear here: I don't know -- nor care -- why the user preference was introduced in the first place, but mistakes happen even to the best of us, and that user preference was obviously one. Connor, you clearly care enough about this bug and appear to know JavaScript based on comment 4. Therefore I suggest that you write a gadget that overrides the main search suggestions handler to disable search suggestions on Monobook. Moving search suggestions to a gadget is simply unacceptable for various reasons, which include, but are not limited to, the following: 1. said functionality has been present in core for many releases and it's proven useful 2. it's also been enabled for default for quite a while and removing it all of a sudden would not only provide an inconsistent user experience, but break extensions and site scripts relying on the associated jQuery code being present and available for use in core Something like this should suffice and it'll make the people concerned with the "disable search suggestions" being removed happy enough by providing similar functionality via JS: $( document ).ready( function() { if ( mw.config.get( 'skin' ) == 'monobook' ) { $( '#searchInput' ).unbind(); } } );
Note that you can hide the suggestions completely using CSS, no need to use JavaScript at all: .suggestions {display:none !important;} And also with CSS you can place it below the GO and SEARCH buttons: .suggestions {margin-top: 30px !important;}
Connor: what about a JavaScript variable or similar to implement... (In reply to comment #0) > 2) open the list *above* the search field. Then users who are concerned about the button overlap could simply switch their setting. Or if having the suggestions above the text input isn't too awkward, we could just change the default behavior for everyone. It'll need a bit of experimenting. Any user concerned about having the suggestions is already obviously executing JavaScript. Adding a bit more JavaScript to customize the behavior on a per-user basis doesn't seem particularly radical or stupid to me. It's a fairly common pattern of behavior on the Web. 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 #7) > (In reply to comment #0) >> 2) open the list *above* the search field. Another option: _next_ to the search field. It would overlap with the article content a bit, but that happens in Vector as well, so meh.
(In reply to comment #5) > Connor, you clearly care enough about this bug and appear to know JavaScript > based on comment 4. Therefore I suggest that you write a gadget that > overrides the main search suggestions handler to disable search suggestions on > Monobook. Done. It's at https://en.wikipedia.org/wiki/Wikipedia:Gadget/proposals#Disable_AJAX_search_suggestions but I didn't see any need to make the script bail for other skins. > Moving search suggestions to a gadget is simply unacceptable for various > reasons, which include, but are not limited to, the following: > 1. said functionality has been present in core for many releases and it's > proven useful > 2. it's also been enabled for default for quite a while and removing it all > of a sudden would not only provide an inconsistent user experience, but break > extensions and site scripts relying on the associated jQuery code being > present and available for use in core Gadgets can be made opt-out. You're saying that the core has internatl dependencies on the suggestion API? That sounds convoluted to me.
Can we close this as WORKSFORME? Solutions to the bug via local custom CSS/JS pages have already addressed the scope of this request, and they're easily managed.
(In reply to TeleComNasSprVen from comment #10) > Can we close this as WORKSFORME? Solutions to the bug via local custom > CSS/JS pages have already addressed the scope of this request, and they're > easily managed. Given that the Vector skin basically solved this issue and has been the default MediaWiki skin for quite a while now, I think requiring Monobook (power)users to customize their own site experience using site-wide or per-user CSS or JS is probably fine in this case. Unless there are objections, closing this bug as resolved/worksforme seems reasonable.
Closing as WORKSFORME as per comment 10 and comment 11.
Oops! Yes, I would only suggest re-opening this if someone comes along who wants suggestions AND the monobook skin. The gadget works great if you only want the latter.
