July 2, 2011 at 4:01pm
App screen #4 – visualising bike data.
4:00pm
App screen #3 – user plays song.
3:56pm
App screen #2 – user sees bike-specific playlist, featuring songs played by previous riders of the same bike.
3:55pm
App screen #1 – user is selecting to play other people’s tracks.
3:54pm
App screen #1 – user is selecting to play his/her own music. The tracks played are recorded for future users to hear.
3:53pm
Our app, screen #1.
3:40pm
New, simple system!
3:40pm
Some more refining work…
2:48pm
Here’s our quick system diagram. The user is in the centre.
2:42pm
Working lunch
After a few more crazy but not-quite-implausible ideas (Mobile phones that use Near-Field Communication to exchange data with bikes? Bikes that play songs out of a handlebar-mounted speaker which is run from a pedal-powered generator?!), we decamped to the Peasant on St. John Street to excitedly discuss our project and our approach to the afternoon design session.
We decided to start the afternoon off with a system diagram, which would demonstrate the interactions between all of the elements of our service. This would allow us to decide which elements needed wireframing and where our user scenario(s) would start.
2:36pm
Team presentations
Each team took their turn to present their morning’s work to the room. There were some really varied approaches on display, from full-on UX geek-outs to plucking an idea out of the air and running with it. Our team’s approach was somewhere between the two.
Some great ideas on display too, including a collaborative never-ending song and a musical geocaching game for tube stations.
2:27pm
A breakthrough
Just before the first round of team presentations, we started to think about how music could play a part in the Barclays TFL bicycle hire scheme in London. The initial idea came from Team Jammers’ Patricia, who suggested that users could leave their musical listening data on the bike system, for future users to find. Playlists per bike and playlists per route.
2:24pm
Building on top of APIs
Mentor Hannah Donovan suggested that we could run with the contextual music sharing idea, but that building on top of the last.fm and Foursquare APIs would be beneficial. This would help us to use existing data and user generated content.
2:15pm
We then started to think about the opportunities that were available to us in these public spaces. We gravitated towards the idea of “context specific music sharing”.
2:12pm
Our challenge for the day was to “Design a service that allows people to play, listen and contribute to the music in public spaces and situations.” You can read the specifics on the Design Jam wiki.
Our initial brainstormimg session gave us lots of different contexts for interacting with music in social places. Jason Mesut, one of our mentors for the day, helped us to do some dot sticking to narrow down our focus onto parks and public spaces.
