It’s not about the functionality but why does Google need to know that I’m looking at fast food from this specific location? Google isn’t a party to my eating decisions and can only be used to target ads. It’s not a reasonable requirement.
Requires a map? On my phone, there’s no map widget nor distance to a restaurant nor anything else distance related.
There’s zero reason for the current functionality to require giving google my location.
Sure, you can argue that one day they might add something that uses the map, but that day ain’t today nor does it seem a reasonable requirement to get the calorie content of some chicken nugs.
Mine are exactly the same, and I presume because you clicked on the url I gave, which includes "/us/en-us/".
Switching to "/se/sv-se/" and navigating over to the McNuggets does give different values, however, given the nation is pre-encoded in the url, adding a google map lookup seems entirely pointless.
The page seemingly doesn't use your location data for anything, you need to go to the specific site for your country to see the nutrition for your country.
As mentioned elsewhere in this post, ingredients vary based on country/location and so geolocation might be used for that. I would think of this as something to explore in this investigation. However, you are coming across as so confident in there being zero value that I’m not seeing any value in continuing this dialog.
The country/location is already detected and used before you get to the nutrition facts page. In the url I gave, it includes "/us/en-us/". As the other commenter to my comment saw, going to that url in Sweden gives the US nutrition facts, not their local ones.
Given the location isn't used to customize the results, nor provide any information on where restaurants are or availability, what do you believe the end user's benefit is?
Almost certainly this. Not just chicken but breading ingredients, the oil they fry them in, probably salt content. Maybe sauces too?
Oil sounds like the likely culprit to me. About a decade ago a bunch of cities, including Chicago, started regulating the types of oil that could be used for frying in restaurants.
That's a nice idea, as if these nutrition facts are super specialized to your precise McDonalds location, and don't actually ya know come down to how much the kid in the back of the kitchen is using the salt shaker.
People don't actually believe these are anything more than averages with huge error bars right?
HN is full of propagandized technologists who have yet to realize how few of the world's problems are technical, and how approximately all of them are political.
I disagree, I think most people here understand the problems are political they just not understand that the problem was CREATED by the politics, and instead believe the solution to the problem is political.
They refuse to believe that government thus politics is the problem, not the solution
I have seen your comments elsewhere on HN. It's refreshing to see some like-minded opinions. Do you have any other online presence or some way I might contact you? My email is in my profile here, if you're open to that.
Just because the numbers may be approximate, doesn't necessarily mean that you don't need to measure again somewhere where you're doing something different. It's far more defensible for regulators to require a measurement or new calculation than to accept "eh, it's about the same, I promise."
McDonald’s does regional distribution that affects some of these factors too; different suppliers, etc.
It’s harder to see these days, but where I live in Albany, NY, McDonalds was in the New England region, and we would get the lobster roll “a New England favorite!”
Head a few miles away and you’d be in an area supplied out of New Jersey, Pennsylvania or Western NY. This sort of thing is noticeable if you live in a place that’s sort of a Venn diagram from a distribution standpoint.
If I understand “total cookie protection” in Firefox correctly, this shouldn’t even be possible. When the website makes a request to Google, the user’s Google cookie is not included in the request, so Google does not know which user it is. All that Google can do is try to determine the user’s approximate location from their IP address.
edit: I asked Bard about this, and it told me that websites can get the approx. location of their visitors via the Google Geolocation API:
> To use the Google Geolocation API, a website must first obtain a Google Maps API key. Once they have a key, they can add the following code to their website:
<script src="https://maps.googleapis.com/maps/api/js?key=YOUR_API_KEY"></script>
<script>
function getGeolocation() {
var location = navigator.geolocation.getCurrentPosition();
if (location) {
var lat = location.latitude;
var lng = location.longitude;
// Do something with the location information.
}
}
</script>
The cardinality of the suppliers is higher than a dropdown of menus can provide. In some areas that straddle distributors it may be unique for each store.
Oh. Drop-down with stores then and the closest one picked by IP location or device location API. Still no need for Google maps unless a user wants to see locations on the map.
Looking at the law (in Oregon) “Total calories must be posted in a conspicuous place in a font size no smaller than the price, or the least prominent font size of the description of the item. A statement listing the daily nutrient intake amounts of calories, saturated fat, and sodium.”
Seems like any legal requirements imply signage in the physical venue ?
Interesting that they won’t infer a location from an IP or other information they have. Seems like they just want the location data and have an excuse to demand it.
>Seems like they just want the location data and have an excuse to demand it.
1. you don't need google maps script to request location
2. the site needs to ask the user before it can get their location. the average user doesn't even know whether google maps is involved or not, so it's totally irrelevant.
Same here. I am in Charlottetown, but can get either that, Halifax or Montreal, which I assume are at different levels of the interconnect to the rest of the Internet.
Occasionally, I will get French language automatically picked because of the assumption that I am “in” Montreal.
Because Sites usually have an input box to enter the store address / zip code, otherwise you'd never be able to look up for another location. Probably the case here too
Sounds like the typical... "We are not doing it because it's easy but because we thought it would be easy." Kind of manager... the ones that can get your whole company in trouble.
Speaking of which, I hate the new trend of requiring you to use their online ordering flow to view a menu or view nutrition info. I just want to know if I have enough calories left in the day for that medium fries on my way home. I don’t want to order online and have them delivered.
Probably not, given that the post's author was seemingly more concerned about making an outrage post than doing the most basic of investigation. From what I can tell one part of the script is trying to do `google.maps`, which errors out because `google` is undefined. The code in question seems to be initialization related, so it's unclear whether the page actually requires google maps api, or the site was poorly designed and tries to initialize google maps api on every page.
I have no idea what you’re talking about. I didn’t “select anything to be bait”. I found an interesting behavior on a website and wanted to share it. What exactly is your problem?
In other words: blocking random scripts might cause sites to stop working. Who would have thought? This is the equivalent of deleting a random third party analytics library and complaining that your app no longer builds. Sure, there's the concept of progressive enhancement or whatever, but at the same time it's also unreasonable to expect the developer to accommodate the possibility of any third party script getting blocked.
> possibility of any third party script getting blocked
I'd say it's not unreasonable. You're giving your third parties the ability to break your business. Third party scripts are blocked or just fail to load all the time, APIs change suddenly, etc.
That might be doable if the library is jquery or whatever, but how are you going to replace google maps? Hosting an OSM tiles server is non-trivial, and I highly doubt that you'll be able to host it with better reliability than google.
jQuery isn't Google Maps. Different tools have different solutions.
You can save your site by self-hosting jQuery, but if your business depends on Google Maps you should at least handle failure more gracefully than a blank screen.
I have done that in the past, but there is an upside to not doing it that way. If you use a CDN, and the user has already loaded it from the CDN via another site, that's only less thing to download. So it can make your site seem faster for a subset of users.
In this case, breakage doesn't seem to affect you paying them or any of the money-making parts of their business. It might fail at an ordering step, I don't know. All online ordering for Micky-D's here is done through third-parties.
This case specifically just seems to hit (mandated?) nutritional information that's also printed on the packaging.
That’s the wrong attitude. Unless the function of your site completely depends on google maps it shouldn’t break other logic. We’ve been building websites that survive these kinds of things for decades. Some people just don’t engineer their stuff correctly and this is the result. It’s not hard to do it right.
Why should I, the developer go out of my way to accommodate people going out of their way (by installing an adblocker/script blocker) to break my app? If you're going out of your way to create a non-standard execution environment, any breakages is on you.
Ad blockers should not be considered "non standard".
Even if blockers do count as non-standard, random scripts not loading should not be capable of bringing down your site, and this should've been clear even before the npm left-pad debacle.
> Ad blockers should not be considered "non standard".
In this specific case the behavior is caused by more than a run of the mill adblocker with standard blocking lists. The OP seems to be using a very aggressive blocking list (eg. blocking all google services), or blocking all third party scripts altogether.
>Even if blockers do count as non-standard, random scripts not loading should not be capable of bringing down your site, and this should've been clear even before the npm left-pad debacle.
"shouldn't" is debatable here, especially when the cost to mitigate those issues are non-trivial (engineering effort) and the chance of it occurring (eg. google maps randomly failing) is low. A failed hard drive shouldn't bring down a computer either, but how many of us are using laptops with RAID1 drives?
Yeah, well, we tried the vision you describe, in which the site has almost complete control over the user experience, and it hasn't turned out well IMHO.
The only reason the site has so much control is that the browser makers gave it away. The browser makers should have retained much more control over the user experience. The site of course should have complete control over the words that appear on the site (and the ordering of the words of course) and some other things.
That was the fundamental mistake of the web. If people wanted to create a new internet protocol for serving user experiences over the net such that the user need not explicitly install any app, that would've been OK with me. The mistake was achieving that goal by extending the internet protocol that was quickly become society's most important way of distributing words (writings).
I've completely gotten off the subject of ad blockers.
> You are not entitled to an experience other than the one they are willing to provide.
And they aren't entitled to have me as a user or customer.
As ad blocking is a matter of basic digital sanitation, this is roughly analogous to me refusing to do business with a doctor whose office has a sign outside saying "no facemasks may be worn" — they might be allowed by law to make a bad demand, but it's still bad and they still shouldn't even if they don't care about losing my custom.
Using an ad block analogy, you aren't refusing to do business with the doctor.
A better analogy is you go into a doctors office, there have pamphlets for other services offered that you are no interested in, so rip the pamphlet displays off the wall and complain you're the victim for not being allowed to see the doctor.
Why would you put auxiliary resources on your critical path if they’re not required? What if google maps has an outage and suddenly your entire website breaks when the only part requiring google maps is the store locator? What if you’re on an airplane or some other network with limited connectivity?
If you engineer your application correctly with non-critical things outside the critical path you can have the best of both worlds.
Imagine going into the CTO’s office to explain why some vital tool or feature hasn’t been working for 35% of users because of some silly issue with Google Maps. “Why did Google Maps issues break our site?” … “well ackshually our entire app waits for maps.init()…” this is like the worst response imaginable.
The first couple of months I moved into my new house, many sites and apps were broken to me, as the address wasn't yet on Google Maps, and rather than degrade gracefully, those sites and apps were borked due to inability to pre-populate my address.
I had a very similar situation when I moved not too long ago.
I couldn't arrange for gas service before I moved into my home because the gas company's web site would only accept Google-blessed addresses.
I had to actually move in, and then go down to the gas company office with a copy of my lease to prove the address exists.
Strange, since at some time in the past the gas company payed many thousands of dollars to run gas service down my street. But, like in most big organizations, I suspect the web people and the company data people don't talk to one another.
> But, like in most big organizations, I suspect the web people and the company data people don't talk to one another.
Sounds like you're trying to assume good intentions, but you sound extremely naive as a result.
The issue is privatized utilities. They are an ordained monopoly. Their failure to "talk to one another" is not a failure at all. They have no reason to even consider the problem in the first place. You're still paying them, are you not?
Oh FFS plenty of government services do the exact same thing. The issue isn't private/public. It's our modern development culture of not looking for edge cases to begin with, and ignoring them when they arise later.
My city uses Google to fill addresses on their tax portal, so for new construction this exact issue arises. My power company (a public utility) uses recaptcha for logins and I frequently struggle with it.
I mean there's a change your location button at the top that literally displays google maps, also might use it to auto complete addresses, they're probably just preloading the script for that. That page doesn't even request location permissions, this is much ado about nothing.
I have a feeling this is some dependency the dev created that's breaking their framework's rendering of the content.
I have Firefox loaded with all the ad and privacy blockers installed for this reason when I do tests and code reviews. It reveals a lot of inadvertent dependencies and bugs that devs are unaware of.
The sourced ingredients are indeed regional. The menu is regional as well. The website is built on top of their mobile ordering platform. The mobile ordering platform requires your location to be able to route your order to the “correct” McDonald’s. This is done via requesting your location from Google or via location services within the mobile app.
This platform is used by a lot of different QSRs. Or Quick Service Restaurants. Dunkin, Starbucks, Taco Bell, Checkers, etc.
I know this because I built the platform.
The biggest hurdle to the platform was delivering your order to the store “just-in-time” for it to be hot and ready when you get there.
Checkout CardFREE. It’s been a decade but they are still delivering value. The VP of Engineering was a new hire junior engineer when I was there.
That ship has sailed. Location data is vital to a lot of internet services now. GeoIP fencing is one thing but location fencing is a tech that is being used by every major government (despite them outcrying privacy concerns).
I wish it wasn’t like this but until the open web becomes the “transparent” web, the snooping, spying, logging, graph-identity-building, MarTech driven, web will continue to go towards walled gardens and deanonymizing the internet.
And yet if you want your app to be listed on the iPhone App Store, it must be equally functional if the user denies location. So, I always do it, and have no problems, although sometimes it is slightly more annoying to use the app.
I’d rather not be picked up by Uber at the middle of whichever area shares my postal code, and I’d rather not get my food delivered there.
On the other hand, postal codes can sometimes apply to a handful of buildings, and sometimes can apply to entire cities, depending on the country and local area, so they can either be very unhelpful or almost as invasive as sharing your precise location.
There are entire counties here in the US with the same zip code. Varying by miles. So yeah, it’s not a reliable source of location for delivery purposes without a complete address.
It fails in the other direction in Canada, where a specific postal code works like a 9+4 zip code, in that it might identify one side of one block of a street, so it doesn't give you much additional privacy through precision loss anyway.
The US does that too in most places. 5+4 zip codes. It's still not enough and suffers the same precision issues and we (the USA) are woefully ill-prepared for the housing build out boom that will happen in the next decade. We need a better system. We will exhaust our zip codes like we have our IPv4 addresses.
You wish it wasn't like that, yet you helped build one of the cornerstones that enabled it to become that way. Curious. I'm getting mixed messages here.
Is this an example of "I knew not what I was doing", or what? I eval projects I'll assist by thinking of applications 2 or three times removed from the project prospectus exactly to not unknowingly further the ends of a surveillance state.
I like location api’s, otherwise we wouldn’t have turn by turn directions, maps, trail guides, etc. I don’t like location tracking for the purposes of advertisements, proximity correlation, geofencing targeting, and location sharing without consent.
Why can't you just select a particular McDonald's, set a (first-party, essential) cookie to say that address is "my restaurant" and then show nutrition facts/delivery destination with that location?
You don't need to know which room in my house I'm sitting in to tell me how many calories are in a McChicken.
Depending on the stores “load”. Exactly. It will hold onto your order until you are close enough for them to start making it and be done when you arrive. It requires knowing the turn-around time, business of location, distance, traffic, order length, estimated time to completion, and of course - your payment authorization. Not all brands show this but all brands do this.
>Ask the user to select a location. I may want to know the nutritional facts about an item somewhere else. Say I'm traveling there.
At the time, it was only National in the USA. You could lookup different stores to get menus after the app determined your closest store.
>Have websites in different countries: like if I go to macdonalds.co.jp, I get the nutritional facts in Japanese about the Japanese Big Mac.
I believe they do this now.
At the time it was implemented, there wasn’t a bias like there is today against location API’s. They hadn’t been used (yet) for tracking purposes outside of maps and what we were doing. No ad based geo fencing and location sharing.
The big issue is QSR’s are fast food. Fast food must be fast. Under 10 minutes. Any select, drop down, input box to enter in your address, added extra complexity to the checkout ordering process during our focus groups. Having an image of the item, add to order, checkout to nearest store, results in a 10x reduction in ordering time. It makes the user experience of the ordering process streamlined and smooth and operational from your vehicle with one hand.
I find mcdonalds won't let me submit my order until I'm on the same block, and it adds an extra step during ordering, and it makes the app janky. I then have to wait while they prepare. This is not an improvement over the non geotracked version.
I specifically order starbucks long before I get there because I prefer their hot food to cool down before I eat. Mcdonalds takes that agency away.
109 comments
[ 5.6 ms ] story [ 193 ms ] threadhttps://www.mcdonalds.com/us/en-us/about-our-food/nutrition-...
Requires a map? On my phone, there’s no map widget nor distance to a restaurant nor anything else distance related.
There’s zero reason for the current functionality to require giving google my location.
Sure, you can argue that one day they might add something that uses the map, but that day ain’t today nor does it seem a reasonable requirement to get the calorie content of some chicken nugs.
Calories Calories 24grams Total Fat (31 % Daily Value) 24g 24grams Total Fat (31 % DV ) Total Fat (31 % Daily Value) 26grams Total Carbs (9 % Daily Value) 26g 26grams Total Carbs (9 % DV ) Total Carbs (9 % Daily Value) 23grams Protein 23g 23grams Protein Protein Saturated Fat: 4g (20 % DV) 4grams (20 Percent Daily Values ) Dietary Fiber: 1g (4 % DV) 1grams (4 Percent Daily Values ) Calcium: 15mg (2 % DV) 15milligrams (2 Percent Daily Values ) Trans Fat: 0g 0grams Total Sugars: 0g 0grams Added Sugars: 0g (0 % DV) 0grams (0 Percent Daily Values ) Iron: 1mg (6 % DV) 1milligrams (6 Percent Daily Values ) Cholesterol: 65mg (21 % DV) 65milligrams (21 Percent Daily Values ) Vitamin D: 0mcg (0 % DV) 0microgram (0 Percent Daily Values ) Potassium: 360mg (8 % DV) 360milligrams (8 Percent Daily Values ) Sodium: 850mg (37 % DV) 850milligrams (37 Percent Daily Values )
Switching to "/se/sv-se/" and navigating over to the McNuggets does give different values, however, given the nation is pre-encoded in the url, adding a google map lookup seems entirely pointless.
https://www.mcdonalds.com/se/sv-se/naringskalkylatorn.html
For england there are 6 and 9 chicken nuggets listed https://www.mcdonalds.com/gb/en-gb/good-to-know/nutrition-ca...
The page seemingly doesn't use your location data for anything, you need to go to the specific site for your country to see the nutrition for your country.
Given the location isn't used to customize the results, nor provide any information on where restaurants are or availability, what do you believe the end user's benefit is?
Oil sounds like the likely culprit to me. About a decade ago a bunch of cities, including Chicago, started regulating the types of oil that could be used for frying in restaurants.
People don't actually believe these are anything more than averages with huge error bars right?
I'm sure there are better essays with similar value, but the one that comes to mind is Heidegger's The Question Concerning Technology: https://www2.hawaii.edu/~freeman/courses/phil394/The%20Quest...
They refuse to believe that government thus politics is the problem, not the solution
It’s harder to see these days, but where I live in Albany, NY, McDonalds was in the New England region, and we would get the lobster roll “a New England favorite!”
Head a few miles away and you’d be in an area supplied out of New Jersey, Pennsylvania or Western NY. This sort of thing is noticeable if you live in a place that’s sort of a Venn diagram from a distribution standpoint.
edit: I asked Bard about this, and it told me that websites can get the approx. location of their visitors via the Google Geolocation API:
> To use the Google Geolocation API, a website must first obtain a Google Maps API key. Once they have a key, they can add the following code to their website:
Instead, it's probably being used for an autocomplete widget to help users type in an address.
We used IP to determine regions before there even was Google Maps.
Looking at the law (in Oregon) “Total calories must be posted in a conspicuous place in a font size no smaller than the price, or the least prominent font size of the description of the item. A statement listing the daily nutrient intake amounts of calories, saturated fat, and sodium.”
Seems like any legal requirements imply signage in the physical venue ?
1. you don't need google maps script to request location
2. the site needs to ask the user before it can get their location. the average user doesn't even know whether google maps is involved or not, so it's totally irrelevant.
Right now, Google maps tells me I'm in suburban Atlanta. It's off by more than a thousand miles.
Occasionally, I will get French language automatically picked because of the assumption that I am “in” Montreal.
https://www.allrecipes.com/gallery/regional-mcdonalds-items/
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
I'd say it's not unreasonable. You're giving your third parties the ability to break your business. Third party scripts are blocked or just fail to load all the time, APIs change suddenly, etc.
What's your strategy for dealing with jquery not getting loaded?
>APIs change suddenly, etc.
That's going to be an issue regardless of you check whether the script is loaded or not.
Host it on your own infrastructure so that it's the same reliability as your site itself?
You can save your site by self-hosting jQuery, but if your business depends on Google Maps you should at least handle failure more gracefully than a blank screen.
That hasn't been true for years due to timing attacks. See: https://news.ycombinator.com/item?id=24745748
This case specifically just seems to hit (mandated?) nutritional information that's also printed on the packaging.
Even if blockers do count as non-standard, random scripts not loading should not be capable of bringing down your site, and this should've been clear even before the npm left-pad debacle.
In this specific case the behavior is caused by more than a run of the mill adblocker with standard blocking lists. The OP seems to be using a very aggressive blocking list (eg. blocking all google services), or blocking all third party scripts altogether.
>Even if blockers do count as non-standard, random scripts not loading should not be capable of bringing down your site, and this should've been clear even before the npm left-pad debacle.
"shouldn't" is debatable here, especially when the cost to mitigate those issues are non-trivial (engineering effort) and the chance of it occurring (eg. google maps randomly failing) is low. A failed hard drive shouldn't bring down a computer either, but how many of us are using laptops with RAID1 drives?
The website has every right to server you the content as they seem fit.
You are not entitled to an experience other than the one they are willing to provide.
The only reason the site has so much control is that the browser makers gave it away. The browser makers should have retained much more control over the user experience. The site of course should have complete control over the words that appear on the site (and the ordering of the words of course) and some other things.
That was the fundamental mistake of the web. If people wanted to create a new internet protocol for serving user experiences over the net such that the user need not explicitly install any app, that would've been OK with me. The mistake was achieving that goal by extending the internet protocol that was quickly become society's most important way of distributing words (writings).
I've completely gotten off the subject of ad blockers.
And they aren't entitled to have me as a user or customer.
As ad blocking is a matter of basic digital sanitation, this is roughly analogous to me refusing to do business with a doctor whose office has a sign outside saying "no facemasks may be worn" — they might be allowed by law to make a bad demand, but it's still bad and they still shouldn't even if they don't care about losing my custom.
A better analogy is you go into a doctors office, there have pamphlets for other services offered that you are no interested in, so rip the pamphlet displays off the wall and complain you're the victim for not being allowed to see the doctor.
If you engineer your application correctly with non-critical things outside the critical path you can have the best of both worlds.
Imagine going into the CTO’s office to explain why some vital tool or feature hasn’t been working for 35% of users because of some silly issue with Google Maps. “Why did Google Maps issues break our site?” … “well ackshually our entire app waits for maps.init()…” this is like the worst response imaginable.
I couldn't arrange for gas service before I moved into my home because the gas company's web site would only accept Google-blessed addresses.
I had to actually move in, and then go down to the gas company office with a copy of my lease to prove the address exists.
Strange, since at some time in the past the gas company payed many thousands of dollars to run gas service down my street. But, like in most big organizations, I suspect the web people and the company data people don't talk to one another.
Sounds like you're trying to assume good intentions, but you sound extremely naive as a result.
The issue is privatized utilities. They are an ordained monopoly. Their failure to "talk to one another" is not a failure at all. They have no reason to even consider the problem in the first place. You're still paying them, are you not?
My city uses Google to fill addresses on their tax portal, so for new construction this exact issue arises. My power company (a public utility) uses recaptcha for logins and I frequently struggle with it.
I have Firefox loaded with all the ad and privacy blockers installed for this reason when I do tests and code reviews. It reveals a lot of inadvertent dependencies and bugs that devs are unaware of.
This platform is used by a lot of different QSRs. Or Quick Service Restaurants. Dunkin, Starbucks, Taco Bell, Checkers, etc.
I know this because I built the platform.
The biggest hurdle to the platform was delivering your order to the store “just-in-time” for it to be hot and ready when you get there.
Checkout CardFREE. It’s been a decade but they are still delivering value. The VP of Engineering was a new hire junior engineer when I was there.
http://www.cardfree.com
Eg, I always block location API access, and sites often have poor fallback UI for entry.
If it'd let me, I'd be setting my browser to always report "Toronto, Ontario" and auto-deny location requests.
I wish it wasn’t like this but until the open web becomes the “transparent” web, the snooping, spying, logging, graph-identity-building, MarTech driven, web will continue to go towards walled gardens and deanonymizing the internet.
On the other hand, postal codes can sometimes apply to a handful of buildings, and sometimes can apply to entire cities, depending on the country and local area, so they can either be very unhelpful or almost as invasive as sharing your precise location.
But yeah, what I meant to express was that Canada doesn't have a lower-precision version in regular use.
That's a much smaller number.
Pickup from McDonald’s is not, at most there will be two or four in a zip code.
Another in TX, 8 McDonald’s. Another in FL, 10 McDonald’s.
Is this an example of "I knew not what I was doing", or what? I eval projects I'll assist by thinking of applications 2 or three times removed from the project prospectus exactly to not unknowingly further the ends of a surveillance state.
You don't need to know which room in my house I'm sitting in to tell me how many calories are in a McChicken.
"Yeah but", do you need Google Maps do do the geolocation?
- Have websites in different countries: like if I go to macdonalds.co.jp, I get the nutritional facts in Japanese about the Japanese Big Mac.
Geolocation is rude, lame and broken.
At the time, it was only National in the USA. You could lookup different stores to get menus after the app determined your closest store.
>Have websites in different countries: like if I go to macdonalds.co.jp, I get the nutritional facts in Japanese about the Japanese Big Mac.
I believe they do this now.
At the time it was implemented, there wasn’t a bias like there is today against location API’s. They hadn’t been used (yet) for tracking purposes outside of maps and what we were doing. No ad based geo fencing and location sharing.
The big issue is QSR’s are fast food. Fast food must be fast. Under 10 minutes. Any select, drop down, input box to enter in your address, added extra complexity to the checkout ordering process during our focus groups. Having an image of the item, add to order, checkout to nearest store, results in a 10x reduction in ordering time. It makes the user experience of the ordering process streamlined and smooth and operational from your vehicle with one hand.
I would build the same system today.
I specifically order starbucks long before I get there because I prefer their hot food to cool down before I eat. Mcdonalds takes that agency away.
They are using Google Maps to get your local nutrition facts. They change with location.