Walkability

As a group, we find walkability incredibly compelling.  We all want to live in walkable cities where there is strong street life, car ownership is unnecessary, and bikes are everywhere.  Before this project, we all intuitively knew when we felt good in a city, but we didn’t really know why.  It turns out that there is a term for this; its walkability.  CIties that are designed around the car are vastly less compelling than those in which cars are secondary to pedestrians and cyclists.

Not surprisingly, cities that feel better to be in are more vibrant, sustainable, and economically sound.  Higher walkability increases sales for local merchants, it keeps money local instead of sending it to middle eastern princes, and it also has HUGE sustainability benefits.  Walkability is the single most important factor in sustainable living.  People drive less, sit in traffic less, are happier, and healthier.

With all these benefits, it is surprising that more american cities aren’t making walkability a priority.  Unfortunately many of the changes that have the best results are a bit counterintuitive and so are hard to get public support, yet once these changes have been made, residents will enjoy the impact they have on the city.

The evolution of the Hardware component

After our group decided to make a camera system to go on a bike, the system went through many different configurations before we arrived at the modular sensor unit we eventually arrived at.  We came up with some configurations that had the sensors distributed around the bike, and each sensor was a separate entity, some used the camera and gyros/accelerometers in the users phone, etc.,   Here we will go through the major paradigms we moved through.  We prototyped many form factors for each configuration yet the thinking behind each design remained the same, and that thinking is the focus of this post.

 

The first configuration of the camera system was designed around leveraging the technology packed into a smartphone.  The idea was that many people have smartphones, and they have paid a good amount of money to own them  so it would be awesome to utilize the the touchscreen, gyro/accelerometers, and HD camera built into their phone.  We decided to make a mount that held the users phone on the handlebars so that the user could interact with the smartphone while riding.  The case also has a prism so that the camera, which points down, records the road ahead instead of the ground.  We also designed a small camera that mounts to the back of the bike to record vehicles behind the rider.

After making this model, we took it out to get feedback from cyclists.  Many people responded positively to the features yet they were all worried about putting their expensive phones on their bike handlebars.  We realized we would need to make a weatherproof case.  This would get quite bulky and we also realized that the case would need to be specific to each smartphone which would mean that one would need to buy a new case every time a one got a new phone.  This made us realize that tying the system to a phone would make the hardware obsolete quite fast.  We decided that the hardware needs to be a separate component.

 

Our next design was made up of two sensor units that then stream to a smartphone.  As we worked on the forms, we played with adding a small screen to the front unit to surface information to the rider.  We played around with what information to show and and how big the screen needed to be.  The issue with adding a screen is that it starts to become expensive and starts to stray away from the intent of the product.  Then we started considering adding lights to the system, but we were wary trying to pack too many features into a product and not just doing one thing well.  This led us to our next concept which was a modular system.

 

The modular system concept revolved around the idea that different people want different features.  For example, if a cyclist already had really good lights, they wouldn’t want a light built into this product.  To solve this problem we envisioned a modular system where you could clip together a camera pod with a battery pod, and a light pod, or just have a battery with a camera, or two batteries with a camera for extra battery life.  We were really excited about this idea until we realized that there were some things that we could do much better if we integrated all of the essentials.  Also it was through the process of discussing and designing the modular pods that we were able to distill the system down to its essential components.  By designing each pod, we started to realize what they could do in conjunction and decided to simply combine the needed components into one product.

 

We started to design a set of sensor units that contained lights, cameras, accelerometers, and laser range finders.  Through the combination of these technologies were were able to support and deliver all of the essential features of our biking product to the user.  We began by designing one front unit for the handlebars, and one rear unit for the seat post.  Each had the same tech inside, but were different because thats how bike lights are currently, and we never questioned it.  Well we did now, and we realized that there were advantages to making one sensor unit that could mount front or back, on a helmet or anywhere else.  It was at this point in the project that we arrived at our current design.

UX update

A lot of updates have been made to the UX design, below is the old UX design.

Screen Shot 2015-04-15 at 6.24.04 PM

The old design was centered around a home dashboard which featured relevant information about relative traffic/road safety conditions and weather conditions. This information is very context dependent and didn’t make much sense when presented in a chart format. We found it would be more effective if this information was integrated into the map/navigation screen.

This also allows the user to take in more information at once without needing to navigate through screen states. In the new design. The app is centered around the navigation screen. The map is layered with information about individual street safety and includes alerts for inclement weather.

 

 

 

Screen Shot 2015-04-20 at 2.42.55 PM

Screen Shot 2015-04-20 at 2.43.04 PM

Screen Shot 2015-04-20 at 2.43.09 PM

From within the navigation screen, users can also access their alerts/recorded trips, realtime ride statistics and all time ride statistics. The map can be used as a traditional navigation system (with an end address entered) or as a reference for the rider to make decisions about their route.

Screen Shot 2015-04-20 at 1.57.15 PM Screen Shot 2015-04-20 at 1.58.16 PM

One of the major roadblocks in creating the UX experience was finding a color pallet that could provide users with at-a-glance information about road safety without being offensive. As well as compliment the google maps color pallet and integrate into the rest of the app interface. Originally we had a burgundy color pallet however this create a lot of conflict within the map state. Where red was meant to symbolize something dangerous or bad.

In the end we opted to treat the road safety information as an overlay on the google map. The map is pulled into the app and given a grey tone filter. Leaving the user with enough information to navigate without competing with the safety overlay. The safety overlay is based on the traditional red, orange, green road color paradigm. This red = bad green = good system is carried though out the app. colored icons indicate actionable items. green indicates go/accept and red indicates alert/exit/cancel.

 

 

 

 

 

 

Overview of Project Direction

We began our research looking at the work of urban planners including, Jeff Speck. Author of, Walkable City: How downtown can save america one step at a time. They conclude that Walkable cities are better. They’re more livable, healthy, happier and, more attractive to young professionals. They’re a city people want to live in. Included in walkability is bikeability.

Looking at Pittsburgh as a case study, commuters are traveling farther than is practical to walk. Biking would be a viable alternative to driving. However in our research we found that 50% of people don’t bike because they feel unsafe riding in the same lanes as cars.

Based on this information we started to explore redesigning transportation infrastructure. Throughout this process we came to find many proposals for alternate transportation infrastructures, however these solutions have hardly been implemented.

We found this surprising so we spoke to local bike advocacy groups who are lobbying for this infrastructure change. we came to realize it isn’t a shortage of compelling designs or public interest but rather, a lack of data. When these advocacy groups go to make their case to city officials they’re required to have hard facts to back up their requests.

One example they brought up in our meeting, was when they were requesting a bike lane on a road in North Side. The city claimed not enough people biked there to justify the expense. So the advocacy group’s solution was to have someone stand on the street corner and count bikes. This wildly inefficient and doesn’t consider the bigger picture. Was that the right road to place lane on? does it have the the maximum effect on the bike community? and will it make sense in the long run?

We designed a system that empowers the existing biking community to gather data to effect change. the system is composed of a bike mounted sensor unit that collects data about the users’ ride and sends it to a mobile application.

The bike unit is equipped with an HD wide-angle camera, a laser range finder, high visibility LED lights, an accelerometer, and a hazard maker button. The camera captures video during a ride to be used in the event of a hit and run or close call. In conjunction with the accelerometer it also records potholes and other obstructions. The laser range finder detects motion in the surrounding area and will flag video of cars that pass too closely. The hazard button is used to flag points in the video the rider wishes to view later. LED lights are used to increase road visibility, illuminate vehicle license plates for the video and flash to alert drivers if they drive to closely.

Data from the bike units on all cyclist with the system is aggregated in the mobile app. It surfaces actionable information to the user. The app is centered around a biking specific navigation system and includes features such as, heath and performance metrics, inclement weather alerts, quantitative road safety ratings, and access to your most recent ride footage which automatically flags important moments.

Unlike existing nav systems which only consider elevation, this system takes into account road quality, elevation, speed to destination, and more importantly, a more quantitative safety rating of each road from the point of view for cyclist to help plan your route.

Updating on the form and model side

We are right now in the process of finishing up our final model. We were lucky enough to use the Objet SLA printer in the chemical engineering lab and we just got our finished print. All of last week, Danny and Uriel spent CADing every part of the model for not only the purpose of 3D printing, but also to make multiple renderings of different states and color options. While we 3D printed, we have began looking at ways this product could be mass-produced and researched a way to injection-mold most of the component.

This week, we have been cleaning up the model and machining parts for it. Today we made springs and put them into the quick release clip, went out to buy special primer that would adhere to the polypropylene, and began applying coats to the model.

Cam_Render_05

Cam_Render_04

Cam_Render_06

Prototyping

From engaging in a make tool study, talking to cyclists, and knowing what kind of device we would want to cycle with, our group has entered the prototyping phase of this project; while concurrently working out the interface to pair with the artifact. We first began with the intent to make our cycling cameras pair with a phone, and use the phone as a dashboard that sat on the users handlebars. Since this ideation, and with consideration to the feedback we have been provided with, we have pivoted slightly to having the system pair with bluetooth enabled smartphones, but not have the phone sit on the handlebars anymore.

Currently, we are working out the specifics to what the form will look like without the smartphone being part of the physical artifact.

IMG_4543 IMG_6821 IMG_7056 IMG_7103 IMG_7711

Making a thing

After talking to professors and members in the community, we decided to go in the direction of making a bike camera system that mounts to a bike with an accompanying application. This week we have been busy generating iterations of the form language for the camera system, concurrently working on make tools and the UI for the application.

Preliminary_Sketches_Bike_CamIMG_2030

UI Wireframes   Make tool Bike

Conducted make tool interview with 3 users to test use scenarios and features for hardware and software.

 

IMG_3622IMG_3620

IMG_3623

With these preliminary models we sought to get a sense of good size and shape of our product as well as exploring different form language. We are going to continue prototyping in clay to further refine our form language.