Exciting activities. Stunning scenery. Great food and drink. These are some hallmarks of a fantastic holiday.
But before you can experience any of these things, an unfortunate soul, the "trip organiser", has the lovely task of trawling through TripAdvisor and Google Maps planning an itinerary that includes the group's interests whilst making the most of the limited time at that destination. It's enough to make anyone cringe at the thought of a weekend break.
How does Huey help?
Our desire to make life easier for the trip organiser lead us to create a simple conversational interface to automate what would normally be hours of work.
Huey provides the services of an intelligent travel assistant by giving the user recommendations of things to do and places to visit, creating bespoke trip itineraries and sending the itinerary to the car’s navigation system automatically.
The trip organiser can tell Huey where they're going, how long for, and what they would like to see or do. Given this information, Huey will return a list of places that could be of interest. The organiser tells Huey which of these places they'd like to visit and Huey generates a bespoke itinerary for the trip.
Where Huey differs from other itinerary planners is that it clusters suggested activities based on proximity, eliminating long travel times and the stress of rushing between locations. Additionally, the link to the customer’s car completes the planning process to ensure a seamless experience.
How we built Huey
To realise our vision we identified a number of necessary components, in addition to a Lex bot:
Google's Places Web Search API - Used to search for places around the given the location. We found that Google gave us the best combination of data quality, performance and ease of access to the APIs.
Google Directions API - Used to calculate an optimal route from which we could then derive clusters of places for each day of the itinerary.
Google Distance Matrix API - Used to calculate the optimal start and end points for the itinerary.
AWS S3 - Used to store the itinerary as a JSON file. We used a public bucket in which we store a single object that the vehicle-side client application can access. Whenever a user creates a new itinerary, the object gets updated with the new itinerary data. Whilst this definitely is not a route we follow in a production project, it enabled us to quickly achieve a working demo. We felt this satisfied our project goals better than implementing full authentication at the risk of not achieving the challenge deadline.
Runtime - We decided to write our Lambdas using Node.js because we wanted this project to be a learning exercise, and selecting Node.js allowed us to explore how we could use it for other projects going forwards.
Use of the Jaguar Land Rover LIVE Platform
JLR’s Connected Technologies & Apps Group strives to create compelling user experiences by integrating systems and services from traditionally separate areas of the user's life. In doing so, we can bring genuine value to our customers' lives. A key enabler for this is the LIVE platform.
LIVE is Jaguar Land Rover's embedded web app platform designed to run HTML5 applications on the InControl Touch Pro infotainment system. It enables us to rapidly develop and deploy applications over the air, and these applications are able to interact with other features within the system such as media and navigation.
By leveraging LIVE we were able to demonstrate a seamless end-to-end use case in which the user's itinerary is available in their vehicle. We wrote a web application which was installed on the car over-the-air. From this application, the user can view the itinerary created by Huey and upon selecting a particular item the system will calculate a route then ask the user if they wish to start navigation.
IMPORTANT NOTE: The team developed this project purely as a learning exercise exploring how AWS Lex and Lambda can work with a connected vehicle. Jaguar Land Rover Limited does not commit to developing any production versions of this or any other chatbot-related feature.
What improvements would we make?
We think Huey is a great technology demo and has taught us a lot about Lex and Lambda. If we were given more time to work on it there are a number of improvements we would love to make.
Individual User Data - Use individual objects per user / per itinerary created. We could also update the vehicle-side client to enable a user to log in and select which itinerary they want to view from a list of all that they have created.
Authentication - As stated before, to achieve the project goals in the available time frame, we decided to make the itinerary JSON object publicly readable. In reality we would have to move to a configuration whereby only an authenticated user can access the JSON objects for the authenticated user.
Multi-step Itinerary Generation - Users can search for, say, "Historical Landmarks and Restaurants" in a location, but it is entirely up to Google's algorithms as to whether they return a list of landmarks and restaurants mixed together, or whether one portion of the results has a higher priority than the others.
To demonstrate our concept we only needed a single round of itinerary generation, but in practice we would want to allow the user to go through the loop of "search for places -> select places -> add to itinerary" multiple times so that the user can build up an itinerary that factors in a wider variety of places.
For example, the user might want to search for Italian Restaurants, Indian Restaurants, Cafes, Historical Landmarks, Museums and Live Music. This is not achievable in a single iteration of the search and selection process using the current design.
Why did we call it "Huey"?
We decided to call the bot Huey as a nod to the company’s history.
The first pre-production Land Rover Series 1 is affectionately known as Huey because its registration plate is 'HUE 166’. Huey is often on display at the British Motor Museum in Gaydon, Warwickshire, UK.
Log in or sign up for Devpost to join the conversation.