This may not be a "product" in the conventional sense, but it's a very interesting integration, and demonstration of a trend where apps are beginning to deep link into other apps in ways that used to be reserved for, or only possible in, web apps.
Consider this quote from Noah Weiss, SVP of Product Management at Foursquare:
“Using Button simplified the process of integrating Uber into Foursquare. With a few lines of code we were able to create a seamless experience when requesting an Uber built directly into our app, saving us time and effort.”
Yes, a marketing quote for sure, but an example of times are changing and shifting towards native app experiences. Literally you could rewrite that quote to say "With a simple <a href>, we created a seamless experience between Foursquare and Uber". But that isn't what Noah said, and that isn't the technology being used here.
So, that's why I hunted this.
@chrismessina really curious what the real reason is why @fourquare picked button integration over direct deeplinking themselves which is merely 1 line:
Uber://? and then some params like "pickup lat lon" and "destination lat lon" ...
Which is maybe less integration time + no sideloading of additional sdks....
Nevertheless great partnership result for "button".
@roelandp@chrismessina@arush Great question! The first part is the obvious one: Foursquare (more specifically the awesome engineers and designers that work there) are our target audience. We do everything in our power to make sure their experience with the Button product, whether that's our client SDK, documentation, or the end-user facing feature, is delightful and working perfectly. I would argue integrating with Button is a much more "productized" experience then a straight API integration-- whether thats guiding factors like docs and best practice, or pragmatics like QA and accounting for odd edge cases.
Second, that "productization" scales. When the time comes that a Button partner (like Foursquare) wants to add additional integrations, there is very little additional work. One Button integration abstracts away all the work of numerous API integrations. And point 2.5, if that's allowed, is our platform is also built to monitor those API's and reduce partner exposure to bugs, downtime, and other oddities that come from being dependent on tons of external services.
Finally, the only thing we obsess about more then making partner teams happy, is making the deep linking experience between apps as seamless and natural for the user as possible. We've done more product, engineering and design work in this space than anyone in the market. Our "Ride Picker" UI in Foursquare brings context into the current app (such as fare estimates and surge indicators), so users know more about where they're headed. Our AttendedInstall feature can run an app download inside of Foursquare if users don't have Uber installed already, then take them to the appropriate place when the download finishes (instead of booting them out to the App Store then dropping them at the front door of Uber).
Making these connections great is what we do. From providing an awesome service experience, to productizing that connection beautifully for the end user and abstracting away any technical dependency or risk, Button is laser-focused on enabling these app connections for our partners.
@chrismessina Thanks for the submission, and the kind words!
You hit on one of the things thats most fascinating to me about this (nascent) space— linking in web apps, and how similar (or not) linking will look on mobile. A key difference on mobile, one that we focus on a lot at Button, is level of user intent. Most apps are single-purpose, and discovery/navigating between apps has been so high friction historically, users generally have a very good idea of what they're doing when they arrive in an app. This is easier to poke holes in on the content side, but in mobile commerce, where Button focuses, it's especially true.
On the web, a user might casually wind up on a page knowing they can easily jump to another, go back, close the tab, etc. On mobile, by the time at user arrives at, say, a Foursquare venue page, their intent is pretty high-- maybe they want a ride, or to see the menu, make a reservation, etc. The realm of possibilities is relatively restricted and targeted compared to the web. At Button, we want to help those users fulfill that intent, in a way that benefits the user, the app and the service provider. Closing Foursquare, finding Uber, inputting the venue, and hailing a ride is a high-friction experience, and one that doesn't benefit Foursquare, which inspired the ride. With Button, we can help users fulfill that intent in the place where it arises, while enabling Foursquare to better serve their users.
@maxbulger thanks for your very extensive answer! Clarifies the advantages of having button sdk, curious what would come up next
in the fsq app! Checking out button's sdk myself too :)
@timjahn your snark is blinding you from the huge value Foursquare gets out of this integration - if a user orders an Uber to a venue, then Foursquare has closed the loop and provided a good recommendation that made the user go to the venue IRL. Short of installing beacons at every bar, coffee shop, and restaurant, this is the best available way to know if that loop was closed. That data point can be immensely valuable to Foursquare, both for advertising and A/B testing their own product to continually improve the recommendations they provide.
Really love what the team at Button is doing and think this is just one of many use cases that makes it easier for developers to reduce user friction.
I know people love to hate on 4sq but I still love it, in part because they experiment like this. I hope more startups understand the opportunity here, like Uber does, and open their services up to Button...