Auto focus - input fields

[em_91]

Hi
Is there a way to implement auto focus on all input fields automatically? So the ‘next’ field because focused as a user completes each field on a form.

[davegoodman]

If you want the user to manually advance through fields using the tab key, you just need to ensure the ordering of the fields in the outline matches the order you want in tabbing.

However, if you want to automatically skip from one field to another, you’ll need to monitor the state of each field. You usually do this with a ‘text changed’ or ‘selection changed’ setting. However, these can really slow down a prototype if you have a lot of them, or the text change is triggering some other action (like whether a button is enabled).

If it’s only for a couple of fields (like sequential DOB fields or bank account numbers), then you can use the ‘Text changed’ interaction to check whether the user has entered the correct number of characters, and, if they have, focus the next field automatically.

[em_91]

Hi @davegoodman ,
Thanks for your reply. I am able to tab through the fields in the correct order.
I am wondering how to implement something like this

So the first field has a blue border, then once field is completed, then user moves on to the next field and that one becomes highlighted with the blue border.

[davegoodman]

You would have to have a way to know when the field was completed. Since first names are all different possible lengths, you would want to wait for a given number of milliseconds and then auto-advance. You could trigger this with an on text change interaction, or fake it with an on-focus interaction that auto-advanced after, say, 3 seconds.

However - I don’t think this would be a great user experience - what if you paused halfway through typing your email address, for example, and it auto-advanced? Auto-advancing fields are generally not great accessibility-wise either, as they can frustrate users who are a bit slower and can really mess with screen-readers. I generally only use them in very specific circumstances, like bank account numbers or DOB fields with specific lengths and accepted formats.

[mbc66]

@em_91, You can use the Lost Focus event to track when an input field is “completed” --meaning the user has either clicked away from the widget, Pressed keyboard Tab key, or pressed keyboard Enter key (when the text field has a Submit button assigned.) For instance, your First Name field could have:

Lost Focus
Focus lastNameInput

You’ll want to define exactly what “completed” means. Is it simply losing focus or is it “valid input” (e.g., text string of a minimum and/or maximum length; no spaces; no special characters; no numbers; etc.; or for email, does it contain ‘@’ and a “domain” like “.com” or “.org” etc.) --Just depends on the purpose of your prototype and what you need. The best way to do validation is with a “submit button” (right-click on a text field widget and select Assign Submit Button; or click Show All in the INTERACTIONS:TEXT FIELD PROPERTIES area to set this.) Submit buttons can be any widget, can be visible or not. The Click or Tap event of the submit button gets fired when the user presses the keyboard Enter key, which should work well for your form. The submit button for each field can use a sequence of “Else If” Cases to evaluate the text field’s value (the text string) to satisfy whatever requirements you have to “complete” the input, with the final “Else If” case (the “successful input” case) setting the focus to the next field or widget in your form. For example, the First Name field’s submit button could have in its Click or Tap event:

Case 1 (blank input)
If length of value of firstNameInput is less than “1”
. Focus firstNameInput
Case 2 (non alphabetic input)
Else If text on firstNameInput is not alpha
. Show firstNameErrorMessage
. Focus firstNameInput select text
Case 3 (success)
Else if true
. Focus lastNameInput

To make things a little more “automatic” and seamless, you could use the text field’s Key Up or Text Changed events (OnKeyUp tends to work better) to test for events that would mean “completed” and call the Fire Event action to trigger your submit button to do validation. in your form example above, if the user presses the spacebar it might naturally be a break between names, signify they are done entering an email address or password, etc. (but for names, consider if a space should be allowed–should a user should be able to enter “Barbara Ann” as a first name or not?) In most cases, can be nice to simply press the keyboard keys, shift+J, o, e, spacebar, shift+S, m, i, t, h --just as they would naturally type their name, and end up with “Joe” in the First Name field and “Smith” in the Last Name field. (You can even use a global variable to track if a user has “re-entered” content in First Name to allow spaces the second time they try.) So, for example, emailInput field could have:

KEY UP
If key pressed equals Space or key pressed equals Right or key pressed equals PageDown
. Fire Event emailSubmitButton fire Click or Tap
LOST FOCUS
. Fire Event emailSubmitButton fire Click or Tap

To automatically focus the first field in your form, you can use the Page Loaded event or that first field’s Loaded event to "Focus <first widget>".

Finally, the “SIGN UP” button can have a sequence of Cases to test if all the fields are valid before performing its main function, like linking to another page.

FYI, the “natural tab order” of “focusable widgets” is from bottom (in back) to top (in front) in the OUTLINE pane (and by “natural” I mean how it is handled in the browser, which for many designers is opposite of what they would expect–so perhaps “unnatural.” ) By default, text field widgets can get focus. Most other widgets–like buttons–would need an action (even a null action will do) in their Focused event in order to get focus from “keyboard tabbing.” You can drag widgets up and down in the OUTLINE pane or select them on the page and use the Arrange menu, right-click menu, or keyboard shortcuts (e.g., Crl+[ ) to send them backward or frontward. So, in your example form above, the list of widgets as they would appear in OUTLINE would be:
tabSignIn
buttonGoogle
buttonFacebook
buttonSignUp
confirmPasswordInput
passwordInput
emailInput
lastNameInput
firstNameInput

Also take note that if a user continues to “tab through” the widgets on your page, after the topmost widget loses focus, the focus will shift to the browser’s “chrome” --meaning the URL field, buttons, etc. before returning back to your page contents. To prevent this, place a hotspot in front of all your focusable widgets, and set it’s Focus event to include an action of Focus <bottom-most or "first" widget>