I am working on a web application which requires users to enter an IPv4 address (in dotted-quad decimal notation) for most of the primary tasks they need to perform. Our primary target "user" is a small business IT administrator. They are very familiar with IP addresses.
I am wondering which style of accepting form input is best? We are currently using Option 1.
download bmml source – Wireframes created with Balsamiq Mockups
Option 3 with no intrusive validation.
1 sucks because it's out of the norm. Copy and paste may or may not work. Tabbing to the next field may or may not work. People are good at correcting mistakes and the limited fields mess up their muscle memory. For example I might type
1912
When I meant
192
My fingers will nearly instantaneously correct that but the field that forces me to 3 digits means that I my pressing backspace twice then typing '2' to fix it ends up with '12' or ends up with 191 in the first box and nothing in the second. In either case I curse the UX designer who in trying to be clever made it worse.
Option 2 is really the same as option 1 just visually different. A space separating or a period separating. The same issues come up. Possibly more as now do I type periods or not? If I do what happens? If type period I then again, with muscle memory press DEL erase my mistake only to have it erase a digit since it didn't insert the period. Ugh!
Option 3 is best but validation should wait until I hit submit or at least validation should be unobtrusive. In other words it should appear somewhere else on the page, not be a popup or something that effects my typing for the same reasons mentioned above.
I might type
19w
When I meant
192
Because my fingers slipped but perception and my muscle memory is fast enough that I'll immediately try to correct it. If the validation interrupts my input then I'll curse the UX designer again. For example I've used forms with validation that when I type the 'w' an alert or modal dialog appears "Numbers only!" which ends up tripping me up since I was already in the process of fixing it.
While were on it, while aaa.bbb.ccc.ddd is the norm for an IP address why not not care what the separator is? If I type
1-2-3-4
or
1 2 3 4
Why can't those be just as acceptable? This comes up because it's so annoying when being asked for a phone number and being told it must be XXXYYYZZZZ instead of just accepting XXX-YYY-ZZZZ or (XXX)YYY-ZZZZ etc and having the computer figure it out. Similarly with CC numbers. Accept AAAABBBBCCCCDDDD and AAAA BBBB CCCC DDDD and AAAA-BBBB-CCCC-DDDD; in fact how about just extract the digits, then figure out if the digits make a valid CC numbers. Similarly for IP addresses. Maybe parse it by looking for
That way
[space]1.2.3.4[space]
will also work and not annoy the user with stupid messages about fixing their input when the computer is perfectly capable of dealing with it.
As a brief bit of brainstorming on how to better present IP addresses to expert users, I'd choose a mix of options 1 and 3.
The way I would implement it would be remarkably similar to StackExchange's own tagging system, except instead of using a space key as a delimiter, I'd use a . so that as you type, it could bin your input into separate boxes:
It's much easier to explain with an example. Pardon my bastardization of the <kbd> element:
1
19
192
192.
192.1
192.16
192.168
192.168.
192.168.1
192.168.1.
192.168.1.2
192.168.1.20
[field loses focus]
192.168.1.20
There are, of course, a lot of implementation details that would need to be worked out in this method. As with most things, it's easier to do it wrong than it is to get it right.
Not option 1. 90% of the time I'm copying and pasting IP addresses from another source and I'll bet these expert users are doing this too. Because of this I have to say Option 3 is the best bet.
Option 2 or 3 would likely be most usable - nobody can be sure without testing it out. Probably option 3, since experts would know there are periods in an IP address (no need for a mask).
Option 1, often seen in phone number entry forms across the web, can get tricky due to lack of convention in interaction design. Sometimes the field auto-advances, sometimes not, so you'll often end up with savvy users tabbing an extra time after the cursor had already advanced.
Since all you're collecting in the field is numbers and periods, validation should be simple enough, and since your users are experts, they will know how to format the entry properly anyway.
For power users, only option 3. For the layman, any of the three, though probably ranked in order.
An IPv4 address is four binary octets separated by periods when written in decimal notation. The power user knows this and is accustomed to typing an IP address correctly.
Often, the best UI is the UI that stays out of the way.
Like Tim indicated, Option 1 will be slightly frustrating for the power user as they won't need the hand-holding. Intuition tells me that option 1 will be most intuitive for the layman, however, as the ambiguity between tabbing or keyboard-arrow-striking between octets in Option 2 will be confusing.
The other benefit of using the Option 3 single box field, by the way, is that it lets you also support IPv6 addresses without changing the interface (and it's easy on the backend to tell them apart, as IPv4 is 32 bits and IPv6 is 128 bits).
I've seen Option 1 before when entering social security fields. It may be just me but I always mistakenly push "tab" to go to the next input field when using these. For some reason I always assume it does not auto advance. This may be because visually it appears as two separate input fields instead of one.
Option 3! Use some nice instant feedback to the right of the field on blur.
I agree, you so often will be copying this info as you don't have an IP memorized and people are not that dumb. Especially Small Business IT administrators.
The other forms get in the users way (much like the Federal Government)!
Option 3, plus the ability to use slash notation if a mask is also required. Furthermore, I should be able to type a decimal or hexadecimal representation as well, and it should take it.
Option 3 definately.
You are dealing with power users, by your own brief, so option 1 is out.
Option 2 isn't needed. Power users know what an IP address is. They just want to enter it as quickly as possible. They can also type, so you basically just need to let them get on with it.
Option #3 with a onchange handler providing feedback by changing the border's color. A single field is a promise that the user can input things however he wants, fix typos, and not get bugged by an overzealous validation process
All 3 options can work nicely depending on the implementation details - for instance, you could implement a full copy paste on option #1 by splitting the string on the dots and filling the rest of the boxes automatically, allowing the user to type/delete from one field to the next, move to the next field with tab or period... but because there are many poorly implemented IP fields, an experienced user will not expect yours to be well implemented.
Option 3. If it were an email address you wouldn't display an input field for the local part and another one for the domain, especially considering the users know what they're doing.
Surely the option 3. But it would be suitable to implement some feedback for this stuff so users will see the right ip address format in case of a wrong input.
Option 3 would be the best. Windows uses option 1 which is very iritating when you make an error as pointed out by other feedback.
Extension: Could use option 3 and automatically enter a period ( . ) after three digits have been typed. Thereby user can just type 1921681001 would result in 192.168.100.1 . Just have footnote at input to suggest this function else will result in a lot of backspacing to remove exstra 192..168 if user types period fast.
