tedd wrote:
At 8:23 PM +0100 1/8/08, Per Jessen wrote:
Richard Heyes wrote:
Nathan Nobbe wrote:
On Jan 8, 2008 2:04 PM, Richard Heyes <[EMAIL PROTECTED]> wrote:
this is not only convenient from a user perspective in the user
interface, but also
on the server side.
It's not so conveni
On Jan 8, 2008 2:23 PM, Per Jessen <[EMAIL PROTECTED]> wrote:
> Richard Heyes wrote:
>
> > Nathan Nobbe wrote:
> >> On Jan 8, 2008 2:04 PM, Richard Heyes <[EMAIL PROTECTED]> wrote:
> >>
> > this is not only convenient from a user perspective in the user
> > interface, but also
> > on t
At 8:23 PM +0100 1/8/08, Per Jessen wrote:
Richard Heyes wrote:
Nathan Nobbe wrote:
On Jan 8, 2008 2:04 PM, Richard Heyes <[EMAIL PROTECTED]> wrote:
this is not only convenient from a user perspective in the user
interface, but also
on the server side.
It's not so convenient when you
Richard Heyes wrote:
> Nathan Nobbe wrote:
>> On Jan 8, 2008 2:04 PM, Richard Heyes <[EMAIL PROTECTED]> wrote:
>>
> this is not only convenient from a user perspective in the user
> interface, but also
> on the server side.
>>> It's not so convenient when you consider Google (and pres
Nathan Nobbe wrote:
On Jan 8, 2008 2:04 PM, Richard Heyes <[EMAIL PROTECTED]> wrote:
this is not only convenient from a user perspective in the user
interface, but also
on the server side.
It's not so convenient when you consider Google (and presumably others)
toolbars auto fill.
fortunatel
On Jan 8, 2008 2:04 PM, Richard Heyes <[EMAIL PROTECTED]> wrote:
> >> this is not only convenient from a user perspective in the user
> >> interface, but also
> >> on the server side.
>
> It's not so convenient when you consider Google (and presumably others)
> toolbars auto fill.
fortunately i
this is not only convenient from a user perspective in the user
interface, but also
on the server side.
It's not so convenient when you consider Google (and presumably others)
toolbars auto fill.
--
Richard Heyes
http://www.websupportsolutions.co.uk
Knowledge Base and HelpDesk software
that
At 12:56 PM -0500 1/8/08, Nathan Nobbe wrote:
i agree, but rather than using spaces, or allowing them in the input string,
i prefer to have several focused form fields that comprise a larger element.
for example, a credit card number is 4 units of 4 digits. my preference for
credit card number e
On Jan 8, 2008 10:42 AM, tedd <[EMAIL PROTECTED]> wrote:
> At 10:18 AM -0500 1/8/08, Eric Butera wrote:
> >On Jan 8, 2008 10:08 AM, tedd <[EMAIL PROTECTED]> wrote:
> >> I just finished a credit card portion for a site where the programmer
> >> before me required the customers to enter their cred
At 10:18 AM -0500 1/8/08, Eric Butera wrote:
On Jan 8, 2008 10:08 AM, tedd <[EMAIL PROTECTED]> wrote:
I just finished a credit card portion for a site where the programmer
before me required the customers to enter their credit card number
without spaces -- why? It's a simple matter to remove
Satyam wrote:
Telephone stuff is comprehensive
Also, it should be Province/County/State, and it should be optional since
some cities are autonomous (usuall federal capital cities), just don't make
it mandatory. And don't force anything on postal codes. Some countries
have letters in them and
On Jan 8, 2008 10:08 AM, tedd <[EMAIL PROTECTED]> wrote:
> I just finished a credit card portion for a site where the programmer
> before me required the customers to enter their credit card number
> without spaces -- why? It's a simple matter to remove spaces for
> processing -- why throw that re
The best design for a form comes from using it.
To a certain extent, but I think the best design for a form stems from
watching someone else use it.
--
Richard Heyes
http://www.websupportsolutions.co.uk
Knowledge Base and HelpDesk software
that can cut the cost of online support
** NOW OFFE
At 3:10 PM +0100 1/8/08, Satyam wrote:
Also, it should be Province/County/State, and it should be optional since
some cities are autonomous (usuall federal capital cities), just don't make
it mandatory. And don't force anything on postal codes. Some countries
have letters in them and the numbe
IL PROTECTED]>
Cc:
Sent: Monday, January 07, 2008 11:56 PM
Subject: Re: [PHP] global address collection
In other words, in the USA we ask for name, address, city, state, zip,
and phone number. What would be a global equivalent that could cover all
(or most) address and phone numbers?
Full na
In other words, in the USA we ask for name, address, city, state, zip,
and phone number. What would be a global equivalent that could cover all
(or most) address and phone numbers?
Full name (optionally forename/surname)
Address 1
Address 2 (optional)
Address 3 (optional)
Town/City
County/State
On Jan 7, 2008 1:13 PM, tedd <[EMAIL PROTECTED]> wrote:
> Hi:
>
> What would be a good form (i.e., fields) for collecting global
> addresses and phone numbers?
>
> In other words, in the USA we ask for name, address, city, state,
> zip, and phone number. What would be a global equivalent that coul
Hi:
What would be a good form (i.e., fields) for collecting global
addresses and phone numbers?
In other words, in the USA we ask for name, address, city, state,
zip, and phone number. What would be a global equivalent that could
cover all (or most) address and phone numbers?
Cheers,
tedd
18 matches
Mail list logo
