Choosing Counties

First, there’s a problem with contextual ordering. There’s a standard form for addresses, and this form breaks that. Ask yourself the question, what typically comes after city, state, postal code in the common form that addresses are written? It’s not the county, it’s the country, a suspiciously similar-looking word that has an entirely different meaning.

The label is correct, but people don’t read the web, they scan, and my hunch is that by the time someone is filling out their address in a form, they’re not really paying attention. When I hit the county field on the form that prompted this post, I started to enter United States.

Second, the county menu is overwhlemingly large. There’s a limit to how many options you can shove in an HTML select tag before another means of collecting the information is more effective. There is room for debate as to how many that is — personally I believe it less than the number of countries in the world, but surely it is somewhere below a thousand, and I found 1,928 distinct names for counties or parishes in the United States.

Sure, someone using a desktop computer can focus the county menu with their keyboard and type out the first few letters of their county name to select it without opening the dropdown, but changing menu values via keyboard is a fiddly process: there is a threshold of time during which keypresses count towards finding an option in the menu, and after which the query is reset and keypresses count towards a new query. Besides, many people don’t know or prefer not to navigate their computer via keyboard.

Furthermore, web users are increasingly using touchscreen devices with virtual keyboards, and using a keyboard to choose items from a select menu isn’t necessarily availble to them. On my iPhone, I’m presented with a dropdown of in place of the on-screen keyboard, and it displays about 10 items at a time. On my iPad, it displays as a normal dropdown menu but no way to select the choice via keyboard — I have to scroll through the list, which is long enough to cause animation glitches.

Lastly, despite the attempt at mistake-proofing the form by ensuring only valid county names can be collected, the form which prompted this post made no attempt to validate the chosen county was in the chosen state. Normally, I wouldn’t consider this a problem, however the sheer number of options in the menu combined with some very similar-looking names such as Allegany, Alleghany, and Allegheny, or Callaway and Calloway, can lead to people mistakenly choosing the wrong one.

I believe this would be a comparatively rare problem, one that a data-reconciliation process would inevitably catch, but I still find it amusing that a structure intended to reduce mistakes might lead to a smaller number of increased mistakes for edge-cases.

So, how can one improve this bit of data collection? Assume we’re required to collect the user’s county for some reason. Let’s focus on the first two problems I mentioned above.

One technique I’ve seen recently is to ask for the user’s state or postal code first, and then use that to auto-populate the other fields. This is tricky, because the dataset required to compute this requires a server endpoint to handle the query, and there are a few ZIP Codes which cross state boundaries. This will require implementing specialized logic on your backend and clean ways of overriding the auto-filled information.

I like this technique because it breaks the typical city, state, zip, country pattern our brains expect from the example form I showed, so when the user is prompted for county instead they’re more likely to be paying attention. I also like it because it offers the ability to slim down state and county menus based on the provided zip code.

I don’t like this technique because it involves extra steps involving a server, and the edge-cases with multi-state zip codes smells of a falsehoods programmers believe-class error. While many teams might believe they can absorb this complexity, they probably shouldn’t.

Taking a client-side-first approach, many front-end developers would reach for a Combobox in JavaScript, which brings their own set of problems. I’ve been fond of using these, but they have many different use-cases and every single third-party one I’ve tried to use brings its own set of assumptions about data sourcing, styling, validation, and other interaction patterns that are frustrating to work with.

HTML has continued to evolve, and offers a simpler solution by replacing the select tag with a text input hooked up to a datalist, supported by nearly all browsers in use which provides a browser-based combobox.

Similar to a Combobox, the user can type out their entry and the browser will filter a list of entries from the list.

There are two downsides to this approach:

1. Inputs with datalists do not provide validation to check if their value is included in the list or not. This seems like an oversight on the part of browser-native validation, but it’s a simple enough check to perform in Javascript.

2. Similar to a select menu, there are no hooks to style the presented options, however the relative simplicity of this mechanism may outweigh that concern.

If you put this field after the state selection, you could winnow the list of counties from the state the user chose, but the county data with states is still about 100K uncompressed, which can be a lot for mobile users.

I don’t think this improved example is perfect, by any stretch of the imagination, but I do think it’s much-improved for the small effort required.

Data entry is an interactive process, and it can get complicated quickly. People who do it as part of making a purchase or scheduling an appointment might not be paying strict attention, particularly when an input process takes on a familiar form. When combination with frustration from bad affordances for entering that data, people are more prone to making mistakes.

The original form was sequenced in a manner contrary to typical patterns for the data it was collecting, and in an attempt to prevent entry of invalid values, it used an affordance likely to overwhelm and frustrate its user, which can increase mistakes. The form which prompted this post used the data for medical purposes, and — having worked in that field — I understand why it may be required, but I have to wonder at the accuracy they’re getting.