7. Wireframes and Titles

First I'll start off with this interesting video of a contact-less dynamo light. I think technology like this would be perfect for the bike mounted beacons.




After producing 3 scenarios worth of drawn wireframes, the system seems to be taking shape. Morals are up to say the least.

Before I started sketching, I did review the previously proposed scenarios, back when I was considering  the personas. It seemed some condensing could be done, and there wasn't a previous scenario from the perspective of a Department of Transportation worker using the system. This sparked some interesting dialogue in the group critique from my peers and professor as well. So a new question has come to mind, not so much a new design question, but one that must be considered when moving forward with the new scenarios.

"In the communication and interaction between Kansas City cyclists and the Department of Transportation, where is the line of power drawn?"

It shouldn't be a negotiation on the part of the cyclists. So previously, as seen in the 3rd scenario proposed at the group critique, the DoT users have been in a sort of moderator position in the system. They acted as a special user with a different interface to post responses to safety issues that are uploaded by the cyclists. But this system seems really round a bout, and could be streamlined my simply minimizing the interaction between cyclists and DoT users.

So moving forward, I'll be looking at shortening 3 scenarios into 2. This will give me more time for design decisions and visual identity and navigation of the system. It should also create more engaging and dense scenarios for the viewers of my presentation.

Scenario #1: User tracks his route, uploads a safety hazard, and views a proposal for a lane on that road.

• User starts the app, immediately tracks route without having to enter the application   fully. 
• Rides his route.
• Turns off the tracking, and views his route he just rode visualized on a map.
• Is prompted to post any safety issues he encountered on the way. He did and does.
• Types the safety issue in the form of a sort of comment. Posts it.
• Other cyclists can now view this safety issue in the street viewer.
• The safety issue is shown as an icon on the route where he placed it, but it has a notification over it, or urges him to enter the safety icon.
• He enters it and sees that the safety count for that road has been reached with his newest safety hazard, and it is automatically scheduled for bike lanes to be installed. The page shows the estimated time till completion, and it's current construction status.
• The previous icon changes from a traffic cone to a bike lane icon, so the bike community knows that lanes are being put there.

Scenario #2: User receives a recommended route, rates it, and saves it.

• User enters the route section of the application, showing all of his routes previously travelled. He touches one to focus on riding, and the application zooms in to that route.
• When he taps the route to start his ride, a notification pops up with the traffic cone icon (signifying a safety notification). It says there is a route that is safer for him to take, and has been recommended by other users that rated the route fairly high. He touches the "try it" option.
• He rides the route.
• At the end of the route, it asks if there were any safety issues. He says no, and is presented with the options to rate and save the route.
• He rates and saves the route, and is taken to his routes page again, updated with the new route. The old one is still there if he still wants to ride it at another time.
• He then navigates to the city/ map section of the application. 
• He touches the view tab at the side of the screen and it expands with viewing options.
• He chooses the safety option, and the tab hides the options again. The map shows any safety issues posted by other users around him.
• He touches the video icon, which activates his camera.
• Using augmented reality,  he can see the safety icons in the environment, exactly where they were plotted by other cyclists.
• He touches one after looking around him, and it expands to show the comment as posted. It also shows the safety rating of that street. 

Moving forward, I'm also considering a few titles for the system. Some contain double meanings, and I'm most interested in those with a cyclist meaning, and a meaning pertaining to the system:

1. Portage: Portage is a term used by cyclists to refer to the carrying of their bicycle over their shoulder. It's a common occurrence in the city, and is used widely in bike commuting from place to place. It is a term unifying bike and cyclist, and represents perseverance. 
2. Tread: Is one of my favorite choices thus far. It refers to the rubber pattern or texture over the surface of a bike tire, as well as the mark it can leave behind in the bikes wake. So in this way, it shows where the biker has been; a route. So there is some interesting language that could be carried into the tracking application.
3. Cog: A cog is a gear responsible for propelling the bike forward when the pedals are moved. It's the center of motion for the bike. So cog could refer to the application as the center for bike movement around the city.
4. Route: Simple enough, but doesn't really have extra meanings.
5. The Hub: My second favorite of the options. A hub is the center of a bike wheel, but also has roots in design as the center of an online system that links together multiple platforms or elements. 
6. Brain: Brain is a cyclist term for a bike mounted computer, like a gps unit. 

6. Mapping it out

After the most recent presentation to the class, I've decided to focus on using the first solution. So from today onward, my system will include designs for the bike beacons, and an iphone application with different views between cyclists and Department of Transportation users. Here's that system as a reminder.

It will use beacons and a smartphone application to track routes. The routes will be sent to a satellite and collected back in the application. Department of Transportation users can then log in and view that mapped information around the city for safety adjustments.

To better structure my progress and my understanding of how the system and application will work, I've started a rough application map. This way I can visually see the links between navigation and different parts of the system.

The believe that application should first start with the option to immediately track your route or to continue to the home map screen. Cyclists that are in a hurry to start their commute shouldn't have to navigate though an application when they are in a time crunch to get somewhere. So with a simple tap on that screen option, they should be able to start their ride right away. Should the user decide to continue into the application, they will be greeted with a map of their surrounding area.

There will be three main icons to continue to the next level into the application. The first one will pertain to the map, and contain a variety of sorting options to view the map including: time, area, bike lanes, and roads. Time will sort the viewed map by time of day, week, month, or year and display the number of riders on those roads accordingly. This is particularly useful for Department of Transportation users to monitor cyclist activity around Kansas City. Area will adjust the map to the local area around the user, an area of so many miles around the user, parts of town, or the entirety of Kansas City. Bike lanes will be a safety section, letting users see not only where bike lanes exist around the city, but where DoT is putting new ones in. Finally, the roads option will let the user filter the map to show only major or minor roads, or both at once.

The second icon will be the tracking icon. This will be the manual option, usable perhaps to the cyclist already in the application or for users who missed the option at the starting screen. It lets the user turn on the gps route tracking at the beginning of their route, and then turn it off at the end. The user is then taken to the route they finished displayed on the map without any other information from other users. Once the route is complete the user might get a notification, asking them if they encountered any dangerous areas or hazardous obstructions along they way. The user could continue if their ride was fine, or input the safety issue for DoT to view. For those that continue, it will take them directly to the next icon, which can also be entered on the home screen.

The third icon will be for the user's routes. By touching this icon, the user will enter their route map, able to view any route they've logged into the site. These can be viewed all at once on a map, or arranged by date and area. Date will be the default sorting state, but the area option would bring up routes closest to the user's current location. The map view would show the same route ridden many times in the form of density. Perhaps using color.  The user could also touch another option to the side, containing routes recommended to the user via DoT. These routes might be safer than their current route, or new routes that they have ridden that have recieved safety changes. 

5. The Workload + Personas and Scenarios

·       F 2/10: Blog Post, First round of personas and scenarios. Have reviewed/ critiqued.

·       M 2/13: Final proposed personas and scenarios. Have system chosen, and list of design artifacts required for that system.

·       F 2/17: Blog Post, Drawn wireframes for Scenarios 1 and part of 2. Have reviewed/ critiqued.

·       M 2/20: Finalized drawn wireframes for small group critique.

·       F 2/24: Blog Post, Possibilities for visual design.

·       M 2/27: More visual design, mocked up from wireframe layouts. Small group critiques.

·       F 3/2: Blog Post, Prepare Midterm Presentation of progress and system elements designed.

·       M 3/5: Midterm Presentation of progress and system elements designed.

·       F 3/9: Blog Post, More visual design possibilities. Have reviewed/ critiqued.

·       M 3/12: Spring Break- Begin designing screens for scenarios. (Work when able)

·       F 3/16: Spring Break-  Continue designing screens for scenarios. (Work when able)

·       M 3/19: Finalized visual design. Have reviewed/ critiqued.

·       F 3/23: Blog Post, Have screens reviewed/ critiqued.

·       M 3/26: Revise screens and begin animating in After Effects, write script for audio. 

·       F 3/30: Blog Post, Show finalized screen designs. Show Animations in progress.

·       M 4/2: Continue animating, have audio recorded.

·       F 4/6: Finish up animating, assemble audio and video elements.

·       M 4/9: 1^st draft of formal presentation. Refine presentation.

·       F 4/13: Blog post, Refine presentation. Begin practicing the presentation for final audience.

·       M 4/16: 2^nd draft of formal presentation. Refine presentation and presentation skills.

·       F 4/20: Blog post, Refine presentation.

·       M 4/23: Formal presentation day! Dress nicely, and have presentation prepared.

·       F 4/27: Blog post, Last day of class- process pdf and artifact documentation accepted. Final deadline is 5/7. 

I've also made my first round of personas to work with. I tried to cover a wide variety of options between the 3 of them to show a ton of different viewpoints and uses for the system. 

Persona #1: Paul (24)
Location: Overland Park, KS
Profession: Part time student
Reason for cycling: Practicality, Cost effectiveness
Bike type: Mountain bike (Used to conquer hills around college campus.)


Paul goes to college part time for business courses. His home is only a 10 minute distance from the campus, so to save
time and money on gas, he prefers to ride a bicycle to his classes. In the mornings, rush hour he fights with determined drivers racing to work, and is often late to class, unable to cross some intersections. The main streets around campus still don’t have bike lanes, and his complaints to the school faculty and student body can’t seem to get through the yellow tape the city places between cyclists and road safety measures.

Persona #2: Scott (36)
Location: Downtown Kansas City, MO
Profession: Works full time at local music hall
Reason for cycling: Exercise and recreation
Bike type: Road bike


Scott rides each night after work to burn off calories and to distress. He meets regularly with friends to ride around t hecity, and he actively participates in Critical Mass and other cycling awareness events. Having ridden on many bike lanes throughout Kansas City, Scott writes the department of transportation and reaches out to other bike riders to advocate for additional lanes and better driver/ cyclist interaction on the roads.

Persona #3: Amanda (29)
Location: Shawnee Mission, KS
Profession: Full time mom
Reason for cycling: Family activity
Bike type: Cruiser


Amanda spends each day with her son (age 6) and daughter (age 5). She strives to keep her children active and encourages them to spend time outside. When riding their bikes, the children stay within the neighborhood, but the family enjoys group rides in the evening to a local park. Without bike paths, the family has to ride their bikes along a busy street. Without bike lanes, the parents fear for their children’s safety.








With persona's in mind, I've constructed my first set of possible scenarios to animate in the final presentation as well. Each scenario at this point revolves around each of the 3 people, and tries to cover a different side or area of the system. 

Scenario #1: Scott wants to track his route at a Critical Mass event. DoT then views the day’s information.

·       Scott turns on his beacon.

·       Rides his route with hundreds of other cyclists.

·       At the end of the event turns his tracker off. (Scott portion ends)

·       DoT (Signs in) views the day’s cyclist numbers around the city.

·       Uses sorting options to view time of day, and roads with the most riders that don’t have a bike lane.

·       As a special user, the DoT employee puts a marker on that road showing that DoT has decided to put in a new bike lane there.

Scenario #2: Nick wants to find and ride with other cyclists traveling to his campus in the morning.

·       Nick is already signed in.

·       He starts on the map portion of the site, but touches the users side.

·       The map empties of routes and he is prompted to place a route he wishes to ride or select from routes he’s previously rode.

·       He selects his daily morning route to school.

·       The map displays his route, and he selects the time of day.

·       It then displays other users that ride on or near that route at that time of day.

·       He sends a ride request to another student and it’s accepted later that day.

Scenario #3: Amanda wants to find a safer route to the local park.

·       Amanda enters the application.

·       She comes to the map page, and opens her routes list.

·       She selects her family’s route to the park.

·       It centers on her route on the map, and she selects the safety sorting option.

·       It shows the safety rating of her street as posted by other users, and the safety rating of other nearby streets.

·       She adds her rating to the road.

·       Her rating changes the roads color to red, alerting DoT that that road is in desperate need of bike lanes.

4. Proposed Design Solutions

So these screens were taken from my most recent progress presentation to my peers. It shows possible design solutions to answer my challenge/ question, and it was agreed that the first 2 solutions seemed to have the most promise, and would work effectively between all audiences. I definitely agree, and look forward to working with one of these directions. But the other solutions are certainly valid options and were well worth the time in the concept phase.

The first solution uses a combination of a smartphone application, and smaller, more simple GPS units called “beacons” handed out by DoT. So let me take you through the system. The app users start by turning on there application at the start of their rides. The beacon users simply turn their beacon on. After their ride is over, they turn them off. As the riders ride their route, satellites track and record their route to the smartphone application.  These routes can then be viewed individually or amassed as a single density map that can be sorted by time of day. DoT can then view this information to better place new bike safety measures.

The second solution uses the beacons, paired with roadside meters that are placed on every street. The riders turn on the beacons, at the beginning of their route, and turn them off at the end.  As they pass these roadside meters, which can be small and hidden from view, the meters count the cyclists, and display this on a simple  gauge. DoT can then view these meters and if the needles point to a set max number, DoT can know that road needs bike safety measures.

Solution 3 lets them take manuel control of the mapping process. The cyclist rides their route without any sort of device. Once at home or somewhere with computer access, the rider can input their route information to the application with other information like time of day they ride, and perhaps even problems they encountered on their route. The application then takes their route information and adds it to the mass of routes from other active users which DoT can then view.

Solution 4 uses driver operated GPS units to build information for the application. The driver simply turns on their GPS unit as they drive throughout the day. As they drive, if they encounter a cyclist around them all they have to do is tap the screen of their GPS, taking minimal attention away from their drive. The GPS unit takes that cyclist and sends it to the satellite, which adds them to a daily count of cyclists on that road and in the local area. Companies like Garmin or TomTom then send this information collectively to the application. and DoT can view it to make changes around the city.

This option uses a series of tickets or handout tokens that are placed in and collected at kiosks around the city. This system would have cyclists come in to DoT to register their bike. Tickets are handed out to these cyclists. When on their ride, the cyclist takes the tickets with them and places them in small collection beens at intersections or near street signs. DoT then collects these on a  routine basis, and uses them to count how many cyclists are using which roads. If the cyclist needs more tickets, they can pick them up from DoT. These tickets would be made of a durable material. So they could be given to new registering riders to use.