[ID Discuss] Capturing a user's postal address

[Craig Oshima]

Definitely a more efficient approach; I always just use the Zip on Mapquest.
But until there's a fast, accurate, and cheap (or free) service to provide
Zip-to-City/State mapping, it's not likely to see widespread deployment.
USPS appears to provide such a service, but it requires registration to
use...I'll have to look into the details.

Craig

-----Original Message-----
From: John Vaughan [mailto:vaughan1 at optonline.net] 
Sent: Friday, April 02, 2004 9:31 AM
To: discuss at interactiondesigners.com
Subject: Re: [ID Discuss] Capturing a user's postal address

It seems to me that use of the zipcode in US would often knock out 2 steps
in a laborious, repetitive process.

Type in a 5 character ZIP:

* You get the STATE by default, and probably the city, too.

* If you want to turn the CITY field into a dropdown with multiple choices
(if appropriate), you could. But simply populating the CITY field with your
"best guess"/biggest town/whatever will probably be accurate 90% of the
time.  Just leave it editable.

* You've just filled in 3 postal address fields by entering only 5
characters.

I don't know how well this method will work internationally, but assume that
some of the same efficiencies apply.

At the back end, you're tying into a database (supplied by the Postal
Service? could be a moneymaker) that provides the table.

>From an Interaction Design perspective, the challenge is to guide your
customer towards entering the ZIP field first.

John Vaughan
email:  vaughan1 at optonline.net
website: http://www.jcvtcs.com
ZIP: 07034   (couldn't resist....)



----- Original Message -----
From: <John.Bedard at ngc.com>
To: <coshima at netscreen.com>; <discuss at interactiondesigners.com>
Sent: Wednesday, March 31, 2004 7:18 PM
Subject: RE: [ID Discuss] Capturing a user's postal address


> FWIW, on a recent system we deployed we used XSLT to manipulate state
names (among other things). One template would hold all the states'
fullnames (even formatted with <option> tags for the drop-down) and another
to convert it to the abbreviation which was then passed into the PDF form
via XSL:FO. By controlling both ends we eliminated both mistakes and
misspellings. We also rigged up the template to preselect the state if it
already existed in the XML so the user often doesn't have to do anything
unless the address has changed.
>
> The infrastructure should be able to handle a more user-friendly way to
read and understand things like state names and do the "dirty work" behind
the scenes.
>
> John
>
> -----Original Message-----
> From: Craig Oshima [mailto:coshima at netscreen.com]
> Sent: Wednesday, March 31, 2004 3:07 PM
> To: discuss at interactiondesigners.com
> Subject: RE: [ID Discuss] Capturing a user's postal address
>
>
> > From: Whitney Quesenbery [mailto:wq at sufficiently.com]
> > Sent: Wednesday, March 31, 2004 10:27 AM
> > To: discuss at interactiondesigners.com
> > Subject: RE: [ID Discuss] Capturing a user's postal address
> > (...)
> > And there is my personal pet peeve: being forced to select the
> > state rather than entering it. I can type "NJ" much faster
> > than I can find the state in a drop down.
> > (...)
> > The usual argument is that we are helping users by preventing
> > errors.
>
> There is some validity to that argument.  Consider the case where you're
> sending a gift to someone via Amazon or something.  When you're typing
your
> own state abbreviation, of course it's easy.  You may have varying degrees
> of ease with the other 49 states however (putting aside territories other
> countries). In these cases, picking from a list of names (not just
> abbreviations) may well be a better design.  I ran into this the other day
> thinking about the two-letter abbreviation for "Mississippi".  "MI" came
> naturally, but no, I think that's Michigan.  It must be "MS" because I
don't
> think there's an "MP"...but then, what about "Missouri"? (It turns out to
be
> "MO").
>
> As in all things, you need to consider the ways things will be used.  What
> is super-efficient for one scenario may not work as well for others.
>
> (Personally though, I'd like to see more single field addresses with smart
> address parsing, where Ohio and "OH" were both understood.  It would cause
> less frustration for non-U.S. users as well.  Unfortunately, it does
> increase the technical complexity when the address elements--especially if
> you accept international addresses--must be parsed out for storage or
> submission to payment services or fulfillment services.)
>
> --
> Craig Oshima
> coshima at acm.org
> _______________________________________________
> Interaction Design Discussion List
> discuss at interactiondesigners.com
> --
> to change your options (unsubscribe or set digest):
http://discuss.interactiondesigners.com
> --
> Questions: lists at interactiondesigners.com
> --
> Announcement Online List (discussion list members get announcements
already)
> http://interactiondesigners.com/announceList/
> --
> http://interactiondesigners.com/
> _______________________________________________
> Interaction Design Discussion List
> discuss at interactiondesigners.com
> --
> to change your options (unsubscribe or set digest):
http://discuss.interactiondesigners.com
> --
> Questions: lists at interactiondesigners.com
> --
> Announcement Online List (discussion list members get announcements
already)
> http://interactiondesigners.com/announceList/
> --
> http://interactiondesigners.com/


_______________________________________________
Interaction Design Discussion List
discuss at interactiondesigners.com
--
to change your options (unsubscribe or set digest):
http://discuss.interactiondesigners.com
--
Questions: lists at interactiondesigners.com
--
Announcement Online List (discussion list members get announcements already)
http://interactiondesigners.com/announceList/
--
http://interactiondesigners.com/