Skip to content

Comment on Google Maps is a critical dependency for nutrition facts on mcdonalds.com

Comments

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.

http://www.cardfree.com

Interesting! But also really speaks to the need for a browser setting for very coarse location without requiring user entry.

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.

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.

Almost any non-mapping application for location is just as well served by “zip-code”.

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.

Zip codes don't need to identify buildings, they need to identify post offices (and with +4, mail carrier routes).

That's a much smaller number.

Oops, right, 5+4, not 9+4. Counting is hard.

But yeah, what I meant to express was that Canada doesn't have a lower-precision version in regular use.

Uber and delivery are both mapping applications.

Pickup from McDonald’s is not, at most there will be two or four in a zip code.

There’s a county in CA, one zip code, 14 McDonald’s.

Another in TX, 8 McDonald’s. Another in FL, 10 McDonald’s.

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.

Mobile app uses location API’s provided by the device. No cookies necessary and plays nice with Apple’s anti-cookie tracking App Store policy.

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.

I do not take responsibility for the current state, only the tech that enabled us to be there. I personally do not eat at McDonald’s.

I noticed Dunkin' has the just in time feature. It asks if you want your order to wait until you get closer to the location.

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.

The sourced ingredients are indeed regional.

"Yeah but", do you need Google Maps do do the geolocation?

When using a browser, that’s the location api that was available at the time. Was there a better option in 2013?

- 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.

- 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.

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 would build the same system today.

GeoIP databases, <input> and <select> elements.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.