street address?
danvideo opened this issue · 25 comments
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.
There are several issues/thoughts in one:
- Why is there no
addressfield inlocation? - Consider using post[al] code [or postcode] rather than zip code.
- Consider adding a
desiredWorkLocationskey. - Consider adding a
desiredWorkPositionskey.
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?
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: #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.
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.
"Postal code" is the most general and common writing: http://en.wikipedia.org/wiki/Postal_code
"Street" is probably too narrow, you're right.
Proposal: address for stuff like street and housenumber, postalCode for the postal code :)
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.
And couldn't you include that information in one field? Hinterhaus 5. Etage li could be one line, right?
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.
Seems a valid reason :)
Revised proposal: addressLine1, addressLine2, postalCode.
Please vote +1 if agree.
+1
Happy to dogfood it soon. :)
I need to convince my wife to move to a fancier place that requires two addressLines ;)
OT: Create another issue for that. :P
@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.
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.
This issue has been elevated to decision needed
@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.
+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."
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.
PR in #102
I botched up my PR, but @mwaclawek created a new one, which has now been merged.
I created an additional PR for clarifying how to add multiple address lines, as per @opensourcegrrrl 's example. Please review and merge :) #111
Great work guys and thanks @dandydev !