DivvySnaps is an event finding service built around a bike-sharing system, in this case, Divvy, in Chicago. DivvySnaps provides a way to learn about interesting events or sights and be guided to them by bike. It connects you to new neighborhoods by encouraging exploration beyond your own.
Divvy is the Chicago bike sharing program. People can rent a bike for short trips and can return the bike to any of 300 stations.
DivvySnaps is an event finding service built around the Divvy bike sharing system. It connects people to events. First collecting and curating lists of events, then directing people to their events through interactions with the bike. The bike becomes an intermediary between people and their neighborhoods. Knowledge of neighborhoods is stored in the bike.
DivvySnaps promotes cross-neighborhood exploration, by fostering pride in your own neighborhood and creating curiosity in nearby neighborhoods. Each bike belongs to and knows a neighborhood, with limited knowledge of events in other neighborhoods. It learns about new sights and events together with you.
Find new events through the collected events on the DivvySnaps website. Mark events of interest to possibly check out later.
At the station, rent a bike with your membership fob. The bike comes alive with the colors of your neighborhood. Or choose another neighborhood to represent.
With the app, choose the event you want to attend. The bike will guide you.
On the street, the bike directs you with a simple display. When you come near other events or sights that you might like, the bike alerts you.
Your neighborhood bike knows you, so it doesn't recommend sights you've seen, and does find sights you like.
The bike has some new features. When the bike is activated, it changes colors. The body of the bike has display materials that allow it to produce different colors. Each neighborhood has its own color scheme -- a regalia to identify it.
In addition, there is a navigation interface on the handlebars. The piece is used for both navigation and alerts. It is an e-ink display with one color in addition to black and white. When an event is chosen, the bike guides you though a simple interface. It displays the streets and the direction to go.
If, when riding, the bike and rider pass by a new or interesting event or sight, the display will alert.
There is never too much information displayed. When more information is needed, the display will create a pattern that can be scanned by the rider. But only when not in motion. More information can then be read on the rider's smartphone.
Each neighborhood has a unique style of display, and a unique mandala as the pattern behind. The mandala changes (for different messages, for different neighborhoods) while the message box is standard.
Riders can add their own sights or events to the system by taking a photograph and uploading a description. The information about that sight is learned by the bike, so that it can show it to other riders. But it is only remembered by the type of bike that the rider is riding when she uploaded the sight. So the knowledge stays local to that neighborhood.
To understand the value of the system, it is helpful to break it apart and discuss the interactions between components.
Of course every person associates with a particular neighborhood. It is a way of identifying ourselves. But in the case of DivvySnaps a person is a person. They have unique traits such as where they have ridden, where they prefer to go, and what sights they have seen on the way. But the system does not assign them a neighborhood. They may however have a particular Divvy station that they prefer. And this station does have a neighborhood.
Every bike checked out from a neighborhood's station becomes a bike of that neighborhood. This means that the bike will display the colors of that neighborhood. In addition, it will act like a bike of that neighborhood. Acting like a Bucktown bike, for example, means that the shared knowledge of all Bucktown bikes - where the sights are that people tagged, and your interactions when on a Bucktown bike - is loaded on that bike.
But nota bene: a Bucktown bike knows only what a Bucktown bike has learned. If you check out a Lakeview bike for your trip home, it will show you the sights that a Lakeview bike knows. And might show you sights that a Bucktown bike has already shown you.
Over time a neighborhood bike builds up a knowledge base on the neighborhood. The bike knows what events are happening in the neighborhood and what sights to see. It also becomes a voice for that neighborhood.
One motivation I had for creating this system is this visualization (see sidebar). Using data from the Divvy system, it maps the rides of Divvy users. The main thing that I notice when looking at this graphic is that Divvys are typically being used for between individual neighborhood and the Loop (Chicago's downtown). The resulting visualization is a hub and spoke image.
I wondered if it would be possible to encourage neighborhood to neighborhood travel. That is, around the rim instead of down the spoke of the visualized wheel. The value of this stemmed from another research project that I was working on simultaneously - how to improve the new Divvy system.
The class, Prototyping Interactions, is about rapidly prototyping for ideation, communication, and testing. The purpose is to understand that prototyping is valuable at all stages, and that there are many types of prototypes.
The direction of this semester's class was Chicago and wayfinding. Knowing that I wanted to build something around Divvy, I began by exploring sharing, or what is sometimes called "the sharing economy." I began with a game. I was curious about the experience of taking a device with you from place to place. Divvy is like public transportation, but instead of getting in a vehicle with others, you take your a vehicle and use it personally. I wanted to explore how people feel about and use a personal shared device. And more specifically, if they would trust it.
My first prototype was a game that explored personality of devices. Participants each selected a guide, without much information to base their decision, and then solved a puzzle with the help of the guide. Each guide led to a different destination, with a different prize. Players then repeated the game on a "return trip." In a follow-up questionnaire I asked about the participant's expectations about their guide and their feelings about their destination/prize.
I continued this exploration with a second prototype game, Buses and Bikelanes, based on the game Dungeons and Dragons. In Buses and Bikelanes participants chose a mission and then could choose either a ride (bike) or guide to help with complete that mission. Each ride had different "abilities": rankings of speed, comfort, etc. The abilities of each ride were initially withheld from the participant. They had to choose only based on the image. If they chose a guide, the guide simply choose their ride.
Participants played on an open map - a blank sheet of paper. Only I knew that the map was loosely based on the grid of Chicago. Play was limited only by our imaginations. By rolling a 20-sided die the players could travel through the streets. Along the way they encountered obstacles or digressions. The bike would offer suggestions on the route taken and stops made. They player could choose to follow the bike's advice or trust their own instinct.
From this exploration I learned a great deal about my participant's expectations of different bike personalities, and more importantly, about their level of trust in a bike guide. Some players listened to their bike and stopped frequently. Others wanted their bike to only act like a bike.
My initial concept was a guiding system built into the station. A user interacts with with a kiosk to find events. The interaction informed by the choice of bike.
After feedback, I moved the interaction to the bike. From here I refined the system - event finding plus bike sharing - and interaction. I struggled to include wayfinding without turning the interaction into a navigation system. The insight that led me to my final concept was a horse metaphor.
The sleepy farmer can fall asleep on his way back from the dance and still make it home, because his horse knows the way. With a bike you might still have to pedal (so no sleeping), but it can still know the way. And if you could communicate with it, then you could have it lead you to other places as well.
From here I went through many interactions of that communication. There are many levels of communication happening in the final concept. There is a website, for event finding, but I did not elaborate on it; it is just a standard event finding site. The bike, displaying the colors of the neighborhood, communicates to the community. The bike communicates to the user - both directions and suggestions. And the user must also be able to communicate to the bike. For this last part, I added the mandala.
The bike communicates with the puck - an e-ink display. The bike interacts with the rider by displaying a mandala. Like a QR the mandala can be scanned by smart phone. In this manner the user can get more and more detailed information about an event. This is also how a user adds content to the system. They can photograph and tag sites and link them by scanning the mandala on the puck.
I went through a series of iterations on the puck display and phone app. Starting with paper prototypes, of the puck and moving into working prototypes. I tested each revision with users to improve the logic and use.
Early interface design
For the final presentation I brought in a divvy bike and lead the audience on a journey. A working puck mock-up displayed on the bike lead a volunteer on a trip from Old Town to the Bucktown Apple Pie Festival. The ride was projected on the screen. Her phone ran the DivvySnaps app prototype. Along the way she stopped at interesting sights and even recorded her own.