Capturing a user's postal address

31 Mar 2004 - 4:28am
10 years ago
8 replies
640 reads
Matthew Goddard
2004

*****************************************************************************************
This email and any files attached are confidential. If you are not the intended recipient of this email please note our email statement at the foot of this email.
*****************************************************************************************

Annoyed by address forms being split over several input boxes I ran a quick
qualitative user test to see what effect using a textarea to capture the
data would have.

Out of the 5 users I test only one press tab to move to the next line, but
as soon as she realised that she should press enter to move to the next line
the test proceeded with out a hitch.

Has anyone else on the list any experience this? Is there more rigorous test
data that I could dwell upon to support or disprove this argument. Even
though I ran the test my developer and product manager still don't seem
convinced.

Kind Regards

Matt Goddard

****************************************************************************************
If you are not the intended recipient of this email please delete it and report the occurrence to postmaster at hants-iow.nhsdirect.nhs.uk. To ensure the security of information being transmitted emails sent and received by this organisation are electronically scanned and may be intercepted/read by authorized members of staff (Regulation of Investigatory Powers Act 2000). This email may not be representing the views or policies of the organisation and may be the personal opinion of the sender.
*****************************************************************************************

Comments

31 Mar 2004 - 9:10am
Narey, Kevin
2004

Matthew Goddard wrote:

>Annoyed by address forms being split over several input boxes I ran a quick
>qualitative user test to see what effect using a textarea to capture the
>data would have.

Matthew

Were you annoyed because you find the separated form elements less usable or
because it's more laborious to code?

I have found that users find that when the tab index is coded correctly they
are more than happy to complete a logically broken down form regardless of
what data it captures. The mouse-click interaction as you rightly point out,
is not as intuitive.

Kind regards

Kevin

-----Original Message-----
From: Matthew Goddard [mailto:Matthew.Goddard at online.nhsdirect.nhs.uk]
Sent: 31 March 2004 10:28
To: discuss at interactiondesigners.com
Subject: [ID Discuss] Capturing a user's postal address

****************************************************************************
*************
This email and any files attached are confidential. If you are not the
intended recipient of this email please note our email statement at the foot
of this email.
****************************************************************************
*************

Annoyed by address forms being split over several input boxes I ran a quick
qualitative user test to see what effect using a textarea to capture the
data would have.

Out of the 5 users I test only one press tab to move to the next line, but
as soon as she realised that she should press enter to move to the next line
the test proceeded with out a hitch.

Has anyone else on the list any experience this? Is there more rigorous test
data that I could dwell upon to support or disprove this argument. Even
though I ran the test my developer and product manager still don't seem
convinced.

Kind Regards

Matt Goddard

****************************************************************************
************
If you are not the intended recipient of this email please delete it and
report the occurrence to postmaster at hants-iow.nhsdirect.nhs.uk. To ensure
the security of information being transmitted emails sent and received by
this organisation are electronically scanned and may be intercepted/read by
authorized members of staff (Regulation of Investigatory Powers Act 2000).
This email may not be representing the views or policies of the organisation
and may be the personal opinion of the sender.
****************************************************************************
*************

_______________________________________________
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/

**********************************************************************
gedas united kingdom limited
Registered in England no. 1371338

This email and any files transmitted with it are confidential
and it may be privileged.

It is intended solely for the use of the individual or entity to
whom it is addressed.

If you have received this in error, please contact the sender
and delete the material immediately.
**********************************************************************

31 Mar 2004 - 9:33am
Matthew Goddard
2004

*****************************************************************************************
This email and any files attached are confidential. If you are not the intended recipient of this email please note our email statement at the foot of this email.
*****************************************************************************************

>Were you annoyed because you find the separated form elements less usable
or
>because it's more laborious to code?

I'm annoyed because it's a user interface based design based upon a database
structure rather than a real world convention. Postal addresses are
generally written in a prescribed format, each line of the address on a
separate line etc.

Software have been capturing data for time and memorial and I wonder whether
splitting the address up needlessly is throw back to systems design in the
implementation model and not the user's mental model.

I have no problems with writing masses of code if it really is addressing
the problem, is splitting the address up really doing that? In actual fact I
will have write more code to mine the relevant information if I do allow it
to be entered in one entry box.

Regards

Matt

****************************************************************************************
If you are not the intended recipient of this email please delete it and report the occurrence to postmaster at hants-iow.nhsdirect.nhs.uk. To ensure the security of information being transmitted emails sent and received by this organisation are electronically scanned and may be intercepted/read by authorized members of staff (Regulation of Investigatory Powers Act 2000). This email may not be representing the views or policies of the organisation and may be the personal opinion of the sender.
*****************************************************************************************

31 Mar 2004 - 1:27pm
whitneyq
2010

> >Were you annoyed because you find the separated form elements less usable
> >or because it's more laborious to code?
>
>I'm annoyed because it's a user interface based design based upon a database
>structure rather than a real world convention. Postal addresses are
>generally written in a prescribed format, each line of the address on a
>separate line etc.

The "requirement" for forcing addresses into multiple fields usually comes
from the database folks, who want everything split up. It's easier to
validate values one by one than to either intelligently parse the address,
or to store it as a multi-line block.

In some (relatively informal) usability testing of a membership form, we
found that participants in the US were more comfortable with the (more
familiar) multiple fields. Europeans were much happier with the single
free-form field.

Our speculation was that US addresses are highly formalized (1-3 address
lines, city, state, zip) where European (and probably other) addresses are
more free form. For example, in the UK, the county may or may not be included.

Another issue is what Caroline Jarrett (see her site www.formsthatwork.com)
calls the "Arkansas" factor. That is...forms created in the US that insist
that everyone not only conform to the US layout, but select a US state. She
says she usually picks Arkansas.

Related to this are poor internationalization issues such as postal codes
that don't match the US ZIP format.

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. (4 key clicks rather and 2, or a mouse manipulation of the
drop-down that includes looking to see whether they are using abbreviations
or full state name). There's a nice article on "Should I Use a Drop Down)
on Forms That Work.com.

The usual argument is that we are helping users by preventing errors.

Feh.

Whitney Quesenbery
Whitney Interactive Design, LLC
w. www.WQusability.com
e. whitneyq at wqusability.com
p. 908-638-5467

UPA - www.usabilityprofessionals.org
STC Usability SIG: www.stcsig.org/usability

31 Mar 2004 - 5:07pm
Craig Oshima
2004

> 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

31 Mar 2004 - 7:18pm
John.Bedard at ...
2004

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/

2 Apr 2004 - 12:30pm
John Vaughan - ...
2004

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/

2 Apr 2004 - 12:47pm
Craig Oshima
2004

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/

2 Apr 2004 - 2:38pm
John Vaughan - ...
2004

Please update when you know. Admittedly, it's a big reference table, but
hardly unmanagable - and certainly useful, if only for this application. A
pity if USPS hasn't priced it to sell. The potential volume of usage in web
entry forms alone is massive.

It seems we now have several "brave new world" shorthand ID's (ZIP the only
un-virtual one):
Personal: SSN
Location: ZIP
Communication, visual: EMAIL
Communication, voice: CELLPHONE#
Identity: URL
Corporate: FED TAX ID

Any others?

John

----- Original Message -----
From: "Craig Oshima" <coshima at netscreen.com>
To: <discuss at interactiondesigners.com>
Sent: Friday, April 02, 2004 12:47 PM
Subject: RE: [ID Discuss] Capturing a user's postal address

> 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/
> _______________________________________________
> 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/

Syndicate content Get the feed