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.

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.

mockup

download bmml source – Wireframes created with Balsamiq Mockups

share|improve this question
3  
Can you copy-paste into option 2? –  Roddy of the Frozen Peas Jan 25 '13 at 22:47
    
Just edited the mockup... let's suppose all options support paste from clipboard. –  jessegavin Jan 25 '13 at 23:00
    
#2. The "."s make it easier to read. –  obelia Jan 25 '13 at 23:19
4  
@MichaelKjörling, he said IPv4. –  this.lau_ Jan 26 '13 at 14:39
    
@Laurent Right, sorry. I read "IP address" in the title but somehow missed "IPv4" in the beginning of the question. –  Michael Kjörling Jan 26 '13 at 20:31
show 2 more comments

13 Answers 13

up vote 60 down vote accepted

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

  • zero or more non digits
  • one or more digits
  • one or more non digits
  • one or more digits
  • one or more non digits
  • one or more digits
  • one or more non digits
  • one or more digits
  • zero or more non digits

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.

share|improve this answer
12  
I hate Windows' implementation of #1 for these reasons. It auto-advances to the next field when the digits are entered but manually advancing works using space it pried while tab puts you into the next row.. Btw. parsing IPs without any separators is not possible: Does 1234 mean 123.4, 12.34, or 1.234? –  poke Jan 26 '13 at 3:45
1  
It's possible to separate fields but allow them to seem as though they were a single text field by reacting to arrow keys and backspace. The problem is that it's much easier to do it wrong than it is to get it right. –  zzzzBov Jan 26 '13 at 4:03
1  
+1, I feel like I can count infinite reasons why the 3 is the best option although I'd be stuck around 2 billion. –  ssg Jan 26 '13 at 11:22
2  
@nightcracker The OP clearly specified this is for IPv4, so your comment doesn't really make sense. –  Andy Jan 26 '13 at 17:15
1  
A thousand times this answer. As an "expert," I spend all day typing into boxes; don't make this one behave differently. –  Nick Farina Jan 27 '13 at 16:32
show 3 more comments

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.

share|improve this answer
4  
I quite like this option because it make it easier to make changes to ones you've already entered. It is possible that expert users will need to change part of the IP address and having each block separate means its easier to select one 'block' to make changes to that and only that part. –  JonW Jan 26 '13 at 8:26
2  
@JonW - except that the native UI provides expected word-select behaviour, so ⌥+⇧+← will let a user select "previous block" in OSX, as will double-clicking a block. Different visual treatment suggests to the user that normal rules MAY not be at play, and they will likely overthink use because of this. –  Chris Burgess Jan 27 '13 at 7:05
1  
@ChrisBurgess, "Our primary target "user" is a small business IT administrator." I think an IT admin would be smart enough to figure it out. –  zzzzBov Jan 27 '13 at 7:12
5  
We're on ux.stackexchange.com; users shouldn't have to "figure it out" :D –  Chris Burgess Jan 27 '13 at 7:14
1  
@zzzzBov I do like your suggestion, but after reading all the above, I'm convinced the familiarity and expected behaviour of native UI outweighs the possible advantages of new UI. –  Chris Burgess Jan 27 '13 at 7:15
show 2 more comments

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.

share|improve this answer
    
The question says all options support paste from clipboard, so this argument is moot. –  Michael Kjörling Jan 26 '13 at 12:26
7  
@MichaelKjörling It has nothing to with what the software supports. It has to do with what the user will expect. Not all users will expect #1 or #2 to support paste because it's not uncommon for those options in other software to actually not support paste. Additionally, only Option #3 seems likely to support copy to clipboard. Sometimes I want configuration data back from the application, too! –  Bacon Bits Jan 26 '13 at 13:28
add comment

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.

share|improve this answer
5  
Option 3 also allows the user to enter it in shorthand if they wish, and the form can auto-complete. e.g., - 124/8 > 124.0.0.0 - 0080:0a21::1234 > 0080:0a21:0000:0000:0000:0000:0000:1234 –  Matt Jan 25 '13 at 22:43
add comment

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).

share|improve this answer
    
I don't see how option 1 is better for layman. Where will they see an example of an IP address without the periods? How would option 1 help? –  gman Jan 26 '13 at 0:02
1  
You shouldn't need to expose IP input fields to users that don't know IPs to begin with. So I don't think it is a bad idea to assume that they know that IPs are usually separated by dots. –  poke Jan 26 '13 at 3:49
    
gman - Option 1 is better for the layman because of the input user experience. Option 2 can be confusing, as the person must choose between trying 1: enter periods (though the periods existing will discourage using the period key); 2: use the keyboard key left or right after each octet is input (if I only type 2 characters, I must explicitly move on to the next set of fields); or 3: tab, which will likely send them to the next form field. Option 2 will be confusing, while interacting with Option 1 or 3 is predictable. –  Matt Jan 28 '13 at 17:02
    
poke - A layman may know how to recognize a pattern of 4 sets of numbers with periods, know that it's called an "IP something", but not know what it really is. The layman interacts with all sorts of things on a computer without knowing what they are, and it'd be short-sighted to assume the only people touching an IP address are experts or power users. –  Matt Jan 28 '13 at 17:07
add comment

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.

share|improve this answer
2  
Your point about tabbing is a prime reason why I discounted option 1. The separators add a cognitive load as the user is typing - "Do I need to tab/click into the next field or not?". Option 2, although less so than 1, still makes the user think whether they need to click past each period in the mask, or type a period. For example, could the mask know where to place its period if I was typing 192.168.0.1 vs 192.0.2.101? –  Tim Jan 25 '13 at 22:27
    
Chris, I am leaning toward option 3 since our target user is an it administrator. They type in IP addresses all the time. And if we can give instant, visual, validation feedback, I feel like it's not a bad option. –  jessegavin Jan 25 '13 at 22:36
    
Tim makes some good points. I agree Option 3 may be the best solution for your audience. I would however, perhaps leave an example in the input or next to the label regarding formatting. –  Chris N. Jan 25 '13 at 22:39
add comment

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)!

share|improve this answer
add comment

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.

share|improve this answer
    
Why do you say option 3? –  JonW Jan 26 '13 at 8:07
    
@JonW Because I can type it in more naturally. I really hate those 4-box monstrosities. –  Keith Jan 26 '13 at 9:08
    
In all my years in the I.T industry I have never, ever, seen an IPv4 ip address expressed in hex. –  Facebook Answers Jan 26 '13 at 10:42
2  
@FacebookAnswers: Really? They're quite common. An IPv4 address expressed in hex is always eight digits in length and does not require seperators. There is plenty of software using this notation to represent IPs internally. –  Marcks Thomas Jan 26 '13 at 12:26
1  
We're not talking about IPv6 though. Personally I don't have a problem switching from decimal to binary on the fly. I guess its down to having to do 8 bit graphics as a kid where you had to convert all the time. Now I instantly see the number as a row of dots. Anyway, I was genuinely curious as to why anybody would want hex input for ipv4 addresses. I did some searching on google and could only find examples pertaining to Java. All the c++ libraries I looked at used quad notation. My research wasn't extensive though! –  Facebook Answers Jan 27 '13 at 8:22
show 3 more comments

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

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.