My members can choose from a list of countries.
The A-Z lists starts at Afghanistan, and goes through many obscure countries.
Should I get the top ten countries and "quick-list" them at the top of the list?
Or is this seen as some sort of cultural superiority yadda yadda?
I'm using PHP/MySQL (trying to get a programming angle there)
I think it makes it harder to find your country.
Germany is (I think) one of those top 10 countries and I always have the problem that I don't know what to search for.
Search at the top, search for Germany, search for Deutschland,...
I think the easiest is alphabetically ordered countries.
If the List is very long you may start typing the first letter to get next to your country.
Another solution is to have the list only show countries that have been given as answers in the past, plus an "Other" option that expands the list (or shows a second list) with the full set.
Thus, if you've never had a visitor from, say, Kyrgyzstan, it wouldn't appear in the list at all. The first time a Kyrgyzstani user comes to the site, they'd choose "Other" on the list, and only then would you show the full list. After that, though, since Kyrgyzstan had been answered, you would show it in the initial list. (The threshold for that doesn't have to be 1 ... it can be any number you like, and you'd want to set it so that on balance, many more people are helped by the omission than are hurt by having to choose "Other".)
You could also include a population (or internet-using population) metric and automatically show all countries above a certain size, so the big ones like Germany would be included even before their first users start showing up. Or, if you know you'll have a lot of users from certain countries, for whatever reason, you can have a list of countries that are manually included as well.
Overall: don't underestimate the benefit you'll get by trimming down the list. It's little things like that that make a user interface "great" rather than "ok".
You may track the list of most picked countries from your list and put them in the beginning of your list. After this sublist add line and then ordered list of the rest of the countries.
After some time you may remove the logic and 'freeze' the sublist of n 'most popular' countries
Why not keep the list intact, but pre-select the country your visitor is in using geolocation?
Determine the user's physical location based on their IP address.
You can get started at http://www.ip2location.com/, but there are other free choices out there.
Do a Google search for city from "ip address", or country from "ip address".
Be aware that there are some physical divisions that are not apparent if you select a simple country. For example, the country France includes the French Caribbean, and if you are calculating port, you could be thrown off.
Apart from using geolocation, it is important to use the same list (and it is the same standardized list) used by Amazon, Google, Apple, etc. To see it, just go start ordering a product on Amazon and change your shipping address country.
The reason is that people who live in a given country are already used to selecting their country from this particular list, and know how to do it quickly. Any modifications that you make to the list, while well-meaning, will just slow them down.
Remember, people spend 99.99% of their time at other web sites. They know how to be efficient using the tools they've already come across. You should emulate those other sites whenever there is a standard way of doing things -- anything else will confuse your users.
I can also recommend using the country names in the language that your site displays. I am always annoyed by a country list on an English website that uses "Deutschland" for Germany. When I am on an English website, I am intuitively looking for the English country name.
An interesting question. I too have been wondering about this usability issue many times. Why not create a category call continent and users would visit a continent before selecting a country of his/her choice? Would it make it faster (or more convenient) for the users? Of course your list would now need to be level deep. Or with Ajax, this allows many opportunities for some new innovative usability ideas.
Personally, I don't like it. I'd prefer that countries were just listed alphabetically instead of "United States, Canada, Afghanistan, ..."
Perhaps if you know that 95% of your traffic is coming from one particular country then it might be defensible.
Related
I'm a little stumped on whether i can make this process of changing addresses easier. I'll explain the situation:
Basically I have three entities, Students, Addresses, StudentsAddresses. Students have many addresses, since they can change alot and rapidly (especially foster kids / homeless kids). So ill be changing them a lot. However based on each address I Want a user to attach (enter it via the UI) the price it would cost to pick that student up via bus service. So my initial thought was, ok, let me attach a column onto my join table 'StudentsAddresses' called 'dailyPrice', this is the cost for each day a student is picked up, and another column called 'adjustmentPrice', which is an additional cost for whatever special circumstance that requires extra work to pick up a student. Is my thinking going to cause me problems the more students I have in the future? Will it get harder to manage?
Another option I thought about, was creating a new Table called Pricing. And another join-type table called StudentsAddressesPricing
StudentsAddressPricing has three columns,
studentId
addressId
pricingId
each field connects the three together. So if i ever needed Students, with their addresses, and the pricing, i would query this table and eager load Students, Addresses, and Pricing. Does this approach seem much cleaner since i've abstracted pricing out a bit? Trying to determine the best way to go about this without having to many headaches in the future incase I wan't to add more attributes pricing related, or address related.
And then I even thought, hey what if pricing is just different for one day? How would I even consider that. Would I need a different kind of entity to handle that? Is doing alot of joins going to hurt my application performance?
Just looking for some insight on how others would do it, and criticism on why im off the ball.
The main question you should ask yourself is: on what does the price depend?
If the price is determined by the address, you might as well add it to addresses. If the price also depends on the student (e.g., depending on their financial situation), it would make sense to put it into studentsaddresses.
In other words: The table where the price is stored should have foreign keys to everything outside the table that determines the price. If that makes it fit into one of the existing tables, keep it there.
We have just started using the Google Places API to display hospitals in particular cities.
The problem we are having is when using the type or keyword "hospitals", it displays all sorts of clinics and medical centres.
If I browse maps.google.com and search for "hospitals in city x" using Google's own website, it displays just the single hospital in that city.
Does anyone have any suggestions as to how to filter out and display the single hospitals and not the other smaller centres?
You can use the prominence option for the rankby parameter to get the results ranked by how important they are in the area. In the case of a hospital this will most likely return the main hospital for a town/city as the first option. Other options will be given in descending order of prominence, so you could check each place name for the first option that includes the word "clinic", "medical centre", "GP", etc and cut the list there.
rankby — Specifies the order in which results are listed. Possible values are:
prominence (default). This option sorts results based on their importance.
Ranking will favor prominent places within the specified area. Prominence
can be affected by a Place's ranking in Google's index, the number of check-
ins from your application, global popularity, and other factors.
Places Search documentation
If I were to design a database in MySQL to the following specifications:
1) Over 25mil records
2) Columns of house number, street, town, city, postcode
3) street, town, city and postcode need to be fulltext-searchable (on the front-end side, the search will be running on AJAX off a text-input field with immediate drop-down results)
How would I design the above?
I was thinking with working with a single table - is this a bad idea? Am not sure whether to normalize across different tables, given this is address data. I am also thinking that if working with a single table, I would do a FULLTEXT index across the searchable fields.
I have not worked with such a large DB before. Is the above a bad idea?
UPDATE #1:
Decided to normalize the street and postcode columns, which are the only ones actually being searched on (re-checked the original specification). Did some quick math and cardinality of street name is 2% and postcodes 6% of total data set, so I think this is the best way forward.
Currently running the import of 29 million rows - will take about 5 hours. Will update again later on performance tests for the sake of wrapping up this question.
Your design sounds reasonable. But. Are you sure that the addresses in the database all conform to the " , , " format? What about "c/o" addresses ("care/of")? Unit/apartment/floor/suite numbers? What about specific building names ("Barack Obama, White House, Washington, DC")?
In the United States, there are various exceptions to this address layout. For example, there is something called "Rural Routes", whose format is "RR BOX " (described here). There are PO Boxes and military addresses. In fact, I just learned that the US Post Office has a publication describing all sorts of different address formats (here).
A more general form is something like "Address Line 1", "Address Line 2", "City", "Post Code". There are services that standardize addresses for much of the world, and even software available for this purpose.
Your idea of using full text search is a good idea. When looking for a partial match on a street name, for instance, it will be much faster.
I am using Ruby on Rails, however am interested in a general solution as well. Lets say I have a model users, a model cuisines, and a relational table connecting the two allowing a user to have a list of 'favorite cuisines'. The user is presented with a list of all the cuisines and can check or uncheck them individually. For example lets say Alice starts off liking American, Indian, and Chinese food. She then unchecks Chinese and adds in Thai and hits save. Whats the best way to go about updating the relational table?
I have three solutions, but since this operation seems so common I was hoping for a more elegant solution. If there isn't, what is the standard way to do this?
keep a set of added and a set of removed, and make sure they have no overlap
drop all of the users favorite foods and insert the selected ones
make ajax calls to update each individual add and remove
use the association_ids approach. Instead of looking for a list cuisines and then assigning them to the user, just get a list of their ids and assign it to user.cuisine_ids. Saving the record will generate the association records for you. Since you're using checkboxes, be wary of the scenario where a user unchecks everything and then saves. What usually happens is no change is saved keeping the old selected cuisines selected. This can be easily fixed by adding a nil hidden value with the same name as the checkboxes.
i am creating a search functionality for a website where i need to take the user's full address from an input e.g "Address 32, City,Region,Country, Postal Code"(no necessary with this order) and return the available restaurant that are around the area.
I have a table "address" where there is a field for each of the above elements.
I was thinking of concatenating the users address from the database and compare it with the user's input by help of SQL REGEXP.
Is there any other approximate SQL search that can give me that or can you suggest me a different approach?
A friend suggested using (http://www.simonemms.com/2011/02/08/codeigniter-solr/) however with a small research on it the problem still remains.
Trouble with concatentating the address together in SQL is you will miss out on it using indexes. Hence it will be slow. Added to which if you do not know the order of the input elements the chances of it matching what is concatenated from the database (is a likely different order) is slim.
I would suggest for much of the address items, split them off into different tables (ie a table of regions, another of countries, etc) and just store the ids in the columns in the users table.
For a search, identify which of the search fields go with which actual field then join on those to find the real address.
Also means you can identify typos more easily.