Hacker News Reader

Comment by another-dave | Hacker News Reader

> Asterisks are an invention of WEB. Operating systems usually don't use them at all.

Asterisks aren't an invention of the web, they're a hold over from paper forms. It is/was common to have an asterisk beside required fields. Because that was already a convention it was adopted by designers & ported over to digital.

> You can separate required and non required fields

I think this is good when its appropriate to the data. It's almost like you'd apply it at a fieldset level rather than field level. As in, asking for username/email/password and then in another section asking for what your interests are for the algo recommendations is great.

If you have something like fields for name — first name/last name are both mandatory; middle name is optional — it would really break the flow of the form if they weren't in conventional order.

View on HN

Forms that ask for names should just as for the name and not try to force the developers cultural view of how names are constructed on the user.

Agree that _systems as a whole_ should be designed for one name, but that's often out of the hands of whoever is developing the form.

If the system _is_ designed to require a first name/last name, trying to correct for that on the front-end just makes the problem worse in my opinion (e.g. doing something like breaking on space and calling the first bit the "first name" and the second bit the "surname").

It's rather off-putting to always be referred to by your full legal name. You might need that for billing statements, but other times you might want to just address people by their first names or as "Mr./Mrs. Doe". Normal communication in our culture requires understanding the cultural use of names.

Or you could just have fields for "full name" and "preferred name".

What if I prefer Firstname in casual settings, Mr. Lastname in fancy settings, and Firstname Lastname as a fallback when the setting isn't so obvious? For people with such preferences, a schema of prefix/first/last actually does make more sense than a schema of legal/preferred.

But overall, for global optimization, I'm a fan of legal/preferred.

Then when you enter preferred name, you put the name you would prefer.

I'm saying I prefer different things in different contexts. Like if I am a student named John Bob Doe, and I set my preferred name to John in the school info system so all the authenticated websites say "Hi, John" in the personalized user header rather than something more verbose, that doesn't mean I prefer that they use only "John" for all but the most legal of matters. I want them to use Mr. Doe when etiquette suggests same, John Doe when introducing me to an audience (say, on stage or in the news), John B. Doe on my diploma, etc. This nuance is what the prefix/first/mid/last schema inherently provides for, in cultures that utilize it. You'd need a whole suite of preferred name fields otherwise.

That said, global inclusivity does seem to be more important.

I suspect that you are conflating first with given and last with family. Not everyone in the world does it that way. Icelanders use patronymics not family name anyway, the Spanish use something rather more complicated, Chinese names are family first, etc.

I'm aware of those things, but I'm just saying that there's no silver bullet given cultural preferences to compose a variety of forms based on omitting/concatenating discrete parts that can't be adequately stored in a globally-reasonable schema. The best we can do is compromise on (or completely do away with) any preference for rule-based composition, and instead just echo whole names without recomposing them. It's fair, but it's a compromise.

Please tell that to the government, product managers, and everybody else who want/mandate names to follow multiple pre-conceived patterns.

I work on ERP software. Name-handling is ridiculously over-complicated. FML, preferred, chosen (distinct from preferred), prior/maiden, legal/mailing, etc.

That assumes that there is no law or legacy system that requires names to be collected in that way, which is not a solid assumption.

Obligatory link to https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-...

Reply on news.ycombinator.com