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 entertaining the notion of a single field for name entry on our scheduling web app. I think this is an excellent case for a "forgiving format" to make it easy to enter their names quickly. I would label it and possibly put additional placeholder text guiding the user. Like this:

Either raw or with placeholder text.

It's important to catch first and last name correctly because it gets saved in our contact database that we provide to our users. However, people could enter "Joe De Maggio" or "Dr. Chopra" or "Ms Sally Ann Mc Dumont". The possibilities are many.

Is this choice wise? Is the engineering worth the UX? Does anyone know a plugin that tackles this?

share|improve this question
    
I think the UX would be pleasant but I think your data will quickly become dirty, more so than if you had the data fields separated. It is unfortunately impossible to deduce what someone wants to be referred to when they list their name as Joe De Maggio. –  Aaron McIver Jan 5 '12 at 21:53
    
Who are the users: co-workers/customers/both? –  dnbrv Jan 5 '12 at 23:20
3  
Does the scheduling tool have to notify the people that have their name inputted? If so, how do you deal with duplicate names? If that's not an issue, then that field is really just a free text field, and I think it's perfectly acceptable to leave it as one field...let people enter the name any way they wish to. –  DA01 Jan 6 '12 at 1:33
    
Yes it does notify them. Emails are sent out when people book saying Dear [name]. It also accepts imports of data from CSVs and we are making the customer table map to CRM API's. I wish it were just a name field. –  Itumac Jan 6 '12 at 13:40
    
How does it deal with a situation where an organization may have two 'John Doe's? Names can't be unique identifiers, so I'm guessing there has to be some other bit of data being used as the unique identifier. How is that being exposed to the user? –  DA01 Jan 6 '12 at 16:40

8 Answers 8

up vote 60 down vote accepted

There are a great many assumptions people make about names (also: W3C: Personal names around the world.)

Thankfully the W3C have some excellent advice on field design for names, of which the simplest is to use two fields (but not for first/last):

  • Full name
    [________________]
  • What should we call you? (for example, when we send you mail?)
    [________________]
share|improve this answer
    
Thank you for pointing this out (it saved me looking up the links :-) (Though I would change the "should" to "may" for the second field, but that's just one of my pet peeves). –  Marjan Venema Jan 6 '12 at 7:41
2  
IMO no answer could be better. –  LordScree Jan 6 '12 at 13:04
1  
So the answer to my question is it wise/worth it is: "Waxing Yes" as we internationalize. "worth it ... "Not yet" based on the design and development considerations as well as the buy-in I will have to get on an approach. What's in a name?... a lot. –  Itumac Jan 6 '12 at 13:59
1  
+1 It's worth noting that GMail (Google Contacts) provides only an "Add name" field as well. –  msanford Jan 6 '12 at 17:26
2  
This is great, but what do I do for the simple case of a user like myself "Matt Johnson" when I need to run a report showing names as "Johnson, Matt"? Do I add yet another field for that? –  Matt Johnson Apr 3 '13 at 0:59

Here's a scenario where it might work to your advantage:

  1. The user enters their full name in one field.
  2. The system reverse concatenates the name as best it can.
  3. The field shows the split apart name so the user can verify it.

If it's correct, no further action needed. If it's wrong, a little edit button lets them go to the complex form (two fields) and correct their name.

But is all the development required to create a smart enough algorithm worth the saved microseconds of user time? I think not. I would spend more time on properly cueing the user to what your form expects, i.e. use standard, best practices.

Here's how I think it actually works for most people:

Name Fields Cartoon

share|improve this answer
5  
I love your pens –  Naoise Golden Jan 5 '12 at 22:50
2  
Each is an arrow in my quiver. –  tajmo Jan 5 '12 at 22:52
1  
Wow! did you just whip that up? take a photo of your white board? Cool! –  Itumac Jan 5 '12 at 23:07
4  
We have a scanner that sends files right to the server. Easy as pie. These are my standard drawing tools: ux.stackexchange.com/a/14818/4695 –  tajmo Jan 5 '12 at 23:10
1  
I thought you did on a Wacom tablet. –  dnbrv Jan 5 '12 at 23:12

It makes for a great idea if the DB is also dealing with it as a single string. (Usually with a follow up field requesting how the user would preferred to be referred to in "short" form. e.g. Full Name: Dr Nicholas Riveria Short Name: Dr Nick)

If the DB is expecting the name as seperate fields then attempting to create a automated system to split the full name into its component parts is an almost impossible task... mainly because even humans tend to get it wrong (and if a human can't do it, what chance do they have in getting a machine to do it).

The classic examples of automated systems (and humans) failing at this is when it comes to dealing with users from cultures where it's normal to cite one's family name first. e.g. A lot of Asia and the Middle East.

My suggestion would be to change the DB instead... but failing that keep the fields in the UI in line with the DB and try one's best to indicate to the user which name should go in which field.

share|improve this answer
2  
If the DB is expecting the name as seperate fields then attempting to create a automated system to split the full name into its component parts Splitting a string is trivial. Getting accurate, useful data from a string of dynamic lengths and assigning a type to each portion is the difficult part. –  Aaron McIver Jan 5 '12 at 21:55
    
The DB is not changeable and doesn't map to a single string. I can stab at the algorithm but I know it will never be perfect. I am letting go of the idea. –  Itumac Jan 5 '12 at 23:19

It does look like good UX but if the DB has different fields it's highly improbable that you are going to make it right 100% of the time.

Here is what I would do: implement a very smart parser, but, before commiting, ask for confirmation from the user. Chances are that the parser made it right (then the user would only have to confirm), and if it made it wrong, then provide two inputs or a reasonable amount of alternatives.

Let's say she enters Lalita Angie Singh:

Is this correct?

  • Name: Lalita Angie
  • Surname: Singh

No! Edit manually or continue with the form...

...in all, it does seem too much for a simple an imput as Name and Surname are, but craftily executed can be quite a novelty.

share|improve this answer
1  
Ha! I saw your answer after I posted mine. Great minds think alike. –  tajmo Jan 5 '12 at 22:51
    
That's an extra step in the workflow. I'm not sure whether it's necessary. –  dnbrv Jan 5 '12 at 23:13
    
@dnbrv yeah, I deleted the continue button because it wasn't necessary. In fact it's the same idea tajmo wrote, but not so well explained. –  Naoise Golden Jan 5 '12 at 23:34

For me the basic pricipal should be: make things as simple for user as they can be, but then give them the choice to go advanced path.

In this case i would use single field with something like "First name, Last name" as watermark suggesting that user should use a comma to split first and last name. However if he dosn't do it, you should split it automatically.

Then user should be able to edit it in his profile in more advanced way.

The perfect example is the gmail contacts app. There is one field for name. the first word you enter is by default considered as first name, and the rest of the string is last name (didn't try with prefixes like mrs, mr). However then you can click on three dots icon and a popup form with details comes when you have ability to enter first name, last name, company, etc separately.

In my opinion this is the best approach.

share|improve this answer
    
It looks to me gmail has name as one field mapping to the db. –  Itumac Jan 5 '12 at 23:12
    
@Itumac gmail has 2 fields, and it messes all my Contacts because we use two surnames. Really nasty. –  Naoise Golden Jan 5 '12 at 23:30

The viability of splitting a single field into name and surnames depends on:

  • The desired success ratio. You can apply some heuristics such as consider a list of common names and surnames or adopting rules depending on the country to increase the ratio but 100% success is not possible*.

  • The impact of a mistake. How bad are the consequences of splitting a name the wrong way? You may consider using two fields when users edit their name later. This way they can prevent a mistake.

I would label the field as "full name" instead of just "name".

*An example of a name that is impossible to split correctly is the full name of Pablo Picasso( http://en.m.wikipedia.org/wiki/Picasso) : Pablo Diego José Francisco de Paula Juan Nepomuceno María de los Remedios Cipriano de la Santísima Trinidad Ruiz y Picasso

share|improve this answer
    
Trying to split a full name into parts is fraught with risks - not only are there many ambiguities and odd cases and exceptions, if you happen to get it wrong then (a) it's something most people tend to care about, (b) most other places will have also gotten it wrong so the person brings a good deal of pent up frustration with them, and (c) often they are the very type of people that are likely to make a big stink about their special snowflake of a name.. –  Erics Jan 6 '12 at 2:05
    
I agree on most of your ponts but I wanted to note in my answer that point (b) is an assumption that depends on the specific application. For example, an application that displays the full name most of the time is not heavily affected by a mistake in the splitting process. –  Pau Giner Jan 6 '12 at 8:35

I think this idea has merit, but I also agree that parsing it correctly in the general case is going to take a lot of work and you may never get it 100% right. If this isn't entered as if it were a mailing addressee, and thus subject to some pretty strict conventions, I think you are asking for trouble (and by "trouble" I mean corrupted/dirty data).

In addition to a high level of exercise with unit tests, maybe a hybrid approach would work? Have a single field as you want, whose contents are parsed out into additional fields that can be hidden behind a collapsible section of the UI. If the user wants to make sure you parsed it out right, they can expand the div (or you can do it for them when they tab out of the textbox) and they can see the split-out name. If it didn't work right, they could edit the individual name fields.

I think overall this would give your users the convenience you're after in the normal case, while keeping the form usable in exceptional cases.

share|improve this answer

If you need specific information - be specific:

  • State you require BOTH a first name and surname.
  • It's very possible to automatically split the two strings into their required components.
  • It's also possible to apply validation routine to the input to ensure that two strings (no more / less) are entered separated by a space.

This would provide you with the same result as two separate inputs.

The main problem would the extra cost in terms of development time / complexity. You'd need to work out if the benefit justifies the increased cost.

share|improve this answer
    
Splitting a string is not a reliable solution. Spaces live in unpredictable places in names. "John Jacob Smith". "Ian Van Der Zahn". "Li Chiu". –  ghoti Jan 10 '12 at 18:38
    
It's a possible solution - the validation routine would obviously need to tackle the problem of separating the names. –  codeinthehole Jan 12 '12 at 14:32
1  
It may be possible, but just not practical in the general case. See stackoverflow.com/questions/1122328/… for a real-world example. –  John Saunders Oct 12 '13 at 14:26

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.