|By Charlie Arehart||
|January 1, 2002 12:00 AM EST||
For both audiences there's still value in learning at least a minimal amount about client-side scripting. Even learning about just one feature - setting the cursor on the first form field you may have - can bring measurable benefit to your site visitors.
Where's Your Focus?
Here's the motivation for the problem I want to solve: you visit a Web site that offers a form inviting you to enter some input. No big deal - we see them all the time, right? Now, how do you get to the point of entering data into that first field?
Do you use your mouse to move the cursor to that first data entry area? Or are you a keyboard maven, like me, in which case you prefer to tab to such a field? The problem is you may have to hit the tab key several times before you can enter data.
Indeed, it's typical to visit sites with navigational toolbars across the top and/or left side of the form, forcing you to tab dozens and dozens of times. It's an annoyance, especially if visitors to your site know the site designer could have easily prevented the problem.
If you think that's being pedantic, consider a simpler example. If you show users a page that clearly is expecting them to enter some data (perhaps a user ID or a search argument, etc.) before proceeding, why not put the cursor right on the data entry field rather than forcing them to use the mouse or keyboard to get there. It's a usability issue.
Laying the Foundation
Gimme the Goods
Focus on Forms
Enter Userid: <INPUT TYPE="text" Name="UserId">
What's in a Name?
There are two ways to do this: we can refer to the form by name or by indicating the relative location of the form on the page. Which is appropriate for you depends on your situation. If you've specified a NAME attribute on the <FORM> tag, you'd use that name.
If we had specified NAME="Login" on the <FORM> tag, we would refer to the form field as Login.Userid. But we're not done yet. The form itself occurs within the Web page, and while it might not seem necessary, the contents of the page are considered to be within the "document" on the page (again, recall the "Document" Object Model). We finally have the complete means by which to refer to the field: document.Login.UserId.
Before leaving this subject, let's clarify that if you haven't named your form, you can still refer to it by indicating the relative location of the form within the document. There's a special "forms" array in every Web page document, so if you have only one form in yours, you would indicate it as the first form.
Notice that this isn't used as "form" but as "forms". It's a subtle point, but if it's not specified correctly, you'll receive an error.
We're on the Case
Similarly, since we named the form field UserId, we must refer to it exactly that way. If we referred to it as document.forms.userid, or even document.forms.Userid, we'd receive an error either way.
Forcing the Focus()
To set the focus we use the focus method just like a reference to an object's method in Java. To set the focus for our form field called "UserId", we might specify it as:
That's about it. There's nothing to be specified within the parentheses. (Notice that the word focus is also all lowercase.) This statement, when executed, will cause the named field in the named form to receive the focus when the page is displayed to the user. In other words, the cursor will be resting on that field when the page is loaded.
<!-- document.forms.UserId.focus() //--> </SCRIPT>
Experienced developers may prefer yet another approach: creating a function instead and calling that function in the ONLOAD.
But Will It Fail?
You should have no trouble if you:
- Refer to the form field using the naming references indicated.
- Remember to specify the proper case for the naming reference.
- Ensure that the statement occurs only after the form has been loaded.
Should you go ahead and add the focus method for the first input field of the forms in all your pages? Well, first it may not be appropriate to the interface. On some pages the form and its input fields may not really be the focus of the page. Consider a page that happens to have a search field on it, such as http://industry.java.sun.com/solutions/ (see Figure 1).
If you look closely at the top right corner, there is indeed a "form" on this page for searching the site, but it's definitely not the focus of the page. There's also a search field to "Find a Solution" on the right-hand side. Should we put the focus in the first form field? The second? Either? Maybe neither. If you put it on the second, which may seem a focus of the page, keyboard users would find that tabbing once wouldn't take them to the top nav bar but instead to the links under that search field. That's not good usability, either.
Another reason not to blindly set the focus on any first form on the page is if the form doesn't appear at the top of the page. If we did that, an unintended result would be that the screen would be scrolled down when displayed, so that the field with focus (that form input field) was visible. This may cause the top of the page to be hidden from the user. Remember, too, that users often have different (and lower resolution) monitors than developers, increasing the chances of this problem developing. It can also happen if the users don't maximize their screen when displaying your page.
When would it be appropriate to put the focus on a field? When the form is clearly the focus of the page. Going back to the previous example at Sun's Solutions Marketplace, consider the link under that "Find a Solution" button, labeled "Enroll Your Company." On the page that will be shown, it prompts for Company Name. That's clearly the focus of the page, so putting the focus on that field would make sense (sadly, they're not setting the focus using this approach as of this writing).
If you visit www.altavista.com, a popular search engine, you'll see that searching is clearly the focus of the page, and they do indeed use the focus method so that you can start typing search criteria as soon as the page appears.
Another natural example, and one that nearly all developers end up dealing with, is a login page that's presented to enter a site or access secured areas. If the user can't proceed without entering a user ID/password and the prompt for this is the only reason the page is being presented, there's little reason not to set the focus on the UserId field.
Afterword: Using SCRIPTJ in JRun Studio
There's one last useful trick that will be of interest to users of JRun Studio (a similar feature may exist in other IDEs). It also works in its sister Macromedia products, ColdFusion Studio and HomeSite.
You could hope to remember to enter that properly formatted set of basic tags:
|Fernando 01/09/02 06:25:00 PM EST|
It is surprising sometimes how we forget about trying to releave the work load to servers. For example for form validation it becomes useful as it releases stress put on the server..Let the client check for its own mess before the server does :)
|Satish 01/09/02 12:46:00 AM EST|
This article by Charles Arehart on Java Script made me to refresh the most basic and useful concepts.
thanks a lot, regards
- HTML5 Web Sockets: A Quantum Leap in Scalability for the Web
- Book Excerpt: Introducing HTML5
- Using Ext JS, Servlets, JSON, MySQL and Tomcat on Fedora
- Cloud Expo 2011 New York: Application Development in the Cloud