jsonresume / resume-schema

JSON-Schema is used here to define and validate our proposed resume json
http://jsonresume.org
MIT License
2.15k stars 277 forks source link

street address? #76

Closed danvideo closed 10 years ago

danvideo commented 10 years ago

Nice work. I was wondering - was it a specific design decision NOT to include an "address" field in location? All job forms I've ever filled out required a specific address. Also you might want to consider the equivalent of "zip code" (obviously something accepted more world-wide such as "post code").

I know this is probably WAY overcomplicating the schema - but have you considered creating a "desiredWorkLocations" key that could take options city/states/postcodes/rangeFrom (km), also "desiredWorkPositions" that could list specific job titles? This may help the job sites sort out what jobs to pair people with.

osg commented 10 years ago

There are several issues/thoughts in one:

For this reason, it is hard for this issue to be specifically actionable, and for it to gain traction. Also, the title street address? is vague.

Which issue/thought is most important to you?

ocram commented 10 years ago

According to the issue's title, the street thing was most important to @danvideo I guess.

I've added this as a more targeted issue here: https://github.com/jsonresume/resume-schema/issues/77

Regarding the desiredWorkLocations and desiredWorkPositions, I don't think that should be a part of the schema, in addition to these problems having no relation to this issue's title.

DonDebonair commented 10 years ago

We shouldn't use street, but use address or addressline instead. In the context of internationalisation, it makes more sense. Also, +1 for post(al)code instead of zipcode.

ocram commented 10 years ago

"Postal code" is the most general and common writing: http://en.wikipedia.org/wiki/Postal_code

"Street" is probably too narrow, you're right.

DonDebonair commented 10 years ago

Proposal: address for stuff like street and housenumber, postalCode for the postal code :)

ocram commented 10 years ago

@DandyDev +1

osg commented 10 years ago

I suspect that an addressline1 (addressLine1?) and optional addressline2 (addressLine2?) could be useful. Nothing at the top of my head wrt resumes, but in Berlin I have to include that information for packages to get delivered. Apartments do not have numbers, and one must include a second address line, such as Hinterhaus 5. Etage li. In this case, if I am delivering mail, I need to go into the rear house (of the courtyard) to the 5th floor, and the apartment is on the left.

DonDebonair commented 10 years ago

And couldn't you include that information in one field? Hinterhaus 5. Etage li could be one line, right?

osg commented 10 years ago

I have never seen it on one line. If it were to be one line, it would be between 41 - 48 characters in this case.

DonDebonair commented 10 years ago

Seems a valid reason :)

Revised proposal: addressLine1, addressLine2, postalCode.

Please vote +1 if agree.

osg commented 10 years ago

+1

Happy to dogfood it soon. :)

DonDebonair commented 10 years ago

I need to convince my wife to move to a fancier place that requires two addressLines ;)

osg commented 10 years ago

OT: Create another issue for that. :P

ocram commented 10 years ago

@opensourcegrrrl and @DandyDev -1 on that. The specification should not be adjusted for styling purposes. What if someone else needs three lines then? You can just enter line breaks into the single address field.

DonDebonair commented 10 years ago

But when you enter linebreaks into fields, you actually do include styling into your resume. There is precedent for having two address lines. [This article] does a nice explanation of different address formats in web forms, tailored to different national standards. Especially the chapter about Generic Formats towards the end of the article, seems to support our notion of having two address lines. Incidentally, it also deals with the Sate/Region problem (in a way that does not apply to our spec, but it's enlightening anyways).

In conclusion: I think there are enough scenarios in which one address line/street field isn't convenient for describing an address. Having two address lines solves that problem, and is an easy way of catering to many different address formats.

osg commented 10 years ago

@DandyDev What was that link?

thomasdavis commented 10 years ago

This issue has been elevated to decision needed

ocram commented 10 years ago

@DandyDev No, if we add a separate addressLine2 field, we are including styling in the specification. However, if the user adds a line break to their single address field, they add styling to their own resume (or "implementation").

We should let the user enter whatever they want and, on our part, prefer not to include any styling/design issues in the specification, which should be more abstract and concentrate on the data.

The address is a single unit of information, so you should not split it up into several fields in the specification. By the way, your proposal of two address fields may not be enough, if that's the way we want to take this.

osg commented 10 years ago

+1 @mwaclawek's approach. Great clarification and reasoning, and it seems to solve my problem.

Next, how would the code comment read? How about this:

"To add an address line, use \n. For example, 1234 Glücklichkeit Straße\nHinterhaus 5. Etage li."

DonDebonair commented 10 years ago

Sorry, this is the link: http://www.uxmatters.com/mt/archives/2008/06/international-address-fields-in-web-forms.php I do think @mwaclawek has very good arguments though, so +1 for his approach of having one address field.

DonDebonair commented 10 years ago

PR in #102

DonDebonair commented 10 years ago

I botched up my PR, but @mwaclawek created a new one, which has now been merged.

DonDebonair commented 10 years ago

Added to changelog.

DonDebonair commented 10 years ago

I created an additional PR for clarifying how to add multiple address lines, as per @opensourcegrrrl 's example. Please review and merge :) #111

thomasdavis commented 10 years ago

Great work guys and thanks @DandyDev !