This project began when a classmate proposed an idea to me of music in the physical world. I had always been obsessed with physical computing the music technology, but this concept explored something philosophically different.
Context is defined as the circumstances that form the setting for an event, statement, or idea, and in terms of which it can be fully understood and assessed.
In the art of storytelling we always talk about how much “setting the stage” is important. Yet so much of our sharing on social computing platforms is done without any context whatso-ever.
The broad strokes goal of this project were to explore the validity of this argument through the implementation of social music facilitation service that Geolocks links.
I conducted a fair amount of user research to guide the design of the service. I’ve also done a lit review. During that process I’ve iterated a few UI’s, which have changed mostly due to that research and, in full disclosure, my currently skill and time limitations, as this is my first time doing any web development in any capacity.
I was able to derive some key findings that informed Insights that guided how I designed this UX and UI
This initial design featured a group timeline structure. This was before my research revealed the intimacy aspects of the social music process. Also its design was pretty rudimentary.
The second iteration focused on a very simple interface where individuals placed link. Here there was no sign up required and users could directly control how much or how little they shared their songs.
So to accomplish this, I’ve received a crash course in database design, server construction, and front-end programming. I’ve used python’s flask framework and have been modifying a existing html template to building the music service UI.
Unfortunately, because of time and skill limitations the UX design on this interface will not be the best, creating a really round-about experience.
Here is the logic of how this interface will work:
Users come to the website. In the form, they can enter a url. When they submit, a code will be generated, and their location will be recorded. The code will be displayed and also sent to the database along with the lat and long coordinates. Users can then share the code with friends and tell them where they need to be to use the code. When at the location, the use can plug the code they received in. The interface will then receive the song from the database, but will check if the location matches the stored location before displaying the official song url.
So without further ado, here is the Leaf UI that I deployed for initial user testing and feedback. You can use it yourself. Just go to:
https://pericthompson.pythonanywhere.com
My main method of research was a qualitative inquiry that had participants use the webpage in their normal contexts.
Participants generally followed normal sharing patterns. People would either share when they came across something that they liked, or they would share when they came across something they thought they liked. One participant did say this tool started making transition to thinking about what the person they would be sharing with would like to listen to at that location. For instance, in TSRB, where people are sitting and working for longer periods of time, the participant shared longer format music mixes.
On the receiving end, I hypothesized that adding geocontext would make receiving shared song more powerful for two reasons. Mainly, I thought adding geocontext would increase empathy, allowing users to step closer in the world and mindset of the person who shared it with them. The second reason is that preventing knowledge of what the song was prior to being in the exact context added a mystery component, which would promote users to more likely open a link when they could. With regards to the first hypothesis, that has been partially confirmed, with individuals saying that they were able to step into the mindset of the person who sent it, or at least attempted to. The second hypothesis of their being additional motivation due to the geo-locking was confirmed.
On the receiving end, I hypothesized that adding geocontext would make receiving shared song more powerful for two reasons. Mainly, I thought adding geocontext would increase empathy, allowing users to step closer in the world and mindset of the person who shared it with them. The second reason is that preventing knowledge of what the song was prior to being in the exact context added a mystery component, which would promote users to more likely open a link when they could. With regards to the first hypothesis, that has been partially confirmed, with individuals saying that they were able to step into the mindset of the person who sent it, or at least attempted to. The second hypothesis of their being additional motivation due to the geo-locking was confirmed.
What I Building the tool took longer and was more arduous than anticipated. There might have been more lo-fi ways to test this hypothesis. Building really squeezed my research planning
Even with the inclusion of social media, they haven’t dramatically changed. I suspect that sharing habits at the core of sharing things like music haven’t changed since the days of 8tracks and records.
When trying to create the most value in context sharing, emotional context must be considered. A person you are sharing with may be in the same place, doing the same activity, and even have the same taste as you, but if their mindset doesn’t match yours, the rest may not matter at all.
Next steps will be to continue to gather research on the existing UI and to try design feedback on screens I'm working on for possible facebook messenger integration
