Last modified: 2013-10-23 18:17:35 UTC
With $wgVectorUseSimpleSearch = false; (Go + Search button) you have to press Return twice to submit. Annoying as hell.
Mmmm... do we need to fix this? Or can we just wait for the day when we remove the bad-usability two-button search forms entirely from the codebase?
Why are the Go / Search buttons bad usability? You think a searchbox with auto-GO is better? It sucks. People don't see / understand the "containg..." function.
(In reply to comment #2) > Why are the Go / Search buttons bad usability? > > You think a searchbox with auto-GO is better? It sucks. People don't see / > understand the "containg..." function. http://www.smashingmagazine.com/2008/12/04/designing-the-holy-search-box-examples-and-best-practices/ Btw, I do have a plin on how to make Go even more intuitive, though haven't gotten around to implementing it.
Ok let's nail it to the basics: Old search: Fail #1: 2 buttons, a "Go" and a "Search" button New search: Fail #1: No submit button at all Fail #2: Submit function is a tiny icon Fail #3: Submit function is a forced redirect function Fail #4: Simple full text search is a text link Fail #5: Simple text search link is hidden as last entry of a suggestions list "From a usability point of view, irritated users use the search function as a last option when looking for specific information on a website." Wikis are not a standard website. Search is fundamental.
(In reply to comment #4) > Ok let's nail it to the basics: > > Old search: > Fail #1: 2 buttons, a "Go" and a "Search" button Fail #1.1: The two buttons do not match practices used in other places on the internet. This leaves the user with no prior knowledge to reference in their confusion. > New search: > Fail #1: No submit button at all > Fail #2: Submit function is a tiny icon The magnifying glass is the submit button. It carries proper alt text, title, and pointer functionality as well. This practice isn't a quirk of our system, it's a practice used by other websites as well, so it isn't completely unexpected. However you're welcome to request user testing to see if users are having a hard time submitting their search queries. Or we could add the equivalent of click tracking. Watch for users entering text into the search box and see how many times they leave without continuing with their search (Though we'll have to be careful about power-users like me that use the Auto-complete to find a template name we need). Perhaps also track how long the time between last character and submission was. > Fail #3: Submit function is a forced redirect function This isn't a fail. Unlike other websites wikis have articles with simple names for the mass majority of searches the user is looking for the page with the same name. Hence we send the user there. > Fail #4: Simple full text search is a text link > Fail #5: Simple text search link is hidden as last entry of a suggestions list Fulltext search rather than the go functionality is not usually what the user intends most of the time. Frankly if you think about it the user doesn't even know what the site structure is so having separate fulltext search functionality is almost useless. The only situation that a user actually explicitly wants fulltext search is generally when they have already made a search and the first result didn't have anything they want. And that's a special situation, not one indicating that Actually... quite frankly in the old system I doubt the user ever understood that they could re-search with a separate fulltext search. For those kinds of situations a feature that adds something like "Not what you're looking for? You can search for <pages containing "..."> instead." (where <...> is a link to the search page) is the correct way to handle the user. > "From a usability point of view, irritated users use the search function as a > last option when looking for specific information on a website." > Wikis are not a standard website. Search is fundamental. Exactly why unlike other websites we have the go functionality. The problem is we need a few more tweaks to perfect it's usability. The old functionality was one of the worst.
> Actually... quite frankly in the old system I doubt the user ever understood that they could re-search with a separate fulltext search. > For those kinds of situations a feature that adds something like I once requested a sub notice for "You have been redirected to this page because it perfectly matched your search. Click here to do a full text search". It was solved as WONTFIX because it won't work with filecached articles. (meanwhile jquery may help tho). I would link to it if Bugzilla had a proper SEARCH. > The old functionality was one of the worst. Not for me. I don't use Vector and Monobook is default for all users so my search is still the old. I don't use Lucene (yet) so I don't have problems with suggestions in the sidebar search. If you remove the old search from core I have to hack it back in :(
(In reply to comment #6) > I would link to it if Bugzilla had a proper SEARCH. Bugzilla has an amazing search intended for and coded by power users. Here's a list of all the bugs you've ever reported that were closed as WONTFIX: http://u.42.pl/2JaQ. I can't see anything about search in there.
(In reply to comment #6) > I would link to it if Bugzilla had a proper SEARCH. It has: https://bugzilla.wikimedia.org/buglist.cgi?emaillongdesc1=1&longdesc=page%20full%20text%20search&email1=subfader%40gmail.com&longdesc_type=allwordssubstr&emailtype1=substring
Ah, there it is: bug 23772. It's not WONTFIXed, it's still open. And I'd say it's a pretty neat idea, it must be somehow doable.
Yes, the bugzilla search is advanced, sure. But it hardly what I'm looking for. Ah, a list of all my reports. Finally!
(In reply to comment #6) > > Actually... quite frankly in the old system I doubt the user ever understood that they could re-search with a separate fulltext search. > > For those kinds of situations a feature that adds something like > > I once requested a sub notice for "You have been redirected to this page > because it perfectly matched your search. Click here to do a full text search". > > It was solved as WONTFIX because it won't work with filecached articles. > (meanwhile jquery may help tho). > > I would link to it if Bugzilla had a proper SEARCH. Yeah cached articles are a problem. And the ?from=<search> idea is bad too. The proper way to do it is with JS. I've added a comment to bug 23772 explaining how to implement it. > > The old functionality was one of the worst. Not for me. > I don't use Vector and Monobook is default for all users so my search is still > the old. > I don't use Lucene (yet) so I don't have problems with suggestions in the > sidebar search. > If you remove the old search from core I have to hack it back in :( Hmmm, what does Lucene break? $wgVectorUseSimpleSearch only controls vector. MonoBook is $wgUseTwoButtonsSearchForm (changing the default is bug 40622). For MonoBook when two-button search is disabled you get a "Go" button and an "Advanced search" button that leads to the search page where you can do fulltext searches. Also btw, Krinkle is working on making simplesearch's suggestions work on all skins and become part of core. Btw, if power users have so much problems with the "Go" functionality. Have you considered writing a Gadget? All you have to do is grab the search form and give the single submit button name="fulltext". Right now you'll have to use the varying IDs but in the future all skins should start using class="mw-search".
>> I don't use Lucene (yet) > Hmmm, what does Lucene break? Nothing. Just reading about installation being comlicated made me wait. Then I tried and realized I can't run maintenance/dumpBackup.php ( http://www.mediawiki.org/wiki/Extension_talk:Lucene-search#Problems_getting_started_18537 ) > Btw, if power users have so much problems with the "Go" functionality. Have you considered writing a Gadget? Why do you assume poer users have problems with it? I assume the non-power user has problems with a forced GO-button. We went quite off topic here (but I like discussing like that). I opened this bug report when I tested Vector. I don't use it (still MW 1.16 here) so I cannot tell if MW still behaves as reported.
I can no longer reproduce; pressing Enter submits the form as expected. Can you verify?
