Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JSON Resume – 5th Birthday and New Features

jsonresume.org

Post reply on HN
Print view View original

51–58 of 58 posts

Re: JSON Resume – 5th Birthday and New Features

#51

Post by elefantastisch »

wongarsu wrote: post #31
bvda wrote: post #29

Earlier quoted context omitted.

Is there any reason not to use a singular field for this? It seems so much simpler to just give the user one input field and it would cover all scenarios.

Apparently a single field works fine in a resume builder. But consider a more complex app that does all of the following: display the name in various lists, has a detail view on that user, greets the user, talks about the person in third person (a report or similar). In each of those cases you ideally want to treat the name differently. Even in English the detail view might show George Walker Bush Jr (the legal name…

Except you are assuming you can reliably make decisions about how a person's name should be used based on your classification scheme for names. First, your classification scheme will not cover all users (see the famous https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-...). Second, your use cases will not match all users. You may consider "Hello Firstname" to be an appropriate informal greeting and "Hello Mr. Lastname" to be an appropriate formal greeting, but even for people having a first name and a last name, this is not universally true.

The only person qualified to say how a name can appropriately be used is the owner of that name. If you need a greeting, ask the user how they would prefer to be addressed. If you need to show their name to others, ask how they would prefer their name to be displayed. If you need their name as understood by some government agency, ask for their name according to that government agency (note: this is not necessarily the same for all agencies; people do not necessarily have one single legal name).

If you don't want to overwhelm the user, you can have a "Display name" or "Legal name" field depending on what is relevant to your application and use that as the default. But you should provide overrides for every case where you are using their name in a different context.

If this sounds complicated, it is because names are complicated. I have seen too many people with names that don't fit the typical pattern of Firstname Lastname (composed solely of ASCII letters) get frustrated with systems that do not support them. I will not ever assume I can know how to manipulate or use someone's name without them needing to tell me. Nor will I assume their name must fit within some predefined character set or length.

Re: JSON Resume – 5th Birthday and New Features

#53

Post by wongarsu »

elefantastisch wrote: post #51
wongarsu wrote: post #31

Earlier quoted context omitted.

Apparently a single field works fine in a resume builder. But consider a more complex app that does all of the following: display the name in various lists, has a detail view on that user, greets the user, talks about the person in third person (a report or similar). In each of those cases you ideally want to treat the name differently. Even in English the detail view might show George Walker Bush Jr (the legal name…

Except you are assuming you can reliably make decisions about how a person's name should be used based on your classification scheme for names. First, your classification scheme will not cover all users (see the famous https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-... ). Second, your use cases will not match all users. You may consider "Hello Firstname" to be an appropriate informal greeting and "Hello…

While you make good point I think I actually do pretty well on the falshoods with the scheme laid out in the grandparent comment. The cases I violate are:

- I assume everyone has at least one name (not strictly true, but close enough to true for people using the internet)

- I assume every name can be mapped to unicode (I don't even know how I would fix that assumption)

- I assume all names fit in some fixed length (I give more space than the British passport and more than I can display in most situations)

- Even though I don't assume that people have a first name or that people have a last name I assume everyone has at least one of the two

I find all of these assumptions reasonable, and your scheme of "Display Name" and "Legal Name" shares most of these assumptions, or would share them in any reasonable implementation (You can't allow names that use gigabytes of space, so there will be some length limit, and most implementations will use unicode).

Of course using a name after decomposing it isn't easy. I will concede that asking the user is easier and more reliable, but it does come with drawbacks as well.

Re: JSON Resume – 5th Birthday and New Features

#54

Post by nv-vn »

crabasa wrote: post #16

So, I am working on a "better resume" product for developers: https://fizbuz.com We plan on shipping API support so that developers can build better experiences on top of the data (alternate rendering engines, import/export, etc). I'd love to see about supporting export to JSON Resume. Is there a list of ecosystem tools that speak this format?

As someone who doesn't do any kind of web dev it seems like this isn't designed for my use case. E.g. things like Android or iOS development didn't seem to be present, let alone more niche things like embedded, graphics, etc.

Re: JSON Resume – 5th Birthday and New Features

#55

Post by mbadros »

bvda wrote: post #36
wongarsu wrote: post #31

Earlier quoted context omitted.

Apparently a single field works fine in a resume builder. But consider a more complex app that does all of the following: display the name in various lists, has a detail view on that user, greets the user, talks about the person in third person (a report or similar). In each of those cases you ideally want to treat the name differently. Even in English the detail view might show George Walker Bush Jr (the legal name…

Ah interesting, I hadn't thought of those use cases.

I recall getting a chuckle out of the honorifics drop-down menu on the Rolls-Royce contact form. https://www.rolls-roycemotorcars.com/en-GB/information/conta...

Re: JSON Resume – 5th Birthday and New Features

#57

Post by beachy »

icxa wrote: post #38
nulbyte wrote: post #27

Earlier quoted context omitted.

> People are smart enough to write down their address. Not usually. In this scenario, given its use for display on a user page, it may make sense. For most other cases, this doesn't pan out. Here in the US, for example, the general public has little sense of how to properly write addresses with floor, apartment, unit, or suite numbers. Folks routinely put things in the wrong order or use the wrong symbol or abbreviat…

Yeah, if you work for a company that has to run any kind of validation on addresses, you learn quickly most people cannot type their address in correctly at all . My take: Make it as dumb and straightforwardly painfully obvious as possible.

Coincidentally enough, we just got through writing a nest of regexps to retrospectively validate about 2K user entered addresses, and they turned out to be surprisingly well entered, probably about 98% parsable. In this case the user was entering a field called "street" and we were validating down to a number followed by a street type (e.g ST) and a few local wrinkles such as additions like "RD1" for rural addresses. The most common error, which we brute force corrected, were various misspellings of "crescent". We did not however attempt to unpack the street number, which fortunately was not required.

Re: JSON Resume – 5th Birthday and New Features

#58

Post by elefantastisch »

wongarsu wrote: post #53
elefantastisch wrote: post #51

Earlier quoted context omitted.

Except you are assuming you can reliably make decisions about how a person's name should be used based on your classification scheme for names. First, your classification scheme will not cover all users (see the famous https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-... ). Second, your use cases will not match all users. You may consider "Hello Firstname" to be an appropriate informal greeting and "Hello…

While you make good point I think I actually do pretty well on the falshoods with the scheme laid out in the grandparent comment. The cases I violate are: - I assume everyone has at least one name (not strictly true, but close enough to true for people using the internet) - I assume every name can be mapped to unicode (I don't even know how I would fix that assumption) - I assume all names fit in some fixed length (I…

I was mostly thinking about "Hello Firstname" and "Mr. Lastname". I know several people who, due to the commonness of their first name, go by their last name. For these people "Hello Lastname" is the correct informal greeting. I know others that go by their initials, and "Hello INITIALS" is the correct informal greeting. For these people, addressing them by their first name actually sounds more formal, and maybe even a little insensitive as it's against their preference. There is just no way for a system to know this without asking.

But yeah, within the universe of ways to handle names, your schema comes pretty close to the ideal. I just think it's worth considering the ways it can still fail. "People consider their first names an appropriate informal greeting" is an assumption that definitely fails in some cases.

Another place I've seen systems get this wrong is generating default avatars using first letter of first and last name as initials. For someone who goes by the initials of their first and middle names, this produces confusing initials. If someone goes by the name H. G. Wells, showing them as "Herbert" or "HW" is confusing. "HG" would be better. It fits the space for 2 letters and is more likely to be recognized as them.

Per Wikipedia, the man most recognized by the name Liberace was known as "Lee" to his friends, "Walter" to his family, but had the first name "Władziu". Referring to the person by first name or by initials is likely to cause confusion. Again, there's just no way to know.

Not trying to tear down your schema here, just provide some context for readers of the thread in general about the additional complexities that can still arise. Thanks for the interesting discussion.

Post reply on HN