Fielded Input Considered Harmful
I am so tired of programmers placing their convenience ahead of mine. They work for me, not the other way around! One common problem is input fields. For example, here’s a chunk of a web form I was asked to fill out when purchasing an upgrade to a product:
I typed in the phone number, and then was warned because the number was invalid. Only the first three digits had entered. The problem is that the area code is a separate field from the rest of the phone number. Why? It’s not like pulling out the area code in a telephone number is hard. In fact, it’s the sort of problem I might give as a final exam question in a CS101 class. It’s that simple!1 Admittedly this is a minor case, but summed over everyone who uses this form, it’s a significant time waster. And it would be so easy to fix!
Apple’s iCal is another program that fields the data into chunks that are far too fine. To enter the start time or end time for an event it’s necessary to type in three separate fields: hours, minutes, and AM or PM. iCal is smart enough to realize it has to advance from the hours field to the minutes field when I type a : as in 3:45. However, I have to use the mouse or the tab key to change AM to PM or vice versa. Why can’t I just type, “12:45 PM” and let iCal split the values internally?
Sometimes the parsing problem is harder, but the results are more significant. For example, Apple’s Address Book annoyingly makes me tab into each field, and carefully enter first name, last name, company, address, phone number, fax number, e-mail address and more. This makes it very time consuming to move an address from an e-mail signature into my contacts file. Address Book should allow free-form data entry, and it should figure out what data belongs in which fields. Let me edit it, in case it guesses wrong; but it should handle most data automatically. Admittedly parsing freeform addresses is more difficult than merely finding the area code in a 10-digit phone number, but it’s certainly doable, and the programmers at Apple should be a lot more accomplished than CS101 students.
Fielded data is a classic case of exposing underlying data structures to the user. The underlying code uses fields rather than storing every entry as a raw string, and rightly so. However, there’s no need to show this to the user. Especially there’s no need to show this to the user for basic data entry. The programmer will have to do more work to make this happen, but all the software’s users will do less. If the software is heavily used (as Address Book is) the trade-off is worth it.
1You may be wondering what would happen with an international phone number. While that could be handled automatically as well, this particular web site separated North American and International orders onto two separate forms, so this issue doesn’t apply.
September 10th, 2006 at 2:12 pm
I have a similar problem with web sites that are far too strict about input formats for fields. Let’s say that I liked “Java I/O” so much I purchased one for each of the twenty-three developers in my group. Ignoring taxes and delivery, my Visa bill will be $1,149.77, and that’s what appears in my on-line banking web application.
Now, I copy the amount due and paste it into the “pay a bill” field. Bzzzt! The “$” and “,” characters are illegal. Why? That’s what the bank told me I owed! Far too many commerce applications don’t accept the same formats they use for display. Lazy programming is the only reasonable explanation for considering a leading “$” character illegal in a field designed to accept dollar amounts.
I have similar isues with date fields that don’t accept the exact same formats the web site uses for display. One site would only accept YYYY-MM-DD, even though every date they displayed was in the very readable “Jun 14, 1962” format. What are they thinking?
September 11th, 2006 at 3:18 am
Parsing free-form address data is a hard problem in the general case.
We invested several hundred man-years into this (and similar) problems, which is commonly referred to as information extraction.
I know, it does sound trivial, but it isn’t. Especially if you have no restrictions about the format used. You could enter an address into one line or have a multi-line address-format. Often, the common syntax to write a full name is different from country to country.
The number of fields are different (in Tokyo, the street address is completely numeric, which 3 numbers denoting an address) etc. etc.
Just storing an address is easier, but if you want to associate this address with an existing database, things get really funny 😉
September 11th, 2006 at 5:01 am
Don’t let the perfect be the enemy of the good. You can’t get this 100% right for all cases. However, you can do a pretty damn good job for 90% of the cases with a reasonable amount of effort. Then let the user manually edit the few weird cases they come across when the system guesses wrong.
I’ll also note that on a practical level this is exactly the sort of problem where test-first development really excels. It enables you to grow a solution organically rather than trying to define an algorithm up front.
September 13th, 2006 at 12:47 pm
Agreed. We spent a lot of time ourselves building nice date and time controls. Both are based on simple entry fields that parse out the value based on what the user enters. For the date they can enter ‘aug 10’ and it would submit as ‘2006.08.10’ (current year). Also they can do things like ‘tom’ for tomorrows date and ‘eom’ for last date of the month etc. For time we allow ’10p’, ‘1023’, ‘1622’, ‘530a’ etc..
It took a lot of work to get it right but the users do like it. 😉
September 13th, 2006 at 3:01 pm
I can’t understand why my phone number can’t be input as “two hundred 2, nine five 5 (4 + 1), four thousand two hundred thirty-1.
Silly programmers, sheesh!
September 14th, 2006 at 7:53 am
My pet peeve for input is credit card number fields with the note: “do not enter spaces or dashes”. I mean, how hard is it to strip them out if you don’t want them?
September 14th, 2006 at 4:09 pm
Good topic, very annoying stuff for the user to put up with. It seems like there should be standard UI widgets (or at least after-market OCX-type controls) that take care of the common cases. I must note that many of the Microsoft products are pretty flexible this way. Various apps in the Office suite will accept measurements in “in” or “pi” or “li”. Outlook is quite flexible this way, too. And Streets & Trips does very, very well in parsing. You can often copy and paste in a formatted address from a web page and get the results you want.
September 18th, 2006 at 7:50 am
How about an e-mail account entry form that separates it into two chunks by providing the “@” in the middle!? SSN entry with three fields! IP addresses in pieces. MAC IDs. I’ve had to deal with all of these.
September 18th, 2006 at 8:55 am
I’m probably the most annoyed person when it comes to entering data or reading data. I absolutely refuse to read unformatted numbers like 1562.000005 or dates 20061809. It gets me furious. Or when I can’t copy & paste into field $1,001.11 – it is not that complex!!! I remember back in the old days when I was studying Pascal, their StrToNum (I think thats what it was called) was very loose function. It would convert string 1b1c2d into 112 without any problems. Why we can’t have a nice loose function like that these days. It has good and bad in it, but still, sometimes we do need it.
Once I had to work on an online store application where I spent hours for all those UI cases to make user’s life easier. Just a note, that app handled US and Canadian phone numbers with about 99% accuracy. That 1% was for people who actually put in textual values – I didn’t even know people do that!!! But in any case, what I’m trying to say is that neither users nor site owners noticed my effort. This sort of thing is never appreciated because people simply assume it’s there. But oh well, it did teach me a lot and improved me as a programmer.
September 18th, 2006 at 9:57 am
I wouldn’t call it lazy programming.
Sadly, these things are not given importance during the software development while scheduling time & effort. With programmer pushed to ‘add more features’, these things get pushed down the priority list.
September 18th, 2006 at 12:52 pm
I’m not sure what’s the problem with delineating fields of input…although it should be done in a standard way which shouldn’t depend underlying data structures but rather the standard way people represent the information.
Look at the examples:
Phone Number: (simple case) 111-111-1111
Dashes represent breaks which can in turn be separate textboxes.
Address: Look at an addressed envelope. There are separate lines for the street address and city state zip. The city and state are separated by a comma.
Date: It is usually separated by dashes or slashes.
Time: Colon separates hours from minutes.
And so on…so is it really the programmer or just naturally how certain data structures translate to computer UI as closely as possible to what people are used to in everyday lives?
I guess I should try free form entry next time I give someone a phone number or address an envelope and see how it goes.
September 18th, 2006 at 1:40 pm
Around 10 years ago we deployed a intranet time management software. We used free input fields for dates, and users entered everything.
18.09.2006
18/09/2006
06/09/18
09-18-06
20060906
9 Spetember 06
And every time we thought we had all, there was another user with another idea of how to write dates. Some of them were hard, like choosing between 09.06.2006 and 06.09.2006. Worked in the end though.
October 3rd, 2006 at 3:25 am
Eliotte:
I liked your remark about the address book. Actually the free-form version exists and is called Sbook5 at http://www.sbook5.com/ by Simson Garfinkel.
It can synchronise with Apple’s address book.
It identifies fields and adds an icon, then you can manually fix the icon if it gets it wrong. Very nice approach and it makes copy&paste of addresses easy-peasy.
Dave
October 6th, 2006 at 4:49 am
Actually it makes perfect sense to split dates or enforce single format. In languages other than English dates can only be little-endian or big-endian. In English middle-endian is also possible, so 3.6.2006 can be June 3rd or March 6th. Not to mention ambiguity of 12-hour time with AM/PM (12:00 AM is 00:00 or 12:00 or 24:00 ?), also English-specific.
If such forms are allowed, you’re going to have many problems. I’m all for forcing people to use “2006-06-03 12:00” format.