At Hoodline, we’re mapping the world of news around you. Our vision is to allow locals to discover the pulse of their city, and help travelers to experience a city like locals do. By classifying local content by time, location, and context, we provide residents and visitors with a rich way of discovering the city around them.
As part of this mission, Hoodline has developed the first hyperlocal news service using the Uber Trip Experiences API. Currently, the hyperlocal integration is available in San Francisco and New York City, and citywide news is offered in Los Angeles, Atlanta and Toronto as we expand our coverage.
When readers are on a trip with Uber and load the Hoodline site, they will find hyperlocal stories about their destination from The Atlantic’s CityLab, VICE, and neighborhood news from local blogs, such as Bernalwood and Mission Local in San Francisco, Corner Media in Brooklyn, and Viewing NYC in New York City at large.
In partnership with Yelp, Hoodline also helps users find new restaurants near their destinations, the best places for a late-night snack, and spots to grab a bite near home. With video highlights of best dishes and the latest reviews, riders can decide what they want to order on their way to the restaurant.
Right News at the Right Time
One of the biggest challenges developing the Hoodline experience was figuring out how to deliver the right information at the right time for different groups of users. By using pickup location, destination, and time, we found we could add significantly more context to nearby events and deliver more relevant information to users. For example, this allows us to offer different content to morning commuters and tourists.
Integrating the Trip Experiences API proved to be quite straightforward. Here are some of the highlights.
Uber API uses OAuth 2 as its authentication model to obtain access to users’ accounts. When integrating oAuth in Node.js, we used the “node-uber” library. It helped with the authentication and requests to the Uber API.
As soon the user authenticates and gives access to their account, our application receives notifications via webhooks every time the status of a trip changes. We then use that information to update and prepare our application context. When implementing a Trip Experience, the main information to pay attention to is the status “all_trips.status_changed.” This informs our application that an important change just happened to the trip. Once we receive the webhook, we then send a request to /requests/current to obtain more information.
This is the main endpoint to obtain information about the trip. This data can be used to provide context to the user experience. In our specific case, we were interested in knowing the pickup and drop-off times and the destination. With that information, we were able to provide users with contextualized stories about the area they were going to.
Most importantly, we worked hard to make sure what we implemented is accurate and reliable, both from the engineering and user experience standpoint. At Hoodline, we did that in a few different ways.
Testing the development environment
The implementation was 100% tested. By mocking all the requests to the Uber API, we were able to make all necessary changes to the product and develop quickly. To validate, generate the mocks, and to better understand the interaction with the Uber API, we made good use of the Uber API sandbox. With it, we were able to simulate rides without the need to pay for a real ride.
Testing in the staging environment
Thoroughly testing the experience posed a challenge, especially since each experience is based on hyperlocal content about the rider’s specific destination. To test the full experience (content, maps, widget, animations, etc.), we built a tool that can generate endless fake rides all over the country by defining a custom pickup ETA, destination ETA, and destination latitude/longitude. With it, we were able to see the exact experience a user in our application would have on a ride to any particular location. This tool proved crucial to our implementation, and our product manager, designer, and developers used it extensively.
Being able to programmatically simulate rides also proved valuable to our operations team. We were able to simulate thousands of rides in a particular area, generating a heatmap of content availability based on a specific feed algorithm (see the map above). This heatmap helped us better define our final algorithm and also show weak spots, helping the operations team identify where to produce and aggregate content next.
The exclusive Uber experience is built for the mobile web, making it easy for people to use on both iOS and Android devices. To connect, simply log on to ride.hoodline.com, go to account settings, and opt in for Uber Trip Experiences.