Last modified: 2014-02-03 16:24:08 UTC
Fulltext search is almost impossible when javascript is disabled: The list with the suggestions and the entry for fulltext search uses JS, so the only element you can use is the button with the magnifying glass. This button sends you to the article if it exists. I can think of two possible solutions: 1. Change the search button into a button for fulltext search. This also fixes bug 24248. This should be quite easy: Change the name of the search-button into "fulltext" (and add a value="1", I don't know if this is necessary). This has the drawback that with disabled JS you need an extra click to get to an article as you always have to do a fulltext search. 2. Always put two buttons (go and fulltext) into the HTML source and replace them via JS with the magnifying glass button.
Unassigning default assignments. http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/54734
SimpleSearch issues => Moving to Vector (as per $wgVectorUseSimpleSearch)
The whole mess is actually in core.
Still true. (In reply to comment #0) > 2. Always put two buttons (go and fulltext) into the HTML source and replace > them via JS with the magnifying glass button. This sounds like a good idea. In other words, $wgVectorUseSimpleSearch should only have affect if the user has JS enabled.
Change 82100 had a related patch set uploaded by Matmarex: Rewrite rendering of Vector simple search https://gerrit.wikimedia.org/r/82100
Something else to keep in mind. This isn't just when javascript is disabled. This also happens when search suggestions aren't supported in a browser. Like Opera < 9.6, Docomo, Blackberry, etc... which our suggestions are disabled for. Checking Wikipedia it looks like search suggestions may also be broken in IE6 too so that also may not have fulltext search.
Ok, they /work/ in IE6 on MW.org. Though the whole search area is messed up in another way. The banner might be messing it up.
https://gerrit.wikimedia.org/r/#/c/82100/ has received one +1.
I'm not convinced this is the right solution. Talking to Jared we agree that there is large cognitive load on the user to determine which button to use to search. It's safer to simply trigger a full text search always in this situation. Also we both agree the design should not drastically change depending on whether you have JavaScript or not. Do we expect everyone to know the difference between Go and search? It certainly took me a while to understand the difference. Simplifying the solution in this way is better for the user and removes the need for an inline script.
Additionally, I would recommend that for no JS users there is no visual difference in the search box itself, there are currently 2 ways to trigger the search, the icon, and pressing enter on the keyboard, which is a standard way to submit forms, and search queries on most sites.
I commented about this on the patch already, but let's copy&paste here. This discussion shouldn't be taking place in two venues at the same time :/ ---- I'd still prefer the two-button layout; I think that anybody with JavaScript disabled these days is some kind of power-user. I would expect those to be able to figure out the difference. I'm willing to give in, though, since apparently I'm the minority here. There's one small issue with this approach, though – we'd have to switch the JS-enhanced form to "Go" mode by default (just like it is now). I'm not sure what would be the best place to do this; Vector's JS or mediawiki.searchSuggest itself are two options. Help?
@Bartosz I'm not sure I follow, looks like the JS (default) mode is Go, for articles where there is an exact match, what is the change you're proposing? also to your point about power users, i think you are right, which is why i would say those user will know to press enter to send their search, rather than needing an explicit button to press. just because you are a power user though doesn't mean you will psychically know there is an article that is an exact match, so full text search by default is probably a better experience for those users since they won't have had the search suggestions a a clue ahead of time.
Jon suggested switching the form to fulltext by default. Thus we need a way to switch it back to go for JS. (In reply to comment #9) > Talking to Jared we agree that there is large cognitive load on the user to > determine which button to use to search. It's safer to simply trigger a full > text search always in this situation.
@Jon, correct me if i'm wrong, but i believe you were saying that for noJS user the behavior would be full text, and for JS enabled users there would be no change.
Yes, that's what Jon was saying as I understand it, what I'm saying is how do we implement the wretched thing. Such things are very unpleasant to do with HTML forms.
This seems to be headed right into what my final suggestion on PS2 was: https://gerrit.wikimedia.org/r/#/c/82100/2/skins/vector/screen.css (Sep 2 1:11 AM) The long comment boiled down at the end into: > Which leads me to think that our whole search feature should work like this: > * We have a new standard search form. > * This form always outputs a search text input and single fulltext search button. > * We have enhanced search JS; Which adds search suggestions that also contain the option to do fulltext searches. And also changes the singular search button from fulltext to "Go" mode. > Then we always have one search button. Search suggestions that can work in any skin. The "search containing" works. And "Go" is available to those who aren't in a mode where enhancements are disabled due to disabling JS or using a broken browser.
Yes, it does. I am still not fond of doing it this way, but now I'm clearly outnumbered, so I'd rather at least get the rest of my ideas in instead of block on this.
Yep this is what I was suggesting. Thanks Bartosz for your patience and helping get this bug fixed. Please do get the rest of your ideas in! :)
Okay, implemented this in the patch (see my comments there).
That was quick, thanks everyone for coming to a quick conclusion (and actually implementing it!) I like when we arrive at solutions that degrade gracefully based on user technology, and I think that this is a great example of that goal. Dan Garry is the new PM for Platform and will be tackling Search (user facing stuff not the back end technology, which is already in the works) soon with my designer May Galloway as the Primary designer. I think that there are probably some good bugs in the system that will help them move that project forward. Doesn't look like search is a bugzilla component or category though. What is the best way to find, and prioritize existing search bugs and requests?
Change 82100 merged by jenkins-bot: Rewrite rendering of Vector simple search https://gerrit.wikimedia.org/r/82100
