Re: [whatwg] Supporting more address levels in autocomplete

On Mon, 3 Mar 2014, Evan Stade wrote:
> > >
> > > I don't think you can just write a stack of inputs that accepts 
> > > input for any country. The country determines:
> > >
> > > a) what fields make sense
> > > b) what fields are required
> > > c) the order of fields
> > >
> > > You could ignore (a) and settle for a crappy UI that shows all 
> > > fields that make sense anywhere in the world, but you'd still be 
> > > left with solving (b) and (c).
> >
> > (b) is an easy-to-solve problem: you don't make any of them required, 
> > and if the customer entered insufficient fields, they're not getting 
> > their package, and will have to be contacted out-of-band.
> 
> I don't think the additional load that would place on customer service, 
> the number of missing packages, etc., would be considered an "easy" 
> problem or even an improvement over whatever they currently have in 
> place.

I am not convinced it'd be that big a load (users generally know what 
parts of their addresses are required!). But in any case, if we're talking 
about mom-and-pop stores with a minimal load of international orders in 
the first place, it's likely that the customer service load would be 
pretty minimal.


> > Can you elaborate on (c)?
> 
> US looks like:
> 
> Recipient
> Organization
> Street address
> City, State ZIP
> 
> Japan looks like:
> 
> 〒 ZIP
> State City
> Street address
> Organization
> Recipient

Ah, interesting. That is indeed a significantly larger difference than I 
expected.

Can you elaborate on these? Where would "address-line2" and 
"address-line3" go? Where would "country-name" go?


If the layout difference is that great, we should seriously consider 
documenting that also.


Looking at the suggestions I listed earlier:

> >    "address-line1" |
> >    "address-line2" |- "street-address"
> >    "address-line3" |
> >    "address-line5"
> >    "address-line6"
> >    "address-line7" / "locality"
> >    "address-line8" / "region"
> >    "address-line9" / "country-name"

This presumably wouldn't work sanely for Japanese addresses.


> > Or we could do:
> >
> >    "address-line1" |
> >    "address-line2" |- "street-address"
> >    "address-line3" |
> >    "subsublocality"
> >    "sublocality"
> >    "locality"
> >    "region"
> >    "country-name"

This could work. It avoids the synonym problem.


> >    "address-line1" |
> >    "address-line2" |- "street-address"
> >    "address-line3" |
> >    "locality"
> >    "subsubregion"
> >    "subregion"
> >    "region"
> >    "country-name"

This _could_ work, but it seems a bit weirder than "subsublocality".


> > Or alternatively:
> >
> >    "address-line1" |
> >    "address-line2" |- "street-address"
> >    "address-line3" |
> >    "region-level5"
> >    "region-level4"
> >    "region-level3" / "locality"
> >    "region-level2" / "region"
> >    "region-level1" / "country-name"

This has the advantage of not leaving "country-name" dangling.


> >    "address-line1" |
> >    "address-line2" |- "street-address"
> >    "address-line3" |
> >    "address-level4"
> >    "address-level3"
> >    "address-level2" / "locality"
> >    "address-level1" / "region"
> >    "country-name"

This could work. It has the synonym issue (having multiple fields that 
mean the same thing is often the source of confusion).


> Again, you really can't just put a stack of input fields and have it 
> make sense anywhere. If you are presenting a UI to enter addresses, 
> there's no way you can escape actually knowing how addresses are 
> formatted around the world. (Well, there's requestAutocomplete.)

You still need to know how to render them when printing the label, even 
with requestAutocomplete(). It really does seem like we should either 
document this order, or point to documentation on the topic. Are there Web 
pages out there that provide sufficient information to do this?


> I'm not married to the address-levelN name. [something-that-makes- 
> sense]N is fine.

The reason I'm being a bit reluctant to embrace address-level* is that 
it's so close to address-line*.


> The reason we went with proposing address-levelN is because 
> region-levelN implies that all political regions are captured, when they 
> aren't. There's no field for US county because county is never part of 
> an address. So it's only for regions that actually make it onto an 
> envelope.

I don't think the implication is that strong. In fact I'd argue it's the 
other way around -- the implication is that this is for addresses, not 
generic regions.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'