MovieMaps

Design Development
  • Year
    2019
  • Timeframe
    4 weeks
  • Team
    Solo project
  • Goal
    Create a WB business concept for autonomous cars

The Problem

When I started at Warner Bros., our team had just wrapped a successful CES 2019 debut of a Batman-themed autonomous car experience in partnership with Intel and BMW Designworks. Eager to capitalize on that success but frustrated by delays with another project, my management team challenged me to pitch a new autonomous car experience that was feasible to implement in time for CES 2020, which was 10 months away. If I sold them on my idea, WB would in turn pitch the project to various automobile manufacturers as a CES 2020 collaboration proposal.

Given the breadth of the topic of autonomous cars, on my first day I simply explored and created a mind map of my experiences. I made only one assumption to start, that most users' first-time experience with an autonomous car would be through a rental or ride share agency like Uber or Lyft, as the average age of a car on the road in the US is about 11.5 years.

Knowing that my target audience would not be owners of autonomous cars, I wrote the words "travel consumer" on the top left of my page, and "entertainment consumer" on the bottom right, and I set out to find the intersection between the two markets by trying to answer the following questions:

  • What motivates people to travel?
  • What apps and workflows do people use to plan their travel today?
  • How can I deliver surprise and delight within a third-party autonomous car?



My day 1 Mind Map


The Market

In my searches on movies and travel, I was surprised to see that many passionate fans had created their own databases of filming locations from their favorite movies. Especially in cities where local governments had public records of film permits, there was a clear trend of fascination with fans wondering where their favorite movies and TV series were made:

Furthermore, it was clear that the film tourism market was underserved by the market offerings of the time. All of these fan-made location databases, while heroic efforts in themselves, didn't have nearly as much access to film location data as WB did, and many also lacked the design sensibilities of a mainstream app in 2019. I felt there was clear window of opportunity for WB to make a play in the film tourism market with autonomous cars, at least for the purposes of my CES prototype.


The Design

I pitched the concept to my management team at the end of Week 1: a ride-share service where users could hail "autonomously guided film tours" to see sights in their area that were used as locations in their favorite films. For instance, if you were an Entourage fan in Los Angeles (either because you lived in Los Angeles or were on vacation), you could book a customizable Entourage tour, as there are several Entourage locations to see in the LA area!

Knowing that our plan was to integrate with a third-party ride-share service down the line, I didn't focus on creating an original app design, but rather threw together some napkin-sketch wireframes of what I imagined would be a limited-time promotion offered natively within a third-party app. I mocked up a MovieMaps UI for our office, imagining an integration with Google Maps.



My MovieMaps wireframes after 6 hours, showing a hypothetical Google Maps integration


The Prototype

WB gave me the greenlight for 3 more weeks of work to verify the feasibility of the MovieMaps backend, for a total of four weeks on the project. I was excited at the possibilities, but I immediately had three problems:

  1. How would I get film loctation data for every WB property ever made?
  2. How would I derive latitude and longitude for all these locations, especially given dirty/inconsistent location data?
  3. How would I optimize search performance so that film locations are always sorted by proximity to the user?


Location Data

Given my limited timeframe, my team encouraged me to use publicly available location data for the mockup if possible. Limiting my application scope to films to keep scope manageable, I started with a list of all Warner Bros. films on Wikipedia. I wrote a script which queried IMDB for each of these films and scraped the film location data, and in five days I had my location data set redundantly saved in MongoDB and JSON files on disk as a backup.



Output directory structure of an early JSON data scrape using DC film titles


Deriving latitude and longitude

Unfortunately the IMDB location data set was dirty. Many location entries were just a single word, like "London", or an incomplete address with no state or zip code. After trying a couple address verification services, I settled on the Google Maps Places Search API because it was incredibly forgiving. If you type "London" into Google Maps, Google will give you coordinates for that! With that kind of flexibility, I was clear to proceed developing the prototype with my input data as-is.

That week I built a database table of locations indexed by IMDB input string, so that as new film location data came in, my system wouldn't incur the cost of calling the Google Maps API if I already knew the latitude and longitude of a given location. After adding a secondary call to the Google Place Details API, I could sort my entire data set by city, state, postal code, and other parameters, even if the original input string was only a single word!


Optimizing search

After reviewing lots of documentation and calling the talented team at Mapbox, it was clear to me that the last step of my prototype process was to generate GeoJSON data points based on my derived latitude and longitude. With GeoJSON data, I could use MongoDB's Geospatial Queries feature to automatically sort locations by proximity to a given user's point of interest, as well as generate some cool interactive map visualizations.

In my last week, I built a GeoJSON generator for my film locations database. As artifacts for my final presentation, I created visualizations of WB films from the past decade in the US, Europe, Australia, and New Zealand. Seeing the data visualized this way made it clear which cities were most viable to pilot the app, including Los Angeles, New York, and London.