Mobile Form Usability: Avoid Splitting Single Input Entities

At the end of the day, it seems that keeping it simple wins out. Great breakdown!

Yes, some of those forms are really poorly designed.

One important ergonomic aspects to consider is to have the user AUTOMATICALLY go to next text/number fields.

If you split a phone number in 3 parts, then there should be no NEXT/Previous button but simply user moving automatically from one field to the other.

Antoine @Datafieldapp

Another great article. I’d like to comment on your third point about single coherent entities.

In my opinion, the “name” field issue is a tricky one. I agree that many users — in many, but not all, contexts — think of their “name” as a single entity, so it would be ideal to collect it via a single field.

However, for a number of form owners, it is imperative that the database hold the name as two separate fields (e.g. given name(s) and family name). Often two separate names are needed because the data has to be checked against other sources (e.g. identification, financial or historical databases). Also, in many cases there is a legacy system, which may have been set up poorly but can’t be changed.

If the name has been collected via a single field, as far as I know it is not possible to computationally parse it into two fields without a high degree of error. One of the many reasons for this is that in some cultures family name comes first where in others it comes last. And just think about names like “de Bruin” or “Mac Donald”. Consequently, you often need two separate name fields.

Given all this, I think the recommendation to form designers should be to:
- identify what the single entities actually are, for your users, in your specific context;
- if you can use a single field for each of these, and still meet your business requirements, great;
- be aware that in some cases, one field for one entity may not be possible, so there may be a (hopefully minor) decrease in overall usability.

Very glad Smashing Mag shared this article. We’re in the middle of a responsive store build so getting this perspective is remarkably valuable; thanks so much for sharing your results.

I want to tack on a question following up on Jessica’s excellent observation and your response to it. I tend to look at all the data being gathered here from a strategic marketing lens, so collecting the name is (in the long run) most important to continued communication with our users. And at least in my mind, few things are as important as timely, relevant, desired and personal communication to our users.

If it becomes difficult to parse out first and last names accurately, that makes addressing a challenge in email comms. Any thoughts on balancing usability versus that particular business goal?

Thanks!

Great points all around. Business logic might dictate that last name be a separate entity for search purposes for example. No problem, you say, just regex out the last string! What happens if the user has a complex name with prefixes and suffixes? Suddenly you’ll have a database with hundreds of people that have the last name Jr.! Ok so you regex out Jr… By creating a full name field you are creating an dataset that less robust.

Thanks for sharing this.

Particularly interesting the case of those ‘previuos/next’ buttons not being used. I think it’s a very good point to highlight how mixed interactions (tap the field or use the GUI elements) do not work – finally too many options only create confusion.

I would expect those prev/next to move to a previous/next field (group) as a mobile phone number, for instance. I guess tapping directly on the field is the result of this uncertainty over the role of those buttons. And possibly the fear of losing the already filled fields < and this is something that has huge role of form filling esp. on mobile where the task might prove particularly painful, and/or of vital importance.

I can see the point in a single field for the name, but I’d say this is a ‘minor crime’, and we also really have to consider the payoff and cost of normalising the name on the back end… (you know, back end users deserve their own fair amount of, at least, decent user experience).

I can think of quite a few reasons not to have a single attribute for the name in a relation based on a relational model, though. Legacy issues, 3rd party compatibility being two of those.

Not to mention some foreign nationals do not share the same concept of first names and last names. Take an application form for a post graduate student program for example. You should see how many people from Asia tried to split their names. Worse, how do you search for such students in the database?

A very useful article – thanks! I’m interested in the ‘Note’ at the end though. Although I can see many practical reasons for wanting to break up the address field – much as I can for splitting up the name field – is it true that people view elements of their address as independent entries? Is there data on this?

My personal view on my address is that it’s a single thing (“where I live”), so I’d be interested in the evidence that the majority of people think differently.

Regarding the keyboard auto-closing: iOS does not allow scripts to focus a new field except within the context of a touch event. A keyboard event is not good enough: iOS will blur the old field but refuse to focus the new one, resulting in no field focus; and so the keyboard is closed.

I imagine what Macy’s is trying to do here is automatically set the focus on the second field once you’ve entered three digits in the first field, which is a common approach to resolving the navigation issues of split fields. It works to some degree on the desktop or mobile browser without this restriction (though plenty of additional issues arise once you begin backspacing!), but fails terribly on iOS.

Regarding a first name / last name / full name dilemma, if you plan to go international this is somewhat more problematic. For example, while Americans and Scandinavians feel comfortable with marketing emails starting with “Hi {First Name}”, Germans and Austrians in general expect a “{Title Surname}” -approach.

clearly if it says First Name then you put your first name not your full name.. But I do agree with the phone number with the 3 fields instead of one. Also keep in mind, maybe users have an extension in their phone number that doesnt go into the last field if your phone number has three fields…