Today, I was searching for some glass scratch remover and came across this little web site. The web site in and of itself is OK, but the implementation of the floating menu is marvelous. Here’s a screenshot of this floating menu in Firefox:

The idea is simple but surprisingly, only few web developers employ it: Provide always-available access to frequently used portions of the web site or the web page. That prevents the web design from getting cluttered with “BACK TO TOP” and/or duplicate link buttons.

And because I was in a good mood, I took a 15–second screencast as well, using the free software Jing from TechSmith.

Any web developer who gathers information from actual human beings knows that there is always somebody who

• a) might be new to the whole Internet thing and doesn’t understand what they need to enter on web forms,
• b) likes entering weird stuff just because they can, or
• c) thinks they can exploit some kind of vulnerability on your web site by attempting to enter SQL or XSS injection code.

Obviously, the best and final defense (in my somewhat biased opinion) takes place on the back-end in your ASP, PHP, Java or .NET code.

However, the folks at JavaScript Coder and I believe that you can save a lot of time and trouble for about 90 percent of your end-users by helping them along with a little bit of front-end, client-side form validation.

Aside from jQuery (written by John Resig), the form validation script from JavaScript Coder is is probably the other JavaScript library I wish I had written myself. However, this script library does such a great job at validating form input, I simply keep re-using it from one project to the next.

They have excellent examples and documentation for this form validation script, and so I’ll restrain myself from repeating that. Let me just note that this script considers numerous real-world scenarios AND allows you to append your own custom validations (e.g., matching passwords).

In a nutshell, with this form validation script, you can check the following:

• required fields have a value (other than blank spaces)
• the maximum and minimum lengths of text input fields are enforced
• only specific types of characters are entered (alphabetic, numeric, alphanumeric, with & without spaces)
• the input matches your regular expression pattern
• at least one radio buttons is selected
• a specific OPTION from a SELECT element is not selected
• e-mail addresses are in the correct format

Considering the price of this JavaScript library ($0), this is an awesome bargain.

Sometimes you just want to select the correct option from a drop-down field (aka Select element in an HTML form).

If you have a Preferences or Account Setting page in your web application, or something similar, chances are you sometimes need to display the correct option in an HTML form Select element. For example, if the end-user selected a specific country during the original registration process, you want to make sure that the correct country gets displayed in the Account Settings page, right?

And sometimes, you just have a pre-determined number of options in a select (or drop-down) field. For example, countries, states, regions or products. Not everyone has all of those option values and descriptions (i.e., text) in a database, and so you end up having to select the correct option as soon as the page has loaded.

The solution that I have used in this situation works really well if you get the value (for example, the name of the country) from PHP or ASP and want to plug it into your JavaScript code. We are using getElementById(), so your form elements need to have an ID tag with a value.

Obviously, this also requires a modern web browser that can handle the associated JavaScript. Unless you’re several years behind updating your web browser, however, you should have no problems.

The approach is fairly simple, and the only tricky thing is to remember the proper syntax. Here is an example with PHP and JavaScript:

That’s it.

Perhaps most of you learned readers consider yourselves Internet savvy. When you end up at a web site with way too much content — or if you simply want to fnd something quickly — you look for the Search box, enter your search term, press ENTER and off you go. No worries, and probably 90 percent of the time, no second thoughts either.

Now consider this conundrum: Surrounded by people who think that being able to find stuff on Google should be a manadatory job skill, I was tasked with revising the search feature for a human resouces (HR) related web application.

What’s the big deal? Well, for starters, the typical end user is not too computer literate, aged somewhere between their late 30s and 50s, and eight out of 10 are female HR directors.*

* Before you complain to me and accuse me of being a completely biased male chauvinist, let me make absolutely clear that I, as a person, have nothing negative to say about the demographic sampling I just described. And I am in no way insinuating that everyone who falls into this category is experiencing technical difficulties. However, as several years on the job have taught me and my fellow-workers (the majority of whom are female, by the way), seven out of 10 clients who call in about technical issues a) fall into the category I just described and b) are having “higher than usual” technophobia. That, however, is another story altogether.

Back to the subject at hand: How do you revise a web application’s search function without intimidating the people who pay to use your product? We used to have a straightforward and simple process to search either by first or last name. You enter the name, then you select one of two radio buttons (first or last), and then you click Search.

However, as people progressed in their use of the web application, they also realized that this was limiting their abilities to search for specific employees in other departments or locations.

So in the process of re-designing and re-programming the entire web application, I came up with something relatively Web 2.0 (see screenshot below). The idea was to provide an extended set of search options (first name, last name, department, division and location) into one compact search box.

Those end users who aren’t too familiar with this kind of approach are supposed to click the info icon for more information. And if you’ve changed your mind about doing a search, you can close the search box by clicking the “X” in the upper right. (By the way, simply clicking anywhere outside the search box will hide the search box, too.)

So far so good: It’s a great improvement over the previous version, that’s for sure. Yet as simple as it seems, there is some serius opposition to change within the organization. “What about the Search button?” they ask.

Hmmm, good question. Personally, I think we could easily cram something into the search box, if we wanted to. Then again, we’ve wanted to avoid having too many controls in an already densely populated area of screen real estate.

Other people have even implemented search features that start crunching and returning results as soon as you start typing text into the search field. For example, Peter deHaan at the flexexamples blog uses the “type and wait to search” approach:

Although I’ve gotten used to that kind of funky-ness, I have to admit that it used to creep me out when I first encountered it. Am I doing the same thing to the end users who will be using my web application?

Note to myself: The try / catch statement only works in web browsers that are capable of running at least JavaScript 1.3.

If you try to run “try / catch” statements in older web browsers, you get a JavaScript message (or, as your end users will point out, “a browser error”), stating something the lines of: try is a reserved identifier.

FYI:
IE6 and IE7 support JavaScript 1.3.
Firefox 1 and Firefox 2 support JavaScript 1.5.

If you want to make absolutely sure that your “try / catch” statements don’t cause errors for those end user’s with older web browsers (yes, they do exist), you could use the following statement in your < script > tag:

language=”JavaScript1.3″ . . .

Unsure about your web browser’s JavaScript capabilities? Check out The language attribute of JavaScript, run by the friendly folks from JavaScript Kit, which contains JavaScript code to test versions up to 2.0.