Routebook Specification Document

Functional SpecificationsDesigners: Amanda Michels, Stephanie Sundheimer, Jessie WhitmillDecember 12, 2012

Michels, Sundheimer & Whitmill 1

Table of Contents

1. General Information1.1 Purpose1.2 System Description

A. Intended AudienceB. NeedC. Solutions the System Will Provide

2. Research2.1 Documenting User Habits

A. Procedure & ResultsB. Conclusions

2.2 Design to Move Users to Action3. Design Overview

3.1 ViewsA. View RoutesB. Activity LogC. GoalsD. Settings

3.2 Icons3.3 Branding & Design Justifications

4. Functional Requirements & User Activities4.1 Features, Requirements, Implementation Methods

A. Adding a RouteB. Add AlarmC. Alarm NotificationsD. Route DetailsF. Activity LogG. GoalsH. Settings

4.2 Key Interactions5. Potential Risks and Challenges6. Future Steps

6.1 Potential Features


1. General Information

1.1 PurposeThe purpose of this document is to provide detailed functional specifications for Routebook version 1.0, a mobile application that shows users their current, fastest transportation options at any given time, or allows users to set up a planned route to an alarm clock. This document contains information about Routebook’s system, features and specific implementation requirements.

1.2 System Description

A. Intended AudienceRoutebook’s intended audience is anyone who travels or commutes. At this time, Routebook will best benefit mid-to-large cities and large college campuses that have public transportation in place, but whose access to such information is not always readily accessible, reliable or consistent.

B. Need Every commuter or traveler has a destination. There are many variables that determine whether or not a commuter will be on time to this destination, like traffic conditions, weather, or a late bus, and these variables are not within the user’s control. A user can access traffic from Google Maps, weather from their mobile phone, and in most cities, can likely access a pre-determined bus schedule. However, all of this information is not readily available in one place. The user cannot control this information, but rather, it controls how his or her morning unfolds. Additionally, many users intend to utilize clean commuting methods, but simply do not wake up in time (see Section 2.1 A., Figure 1) and are left with two options: 1. To be late and fulfill goal of clean commuting, or2. Drive and make it on time (or at least quicker) The user’s ultimate goal, we’ve found, has always been to make it to their destination on time.

C. Solutions the System Will ProvideWe aim to ensure the user is on time by utilizing mobile technology to link planned routes to an alarm clock, and offer information to make biking, walking or bussing information more readily accessible. This will ultimately help users make their personal best commuting decisions while


encouraging stress-free, clean commuting and potentially help users achieve an overall goal like losing weight by biking or spending less money on parking.

2. ResearchWe followed our peers around for a few weeks in order to discover their morning habits and gain insight into how a mobile application could best be implemented in order to reduce morning stress. Our original audience focused on college students who had a wide range of transportation options and no easy way to determine the best method to take on any given day. When we took a look at the data we collected in observing a number of students all with different options and needs, one of the most interesting things that we found was that everyone tended to oversleep far past their intended wakeup time. This led us to conclude that there is a definite need for an alarm clock within our application. We also discovered that many users who simply drive to class out of perceived convenience tend to be interested in cleaner, healthier options but do not have the time or the resources to make an informed decision each morning.

2.1 Documenting User Habits

A. Procedure & ResultsEmily Olrich is an MSU student who does not live too far from campus (a little over a mile away). She does not use public transportation and does not own a bike. Her two primary modes of transportation are driving and walking. After following Emily around during her morning commute, we found that the majority of her time in the morning was spent oversleeping (60%) and getting ready (30%). The rest of the time was spent rushing to campus via car and on foot (see Figure 1). Initially, Emily intended on walking to class to save money on gas and parking and to enjoy the weather. However, after oversleeping, this was not an option. While Emily was not late to class, she expressed anxiety in the way she rushed to class, and disappointment that she was not able to walk that day.


Figure 1: Activity Analysis

Emily is only one of subjects we researched, but her experience exemplifies what we saw across the board in terms of commuter behavior. Commuters have a collection of tools including an alarm clock, transportation methods, and routes, that they use to on a daily basis, culminating in the eventual arrival at their destination, whether early, on time, or late. Unfortunately, the only connection between these tools is the commuter.

B. ConclusionsIn order to reduce morning stress for users, this app aims to bridge the gap between the user’s alarm clock and his or her transportation options in order to allow the user to make more informed, goal-oriented decisions. The alarm will let the user know the time they have to wake up in order to bike, bus, drive or walk to be on time. Based on the research conducted, this would prove useful, as each subject spent a chunk of time snoozing the alarm clock. However, if a mobile phone pulled in live information as the user was sleeping, he or she would know exactly how long he or she can snooze before the risk of being late arises.

2.2 Design to Move Users to ActionAfter research proved that users would find a customized alarm clock useful, the next step was figuring out how to get users who always drive to use our application. Beyond the mere incorporation an alarm and commute information all in one place, the application must present information in a way that will actually transform the behavior of users. Our solution to this problem is an Activity Log that will provide users with a history of past commutes and options for setting goals and reviewing progress. In offering users this type of data, we hope to provide


insights into implications of their commuting decisions that they may be overlooking, such as gas and parking costs and health benefits.

3. Design OverviewFigure 2 below shows all elements of Routebook and their relation to one another. The physical diagram of the product (see Figure 3) will be strictly on mobile platforms, as users who use the application are primarily on-the-go.

Figure 2: Class Diagram. Users have goals, an alarm clock, and a Routebook. Within the Routebook is user settings, destinations, and the user’s activity log. Within the activity log is all of the user’s data (past routes, money saved, calories burned, etc. Destinations speaks to all transportation options available: currently walking, drive, bike, and bus, with their respective data inputs such as weather, GPS, parking, traffic, and gas. The user has an option to share destinations and goals.


Figure 3: Home screen, where the user can access any view of the application.

3.1 Views

A. View Routes● View saved routes ● Add route (destination, time, etc.)

○ Set route to alarm clock


○ Note: if user checks “now” under “time,” current data will be displayed, and the alarm clock option will not appear

B. Activity Log● View old routes in a collapsed view

○ Expand routes for detailed view, including goal progress

C. Goals● Add goal● Edit goals

D. Settings● Edit settings

3.2 IconsAll four views can be accessed from a top navigation bar anywhere within the application in order to optimize ease of use. The icons are simple and easily recognizable.

● View Routes is represented by a green highway sign● View Activity Log is represented by a pink pen and notebook● View Goals is represented by a blue check box● Account Settings is represented by a yellow character● Alarm clock is represented by a black clock● Editing functions are represented by a black pen and notebook, though different in style

than the activity log● Biking, Driving, Bussing and Walking icons are represented by a bicycle, car, bus and

pedestrian, accordingly● Adding a route or goal is represented by a plus sign● Weather is represented by a sun, or rain cloud, accordingly● Temperature, gas prices, parking information will not have an icon, but represented

through text

3.3 Branding & Design JustificationsThe design for Routebook is loosely based off of Massimo Vignelli’s famous 1972 NYC subway map (Figure 4). This map is easily recognizable, gender-neutral and will give users connotations of commuting. The main colors of the application are green, pink, blue and yellow (Figure 5). “Sort by” drop down lists when viewing route options or the activity log allow the user to choose how he or she wants data displayed. Customization is key when helping users make and fulfill commuting goals. These drop down menus are the quintessential element to Routebook and


should therefore be displayed whenever appropriate. The overall design of the interface is, and needs to remain, simple because the focus of the application is on the data and getting that data to the user in a clear, unobtrusive way. The primary typeface for the application is Helvetica, based off Apple’s iPhone interface. The title of the application on all screens is in Museo.

Figure 4: Massimo Vignelli’s 1972 NYC subway map.

Figure 5: The colors of Routebook’s navigation icons.

4. Functional Requirements & User ActivitiesThe essential requirement for this mobile application is metadata and linking that metadata to a planned route and alarm clock. The application has to pull in data from a GPS source, weather, etc. in order to function and provide the user with actionable information.

4.1 Features, Requirements, Implementation Methods

A. Adding a Route● Add destination


○ Requires GPS to list surrounding locations and search feature○ Suggested results will appear in a drop down list as user enters an address

● Add starting point (or current location)○ Requires GPS to determine user’s current location○ Suggested results will appear in a drop down menu list as user enters an

address ● Select one-way or round trip route (this will affect ultimate route options, as busses in

mid-sized cities often do not run for 24 hours)● Set arrival time (if user chooses “now,” current data will be displayed)

○ A “now” scenario would require information from Section 4.1 D, depending on which method is chosen, updated in real-time

● Activate/deactivate destination alarm by selecting “Set Alarm”● Save (activate route)● Share route via Facebook, Twitter or MMS

○ Requires access to user’s Facebook or Twitter account and to user’s contacts

B. Add Alarm● Prompt user to ask how much time is needed before alarm goes off. Since the variables

that affect morning commutes change daily, the alarm chooses the time for the user, based on the value they enter the night before.

○ Requires access to user settings (default prep time)● Choose alarm sound● Set alarm label, or name

C. Alarm Notifications● User can snooze to ___ (next option)

○ Requires access to route● View other options available

○ Requires access to route details

D. Route DetailsThe route details page features a map with a planned route. On the top of the screen, users can see when they have to leave in order to arrive at their destination on time. On the bottom, information like weather, gas prices, parking, etc will be displayed. Users can select “details” to see all factors affecting their route. The following are a list of requirements for each method of transportation:

● Bike○ Access to weather○ Access to map with bike lanes○ Distance○ TIme○ Access to alarm clock (leave in... to arrive at...)


● Walk

○ Access to weather○ Access to map○ Distance○ Time○ Access to alarm clock (leave in...to arrive at...)

● Bus

○ Access to weather○ Access to pre-determined bus schedules○ Access to map with bus stop locations and live bus GPS○ Access to traffic information○ Cost of bus fare○ Distance○ Time○ Access to alarm clock (leave in... to arrive at...)

● Drive

○ Access to weather○ Access to map○ Access to live traffic ○ Access to parking information, including cost○ Access to current gas prices○ Access to a GPS/Navigate feature○ Distance○ Time○ Access to alarm clock (leave in... to arrive at...)

Each requirement for the views listed above will require some type of data source or the creation of the required data. We will be utilizing various APIs to obtain the information that is needed to accurately calculate transportation options. The weather.gov API will give the app current weather information as well as forcasts for throughout the day to ensure a biker does not get caught in a downpoor on his return trip. Google Maps API will give us access to information regarding public transportation routes and schedules. We anticipate integrating additional information including live GPS tracking, parking options, and gas prices in future versions of the app. While some of this data is available now, it is not as readily available in all cities, making it difficult to implement with our initial version.

F. Activity Log● User can view all past routes until he or she chooses to clear them● Belongs to Routebook


● Contains all user data● Feeds data to goal progress (if goals are set)● Drop down menu allows user to choose how to display old routes

○ By date○ By category

■ health■ cost■ money spent■ time spent

G. Goals● Create a goal

○ ex) “Lose five pounds in two weeks”● Name goal● Categorize goal

○ health○ money○ environmental

● Choose method of completion○ ex) “Bike to work three times a week.”○ ex) “Ride the bus everyday for two weeks.”

● Choose date of completion● Assign goal to a route● Save goal● Share goal via Facebook, Twitter or MMS● Goals are listed in a collapsed view● Goal progress shown in a detailed view

○ Status bar○ Days until completion○ Next steps if applicable

H. Settings● Sharing

○ turn Facebook and Twitter access on or off● Notifications

○ opt out of pop ups that contain bus location● Alarm Clock

○ set default preparation time (can be changed daily in alarm clock set up)● General

○ set preferred modes of transportation■ User can indicate whether they have a bike or a car

○ set default order for routes


○ add account information (name, birthday, set ○ current location, etc.)

4.2 Key InteractionsSee link for prototype: http://invis.io/EV9JC8S3Areas highlighted in pink are clickable in the prototype.


http://invis.io/EV9JC8S3















5. Potential Risks and Challenges● Routebook is currently a local application. Making this application universal will require

major growth from our original prototype. ○ With funding, the potential for our application increases, as we will be able to

incorporate other cities

● Public transit authorities must offer GPS data if it exists, and if it doesn’t, GPS data would need to be implemented

○ Requires strong communication/relationship between us and local transit authorities

● We must account for all potential user goals, which requires extensive user testing

● We must help users to overcome their tendencies to simply press “snooze”

6. Future StepsIn order to provide users with the most practical transportation application possible, we will need to take several measures to follow through with our service, including:

● Finish all views in the interactive prototype and further develop brand

● Continue user research, specifically around Goals and Activity Log to determine best ways of influencing behavior change

● Develop an initial build based on our current vision and continue testing with a beta audience

● Work with local transportation authorities to implement GPS tracking for more accurate

route information

● Research, design and develop a supplemental web application including a social focus to help build momentum around the app

6.1 Potential Features● Work to include features for all-day commuters, including iCal integration and segment

time based on morning tasks


● Add an alert for going to bed on time

● Include a car-pooling feature

● Sponsored destinations with an option for adding stops to routes (coffee shops, gas

stations)

● Options for branding for other companies○ Transportation authorities pay for custom app○ Allow these authorities to gain insight/data to improve fleet management


Documents

Routebook Specification Document