Copied over from US-based for profit discussion
Today I would like to discuss and get your view points on one of the most important changes that we are going to make in OFN. As @jveilleux has mentioned in his introductory post that we would like to focus more on showing the Nearby Markets to a customer’s location as compared to the general approach followed in the present software. Our flow would be as follows:
- When a user comes to the website we would try to fetch the User’s approximate Geo location.
- If point 1 is successful then after clicking on “Shop Now” button on the home page the user will be shown a list of nearby Farmer’s Market.
- If point 1 is unsuccessful we would ask the user her zip code so that we can show the Farmer’s market in a predefined mile range. The mile range can be changed by the user.
- We would be showing the Market Names instead along with their distance from user’s present location.
- Please consider the flow to be same for the rest of the part even though it would change a bit according to our needs.
We would like to get the viewpoints of the community so that we can build something useful for all in the best possible way.
thanks for this, initial comments / thoughts from me . .
The biggest question is how / extent to which this co-exists with existing functionality. Having had a look at the mock-up @jveilleux sent me, alongside the existing /shops page, it seems like there are three main differences (in relation to this topic):
- “Here you are” display of Customer’s City, State, Zip (detected from IP)
- Changes to the fields shown in the listing, including a ‘distance’ field
- “Or you can look around” [XX] miles/km from your location (allowing Customer to extend the search)
@RohanM has suggested that the easiest way to do this might be to fit with the existing logic in the search, so if your geo-locating can get a suburb or postcode and then just auto-fill the search box - then it should basically do this for you anyway. See discussion here around some recent changes to how this search works (which may not be deployed yet)
####1. Geo-locate . .
- If 1 is successful,
- search box pre-filled with suburb or postcode
- the text above the (now pre-filled) search box becomes “Here you are”
- If 1 unsuccessful, no change to existing operation - they can put zip/postcode into search box. Or you can change the text specifically on your version to prompt for zipcode, but searching for a suburb name or farmers market name would still work
####2. Show distance
Note in the image above that when the distance search is being used to filter shops, the distance is already shown - so the work to calculate and display distances is already done. I suspect this should happen automatically once you’ve pre-filled the search
How you display this distance and the other proposed changes to fields I think keep for your version only
####3. User selects ‘scope’ of distance search
I think having this option on the main shop page for all OFN would be good. Re. UX, not sure if you’re planning to carry the filter options over into your white-label version or not (could affect preferred location for this field), couple of possibilities for how this could sit shown below. Open to suggestions from others as well e.g. @MyriamBoure @CynthiaReynolds @tschumilas
There is existing logic that is determining scope for this distance search - it is using a limit “number of kms” within which results are returned, otherwise it says “no results for xx” . . so this should just be a case of making this into a variable that the User can modify. @lin_d_hop @Matt-Yorkley @jeronimo @Oliver @maikel have been looking at the search more recently (in Git#1453 linked above) so can maybe tell you exactly what/where it is . . @oeoeaio and @RohanM can help if this does not become obvious
###Other proposed changes on your mock-up
e.g. search by product - can we open a new thread when you get to this, if it is planning to go to next level beyond product category (e.g. search by apple rather than fruit)
@jveilleux can you confirm whether you’re ok for your mockups to be included in these threads or not?
I’m fine with having my mockups included in the thread. I was going to do it, but haven’t gotten there.
Still getting used to what the software actually does so I understand your comments, but a few observations:
There is no uniqueness in municipal names across state lines in the US. There are many Washington, Union, Franklin, etc townships, cities and counties. And we don’t use the term suburb here to mean a specific place, so geo-locating an address or user usually requires more detail than a place name.
In fact, postal codes in the US can often encompass very large pieces of geography, in rural and less populated areas. So I actually prefer something more detailed than even just ZIP (postal) codes…
I should also mention that in the US, municipal addresses can be ambiguous. Example: I have a house in an unincorporated part of Burke County, NC, but my mailing address is Nebo, a town that is in neighboring McDowell county. We don’t live in Nebo, but the post office that services our house is there, and most US residents use the mailing address as frequently as they use the actual municipal place where they live. (If you’re confused, it’s because the reality is confusing.)
If we populate based on location services (e.g. IP geocoding), we can attempt to use a municipal place name (in the US, the government calls this a Minor Civil Division) and will be correct at least 80% of the time, but will sometimes be off by a lot. So I prefer to simply try to identify the markets without confusing the user by populating the “suburb” (to use your term) label.
Reacting to your comments:
Where you say this: “If 1 unsuccessful, no change to existing operation - they can put zip/postcode into search box. Or you can change the text specifically on your version to prompt for zipcode, but searching for a suburb name or farmers market name would still work” I have no problem with keeping the search by municipality but am concerned about missing markets that are outside the municipal/suburb boundaries but are close by. Example: the closest markets to my house in Burke County are in Morganton and Marion, two towns that outside my town but about equidistant from my house in opposite directions.
When you show distance, are you using the centroid of the suburb or postal code, or the actual geo-coordinates of the address?
Your UX example seems to be calculating from the market the user is looking at. Is that correct? I’d prefer to use the user’s location (or the location they enter as their address).
It’s very helpful to know there is already logic and data fields to support a distance calculation and search function. We’ll have to find it.
As for other searches (by specific product), yes, let’s open a new thread. I don’t want to make things more confusing than they already are. And we’re not really ready to get this started. (My biggest interest right now on this point is understanding and/or modifying the categories, so a user can search for Kosher, Hallal, Animal-Welfare Certified, etc.)
Some questions on this comment:
What’s the comparison point for the distance calculation? Are you using the user’s geocode, and if so, how are you getting it?
How do we find what table the geocode of the markets is being kept in? Or is it obvious? (there are so many tables in OFN, I haven’t tried to understand the structure myself.
What are you using the geocode the market’s address? I know this is possible using Google Maps API, but trying to understand what method OFN actually uses.
Or point me to a source who can answer these questions…
Here are the screens we’ve mocked up for the search by distance feature (note that we’re bringing in a designer - haven’t hired yet - so these are subject to change:
Hi again @jveilleux
some quick responses, assuming the 3 numbered questions above are summarised / refined versions of the previous post
- What’s the comparison point for the distance calculation? Are you using the user’s geocode, and if so, how are you getting it?
Not sure - pretty sure we’re not using the user’s geocode (don’t recall it ever being discussed) so I’d be guessing it’s working from the location identified in the search box. Have just had a little poke around using Chrome’s developer tools (view, developer, developer tools, network) and as a non-tech person it kinda looks like that’s what’s happening. Seems to be sending requests to google api as I’m typing
- How do we find what table the geocode of the markets is being kept in? Or is it obvious? (there are so many tables in OFN, I haven’t tried to understand the structure myself.
As above, I don’t think the geocode is being stored . . Again, there may be some clues for where to look at what’s going using developer tools (see below), but this is best confirmed by a dev - let us know if @ravi can’t easily see what’s going on
- What are you using the geocode the market’s address? I know this is possible using Google Maps API, but trying to understand what method OFN actually uses.
pretty sure that would be the google maps API as above.
Some quick points re. other comments above:
- stuff about addresses - the Enterprise addresses are street addresses. I don’t know how google maps deals with address geocoding for a suburb / area e.g. if it is looking at centre or what. I’m sure their documentation will tell you. But if you’re trying to match a user’s IP with an enterprise address you’d be comparing two quite specific things and should get a clear distance result
- does google deal with both mailing and municipal addresses? If so your concerns simplify as users can enter (or detect from IP) more info if they need closer matches. But as long as you’re returning the enterprises/markets closest to them it’ll be fine
- re. search / categories: as you’re running your own instance you can set both the product categories and properties (more suited to Kosher, Hallal etc) however you want them. If you haven’t had a read-through the setting up your own instance threads now would probably be a good time. Also this recent post could be useful Product categories/taxonomies
Thanks. I agree it appears to be getting the geocode in realtime. That’s not efficient, I don’t think, without understanding how the original search starts. There are over 10,000 farmers markets in the US and we can’t be submitting each address to Google, getting the lat/long, calculating the distance and filtering that way.
It must be the case that the OFN software uses some other algorithm, but even given that, I’d rather store the lat/long (latitude and longitude) in the database, then calculate using local values. (At some point of usage, the Google Maps API is not free.)
Google geocodes to the point (street address), whenever it can. So I think we’re good here as long as the address is clear (US addresses can be a mess) .
While Google keeps municipal addresses in the database, the population of the data is spotty in my experience. Postal address is the default, in part because there’s one national entity (the US Post Office) that keeps the data updated. I was asking because I didn’t understand your search logic (and it’s still unclear to me), but I agree that replacing it with a distance calculation will eliminate the problem.
Thanks for point us to the categories discussion links. Still in learning mode.