Ever heard of the traveling salesman problem? The idea is that given a list of cities, you must find the fastest route in which the salesman visits each city only once and returns back to the starting point. It seems simple enough when you think of the list containing three cities, or even four cities. But what if there were eight cities? Or ten? For ten cities there are over 360,000 different possible combinations. Where do you even start?
For our first MakerSquare hackathon, my group and I decided to try to solve this famous problem in 36 hours. Needless to say, it was much more complicated than we had expected. And unsurprisingly, we failed.
We wanted to create an app that would allow a user to set a starting point and any number of errands and we would return the most efficient route to complete the list of errands. We had dreams of user authentication so we could save favorite places and maps for each individual component of the trip and a lot of additional functionality. But it revolved around creating an algorithm that would sort the locations into the most efficient route. Ben, one of my group members, spent the entire first day of the hackathon building out a solution, but it wasn’t ready to deploy.
Luckily we had a backup plan in using Google Maps to do the algorithm for us. We used their developer-friendly API (Application Programming Interface- basically a back-end way to use a website’s capabilities without actually going to the website in your browser) and we got it all to work!
As disappointing as that may seem, we were actually incredibly excited to get the app up and running with the ability to input addresses and return an efficient route. Alex, our superstar design expert, had the site looking great and Lili, the API mastermind, got the requests together and parsed the data returned by Google into a format that we could present back to the user on the results page. Ben and I both jumped around a bit, troubleshooting as necessary and contributing where needed. We had accomplished the minimum viable product- it did the bare minimum of what it was supposed to do.
So we kept working. We added error messages if the user forgot to enter a name and and address, and included toggle functionality to choose between walking and driving directions. We incorporated the option to set a specific endpoint rather than always ending back at the start, and offered directions to the next location when you clicked on that location on the results page. And we got more and more excited about our product- it was pretty cool, even if we hadn’t solved the algorithm on our own.
There are a lot of features and functionality that we didn’t get to in our 36 hour time limit, but we were proud of the ‘final’ product that we presented. And I for one definitely plan to continue adding to it!
Here are some pictures of the main page for entering directions (top left), the main page with a list of errands already entered (top right) and the results page with the directions shown for the second location to the third (bottom left):
Oh yea, we called it EffErrands…for Errands Made Efficient. What else would we mean by that?