When designing an internation registration form how should I be asking for a user's information. Should name be [First, Last] or [Common, Surname] or simply [Name]. Does first and last name make sense for all names?
When asking for state and zipcode what would alternative terminology be, should I even be collecting this information for some countries?
We're recently getting into international users and methods and I'm hoping someone with experience can weigh in on the proper fields and labels that would be present in a solid international registration form.
I would reccomend just a single input for name, not all names are logically separated into just two parts, some people have just one name (such as Teller, and if used for addresses, the name may be a company name). Labeling is complicated since first and last name is not the same as given and family name, if names in your language is normally in which field should the first/family name go and the last/given name go?
For an address input you need:
Name/Company: <text box; no validation or munging>
Address: <Multiline textbox; no validation or munging>
Country: <text box or select-box if you're paranoid>
Making it more detailed and you're creating problems for foreigners.
The only thing your local post service need for a foreign address is the name of the country. The rest is country specific and may include several fields or in some cases something like "behind the church in the woods" etc.
Do not include zip code or anything country specific like that unless the user has chosen a country you have extensive knowledge about. People tend to know how to type their address in a free form text area, but they may actually mess it up if they have to force their address into foreign fields.
The worst you can do is silently discarding invalid fields. That happened to me when registering my address (in Norway) for a magazine subscription from USA. The norwegian addres format is:
<Name or company>
<Street name> <house number>
<post code> <city or suburb>
NORWAY
But when trying to force these fields into the closest equivalent in a very US-centric form they ended up mailing it to:
<my name> Oslo/OSLO//<And a lot of garbage letters and symbols>
/NORWAY
It eventually arrived, but it was a month delayed. It probably helped that I have a unique name, and that we're only about 5 million people in Norway. I doubt it would have arrived if I my name was "John Smith" and lived in New York and some web form had munged it to John Smith NY/New York;/ USA///
Sorry for the long rant ;)
I would suggest just the name, so that user could enter whatever seems right.
As for State, I quite don't understand what you need this information for. But I am not U.S. citizen, so...
Two address lines (without implied format), zip code (terminology is OK, but do not try to validate) and country name should be sufficient. The problem with "States" is, some countries do not use such concepts (either at all, or use different regional split concepts, i.e. in Poland it is voivodship, in England it would be county, etc.). Again, I wouldn't use such details.
How you accept the user data is based on what you want to do with it. Having said that
Name: This is also country specific but based on the suggestions I've got "family name" and "given name" are generic/common across any country. Some names have multiple "family name"'s.
Address: Different countries have different address formats. You can get different format information here
As a non-US resident, who has a very non-standard address (live on a boat, which requires additional address information, and very often does not have a Royal Mail standarised address) I do find that US-centric registration forms are very irritating. As far as name goes, I have found first and last name appropriate. For addresses I would consider either leaving labels off for most lines or labelling them innocuously as "address line 1", etc. In addition make sure that there are a number of such lines; the dialog box is long enough to accept multiple fields; and the dialogs will accept address delimiters such as comma. The only ones I would leave as they often displayed are Town/City and Country. Zipcodes should not be referred to as such - the minimum courtesy I would expect from a registration form is a request for Zip/Post code.
Though not directly related to registration forms, I have previously provided a (very long) answer to a question on validation/normalisation of international data. It is not a simple topic.
Related
I have an SaaS application in the pipeworks.
One of the things that has me a bit confused is the best way to manage the stable of Austalian suburb and state data across multiple databases (this applies to any country as each country has a list like this).
For example in Australia you have Australian Postcode list that links all the postcodes to the suburbs and you can use that to create a dropdown for state, suburb and postcode etc.
An example of the CSV of australian postcodes can be found HERE.
So you can upload a csv file for example but the problem remains..
Whats the best way to hold this data.. its common to all databases where you have a person, client, employee etc..
Do you replcate it in each database? Is there a better way than having redundant stores of data..
Best way to implement it..
There are several options and considerations I would look at for this problem. Some considerations:
Number of address rows expected
Whether a client database is concerned with prefill/validated international addresses
Whether the client system is web connected or can operate in isolation
Are these databases/systems hosted by you or distributed to individual clients? (SaaS implies "Web" and "Hosted by You" to points 3 & 4)
How critical address integrity is.
For smaller systems, a simple option for address systems is to de-normalize the address data (state, postcode, suburb) and consider using a central lookup database/service, either under your own control or a third party. The denormalized address table would contain the text fields for the State, Postcode, Suburb etc. rather than FK values (stateId, suburbId, etc.) This avoids needing to store lookup tables in every client DB, just one Lookup DB or leave that to a 3rd party service.
The advantage of a third-party lookup is that keeping it up to date with new areas and changes is handled for you. Third party services would require a web connection, and you have to factor in the risk of their service being down or a web connection being unavailable. Larger systems with millions of addresses might benefit from normalizing the address table, so the "cost" of replicating suitable address lookup tables might be worthwhile. You can still a central service to look up addresses, then resolve whether the client DB already has a StateId, SuburbId etc. for the respective state/suburb for that post-code before inserting one if necessary. (Cutting down the number of rows each client DB needs to address values that are actually used)
In that last example you might have lookup tables for State and Suburb linked to PostCodes, linked to Country. Country would default to the target, maybe be an optional selection for international addresses. The user provides a post code to the service which returns suburbs, they select a suburb. The address validation service could go as far as to validate the street address. When you're happy an address is "valid" and ready to be saved, you search your local State, Suburb, (even Street) tables for matches for that PostCode, if found use those FKs, otherwise insert new entries and link the FK.
Using a separate service, or services would be my consideration especially if you need to support validating/storing international addresses. For instance if the client is in Australia but regularly has address information for New Zealand. Storing entire address validation tables could get rather large if clients could be resolving addresses for many countries. (I.e. European countries and neighbours) You can write a Façade service to support different 3rd party address validation providers and/or homemade implementations with a standard interface.
If a system has to operate in isolation of an internet connection then you'll probably be stuck with each database having one or more local data sources to resolve address information.
Data integrity of address information is a separate concern you might want to consider. In some systems you need to validate that an address is recognized and don't want to allow invalid combinations or detect unexpected changes. Services that validate a particular address can provide unique IDs for an address that you can store as part of your address information. (These often tie into geocoordinate solutions where you want to quickly direct a map service to a particular location) Alternatively, if you successfully look up an address then validate that the address information is valid, even if just the country, post code, and suburb, you can create and store a hash of those values to check for tampering. (I.e. someone or some system changed a field to make the address invalid, the combined address won't match the stored hash) Addresses can be checked before use and flagged if not valid.
I am working on making a reservation tab as follows:
Date of the pick up: #sys-date
Time of the pick up: #sys-time
Address of the pick up: #sys-location
The problem is that Watson Assistant doesn't recognize the location on live test when customer input detail of their location. It keeps asking me what's the address?
All I get is date of the pick up and time with no pick up address.
The system entity #sys-location in Watson Assistant should be used with caution. It is a BETA feature for some languages and only with this capability:
The #sys-location system entity extracts place names (country, state/province, city, town, etc.) from the user's input. The value of the entity is not a system-standard value of the location.
My suggestion is to ask for the address and capture it as an entire string. Then, try to standardize the input to your local address format, e.g., by using an address verification system.
Another option is to break up the address into parts like city, street, zip code and more. Depending on the country there are different formats and even more than one format to specify it. "What is your city?", "What is your street address?", ...
When I check up an IP with whois tool, I'll get the result with one of the columns named 'roles'. The value of the 'roles' column can be 'abuse', 'technical' or 'administrative'.
It's easy to understand the meaning of 'technical' and 'administrative', but is there anyone who know what does 'abuse' mean here?
Thanks a lot.
role may be used to determine the type of contact that the node describes. There are several types of contacts, such as: administrative, technical, owner, etc.
The term "abuse" refers to a recipient that is intended to report complaints about possible illegal use of that IP address. For example, if the IP is used to send SPAM emails, or as part of some kind of frauds.
This is similar to the scope of the abuse# email in a domain.
My app has the ability of sharing its content between different instances of the app i.e. there is a button that lets me attach a document to an email and send it off to another user of the app. When they receive this file it opens up in their instance of the app. This is all working.
However, during the import of this data file, I need the app to add address book records to the address book unless the email address is already in the address book then it must just return the ABRecordRef.
I need to decide which approach is more efficient:
A - Loop through the entire address book creating an array of user defined objects with name and email address (which is all I require) and ABRecordRef. Then when the app is reading the attachment file XML it must check this NSArray each time.
B - Access the address book every time I encounter a contact in the attachment XML and search for it based on email address e.g. ABAddressBookCopyArrayOfAllPeople
Any other ideas?
Note: this applies to searching by e-mail address. If you are searching by name this does not apply.
For an arbitrarily sized address book with a fixed size number of addresses to lookup, searching the address book will be faster. This is because the initial cost of putting all the addresses into a hash is guaranteed to take at least linear (O(n)) time with respect to the number of addresses in the book while (assuming the address book is at least moderately efficien) lookup should be either logarithmic (O(ln(n)) or constant time (O(x)) depending on the implementation since you have a fixed number of addresses to check.
Edit:
A brief survey of the address book api shows that you can't simply "search the address book", you have to make a copy and then filter it.
Using Record Identifiers
Every record in the Address Book database has a unique record identifier. This identifier always refers to the same record, unless that record is deleted or the MobileMe sync data is reset. Record identifiers can be safely passed between threads. They are not guaranteed to remain the same across devices.
The recommended way to keep a long-term reference to a particular record is to store the first and last name, or a hash of the first and last name, in addition to the identifier. When you look up a record by ID, compare the record’s name to your stored name. If they don’t match, use the stored name to find the record, and store the new ID for the record.
To get the record identifier of a record, use the function ABRecordGetRecordID. To find a person record by identifier, use the function ABAddressBookGetPersonWithRecordID. To find a group by identifier, use the function ABAddressBookGetGroupWithRecordID. To find a person record by name, use the function ABAddressBookCopyPeopleWithName.
Given the limitations of the address book in iOS, copying the address book into a NSDictionary is going to be faster than trying to search each time.
Assuming you are fine with overwriting on email address collisions, I would create a dictionary with the email address as the key and the ABRecordRef stored as a NSNumber for the object.
I would do all this on a background queue and then monitor for address book changes and reload the dictionary as needed.
We've encountered users with several thousand entries in their address books. In those cases, you may want to create a record object and store it in Core Data. By filtering on the last modified date, you can determine whether or not to update the email addresses for a given record.
I want user to select city during filling his profile. What is the best way to do it in web application?
I there any other way than just store a list of cities in my DB. Maybe some public API?
The best way to do this is with a big database, unless you want to allow the user to type in a city name.
Fortunately for you, you don't have to go out and make the database yourself. Here's a directory of free databases: http://www.sqldumpster.com/databases/geographic/
I'd just go with a simple text field with an auto-completer. You can get a list of cities but you'll have to keep it up to date and you'll have to worry about nonsense like the difference between "Saint John", "St John", and "St. John".
Sending an entire list of cities to the client will just be a user interface nightmare, a selection list would have thousands and thousands of entries and you'd have to send a lot of data to the client; there's no reason to hate your visitors that much.
The auto-completer can use the currently chosen cities to provide suggestions for new cities. If you have city names in several places, then just keep a master city list somewhere for the auto-completer and updated it with new entries every day. You will end up with a list of cities but the list will build itself.
A simple text input will work the same everywhere and just about everyone can type out the name of their city pretty easily.
You could store them in a text file, have a copy in your server (for validation), and load the cities via AJAX.
That approach will break, however, for users without JS.
And, to be snobby, can you define best? Best in what sense? Fastest? Lightest? Awesomest? Most Pythonic? I'm not sure what you mean by that.