Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

An issue I repeatedly observe with novice web users is that they will occasionally begin typing without first properly selecting (focusing) an input field. A typical pattern I see is this: the user clicks just outside of the input field, and will start typing in a hunt-and-peck fashion -- they will only learn that their text hasn't been inputted when they return to look at the screen. I guess there are various reasons this problem arises: poor mouse control or poor motor control seem to be the most significant.

I wanted some opinion on what you think the best strategy of dealing with this issue is. Should it simply be ignored, or should the application take a proactive step to deal with it?

share|improve this question
3  
I'd advise against jumping to a text field when keys are pressed. Flickr does this, jumps to comments when you hit "c" and jumps to the search when you hit "s". With my setup, "s" scrolls down, and "c" closes a tab. And flickr breaks that configuration. Users might have a reason to be hitting keys outside of a text field. –  Gray Jun 13 '13 at 18:00
3  
"With your setup"? Sounds pretty unusual - what is it? –  Steve Bennett Jun 19 '13 at 1:11
add comment

5 Answers

up vote 3 down vote accepted

Auto focus is less than ideal. It can make sense in some very simple single-task pages, such as a login screen, where the ONLY two fields are username and password.

But on a page that is any more complex than that, it can be a huge accessibility hurdle. If, for example, you have a large complex form on a page with the first field being, say, 'ID' then a person using a screen reader would load the page and hear "Form. Field: ID". Which gives absolutely not context as to what this page is about. Ideally, they'd be able to first read things like the title of the page, introductory content, etc.

Some more reading on this: http://www.brucelawson.co.uk/2009/the-accessibility-of-html-5-autofocus/

As for usability, many people prefer to keep control over their own cursor. So while autofocus might be a usability enhancement for some, it can be a usability problem for others. So another reason to avoid the auto-focus route.

To go back to your question, note that you are dealing with hunt-and-peck computer users. They certainly exist. And we need to accomodate them. But not at the detriment of other users. ;)

What I would suggest is simply create a larger target area for them to focus into. Make the fields bigger.

Instead of the top 'standard', style it like the bottom.

mockup

download bmml source – Wireframes created with Balsamiq Mockups

And added bonus is that this makes things a lot easier for those using touch devices.

share|improve this answer
2  
One of the key benefits of the @autofocus attribute in HTML5 is that it can conceivably be suppressed by the UA/accessibility tools (e.g. Mobile Safari ignores it because it zooms the page and brings up the keyboard without any user input). It's significantly better than JavaScript-based autofocusing which is user hostile for a bunch of users, regardless of assistive tech. –  Kit Grose Jun 17 '13 at 0:30
add comment

Best strategy is to place the cursor in the first expected input field as soon as the page loads. Remove the need for selecting the field completely. However, if the user can have more than one alternatives, you should avoid auto selecting since it can lead to confusion.

As for the next fields, use a proper tab-navigation to allow a mouse free typing experience.

eg: Look at facebook and gmail login pages, as soon as the page loads the cursor is already in the username field.


If you want to annoy the users who left their speakers on, you can start making error beeps when the user starts mashing keys outside of the input fields. (Problem is, it messes with the browsers keyboard navigation shortcuts)

share|improve this answer
3  
Having helped many folks fill forms out at the library, I can say with confidence this will ONLY help with the very first field in your form. Most people who don't know to check if the field has focus, also don't know how to tab between fields. And as soon as they click 3 pixels off of the field no field will have focus. –  aslum Jun 12 '13 at 20:29
2  
This can be annoying for users that want control over their cursor--especially for those using assistive technologies. As such, I strongly recommend against this. The one exception, as noted, would be incredibly simple one-task pages such as the login page (where USERNAME would be an obvious bit of content to initially focus on since it's the only thing you can do on that page). –  DA01 Jun 13 '13 at 18:04
2  
@rk on the web the goal is often to make the page accessible in general--not have to design specifically for assistive technology. –  DA01 Jun 13 '13 at 18:30
1  
@DA01 Even those users need to fill up the form and you can announce the location of the cursor on page load. It is not bad usability, it is a case of how the implementation is handled. –  rk. Jun 13 '13 at 18:31
2  
But that's the problem. It will announce the field you are focused on. In a lot of cases, this will be completely disorientating. On a login form, maybe not. –  DA01 Jun 13 '13 at 18:38
show 3 more comments

Depending on your page layout and its purpose, auto-focusing a field could help.

Note that if the main point of the page isn't to fill in an input, then it might not be a good idea.

Also, if the field in question isn't near the top of the page, then don't do this. I've found that when auto-focusing a field that isn't at the top, the page loads partially scrolled down (to the input) which is quite odd behavior if you don't understand why.

Another solution (assuming you're working with HTML) could be to wrap the input inside a corresponding label tag. Then with CSS you can pad the label out a bit. That way, clicking in or anywhere near to the input will focus the field. I haven't ever actually tried this method, but it is valid HTML according to W3.

share|improve this answer
    
There should already be a valid label tag associated with the field, which can help if laid out appropriately as suggested. –  DA01 Jun 13 '13 at 18:05
add comment

I would take a proactive approach that does not annoy the user through beeping or auto-focusing.

If users are clicking just outside of the field, it is possible to provide some progressive enhancement to the input fields via JavaScript that might help with this issue. The input field could be surrounded by a < div >, or other element, that provides some clickable white space. When the input field's parent element is clicked, which JavaScript can listen for, then the element's input field child would gain focus.

Statistically, this may not yield worthwhile results, but if you're seeing that same problem a lot, it may be worthwhile because the development shouldn't take too long. I've heard of similar implementations on buttons, where the click area is slightly larger than the visual button itself.

share|improve this answer
3  
The <div> should actually be a <label> tag. Selecting the label puts the cursor into the field. You can wrap the input field in the <label> tag, but that may prove to be more challenging from a layout perspective. –  Mark0978 Jun 18 '13 at 14:50
add comment

I would agree with rk. A proactive approach seems to be overkill such as beeping on typing outside of text field focus.

Just to echo rk., understanding where the users are most likely to start typing when they launch into your site is crucial to the strategy of auto focus on page load though. If people are used to this, and the wrong field is in focus, it would just be an annoyance and not a large issue. But if you have analytics wired up, you could see how many people focus outside of your auto focused field before performing any other actions on the page to see for sure what people are doing.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.