#mixism and the
48 hour Hackathon
During the long weekend of 24–26 January 2015, Viren Ratan (@humanPincushion) and myself competed in the 2015 Static Showdown Hackathon to build a static web app called #mixism.
It was a weekend of minimal sleep and maximum work, plus a bunch of beer, music and fun times. Our app idea was born from an earlier idea that we had worked on a few times before, so we were able to approach the competition with a mostly resolved product design that just needed realisation and a working prototype to understand its potential.
Hackathons are great because of the great motivator of immediate deadlines and the incentive of prize winnings, not to mention a potential user-base to establish our product with and get feedback from. The Static Showdown hackathon managed to coincide with a long weekend holiday in Australia, so it was a perfect moment for us to finally put our ideas and skills to work.
The social playlist
We had a couple workshops late last year for an app idea that Viren had come up with about a social music playlist. The existing market for online music is so wide, varied, and fractured, the legal means to share and listen to music between people who use differing or multiple music platforms can add frustration. I myself use Rdio and Viren uses Spotify, two separate “walled gardens” of music, which for the most part share the same content. If I want to share a song or playlist with Viren, I’d have to do it via Spotify, or some other alternative (YouTube, SoundCloud) provided that one can find it available. Our solution: create a service which can act as a bridge between all these different platforms, for discovery and consumption.
A lot of the online world today is built upon what they class “cloud computing”. This means that the data and business logic for various platforms and services sit on many servers across the world, as opposed to being hosted and served from a single location. A lot of these services are international and have APIs (application programming interfaces) that savvy programmers can use to access the information stored within — you can create a product which doesn’t store any information but makes connections between other services.
Our idea leverages cloud computing conventions, by accessing publicly available data and media through existing APIs and protocols (such as oEmbed) we scrape social networks for hashtags and media URLs, then aggregate them into listenable playlists.
The design phase
The competition allowed us to plan out our project before we actually built anything. This was handy as we already had the existing idea and some planned features, however our original idea was a lot more involved and technically demanding. Doing the hackathon meant that we needed to reduce the product down to its MVP (minimum viable product) in order to focus on the core product feature-set and user journey, and to develop a product which can meet expectations and also work as a proof of concept.
I started out by writing a brief design document called an elevator pitch which outlined the the problem, the solution, intended demographic, and various other considerations that affect the product’s feasibility, design, and construction.
#mixism Elevator Pitch
1. The Problem
There are many different apps, services and platforms to consume music and video media through — some are walled gardens that restrict playback depending on paid subscriptions and device applications (Spotify, Rdio, etc.), others are open fields which allow free playback (SoundCloud, YouTube, etc.). Ironically all employ the feature to share media stored on their platform to social networks.
2. The Solution
#mixism is a web app/service that will allow users to aggregate media from various different platforms shared via social network posts into playlists. These playlists can then be played back using the #mixism service-agnostic* media player.
Sharing a piece of media to your social networks is performed by posting the URL to your feed. Aggregating this media into #mixism playlists is performed by including the hashtag #mixism and optionally any additional hashtags for further classification/categorisation.
#mixism then has a dedicated service-agnostic media player which accesses the various social networks (via API calls), detects any new or existing posts containing media URLs with the #mixism hashtag and collates the various platform-hosted tracks into playlists for standardised playback through the app (via API calls or the oEmbed protocol).
*service-agnostic would be only applicable for supported media platforms/services who have an accessible API that allow third-party playback, e.g. SoundCloud, YouTube, Rdio, Deezer, etc.
3. Intended Demographic
Technology-savvy people who use social networks (Facebook, Twitter, etc.) and consume audio/visual media through various online platforms (SoundCloud, YouTube, etc.) and devices (web browser, tablet, phone).
Characteristics
- Share media with their peers
- Converse with their peers online
- Follow media authors, or are media authors themselves
- Utilise a number of different free and paid online media platforms/services for media consumption
- Use hashtags to categorise their social network posts/media
4. 6 U’s
Urgency: Why the problem to solve is urgent to demographic
There is fragmentation with media discovery and consumption, further exacerbated by paid-subscription access. Also, people sharing and conversing to one social network are limited to that one audience set.
Unique: Why solution is unique
#mixism uses existing social networks and existing conventions (URLs & hashtags) to allow users to create, consume and share media with others across the world wide web. There is no sign-up process necessary as it leverages existing services for content posting, classification and aggregation.
The media player aims to be service-agnostic, as in one user could share content from multiple media service providers and the app will still have the means to access/play it.
Useful: Why solution is useful to demographic
Since people already accommodate sharing media throughout their online lives, #mixism seeks to conveniently package existing sharing behaviours into creating and organising users’ posts.
#mixism encourages keeping the conversation within the respective social networks as well as utilising multiple social networks for playlist collaboration between many users. A user on Twitter could contribute to a playlist that was started by a Facebook user, and vice versa.
By combining playback across multiple services into one app, #mixism seeks to reduce any friction users may encounter when trying to access media on differing or restrictive services.
Ultra-Specific: Remove ambiguity
#mixism is a content aggregator: through the usage of hashtag categorisation users can create, contribute to, and comment on social playlists via their existing social networks.
#mixism is a media player: through the usage of APIs and oEmbed protocols, service-agnostic playback of media can be possible.
#mixism is a media creator: by categorising social network posts and aggregating them into playlists, users can effectively create new media for themselves via their playlist compositions and encourage others to contribute and enjoy.
User Friendly: How it is easy/convenient for demographic to use and incorporate into their lives
#mixism utilises existing social network and internet features and conventions to add value. It requires no users to sign up as it uses existing information publicly available online. This reduces onboarding friction — there is no need to sign up to use it’s MVP.
Unquestionable Proof: Measurable evidence to support the above
There is currently no known way (that I know of) to create/view/consume media across a wide range of different media platforms from one touch point.
Often when an app or service does support multiple media services, it compartmentalises them into their respective services, rather than aggregating them all into a single point of access.
#mixism would be a unique solution to a problem that isn’t entirely obvious. It has the potential to fill a gap in the market that otherwise people may not realise exists.
In terms of potential return on investment (ROI), #mixism could be further developed into a more comprehensive media analytics service which could track playback and engagement across multiple media services, social networks, and target markets. It could allow content creators the means to assess through social media and the interactions with the media services how people are discussing, sharing and consuming content online.
Similarly, the principles of the social network scraping and content aggregation could be applied to other types of content for repackaging: news, photos, stories, goods, fashion, etc.
We also considered allowing users to veto tracks from particular playlists, but I thought it’d be more interesting to leave everything up to the public, for them to create their own meta systems of sharing and restricting. Since everything is based on social networks, it was an attempt to let people sort out any conflicts or issues via communicating over their social networks. I feel dialogue and rules being built within and between communities to be more effective and constructive than a complete system-imposed control.
The MVP
After laying out the elevator pitch we were able to identify the needs of our minimum viable product — a short checklist of features which form the core of the product and the experience. Since the hackathon was limited to 48 hours and there were some unknown factors that may blow out our build time, we planned a two-tier strategy: features that were absolutely necessary to operation (primary), and other optional features that would be nice to put in if we have the time (secondary).
The primary feature list:
- Promotional page to detail app and encourage users to participate (“on-boarding”)
- A media playlist viewer which supports searching and displaying Twitter posts that include SoundCloud URLs by specific hashtags
- View playlists by #hashtag
- View playlists by @mention
- View playlists by @mention and #hashtag
- View original social network post and user that referenced media URL
- A media player which supports playing the SoundCloud tracks that have been linked in the Twitter posts
- Play, pause track control
- Controls to skip to next or previous track within the playlist
- See current play position of track
- Navigate site while maintaining audio playback
The secondary feature list:
- Search and view playlists by multiple #hashtags and @mentions
- Support viewing and playback of content hosted on YouTube
- Support scraping Facebook posts for shared SoundCloud and YouTube links
- Show current position and duration of playlist
- Change volume
- View conversation (replies) to original social media post
The build
The competition’s rules allowed us to have some preliminary planning (the “napkin” rule) so we had our MVP mapped out above before we started. Viren also had a boilerplate stack that he’s been crafting for a while, tried and tested with his professional day job, so we had a reliable pipeline which involved node.js and gulp, plus CI (continuous integration) with git repositories, before we even had to code a single line. It was a well-oiled machine that didn’t squeak a peep. Even integrating with divshot (the creator of the competition) was almost seamless.
Viren handled all the business logic side, utilising AngularJS to act as the app’s framework. My role was in visual design and front-end styling. The team dynamic between us worked smooth and we collaborated easily with designs, code, jokes, food and beers.
One of the brilliant parts of digital project management is using agile software development techniques — this meant that we build to the need of the featureset, and also allowed for some measure of refactoring code if and when necessary. This allowed us to concentrate on delivering results and then dealing later with changing the underlying code structure if we really needed to. It alleviated the stress and anxiety by “delivering something that works now; redo it later if it breaks”.
We used a kanban board to manage our overall tasks and flow. This was really effective for letting us see where the project was at in relation to what we had to do. With minimal sleep and responsibilities stacking up, the kanban board allowed us to arrange priorities and order related tasks, to better concentrate on what we were doing then, and figure out later what to do next after we’d finished that particular task. It was a clean and efficient way to keep our heads above the water and it certainly managed our stress levels well (it was really quite minimal).
In terms of bumps along the way, we had some minor troubles dealing with the two external APIs we were utilising: Twitter and SoundCloud. Twitter has in the past been troublesome with some API issues, but for the most part we just outsourced interfacing with it by using the Codebird library, which I think worked well for the most part (you’ll have to ask Viren about that). There was one point in which the API wasn’t actually loading tweets and we thought we may have hit some kind of request cap, but it just happened to be a temporary ghost in the machine and it eventually passed.
My initial plan was to rely on the oEmbed protocol to get the necessary information for each piece of media to play, as it can be retrieved by regular AJAX requests and no need to sign up for an API key, however in order to support streaming playback we had to sign up to the SoundCloud API. There were some confusing moments trying to decipher the SC API (I had used it twice before on previous projects, but that had been some time ago), and once we realised that we didn’t need to worry about client-side authentication for streaming playback, we were off like a rocket.
There’s probably a lot of stories I’m missing on Viren’s side from the build since he held his own quite well. Aside from irks with the SoundCloud API (their documentation looks nice, but a little lacking) he was implementing features quick-smart and squashing bugs left, right, and centre. I was designing and front-end devving using SCSS and Foundation — two tools I hadn’t used before — and getting irritated by my lack of experience (I prefer LESS and I have used Bootstrap before), but eventually I managed to make peace with Foundation’s scaffolding system (I still don’t like it though).
We whipped up a pretty lean little MVP which scrapes Twitter posts for the #mixism hashtag, a SoundCloud URL, and any other hashtags used to classify. The whole time through we were excited and motivated to make something really neat, and I think we really achieved that. While we only supported one social network and one media platform, it was enough to illustrate the potential space to support more.
The review
We met at the formidable Two Row craft beer bar and exchanged our thoughts about our 48 hour efforts. We each had our own pros and cons, listed below in no particular order:
Pros
- Created a working prototype that did exactly what we intended it to do and illustrated the initial feasibility of such a product.
- It was our first project working together and we found that we both enjoyed the experience and that our skills worked well combined.
- The “Hang Loose” logo was a funny idea born from sleep deprivation. Even more genius was animating it and using it as a loading animation.
- #mixism’s usage leverages existing social media systems and conventions, so no-one has to sign up to start creating and listening. It also encourages sharing media to one’s social networks, so the media’s creators get further exposure out in the social network.
Cons
- Due to the frenetic nature of the 48 hour competition there were product design and code details that weren’t further developed and expanded upon in the planning process. We didn’t consider many (if any) user journeys, just our own anecdotal experience and desires for such a product. It was potentially too-specific a use case which inhibited some of the functionality as it was being built. This aspect would require more work should we take #mixism to the next phase (which we intend to do!).
- It probably was a bit limiting that the algorithm was restricted to only displaying posts which had the #mixism hashtag. Had we removed that minimum condition we would have had a larger sample set to test with and also a more accessible (and easier to use) product, that treated any hashtag by itself (i.e. not in conjunction with #mixism hashtag) as a playlist.
The summary
I feel that #mixism and the 48 hour Hackathon was a success. Viren and I set out to make a working prototype of our idea within a short span of time and we did it with a lot of enjoyment. I was really proud of what we produced, and it was great to finally collaborate code-wise with Viren on a project (something we had talked for a while but hadn’t yet done). Hell, I don’t even care about the competition results! I’m satisfied with our prototype, warts and all.
It was such a good feeling to have a plan and execute it. There were a few bumps along the way, but the overall vision of the product motivated us and to see it actually working as intended was such a rush. It was a huge delight to finally work with Viren as we both enjoy doing what we do and it fit together so well.
We’re looking at developing #mixism further under our team name Everything Is A Fractal, so if you’re interested in learning more about future #mixism updates, consider following @_eiaf on Twitter and also signing up to our #mixism newsletter.
