Double quotes inserted automatically around search phrases

Hello!
I have installed a search script from KSearch and wanted to adjust search form to have double quotes inserted automatically around search phrases.

Here is the HTML of my search form page:

    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>OM Radio » Song Requests » Search</title>
<link rel="stylesheet" href="ks_images/style.css" type="text/css" />
</head>
<body bgcolor="#8fc4f0">
<div class="content">
	<div class="search_table">
		<form action="ksearch.cgi" method="get">
			<div class="fieldset_1">
			<fieldset>
				<input type="text" size="65" name="terms" id="tips" value="" onfocus="select(this);" />
                &nbsp; <input type="submit" value=" Search " /><input type="hidden" name="showm" value="5" />
                <br />
				</fieldset>
			</div>
			<div class="fieldset_2">
			<fieldset>
				<table border="0" cellpadding="10" cellspacing="0">
					<tr><td>
                            <p align="center">
							Results: <select name="display">
									<option>5</option>
									<option selected="selected">10</option>
									<option>25</option>
									<option>50</option>
									<option>100</option>
									<option>500</option>
									<option>1000</option>
									</select>
                            </p>
						</td>
					</tr>
				</table>
			</fieldset>
			</div>
		</form>
	</div>
</body>
</html>

And here is the search page URL: http://om.md/radio/search/search_form.html

Any possibility to give and advice?
Thanks!

You probably need to do that with the backend script—presumably by altering something in the ksearch.cgi file. But it might be better to just add a note to the page suggesting that users add double quotes around the phrase if they want an exact result returned. Then you are educating users while not forcing their hand. :slight_smile:

I know many users are dumb enough to miss that important tip while trying to have an exact phrase search, that’s why i prefer it as a default state.

Plus then you have the issue: what if some people do follow the rule? Then if someone does it right and types
“some search”
you’ll get

““some search””

(of course your back-end script would check for these and strip them or whatever)

What if users are not looking for an exact phrase? What if one or another keyword is fine? How do they determine that?

At least it’s generally a convention (even on Google) to use quotes around exact matchings and no quotes means “any of these words”, but yeah there are also lots and lots who don’t know that.

Heck someone had to tell me recently that I could get a picture identified if I dragged it from my Desktop to the Google image search toolbar. That was kinda hard to do with keyboard but apparently everyone else knew about this but me. Lawlz.

Type of content users are searching on my site it’s strictly only songs IDs, because it’s a radio website where people search for a certain track to request it. So, i have experimented a lot with my search engine, and determined exactly that you get best matching result if you apply a phrase search only, and that is done by using double quotes.

Sounds good, though do you have some kind of “did you mean…?” backup so people who search for something that doesn’t come up still get… possible results? That’s a nice backup with search, if your engine can offer that.

Then again it can also be annoying as heck, but if it were just the cases where no exact match was found…?

Anyway, back on topic, this is a back-end programming issue. You can never trust anything inputted via the front-end: it’s always tainted. Your back end must do all relevant validation and data-massaging. Stuff they’ve added to HTML5 like validation and whatnot are only there are guides to the people typing, but they cannot substitute for back-end validation because it’s never trustworthy.

I don’t think the pattern HTML5 attribute (where you could demand " around) is worth it… the default error messages are balls anyway, and people will get confuzled. You could try forcing quotes on with Javascript after they’ve left the focus of the input, to give them the idea, and most users might just leave it like that and submit… but again your backend will deal with the data whether Javascript sends it in with quotes or not.

I would give it a try, but i am a java noob. Would you help me?

Oh, assuming it was vanilla Javascript and not some fancy library, it would be something like this:

Your input will have an id on it, to match the label’s for attribute, so let’s pretend it’s id=“q”.


<input type=“text” id=“q” name=“searchiwhatever”>
<input type=“submit” value=“Search”>


var query;
if (query=getElementById('q')) { [color=grey]//only runs if q exists[/color]
    q.onblur = function() {
         if (q.value=='') return; [color=grey]//don't do anything if they left it blank[/color]
         var pattern=/^[^"].*[^"]$/i;
         if (pattern.test(q.value)) { [color=grey]//if what they typed doesn't start or end with quotes, add them[/color]
             q.value='"' + q.value + '"';
         }
     }  
}

…I think.

The pattern is very stupid, and it’ll miss things, but you could make it more elaborate.
Right now, if there are no quotes at the beginning and end of the query, Javascript will wrap in quotes. Also if they do something like
foo “man choo” bar
they’ll get
“foo “man choo” bar”
and if they start OR end with quotes, Javascript won’t do anything, so if it’s
everybody say “foo man choo”
or
“foo man choo” main chorus
it won’t add the other quote

Another thing, a lot of people hit ENTER instead of moving the focus. I don’t know if Javascript actually gets time to add the quotes in before it’s sent to the form, but the user won’t see the quotes added.
You could add in an event listener instead of just onblur(), listen for both onblur() and onkeyup of keycode 13… you see once you start using Javascript for stuff like this, you start wanting to really have it work for all sorts of instances, because users just do things various ways.

Since you’ll be massaging this on the back end anyway, I dunno if you’d want to get too elaborate on the front end.

Thank you a lot, I’ll be experimenting with this and let you know about the output.
Regards

I have experimented and so far it doesn’t work. You can have a look your self.

Outside of the rest of the discussion, you’re assuming that your users are collectively as dumb as a box of rocks. Never a good thing.

Off Topic:

But entirely realistic, though. :lol:

I’d even go further to affirm that based on my personal experience i have realized even the entire internet audience has a incredibly huge % of idiots in front of computer monitors (i am working as IT, so it’s a true story).

So, would you guys help me set those freaky double quotes as default?
:slight_smile:

It doesn’t work because you have straight Javascript sitting in the <head>. Do you see why that’s a problem?

Moving it to just before the closing </body> tag is one solution. Otherwise you’ll need an event listener for the page load event.

Also you have this
<input type=“text” size=“65” name=“terms” id=“q” onfocus=“select(this);” />
and since you’ve got some script tag dealing with this same element already, why not just add it to that and take it out of the HTML (inline Javascript is kinda ew ew):


var query;
if (query=getElementById('q')) { //only runs if q exists
    [b]q.onfocus=function() {
        q.select();
    }[/b]
    q.onblur = function() {
         if (q.value=='') return; //don't do anything if they left it blank
         var pattern=/^[^"].*[^"]$/i;
         if (pattern.test(q.value)) { //if what they typed doesn't start or end with quotes, add them
             q.value='"' + q.value + '"';
         }
     }  
}

Again, I’m using the name here because I forget when IE gets confused. this is okay on all browsers when it’s inline Javascript, but I think in all other cases IE thinks this is the Global Object (the window).

I’m not sure why you have this function though? Typically it’s used if there’s already a value in there, so people can hit backspace once and remove it. Like, placeholder text… will there be any?

I like to tell people, when they are designing forms, that no matter how high (or low) the IQ is of a person, the moment they start filling a form in behind a computer, the IQ immediately drops to low double-digits, and as an added bonus, many people also magically become illiterate.

It sounds demeaning until you realise this happens to everyone. It would happen to Einstein, and it even still happens to IT guys. We all get dumb when filling out forms and following directions.

Still, with something like this (a demand for input in a certain format), you also have to assume someone’s going to follow the directions. The best forms follow Postel’s law, and are liberal in what they accept, and the user is not told that they did it wrong if the back-end can massage it to correctness anyway. This is why this input should not complain if users do add quotes properly, and ideally shouldn’t complain if they don’t either. And should act intelligently for cases of
foo “man choo” bar
as well.

Also can I still do
foo bar
and get results who may only have foo or may only have bar?

For example the instructions use a song called “Above & Beyond” but let’s say I’m a normal literate person and I don’t use & to mean “and”.

If I type in
above beyond
I should get that song as a result, even if the db doesn’t have a song actually called “above beyond”.
Also if I type in
Above and Beyond
I should get that song as a result.

“boy named sue”
and
“a boy named sue”
should also get me that song.

What if I’ve only heard the name Thomas Datt and spell it “Thomas Dat”?

I’m curious how much this search will try to accommodate things… I use Last.fm and discs that I’ve bought in the store with the song information encoded as tags still sometimes get “auto-corrected” by Last.fm because other users have another spelling of a song name (possibly also from store-bought discs, but maybe a different release date or something).

I have tried moving it to just before the closing </body> tag, sorry still no luck.

Not sure if my search engine is absolutely all scenario - ready, but from my experience, simply using double quotes for search query gives pretty much precise and proper results.

Excuses, my retardation was showing…

when I wrote the script I had tested it real-quick on a form I have elsewhere… but the name of the input was different so when I changed it on the forum-posting page for yours, I made two big-big mistakes:
made a var called query but then started calling it ‘q’
somehow while rewriting it I lost “document” before getElementById.



var [b]q[/b];
if ([b]q[/b]=[b]document[/b].getElementById('q')) { //only runs if q exists
    q.onfocus=function() {
        q.select();
    }
    q.onblur = function() {
         if (q.value=='') return; //don't do anything if they left it blank
         var pattern=/^[^"].*[^"]$/i;
         if (pattern.test(q.value)) { //if what they typed doesn't start or end with quotes, add them
             q.value='"' + q.value + '"';
         }
     }
}

I ran this on a copy of your demo page and it did what I expected. Again, sorry. These are really dumb errors. The script must still remain below the input though (the reason it can’t sit in the <head> is because it’ll run as soon as the browser sees it while parsing the page… meaning the form hasn’t even existed yet, so the script fails).

Nice help from you, it works if you use Search button to submit form, and that’s fine i guess, i have told users to use “Search” button in order to send terms enclosed within double quotes.

Thank you a lot!

Clicking on Search (or anywhere else actually) should trigger the onblur() event, but hitting the ENTER key either doesn’t, or does so quickly the user won’t see it.

But again to catch those people, you’d have to really start adding event listeners (and something to fix IE’s attachEvent) and listen for either onblur OR onkeyup with charcode 13 blah blah… But again, you’ll always fix it in the back anyways and people will then still get the better results.