For thesis projects at SVA IXD we were asked to create something that contributed to the field of interaction design. I came in with a plan for what I called "Google Maps but for foot traffic." In short, I wanted to figure out how to use technology to accurately predict and also monitor in real time the ebbs and flows of stores, cafes, bars, and transportation hubs. I was planning to get deeply involved with data visualization as well as coding, so I asked Nicholas Felton to be my thesis advisor. Luckily for me he said yes.
After some time thinking through the functionality that I would need, I decided to get into sketching. The progression of my visual thinking for that concept can be seen below.
In the wireframes above, the red line is the current time, and the blue line / section represents the estimated foot traffic at the location. The idea was that the dotted blue line represented a "comfortable" range, with anything over it veering into uncomfortably crowded or excessive wait times. There is also the option to change the timeframe above.
After a number of presentations and in-class discussions, I soon realized how challenging it would be to build a working prototype for such a system and test it before the end of the semester and decided to pivot to a different idea. However, it's worth noting that just a few months later Google came out with the exact same functionality. Seen below is my original mockup on the left, and the current Google implementation on the right. I was really happy to see that my idea was sound and that it was technically possible, albeit only with access to the huge amount of data from Google Maps location services.
I scrapped the foot traffic idea, but underlying all of it was the following motivation: I knew that data was being generated but not used to its full capacity. I decided to focus on recommendation engines because I think that while they're present in many of the services we use today (Google, Netflix, and Amazon among them) they can feel opaque and impersonal.
Once I knew my final direction for thesis, I set out to build a system that would allow people to add the things that they like, without having to worry about companies or brands marketing to them, in order to get better and more targeted recommendations based on real people like them. I also wanted to build something that people around the world could really interact with, instead of just a glossy clickable prototype with no back-end logic.
Below are a few examples of my thinking around networks and individual users. I was trying to visualize the way that people's favorite things could be related to one another.
In the end, I decided to focus on something that I loved (music). In essence, the goal of LikeMine was as follows:
Once I had clarified my thinking around how the system could work, I needed to start coding. After a few dead-ends, I chose Meteor. It's a JavaScript framework with robust backend connections, security, and easy deployment. I also saw that thanks to the strong documentation and tutorials it would be easier to learn. As they say, "Meteor’s mission is to empower everyone to write software." I figured it would be a good option for a designer who had only dabbled in code.
After quite a lot of time spent learning the ins and outs of Meteor, I had a live website with users, passwords, and a database, but I needed to figure out how to run live queries within the database to achieve the functionality that I hoped for. Below is the first iteration of that site. In the top window is a simple call-to-action and a bit of how-to copy. The second screen seen below is an example of the straight MongoDB results that came back. However, at the time the functionality wasn't working correctly.
With a lot more work and a bit of help from a tech advisor, I was able to put the query together, and my thesis project was running as I'd hoped it would. Soon after I launched the site using the Modulus framework at www.likemine.io and started telling my friends about it. Everything worked as I'd hoped, and after just a few days more than 40 people had used it and had submitted over 600 band names.
Below is an example of the final UI, with the custom form design above and the results below. I was able to integrate Spotify API's search functionality and also in-line previews of each artist's top music.
I also made sure that the site was scalable for mobile users by including Twitter Bootstrap breakpoints.
This project was the most ambitious thing that I've ever conceived of and then built. In the beginning I grew quite frustrated by the relative slowness of my progress with code. However, as I got more deeply invested in the Meteor framework, I began to take a kind of a perverse joy in my dozens of attempts at working past roadblocks in the code. There was something very liberating in the awareness that I was wrestling with a challenge that was (for a long time) bigger and thornier than I was equipped to handle.
Every time that I solved something in the code I felt validated and euphoric. Every time I was able to reduce the number of lines I felt lighter and more efficient. I began to understand the joy that developers get in neat, clean, and elegant code. I believe that this awareness will be valuable going forward.
In addition to creating and testing the core idea, I had to build the webapp and then present all of it via a "Process Book" website and an 8-minute presentation for an audience of peers. That video is linked below.