jumping to next field without javascript

[Koos]

Hello everybody,

I have a PHP application with a lot of form fields. I would like to
automatically have the cursor (focus) jump to the next input element
once MAXLENGTH is reached. I found this:

http://www.htmlcodetutorial.com/forms/index_famsupp_162.html

but it's javascript. The app will be approached with several clients,
mozilla, ie, elinks and so far I managed to keep is javascript-free.

Can I do the jump without javascript, that is: in pure html (4)?

Thanks!

 

[Andrew Urquhart]

Hello everybody,

I have a PHP application with a lot of form fields. I would like to
automatically have the cursor (focus) jump to the next input element
once MAXLENGTH is reached. I found this:

http://www.htmlcodetutorial.com/forms/index_famsupp_162.html

but it's javascript. The app will be approached with several clients,
mozilla, ie, elinks and so far I managed to keep is javascript-free.

Can I do the jump without javascript, that is: in pure html (4)?

I don't know how general the audience for your application will be, but
if it's for Joe Blogs/John Doe on the WWW he won't be expecting the user
interface to behave this way. I could imagine someone (quite
reasonably!) expecting the form to act like any other form they've used
before, typing away whilst looking at the keyboard and looking up to
find that they've filled in several form fields whilst writing a lot of
content in a single field.

How would they know what's happened, why train people to use your new
form system when people already know how to use the standard version? If
this was my application and content needed to be restricted in form
inputs I'd use maxlength on inputs where allowed but have warnings in
the labels associated with the inputs, e.g.:

<label for="usersname_1">Your full name (100 characters max. including
spaces)</label><input type="text" name="usersname" id="usersname_1"
maxlength="100" tabindex="1" title="enter your name">

'No alarms and no surprises'

 

[Mitja]

Hello everybody,

I have a PHP application with a lot of form fields. I would like to
automatically have the cursor (focus) jump to the next input element
once MAXLENGTH is reached. I found this:

http://www.htmlcodetutorial.com/forms/index_famsupp_162.html

but it's javascript. The app will be approached with several clients,
mozilla, ie, elinks and so far I managed to keep is javascript-free.

Can I do the jump without javascript, that is: in pure html (4)?

Nope. All you can do is reveal The Secret Of The Tab Key And Wondrous
Workings Thereof to the end user - many people still move between form
fields using mouse only.

 

[Neal]

Hello everybody,

I have a PHP application with a lot of form fields. I would like to
automatically have the cursor (focus) jump to the next input element
once MAXLENGTH is reached. I found this:

http://www.htmlcodetutorial.com/forms/index_famsupp_162.html

but it's javascript. The app will be approached with several clients,
mozilla, ie, elinks and so far I managed to keep is javascript-free.

Can I do the jump without javascript, that is: in pure html (4)?

Thanks!

I remember being on sites which ask for my phone number. Three boxes. So I
type in the 1st box (599) the 2nd 555 and the third 1111. I tabbed, as I
am used to, between the boxes. This all takes, what, two seconds, and I'm
not looking.

Here's how the form got filled in:

|(59||9) ||555 |
(next box)
|1111 |

I had to do it over.

This sort of little "helpful trick" runs against how users expect the
interface to work and should be avoided.

 

[Mitja]

I remember being on sites which ask for my phone number. Three boxes.
So I type in the 1st box (599) the 2nd 555 and the third 1111. I
tabbed, as I am used to, between the boxes. This all takes, what, two
seconds, and I'm not looking.

Here's how the form got filled in:


I had to do it over.

This sort of little "helpful trick" runs against how users expect the
interface to work and should be avoided.

Ah well... just what percentage of users?
I think for majority of people such JS is an welcome aid, especially if
larger amounts of data have to be entered.

 

[Neal]

Ah well... just what percentage of users?

Whatever percentage has filled in a few forms on web pages using
traditional markup. I see very few sites using the tech you describe
(thank goodness) so it's unlikely the average user will be anything but
peeved by this performance.

I think for majority of people such JS is an welcome aid, especially if
larger amounts of data have to be entered.

Well, feel free to do it. Just mark my warning.

 

[OJ]

Ah well... just what percentage of users?
I think for majority of people such JS is an welcome aid, especially if
larger amounts of data have to be entered.

Hi,

I think you're wrong, but if they're larger amounts of data, what is
the possibility that they will reach MAXLENGTH and the end of their
data at the same time? Works for phone and zip, but everything else
is variable length.

oj

 

[Beauregard T. Shagnasty]

Quoth the raven named OJ:

Works for phone and zip, but everything else is variable length.

Phone and zip are not always the same. Wait... what is the zip for
downtown London, England?

 

[Daniel R. Tobias]

Ah well... just what percentage of users?
I think for majority of people such JS is an welcome aid, especially if
larger amounts of data have to be entered.

I've run into just the same problem myself; I'm used to tabbing
through the fields myself, and programs that try to change the field
focus on me can get me all out of sync.

 

[Neal]

I've run into just the same problem myself; I'm used to tabbing
through the fields myself, and programs that try to change the field
focus on me can get me all out of sync.

If we really want to think about what users are used to, look at the sites
with forms that users most commonly encounter. Yahoo, Ebay, Amazon are
probably among the top. I don't think any of those sites use this type of
voodo bullshit on their users.

While I'll never advise a web designer to look to the big popular websites
as a model for effective web design, they are important in that their
interfaces represent what users are most accustomed to.

 

[Jeff Thies]

Quoth the raven named OJ:


Phone and zip are not always the same. Wait... what is the zip for
downtown London, England?

The only data I can think of that is reliably fixed length are serial
numbers.

Jeff

 

[Mitja]

Whatever percentage has filled in a few forms on web pages using
traditional markup. I see very few sites using the tech you describe
(thank goodness) so it's unlikely the average user will be anything
but peeved by this performance.

I don't think the average users expects _anything_, because he/she's got too
little experience. And even if it does surprise him, he will soon find out
what it's all about.

Well, feel free to do it. Just mark my warning.

Despite what I wrote I am against implementing such JS, because I as a user
would certainly hate it. Still, with an average user and large quantities I
mentioned... In that case it is probably solely a matter of prinicples over
user-friendliness, though I'd still go for the non-JS version.

 

[Koos]

Neal <[email protected]>
(wrote:


Ah well... just what percentage of users?
I think for majority of people such JS is an welcome aid, especially if
larger amounts of data have to be entered.

That's exectly the point, it's not really a website, it's an existing
application ported to a larger dbms with an HTML frontend. Some 50
people will spent hours per day using the system and submitting input.
Let's assume the system will exist for at least a few years (it
replaces a system that has been used since 1995)... That's a whole lot
of times the users have to press tab.

The reason I chose HTML was the portability, and that's why I really
wouldn't like the javascript solution, but if there is no other
option I may have to use it :-(

It would probably cause a problem right away, some users (half of
them) will use a slow (gprs) connection to log into a linux server and
approach the system via elinks running on a local SSHed account. AFAIK
elinks and the like don't speak javascript...

 

[Koos]

....

I think you're wrong, but if they're larger amounts of data, what is
the possibility that they will reach MAXLENGTH and the end of their
data at the same time? Works for phone and zip, but everything else
is variable length.

In the app there's a lot of date and timestamp fields There is also
percentages, codes with a fixed length, social-fiscal number
(sofinummer, that's a Dutch sort of social security number). But it's
mainly the date and time fields that would profit from this approach
and spare my users lots of time.

 

[Beauregard T. Shagnasty]

Quoth the raven named Koos:

That's exectly the point, it's not really a website, it's an
existing application ported to a larger dbms with an HTML frontend.

Ahhhha. If you had stated this in your first post, the responses would
have been much different. You did call it "a PHP application" but that
really isn't a clue as to where you propose to use it.

Some 50 people will spent hours per day using the system and
submitting input.

For some 50 who are not on the WWW... do what pleases you.

 

[Karl Groves]

That's exectly the point, it's not really a website, it's an existing
application ported to a larger dbms with an HTML frontend. Some 50
people will spent hours per day using the system and submitting input.

If that's the case, don't spend so much time deliberating about which method
will work the best for them, build functional prototypes of the application
and TEST IT with the people who are using it! Everything else is conjecture.


-Karl

 

[Mitja]

That's exectly the point, it's not really a website, it's an existing
application ported to a larger dbms with an HTML frontend. Some 50
people will spent hours per day using the system and submitting input.
Let's assume the system will exist for at least a few years (it
replaces a system that has been used since 1995)... That's a whole lot
of times the users have to press tab.

The reason I chose HTML was the portability, and that's why I really
wouldn't like the javascript solution, but if there is no other
option I may have to use it :-(

It would probably cause a problem right away, some users (half of
them) will use a slow (gprs) connection to log into a linux server and
approach the system via elinks running on a local SSHed account. AFAIK
elinks and the like don't speak javascript...

If that's the way things are, then by all means do use JS. It doesn't cause
a single problem - users with JS disabled or not supported will have to use
the tab key, that's all there is to it.