Carpool.UMD
Interface Design Report
John Dobrosielski - jdobrosi@umd.edu
Tiffany Gray – karateTD@yahoo.com
Anton Kropp – akropp@gmail.com
Anna Nhan – anhan@mail.umd.edu
Martin Stolen – mfstolen@ssl.umd.edu
December 12, 2006
Abstract
With the demand on energy resources increasing as the supply decreases, energy costs in
the United States have been at an all-time high. Despite these costs, congestion is still
steadily increasing. Carpooling has for a long time been an option to help reduce
congestion, but it is currently underused by commuters.
Carpool.UMD is a social-networking website designed to make carpooling to and from
the University of Maryland-College Park easier. The website allows users to search for
carpools, learn more about other riders and manage their carpools. Carpool.UMD aims to
create a safe and friendly community as well as making it convenient to carpool to and
from the University.
2
Credits
John Dobrosielski
 Compilation of calendar low-fidelity prototype design
 Database design
 Backend integration with GUI
 Interface redesign
 Messaging system design
Tiffany Gray
 Compilation of user needs report
 Help documentation
 Assistance with initial interface design
 Interface redesign
Anton Kropp
 Development of the initial concept
 Compilation of design proposal
 Compilation of system requirements
 Initial design of prototype user interface
Anna Nhan
 Compilation of annotated bibliography resources
 Compilation of usability test results
 Search algorithm design
 Backend integration with GUI
 Interface redesign
Martin Stolen
 Compilation of map low-fidelity prototype design
 Compilation of usability questionnaire and task list
 Ranking algorithm design
 Backend integration with GUI
 Interface redesign
3
Table of Contents
Abstract ............................................................................................................................... 2
Credits ................................................................................................................................. 3
Table of Contents ................................................................................................................ 4
Introduction ......................................................................................................................... 5
Overview of the problem ................................................................................................ 5
Discussion of previous work........................................................................................... 5
Presentation of Design ........................................................................................................ 7
Overview of Approach.................................................................................................... 7
Description of Interface .................................................................................................. 8
Description of Backend ................................................................................................ 15
Comparison with other products ................................................................................... 17
Design Process .................................................................................................................. 18
Defining User Needs ..................................................................................................... 18
Low Fidelity Prototypes................................................................................................ 20
High Fidelity Prototype ................................................................................................ 24
Usability Test Process and Analysis ................................................................................. 27
The Process ................................................................................................................... 27
Our Users ...................................................................................................................... 28
Post-test Questionnaire Results .................................................................................... 34
Analysis of Results ....................................................................................................... 34
Effect of Results on Final Design ................................................................................. 36
Conclusions ....................................................................................................................... 40
Final Status ................................................................................................................... 40
Future Work and Recommendations ............................................................................ 41
Acknowledgements ........................................................................................................... 41
References ......................................................................................................................... 42
Appendix A: Usability Questionnaires and Scenarios ..................................................... 44
Prototype use instructions ............................................................................................. 46
Appendix B: Database Schema ......................................................................................... 48
4
Introduction
Overview of the problem
Congestion around College Park, MD can be quite severe at peak hours, making what
should be a short commute both lengthy and frustrating. Alternative methods of
transportation are available, but many people still prefer to drive because it is more
convenient for them. Carpooling has been a long time option to help reduce this
congestion, and at the University of Maryland even presents economic benefits in terms
of reduced parking fees, but carpooling is currently underused by most commuters. One
problem is that coordinating carpools on a large campus community such as the
University of Maryland can be difficult. The effort required to set up a successful carpool
with multiple members, each with different starting location or destinations, can be too
high of a barrier for many commuters, especially if the other members are strangers. The
problem then is to create a means for fellow commuters to easily and safely find, create,
and coordinate carpools that will suit their commuting needs in the College Park area.
Discussion of previous work
Commercial systems:
Carpool Zone <http://www.carpoolzone.smartcommute.ca/en/my/>
Carpool Zone is a Canadian carpooling website for the general public in
Ontario, Canada. Carpool Zone allows users to organize carpools based on users'
preferences. Standard features of this system include a map of matching carpools,
user vehicle descriptions, and start and end times of the carpools. Carpool Zone
users communicate through a third-party email system.
eRideShare.com
eRideShare.com is a website that helps to organize local and long distance
carpools worldwide. Carpools can be searched for based on users' preferences
and are listed accordingly with origination city, destination city, days that the
carpools run for, contact information, and comments by the carpool starter. Third
party email is used so that personal information will not be revealed. Safety tips
and benefits of carpooling are also provided.
Previous academic papers
ORISS: A Web-Based Carpooling System
Initially a student project at Carl von Ossietzky University, Giesecke and
Reents describe ORISS' roles and benefits to the university community. Project
5
development is outlined, including the system's goals, architecture, user interface,
and algorithms. ORISS is currently being adapted by the German university.
Bellevue Smart Traveler: Design, Demonstration, and Assessment
Haselkorn and colleagues present a technical report on the development of
a dynamic ride sharing system by the Washington State Transportation Center.
The Bellevue Smart Traveler is designed to help commuters form dynamic
rideshare groups, as well as provide them with traffic congestion and transit
information. They document the design, demonstration and assessment of the
Bellevue smart traveler system.
A Prototype Web-based Carpooling System
Keenan and Brodie describe the initial development of a web-based
carpooling system in Ireland. The system would automatically match users based
on their location and desired travel times. Features include a clickable map
interface, email notifications, and user privacy protection.
Ridematching
Loukakos and Picado describe testing procedures for three ride matching
services and provide a case study of their effectiveness. Report includes usage
reports, user characteristics, user response, and travel impact information for each
system.
Parking Discounts and Carpool Formation in Seattle
Olsson and Miller conducted a survey to participants of a carpool
incentive program in Seattle. They concluded that parking discounts will attract a
relatively small amount of people to switch to carpooling. However, findings
showed that of the people who switched to carpooling, the majority of them
switched from public transportation instead of from driving by themselves.
Location-aware community applications: Privacy Issues and User Interfaces
Terveen and colleagues discuss privacy issues associated with locationaware applications that require users to share some information about their
location. Authors outline three classes of location-aware applications:
GeoTemporal matching, GeoTemporal messaging, and GeoAwareness. Also
discuss three key design ideas regarding privacy in such applications:
personalized disclosure, transparency, and ambiguity.
Design Decisions in the RideNow Project
6
Wash, Hemphill, and Resnick discuss the process of developing RideNow,
a project to help individuals within a group or organization carpool. Wash,
Hemphill, and Resnick outline their motivation in pursuing this project, their
design approach, their design decisions, and their future research.
Relevant websites
PTS: Carpools--The University of Texas at Austin
PTS: Carpools is a website provided by the Parking and Transportation
Services to encourage students, faculty, and staff to carpool to the University of
Texas at Austin. The site includes a list of current carpools and forms for users to
fill out to join or register carpools on the website. Users are provided monetary
incentives to carpool to campus.
Smart Park—University of Maryland College Park
http://www.transportation.umd.edu/alternative_transportation/students.htm
Smart Park is a student carpool program for University of Maryland,
College Park students. Participants are given monetary incentives and reserved
parking on campus. Special signature cards are used to check attendance and it
has a web-based database to find students involved in the program in a given area.
Presentation of Design
Overview of Approach
For the problem at hand, a relatively quick and simple solution, from an implementation
point of view, would be a public sign up sheet via a general website or in paper form.
However, such a solution could create safety issues because users would know very little
about the other people they are sharing a ride with. Extensive effort and time would also
be needed to assemble a functional carpool. Similar to Facebook, which helped make a
large campus community seem smaller, Carpool.UMD is a website targeted to UMD
commuters with the main goal of simplifying group travel for purposes of safety,
economics, resource efficiency, and flexibility. Users can get a sense of who they are
riding with based on other users’ profiles. The website will be available only to current
UMD students, staff and faculty via a valid UMD email address and password to help
address safety issues. Users can join a carpool based on profile preferences of members
of the group and specifications of the carpool, with search functions to find carpools that
match the user’s criteria as well as a visual presentation of the carpools and ranking of the
results.
7
Description of Interface
Carpool.UMD was implemented in Macromedia Flash, with the menu structure shown in
the transition diagram in Figure 1. The resulting Flash movie had each screen as a single
frame, and screen to screen transitions were carried out by performing jumps within the
movie. Most interactions with the backend database system were carried out by
submitting form fill-ins. Whenever possible, we used combo-box Flash components to
ensure valid input from a set of viable responses. In cases where a combo-box was either
impossible or inefficient, a text input box was used. In both cases, whenever any
potential change was being made to the databases, we performed checks to ensure that
the input was valid based on the appropriate constraints. These checks were performed
on the interface as well as in the database class files to ensure a double protection of the
integrity of the supporting data. In some cases, screen transitions were needed to allow
the user to either jump back to the previous screen with all the filled-in data preserved, or
to transfer data from one screen to the next. Unfortunately, Flash movies do not allow for
this functionality by default. Therefore, in these situations, a stack structure and series of
global temporary variables were used to save or transfer the state of a screen and its input
components.
Home Page
Login
Search/Create
Carpools
Manage
Carpools
Edit Profile
Messaging
Inbox
Search Results
Request to
Join
View Rider’s
Infor mati on
Create A
Carpool
Read/Del ete
Message
Compose
Message
View
Detailed
Carpool
Infor mati on
Figure 1 Transition diagram of final design
8
Welcome/Login Screen
Login: Returning members may log in by inputting their usernames and
passwords. New users can sign up for a Carpool.UMD account to get started. A
help screen is also available.
Sign up: New users may sign up for a Carpool.UMD account by clicking "Sign
Up" button on the Login screen. This information entered may be shown with
carpools that the users are associated with. Users may go back to the “Login”
screen or go to the “Help” screen if needed.
Help: Quick links for the major features of Carpool.UMD are provided on the left
side bar of the “Help” screen. A scrollbar is also added to the right side of the
screen for faster navigation with the mouse or laptop touchpad.
Figure 2 Login screen
9
Figure 3 Signup screen
Figure 4 Help screen
10
Home: After logging in, the user is sent to the Home screen. The Home screen provides
a quick overview for the user, namely the status of their message inbox and a list of their
current carpools. From this screen, the user can access every section of the
Carpool.UMD system from the menu bar across the top of the screen. These sections are
“Search/Create Carpools,” “Manage Carpools,” “Messaging,” and “Edit Profile.”
Additionally, the menu bar has a button for the user to log out of the system at any time.
Figure 5 Home screen
Search/Create Carpools: In order to search for a carpool, all search parameters must be
filled in. Pressing the “Search For Carpool” button would return the search results found
based on the parameters the user sets.
Possible carpool matches are shown on the map and in the key to the right on the map.
There are three options that carpools can be ranked. The first is "Time Deviation", which
is the deviation from the user’s desired arrival time. The second is "Time Added to
Carpool", which is the time that is added to the carpool if the user’s destination is added
to the current list of stops. The third is "Your Total Travel Time", which is the total time
of how long a carpool could take from the user’s stop to the user’s destination. All times
are estimates. Users may choose any carpool to view its details or to join. A pop-up will
appear to confirm a user’s addition to a carpool. If the search comes up empty or the user
does not like the carpools given, they can search again with changes to the criteria or
create a new carpool.
11
Figure 6 Search screen
Every new carpool must have a unique name before creating it with the “Create new
Carpool” button. The parameters from the search screen are then carried over to the next
screen to where users can either modify parameters, such as the number of maximum
riders allowed in the carpool, or simply save the carpool with the specifications they had
searched for. A carpool much be selected before a user can join the carpool with the
“Request to Join Carpool” button or view the details of the carpool with the “View
Details” button.
Manage Carpools: On this screen, users may modify certain specifications of their
carpool, see what stops the carpool is stopping at, and the number of riders in the carpool.
Editable specifications include: time, day, traveling to or from the university, and the
number of riders. From this screen, users can also view the profiles of the other riders in
the carpool or send them a message.
12
Figure 7 Select carpool screen
Figure 8 Manage carpool screen
13
Messaging: Carpool.UMD features a messaging system to allow its users to
communicate with each other. Users can compose, read, or delete any message in their
mailbox (not shown). When composing a message, two different contact lists will
automatically appear namely a list of the user’s carpools and a list of fellow riders within
those carpools, to allow the user to send messages to other members of the system
without having to memorize their usernames.
Figure 9 Create message screen
Edit Profile: The link to edit user’s profile can be found on the Home screen or on the
title bar. The “Edit Profile” screen will show all the information that the user entered
when first signing up for a Carpool.UMD account. All of this information is editable
from this screen, except for the user’s username, which must stay unique for backend
purposes, and password. The information that can be edited include the user’s email
address, first name, phone number, gender, whether or not the user smokes, whether or
not the user can drive, and affiliation with the school.
14
Figure 10 Edit profile screen
Description of Backend
The functionality of our system was made possible by storing the various information
items in a collection of databases and utilizing that structure to create a searchable
system. The two main databases we used are the user database and the carpool
database. The user database, as the name suggests, stores information on the users
registered in the Carpool.UMD system, such as username (their unique identifier),
password, name, and other profile-related information. Similarly, the carpool database
stores information on carpools currently in the Carpool.UMD system, such as the
carpool’s unique ID, direction, day of the week, and arrival time. The riders of a carpool,
and the locations at which they are to be picked up or dropped off (depending on whether
the carpool is heading to or from the University), are stored in yet another database
embedded in each entry to the carpool database. This rider database allows for a dynamic,
structured list of users and locations associated to a carpool, and allows for efficient
utilization of this information. Lastly, the messaging aspect of our system was
implemented by using a message database to store all messages in the system, keeping
track of the sender, recipient, subject line, and message body.
Since the actual coding of this interface was done in Flash Professional 8, the DataSet
component was used heavily to implement the various databases needed for this
system. Each database has different functionality needs, and therefore a separate class
was created for each database type, with a DataSet at the core. This decision allowed us
to create functions within each database class that suits the needs of the interface we
15
designed. For example, we wrote functions within the carpool database class to not only
add valid carpools and update a carpool entry, but to find all carpools for a specified user,
find all users in a given carpool, and find all stops in a given carpool. This
implementation embodies the object-oriented approach to programming and allows for an
organized code and file structure, as well as a logical integration of the backend code
with the interface. Most of the features of the Carpool.UMD system are implemented by
performing relatively simple actions on the various databases driving the functionality of
the system, such as adding, updating, and deleting items. The main exception to this is
searching for carpools.
The most complex aspect of the Carpool.UMD system is the search algorithm used to
find and rank carpools based on user-defined criteria. It is important to note that for all
carpools in our system, we assume that the departure and pickup times for the carpool are
adjusted as needed to ensure the arrival time designated for the carpool. Also, all
calculations based on distance and geographic locations are simulated. Geographic
locations are generated by assigning x and y coordinates, and distances are calculated as
the length of the line connecting two points. In the actual implementation of these
features, the Google Maps API would be used to provide a visual map and to calculate
the various distances. Our first task is to determine whether the carpool is a match based
on the user’s search criteria. Verifying whether a carpool matches the day and time
specified within the designated window is a relatively simple check. However, we also
allow the user to limit carpools based on the travel time between their location and the
University. In order to accomplish this feature, we determine the most logical order of
stops within a carpool, including the user’s location, based on relative distances, and then
calculate the approximate travel time between the user’s location and the
University. Based on the total travel time determined by this process, the results are then
limited by whether this calculated time falls within the user’s specified acceptable total
travel time.
After getting a set of carpools that meet the search criteria specified, the task is to order
and present these matches in a useful way for the user. In developing our design, we
thought of three useful criteria by which potential carpools could be ranked: deviation
from the user’s desired arrival time, smallest travel time impact on the pre-existing
carpool, and shortest travel time between the user’s designated location and the
University. Instead of forcing any one of these rankings on the users of our system, we
decided to allow the user to dynamically sort the results that matched their search criteria
by any of these three methods. The end results of the ranking as designated visually by
the user in an ordered list, and in a visual map of the routes with lines weighted to
emphasize the higher-ranked routes. Again, as with the route and location information,
the map visualization is simulated in our revision. The first ranking method, which sorts
matching carpools by deviation from the user’s desired arrival time, does the simple
calculation of finding the difference between the arrival time designated by the user and
the arrival time of the carpools to then sort matches in ascending order by this
difference. The second method sorts matches in ascending order by the difference
between the total travel time of the carpool with the user’s location added and without the
user’s location. These two figures are calculated in the same manner as the calculation of
16
the user’s travel time in the actual search process: based on the locations included in the
carpool route, the shortest path between stops is calculated and then the time is estimated
by traversing that path. The last method is implemented sorting the user’s travel time,
calculated in the search process, in ascending order.
Comparison with other products
There are many websites designed to facilitate commuters’ search for carpools. Usually
they are tailored for their specific locales allowing for a more customizable community
approach. Carpool.UMD is a Flash-based carpool locating tool created for the use of
University of Maryland-College Park students, staff, and faculty.
Carpooling websites currently in use by many cities share many common design
components. Almost all of them, like Carpool.UMD, let the user search for a new carpool,
create a new carpool, create and edit a profile, send and receive messages from users, and
view and modify current carpool status. In much the same way as Ontario’s carpooling
website, Carpool Zone (http://www.carpoolzone.smartcommute.ca), Carpool.UMD
displays potential carpools and current carpools in a Google map based form. While
current prototype of Carpool.UMD system does not feature a fully functional map system,
the final design of our system calls for integration with Google Maps. Also sharing in
Carpool Zone’s design process is the requirement that carpools are recurring, not onetime rides. Carpool.UMD takes the common implementation of a carpooling site to the
next step by restricting users to rides only to and from the UMD campus. However,
Carpool Zone has preset carpools for certain employers who have signed up, which is
similar to Carpool.UMD in that these carpools are set to go to and from the
workplace. Carpool Zone also differs from Carpool.UMD in that it has many more
options for a user to enter into a profile. While Carpool.UMD is limited to directory
information regarding the user, Carpool Zone allows a user to enter in miscellaneous
information, such as favorite music, intended to help users get a feel for each other.
University of Maryland-College Park in fact has a carpool database called Smart Park
currently in existence. However, unlike the design proposed by Carpool.UMD, Smart
Park has no route matching, carpool management, profile information, or messaging.
Instead, Smart Park is strictly a database of people interested in joining a carpool,
consisting of users’ names and emails, grouped by zip code and city. This leaves the
entire burden of coordinating a carpool to the user.
Carpool.UMD shares many attributes with current carpooling services, and even
surpasses the available options on some highly trafficked sites. The direction that
Carpool.UMD seems to be heading is towards a more graphically-organized applet, with
dynamic maps and photos of users with customizable profiles. While both approaches of
map based systems and text based lists are suitable to the user, taking the best of both
instances and incorporating them into a location-specific website would be the ideal for
helping carpoolers get to where they need to go.
17
Design Process
This section describes the process of arriving at the final interface design. The process
involved establishing the user needs through detailed user scenarios as well as setting the
system requirements. Two low fidelity prototypes were produced, to get different ideas
down on paper and get a first impression of the likely complexity of the system. Then the
high-fidelity prototype used for usability testing was implemented based on the
experience gained from the first designs. The results from the usability tests performed
were then used to redesign the prototype and come up with the final design.
Defining User Needs
The first part of the design process was to identify the needs and requirements of the
typical users of our system. This was done by brainstorming six specific user scenarios
(see Figure 11) that would identify the typical ways in which users would use and
interface with the system. It was found that the user pool would be quite diverse, with
students, both undergraduate and graduate, as well as faculty and staff. However, it was
also anticipated that most users will use the system in the same fashion, for commuting to
and/or from campus.
18
Miss Judy Jones, age 30, is a secretary in the undergraduate office of the
Psychology Department. She lives alone in an apartment in New Carrollton. Her
work hours are from 8:30 am to 4:30 pm, Monday to Friday. She frequently works
overtime during August and September when student registration is at its peak, but
otherwise she follows the regular office hours. She enjoys her work, although her
supervisor can sometimes make life difficult for her if she gets in late, even as
little as a few minutes. She usually takes public transportation to and from work,
by way of the Metro bus system, but the journey time can be up to 45 minutes.
This is mainly due to the fact that she has to change buses halfway to campus and
the first bus is often delayed, causing her to miss her second bus, which adds 15
minutes to her waiting time. A typical drive to campus would be approximately 20
minutes, but she currently does not think that the cost of a car, the maintenance,
the fuel, and the insurance would be something she could afford. She also feels
somewhat unsafe after dark in her neighborhood, and the 5-minute walk to her bus
stop does at times make her feel uncomfortable. Thus she would like an
alternative method of transportation, like a carpool, that can bring her from her
apartment to campus at regular hours every day. However, she is worried that
signing up for a carpooling service and giving out her address and contact details
to strangers could put her further at risk.
Discussion. The task of using a carpool routinely for time-critical appointments is
important, and is frequently performed by employees in particular. Only a well
functioning and communicating carpool can be trusted with this task, although
some extra time for unforeseen events should always be included in the travel time
estimate when carpooling. This is a first-time user with no previous experience
with carpooling. While using a carpool could give the sense of safety in the
company of others, the task of signing up for a carpool for the first time with
unknown people can make a user concerned. This is a very important task
although not frequently performed for most regular users, without which the
carpooling system would not work.
Figure 11 User task example
The system would work by users signing up from a web-connected computer and
creating a profile, then setting their carpool location and destination needs and searching
for matching carpools. Users would join carpool networks based on preferences they
have selected as well as which carpools can get them to their desired location within their
allotted time frame. If the users do not find a carpool that suits them, they can create a
new one. The burden of making sure that carpoolers get along, share gas costs, and are
punctual in the planned arrival and destination times would be left to the users. A
discussion network was also found to be useful to allow users to communicate. In general,
the purpose of Carpool.UMD was to help the user find reliable people to share their
commuting with.
19
Thus it was decided that the main challenge in designing this system would not only be
the interconnecting of people, which many websites have capitalized on, such as
Friendster, MySpace, and Facebook, but how the design meets the needs of the varied
user pool, which consists of people who need to be in a specific location on time. It also
became clear that many of the users will have fluctuating schedules due to the nature of
the university setting. Students may have more leeway in the punctuality of a carpool,
whereas professors may have some fluctuation when there isn’t an important class to
teach or meeting to attend. Staff will most likely have a stricter schedule than the
students and the professors. The academic year also adds variation to the users’ needs
over time. As such, the system would have to be flexible, dynamic and simple.
In addition it was decided that the current members of a carpool would have to all be
informed and made to confirm the addition of a new member. This is because the
addition is likely to alter the schedule of the carpool somewhat, and might add more
travel time to some of the current members beyond what they find satisfactory. The
verification of a new rider also addresses the issue of trust, as it gives the carpool
members some control over who they share a ride with. This was also found to be an
issue for users looking for a carpool, and sufficient information should be provided about
the current members to allow an informed decision to be made.
Low Fidelity Prototypes
Two prototypes were explored early on in the project, and the group split into two
subgroups for this task, each developing one of the prototypes. To ensure that only
persons associated with the University are allowed access to the system, the user ID and
password used to manage access were assumed to be the University of Maryland’s
Directory ID and password combination for both prototypes.
A separate screen for setting the user profile information was also included for both.
Every user of the system was envisioned to have a personal profile that contains
information that can be accessed by other users to determine whether they would “match”
with the person in question. Two types of information could be entered, public to all
users and restricted to members of joined carpools only. The former included first name,
gender, age and employment status, while interests, picture and other more personal
information was thought best left optional to each user. The full name, contact
information and pickup location was then only to be revealed to the members of a joined
carpool, to maintain privacy and prevent abuse.
Both involved a user main screen, or home screen, which would be used to provide an
overview of the current carpools which the user is involved in as well as provide site
navigation options and messaging. One of the prototypes explored for the interface
design was based on management of carpools through a calendar view, displaying
carpools on the days they occur. The main screen would provide an interface of the type
shown in Figure 12. The calendar graphic has a monthly view, with controls at the top to
go forward and backwards one month at a time, as well as a dropdown box to the left that
allows the user to jump to a desired month. For a given day, confirmed carpools were to
20
be listed in a dark green font, pending carpools listed in a dark orange font, and carpools
the user proposes listed in a blue font. Clicking on a carpool title would take the user to
the carpool details screen, which contains information about the carpool, including
location, time, and other information depending on whether the carpool has been
confirmed.
Figure 12 Main screen of calendar-based prototype
One of the benefits of using this type of visualization is that it is an interface many users
are familiar with through calendar applications. Another is that it presents the carpool
data in a structured fashion, making it easier for the users to find the information they are
looking for.
The second prototype envisioned the more common approach of a map-based interface
(Smart Commute Association, 2006; Keenan and Brodie, 2000), where carpools could be
visually represented and interactive in nature. This spatial representation makes the
carpools stops and route simple to interpret, but it not as well suited to provide the time
aspect of the carpools as the calendar (see Figure 13). Times and other information was
envisioned displayed whenever the user clicked on one of the carpools, and as such
would not as conveniently allow the user to determine which carpools are running on
which days or at what times.
21
Figure 13 Main screen of map-based prototype
However, for the second prototype the map based interface was also envisioned for
displaying the search results, a task for which it is much more suitable. For both
prototypes, the search was initiated on a separate screen where the user could search for a
carpool based on a number of criteria, including proximity to his or her location, the time
to depart or arrive at a destination, leeway in the time and the days of the week the
carpool runs on.
One difference between the two prototypes, however, was the definition of a carpool
itself. While the calendar-based prototype allowed a carpool to span several days, albeit
at the same time each day, the map-based prototype defined a carpool as one-way travel,
between two locations, on a given time and day. The latter does simplify the data
structures used to store and access the carpools, but it is likely that a significant fraction
of carpools will be repetitive in terms of time and locations. An example of this would be
a staff member with a fixed work schedule and no other obligations before or after work.
Once the search had been performed, both prototypes guided the user to a separate results
screen. The map-based prototype (see Figure 14) would then display the matching
carpools as routes on map. It would also have a “pointer” for each stop, much like the
markers used in Google Maps. The user could then also click on the route to get more
information on the carpool, like the participant’s interests, age, and other public
information. The screen would have a number of adjustable preferences for the search,
which would have default values set in a separate screen. This preference screen would
22
be filled in as part of the process of creating an account on the system, and was also
included in the calendar-based carpool prototype. For the map-based prototype, however,
these preferences could be used to effectively filter out results, with the map updating
after each adjustment. This was thought to be useful in situations where too few or too
many results were found for a given search, and could also be accessed in the calendarbased prototype, albeit through a link to a separate screen.
Figure 14 Search results screen for map-based prototype
The calendar-based version would produce the search results in a list format, structured to
make the information easier to interpret, as can be seen in Figure 15. This would be
significantly easier to implement compared to the map version but would provide little
information as to the spatial aspects of the carpools. An example of this would be the
road layout. Two carpools might be equal in terms of arrival and departure time, but
differ greatly in suitability as the road layout may force large detours for either or both.
This may be estimated relatively easily by having the carpools and the users’ location
drawn on a map.
23
Figure 15 Search results screen for calendar-based prototype
Both prototypes included a feature for proposing a new carpool if a suitable existing one
could not be found. The main difference between the two versions here was that the
calendar based version included this feature in a “Change/View Carpools” screen, while
the map-based version allowed the user to do this on the search results screen. While the
former would facilitate users that already know there are no matching carpools, the latter
would be a faster method for users that are in the process of searching for carpools, and
have no previous knowledge of the likely search results.
High Fidelity Prototype
Both of the low-fidelity prototypes were designed with an HTML based delivery system
in mind. However a decision was made to make the high-fidelity prototype in
Macromedia Flash embedded within a website. This meant that a nearly full functional
prototype could be developed for the usability testing, which allowed for more realistic
testing. The color scheme was chosen to be simple and something that would display
well on all screens. Links were chosen to be black with a rollover to yellow. The main
logo was chosen to conform to UMD color formats and fonts, incorporating the UMD
logo as well as a self-explanatory graphic of cars on the road.
We next had to choose which low fidelity prototype design we would implement. It was
decided that the map would be the most suitable interaction form for the search results
screen as it would provide a spatial feel for the various carpools, which could help in the
decision making process for the users. It was assumed that the time information about
24
each carpool would not need to be shown directly on the screen, but rather be used when
ranking the suitable carpools found. However, we also felt that the calendar view of the
users’ current carpools was a useful tool. We initially thought of merging the two
designs, so that the main screen of the system would feature a calendar-view of all
carpools the user is associated with. The search interface would feature the map
visualization of the carpools. However, time soon became an issue and we had to
abandon the calendar aspect of our design. While we liked the idea as a method of
viewing one’s current carpools, we felt that the map visualization was more helpful to the
user, and therefore, more important.
Early in the design process research was made into the possibility of including the
Google Maps API as the basis for the maps displayed in the high fidelity prototype.
Google Maps is a popular web-based geospatial viewing tool that allows the user to
interactively access map and imagery data. One of its main strengths however, is that it
can be embedded in web-applications, and has classes for including markers, poly-lines,
coordinates, and other info on the map. In addition it can respond to user actions, read
data from XML files and is currently offered as a free service (Directions Magazine,
2006). To make the API communicate with Flash however, a Flash and JavaScript
integration kit would have to be used (Macromedia, 2006). It was decided that including
the Google API into our Flash application would be complex and beyond the scope of
this project, and that the functionality could be replicated on a large enough scale to allow
for testing of the interface.
In the initial prototype drawings the design called for two menu bars, one on the side and
one along the top. This was eventually minimized to just a single main menu bar across
the top that encapsulated the main group options: search/create carpools, view/edit
carpools, and messaging. This can be seen in Figure 16. In addition the tab descriptions
on the top of the screen were made more detailed, to accurately describe the function of
the screen each links to.
Figure 16 Removal of left-hand side navigation bar
25
Along with the main groupings were links to the home screen, which displays the current
carpools available as well as any messages sent to the user and a link to logout of the
system. The home screen, which went through several iterations of design, also has a
short description of how to use the system. An in depth explanation of each screen is
available through the help link, which is located at the top right of each screen. Initially
the home screen was going to contain a map of the current carpools, as well as redundant
links from the main menu but this idea was revised to the simpler design currently in
place.
The layout of the search screen was also altered, as can be seen in Figure 18. While the
low-fidelity prototype had a separate screen for inputting the search criteria, it was found
that this could fit along the left hand side of a unified search screen. Taking the idea from
the original prototype with a menu bar on the left, the main search features were placed in
that position. On finding a carpool a map is shown in the remaining space displaying the
path of the carpool, see Figure 17, and as the search settings remain the user can quickly
alter the criteria if needed, as seen in Figure 18. No preferences on what carpools would
match personal settings were included in the search due to time constraints, although a
ranking feature was added to indicate the closest matching carpool, based on times and
locations. It was decided to focus on making the basic search and database working, as
this would allow for realistic testing to be done.
Figure 17 High-fidelity prototype search results
26
Figure 18 Comparison of search input
For the ranking of the search results, several possible options were considered. Among
the factors judged important by the group, and implemented in the high-fidelity prototype,
was the total travel time for the user. This would indicate whether a carpool has a more
suitable route to the destination than a competing carpool, with fewer detours after the
user has boarded the car. However, the suitability of the user from the carpools
perspective is also of importance, as it affects the likelihood of being accepted into a
carpool. A decent measure of this is the time added to the total travel time of a carpool by
the new users’ location, which is simply the difference between the total carpool travel
time before and after the new user has been added. The difference between the actual
carpool arrival time and the desired time entered by the user was also included as an
option for ranking, as this affects the suitability of a carpool for a given users travel needs.
The use of Flash introduced unexpected issues related to working as a team on the same
end product. The groups consisted of 5 members, and a lot of time was spent simply
waiting for another member of the group finishing their work on the Flash files, and
emailing them out to the rest. Some of the backend coding could be split into separate
Actionscript files and run on local copies of the interface, however no easy way of
working synchronously on the Flash graphical interface design was found.
Usability Test Process and Analysis
The Process
Our usability test consisted of two parts. The first task was intended to test the
experience of a new user. During this task, the user created a new profile, performed
searches for carpools, joined a carpool that matched the user’s preferences, and sent a
message to other users. We thought that this task would cover a significant number of
features and screens, and represent a logical progression of events a new user might
encounter when using Carpool.UMD. The second task was meant to test some more
27
complex operations that users might need to perform once they became a member.
During this test, users were asked to search for a carpool that did not exist in our carpool
database, and in turn asked the user to create a new carpool. Afterwards, we asked the
user to search for the same carpool on a different day. Although the second part of our
usability test only covered fewer operations than the first, the goal was to cover a few
complex operations that we believed would be among the most frequently completed
actions.
For our users, we targeted commuters who were affiliated with the University of
Maryland. These people were our target users because the purpose of our system is to
create a carpooling community for people who need to travel to and from the University
of Maryland regularly. We pooled our users from people we know by asking them in
person. The testing process took place in common environments for students, staff, or
faculty of the University of Maryland. Our testing environments consisted of the public
areas on campus, such as the Stamp Student Union, and personal areas, such as the user’s
office or home. We chose these environments because they were familiar and convenient
to the users. They are also areas where we think our users would most likely use our
system. The users either used their own computers in their offices or homes or one of our
personal laptops.
Each user was given a pre-test questionnaire, the two scenarios, and a post-test
questionnaire. Each user was aware of the entire testing process upon agreeing to
participate in our usability test. While testing our system, every user had the opportunity
to ask questions. The questionnaires and scenarios the users received are reproduced in
Appendix A.
Our Users
User 1:
22-year old female undergraduate student who drives to campus everyday, has
never used a carpooling website or carpooled before, but does consider joining one. For
the first scenario, the user did not immediately find the “Signup” button. The user tried
to login in first in hopes that it would take her to a sign up page. After a couple of
attempts, the user noticed the “Signup” button and proceeded to create a new profile.
The user was thrown off with the tab order in the sign up page, but was able to create a
profile relatively easily nonetheless. The user had no trouble searching for a carpool, but
had a hard time knowing how to select a carpool and viewing its details. The user
comments that the error and confirmation messages should be made clearer. The user
questioned how to message a certain carpool after searching and consulted the help page
to find out. After reading the help page, the user had no trouble sending a message. The
user mentioned that she would like a copy of her sent mail be in an “Outbox” instead of
the “Inbox”. The user also changed her profile without any troubles.
28
The user completed the second scenario in a shorter amount of time than the first
scenario. During the second scenario, the user commented that clearer confirmation was
needed after creating and saving a new carpool.
User 2:
24-year old male undergraduate student who takes the bus everyday to campus,
has never used a carpooling website before, but has been a carpool in the past and would
consider joining a carpool. During the course of the first scenario, the user clicked the
back button on the browser instead of the back button on the Flash movie, which caused
him to go back to the previous web page and had to start the test over. This user also had
trouble using the keyboard on the laptop since he is used to bigger keyboards made for
desktops. The user found that the directions on the task list were a little confusing, which
made it harder for him to understand what he should do, and that the tab order on the sign
up page was sort of annoying. The user did not have trouble searching for a carpool, but
did have trouble finding the details of a carpool and commented that the buttons on the
interface and the error and confirmation messages should be more distinct and clear. The
user said that he liked how the routes were mapped out after searching and that the drop
down box of his carpools on the message page was very helpful. When trying to edit his
profile, the user could not find how to do so. The user consulted the help page and could
not find anything on how to edit his profile, but the user eventually found the “Edit
Profile” button on the “Home” page. The user commented that it would have been easier
to find the profile page if the button for it were clearer.
The second scenario was completed with less confusion and in less time. The
user commented that it was neat when creating a new carpool, the information that he
searched for was already on the new page for him, but he also said that better feedback
for creating a new carpool was needed. The user found that the “View/Edit Carpools”
page was a little confusing to him and that the page would be easier to understand if the
information on the left hand side and the information on the right hand side were
switched to make the editable information the first thing a user comes across. The user's
biggest issue was that the buttons on the interface were not clear since they looked like
the normal text.
User 3:
28-year old male undergraduate student who drives to campus every other day,
has never used a carpooling website before, but is currently participating in a carpool.
During the first scenario, the user found the tab order on the sign up to be annoying and
commented that it would be useful if there were a back button on the sign up page. The
user had a relatively easy time searching for a carpool and liked how the results were
mapped. The user commented that the “leeway” drop down menu should have an
external label so that it is easier to remember what that drop down menu is for. The user
also mentioned that the confirmation messages and buttons should be more obvious, and
that the search page would be better if there was a way for users to add new addresses to
the address drop down menu. When this user clicked the “View Details” button without
selecting a carpool first, an error revealed that some error checking for the button was
missing. The user did not like how the carpool key did not dynamically match the
carpool results on the map. Without any trouble, the user sent a message to his carpool.
29
The user commented that the drop down menu for his carpools on the “Messaging” page
was good and that an extra drop down menu for the riders in his carpools on the
“Messaging” page might be useful. Additionally, the user pointed out another missed
error such that the username and carpool ID need to be different so that the messaging
system can distinguish between them. The user liked having a copy of the message that
he sent to his carpool.
The user completed the second scenario faster than he completed the first scenario.
The user liked how the values from his search were entered in the page for creating a new
carpool. However, the user did find that the drop down menu for the riders of the carpool
was unclear to him when creating a new carpool. The user's biggest issue was that the
buttons on the interface were not clear since they looked like the text.
User 4:
25-year old male graduate student who drives or bikes in to campus every day,
never used a carpooling website before, but has previously been involved in a carpool.
The user easily created a new profile in scenario one, but commented that the tab
functionality was not working for the various form text boxes. The user was able to log
in and had little problems preparing a search for a carpool, although he wondered
whether a rank had to be specified or not for a search to succeed. When looking for a
given carpool the user commented that selecting a carpool from the drop down menu of
results didn’t do anything, and then proceeded to the edit/view carpool tab to look for
information, which deleted the search results. Second time around the carpool details
were found, but the user noted that there was little in the way of confirmation, and the
feedback was unclear on whether he was added to or had requested to join a carpool.
The user also said he would like to see the actual numbers for the “travel time”,
“time added” and “time match” ranking options for the search. In addition, the user felt
that carpool key should also be ranked accordingly to the rank option. When requesting
to join a carpool for the 5 o’clock departure from UMD, the user said that he wasn’t sure
if he had clicked the request button several times and if that meant he had added several
instances of that carpool. The remaining tasks were completed with little trouble or
confusion, but the user commented that perhaps the profile page should have a separate
tab and that the help page did not have a log out button in the top right-hand corner. The
user’s final remark was that he thought the site seemed very easy to use once the bugs
had been removed, but that perhaps the buttons should be made more distinct from the
normal text.
User 5:
23-year old male graduate student who drives or walks in to campus every day,
never used a carpooling website before, and have never been involved with a carpool.
The user easily sets up his profile, only having issues with the lack of a clear tab structure
and the fact that the password field did not star out. Logging in and setting up the search
was also done quickly, but the user had some comments on how the search results were
portrayed. First, the user attempted to click on the map to select a given carpool, before
finding the drop-down menu of carpools. Secondly, the user felt that the best carpool
should be given more emphasis in the display, and that the different patterns used for
distinguishing each carpool route confused the ranking. The user also noted that
30
controlling the transparency of each carpool for ranking wasn’t clear enough and that
perhaps some other solution should be found.
When repeating the search for the second part of scenario, the user said he didn’t
immediately know what the “time added” ranking meant. The user also had difficulties in
finding where to alter the email address, and said he was confused by the fact that many
of the buttons were very similar to the normal text in the interface. While the user
successfully went to the help page for clues, he found that it was missing information
about the profile page. The second scenario was performed without significant difficulties,
and the user added that he liked the way the search information automatically populated
the page for creating a carpool.
User 6:
46-year old female staff member at the University of Maryland, who drives to the
University from her home in College Park, has never used a carpool website, has not
carpooled before, and has not considered joining a carpool. The user had repeated
difficulty with the wording of the task list, but once she understood what was meant she
navigated the system fairly well. Some of the usability issues the user mentioned
included a lack of confirmation after completing certain key tasks, the lack of ability to
press the enter key when clicking the various “submit”-like buttons, and the lack of
saving the state of certain screens after going to other areas of the system and then
returning later. One of the features she expected to see was an easy way to view some of
the statistics of a carpool, such as the current number of riders and who the riders are.
The “View Details” button, which completes part of this task, was not prominent or clear
enough to be seen as a potential solution. Another feature she would like to see is an
easy way to try and join another carpool with members of a carpool to which she already
belongs to. Specifically, if a user forms a carpool to the University in the morning with
three other individuals already in the carpool, it would be nice if there was an easy way to
try and find a carpool leaving the University with the same users. Overall, she felt that
the system was easy to use and useful after overcoming the learning curve, but she would
not use the system because of her proximity to the university.
User 7:
28-year old male staff member at the University of Maryland, who commutes by
car to the University from southern Maryland, has never used a carpool website, has not
carpooled before, and has not considered joining a carpool. The user had issues with the
instructions in the task list, but afterward performed fairly well. This user stumbled over
the task of creating a new profile, mostly because of the wording of the task, but would
like to see the tab key move the cursor from in order on the signup page. Also,
throughout the testing, the user noted several other interface changes that could be made
to improve the system, such as changing the “Enter” button on the login screen to “Log
in,” changing the hour and minute inputs in the search form to drop-down boxes with 5
minute intervals, pressing the enter key instead of clicking a button, rewording the labels
of the ranking choices, and changing the process of creating a new carpool so that a
carpool name is not required before clicking the “Create Carpool” button. Also, in
relation to the map, the user suggests changing the coloring on the map (specifically the
green route), clarifying the meaning of the numbers along the routes on the map in the
31
search results, enlarging the map, and ensuring only carpools that appear in the results
appear in the map key. The user also noted that notifications are not visually emphasized.
Lastly, the user had trouble with the distinction between a carpool with a driver and a
carpool without a driver—to him, a carpool must have a driver, so creating a carpool
where the creator is not the driver struck him as confusing. Overall, he felt that the
system was useful and easy to use, after overcoming the learning curve.
User 8:
37-year old female staff member who commutes to the University of Maryland
from Bowie, has never used a carpooling website before or participated in a carpool, but
has considered joining a carpool. This user had issues with the task list instructions, with
not being able to use the tab key to move from one input to another in order on the sign
up page, and with some visual issues with the map. Additionally, she had some
suggestions in the flow of the system, namely that it would be useful to go from the sign
up page directly into the Carpool.UMD system instead of back out to the login screen, the
“Edit Profile” button should be in the top menu, and logging out should go to a logout
page instead of back to the login page. After completing the first search, the user was
confused by the order of the results. She expected them to be sorted alphabetically, but
when they were not she did not immediately understand why, and then suggested that the
method by which the results are sorted should be made clearer. She also shared some
concerns with the color schemes used on the site, specifically the green route on the
search results map and the red text disclaimer in the help page, sign up screen, and edit
profile screen. In both cases, the contrast of colors was visually displeasing. She also
shared her confusion over the labels of the ranking methods, saying that she wasn’t sure
of the distinction between some of them. Lastly, the one feature she felt would be a
useful addition is the ability to save and modify searches so that parameters don’t have to
be re-entered every time. The user felt the system was as a whole useful after the
learning curve, but pointed out some areas where relatively small changes would prove to
be a great improvement.
User 9:
19-year-old female undergraduate student, who lives in Fort Washington, often
commutes to school 3 days a week by metro, car, or bus, has never used a carpooling
website, has participated in a carpool in the past, but has not considered joining a carpool
recently. The user had some trouble when after accidentally clicking the “Sign Up”
button instead of logging in. There was not a back button or any other way to allow the
user to leave the sign up page but to restart the test over. The user thought the search was
difficult at first but she found the search easier to use after using it a second time. Unsure
of whether or not she had joined a carpool, the user suggested that the confirmation
messages should be more obvious. This user indicated that she would like to use the
website one day, but thought it should have a tutorial for the search features.
User 10:
30-year old male staff of the University of Maryland, who lives 20 minutes away,
often has to take trips to conferences, so he would like to have others ride with him to
make it easier and less boring. This user has never used a carpool website, has not
32
carpooled before, and has not considered joining a carpool. The user enjoyed the design
and found the search a little difficult on the first try. The user also did not know that he
had to name the carpool before adding it and indicated that better error messages would
be more helpful. The thought of a carpool seemed like good idea but the user mentions
that he feels that staff and students should have separate websites. This would allow staff
to ride with other members that may be going to the same conference, but don’t know
each other. He was not eager to ride with students of any kind.
User 11:
21-year old male music major undergraduate who has never used a carpooling
website or carpooled before, but has considered joining one. The user had no difficulty
in signing up or logging in, with the exception that tab order skipped the password field.
The user also disliked that the password field was not encoded, which could potentially
allow passerby’s to see their chosen password. Once logged in, the user was shortly
confused as to what to initially do at the main menu. After recognizing that the
appropriate button to start the task was “Search for a Carpool”, the user then hesitated on
deciding whether to select the “To UMD” or “From UMD” radio button based on the
user task guidelines. The user commented that it would help to have a “from” column
and a “to” column. Searching for a carpool provided no problems, however the user
became confused after returning from the view details page to find that the carpool they
had selected was not saved for them.
In the second scenario, the user wasn’t paying attention and tried to sign up, but
upon re-reading the task list, he noticed that a login was provided for him. The user was
frustrated by the lack of a “previous” or “back” button from the sign up page in case of
such errors. The user also didn’t like the lack of a confirmation or conclusion page for
actions such as creating a carpool or joining a carpool. The user was unsure if the actions
had actually been confirmed, regardless of the confirmation message that showed.
User 12:
20-year old male English major undergraduate student who has never used a
carpooling website or carpooled before, but has considered joining one. The user had no
difficulty signing up or logging in. After searching for a carpool, the user did not
understand that the results were sorted based on the ranking preference. The user
commented that it would be nice to add a feature to show all carpools leaving from a
location in order to choose a carpool based on existing carpools and alternate locations.
After sending a message, the user suggested that the message he just sent should not be
displayed in his inbox. The user also had problems changing his email address because
he could not find where to go to do so.
User completed task 2 faster than task 1. The user was confused when creating a
carpool, significantly due to the lack of guidance on the create carpool page. He also
wanted to try to change the day, time, and location of the stop of the created carpool, but
was unsure of how to do that.
33
Post-test Questionnaire Results
Post-Questionnaire Results
Average User Rating
9.0
8.0
7.5
7.0
7.2
7.1
7.3
2
3
4
5
7.0
7.4
6.9
6.7
6.0
5.0
4.0
3.0
2.0
1.0
1
6
7
8
Question
Key:
1)
2)
3)
4)
5)
6)
7)
8)
Registering/setting up profile
Site navigation
Searching for a carpool
Joining a carpool
Proposing a carpool
Modifying a carpool*
Sending a message
I can find the page I need to go to
* Column 6 is out of 8 users instead of 12
Figure 19 Post Questionnaire Results
Analysis of Results
The average time it took for the users to complete the tasks was nearly double our
expected time of 10 minutes. Users overall responded favorably to our prototype,
averaging responses between 6.7 and 7.6 on a 1 to 9 scale (1 being least favorable and 9
being most favorable). However, while none of these responses were low, there were
also not particularly high, implying that while our interface is good there is definite room
for improvement. This statement accurately captures the comments given to testers after
testing was completed.
34
We found that the top four problem areas mentioned by our twelve users were:




a lack of clear confirmation and error messages
buttons that were indistinguishable from normal text
a confusing presentation of search fields and results
keyboard navigation of the interface behaved unexpectedly
Before discussing the responses to the post-test questionnaire in detail, it should be noted
that we have decided to exclude question 6 from our analysis due to some confusion
surrounding that item. Four people respond "Not Applicable" to this question even
though they each completed a "Modify Carpool" task. While this was informative in that
these users highlighted the confusion surrounding this aspect of our design, we decided it
would be inappropriate to compare the responses to this item with the rest of the
questionnaire. Therefore, excluding question 6, the questions in the post-test
questionnaire which addressed site navigation received the two lowest scores from all the
users (questions 2 and 8, with average scores of 7.0 and 6.7 respectively). When
observing our users complete the two scenarios, the hardest task for the users seems to be
finding screens that they needed to go to, do largely in part to the difficult they had
distinguishing buttons from normal text. This problem was most noticeable when users
were looking for a way to edit their profiles. The “Edit Profile” button was on the Home
screen, but almost everyone had trouble finding it because the button looked like regular
text to them. The lack of confirmation messages influenced the third lowest score the
“Joining a Carpool” task (question 4, average 7.4). Many users noted confusion during
this part of the task list, expressing uncertainty as to whether they joined a carpool
successfully. The easiest tasks appear to be setting up a new profile and sending a
message (questions 1 and 7, averaging 7.6 and 7.4 respectively). The users probably had
the easiest time with these two tasks because they were the least demanding.
In addition to the items we addressed in our post-test questionnaire, some testers
volunteered their own opinions and recommendations during the testing process. Four of
our users commented that there was not a way to exit the sign up process when they did
not want to sign up for a new account. Another user mentioned that it would be better to
have a separate landing screen for log out instead of going back to the login screen. Also,
two of our users indicated that they liked how their search parameters were saved when
they were creating a new carpool. Overall, all users were instinctively aware of the
numerous principles of good human-computer interaction without having any formal
education in the subject, which was an enlightening insight to the usefulness of extensive
usability testing.
On the next page is a detailed list of the problems that arose during our usability testing,
along with the importance placed on these items by our users (1 being not important and
5 being very important), and our estimations as to the ease of correcting these problems
(1 being easy to correct and 5 being hard to correct).
35
Problem
Importance
(1=least, 5=most)
Ease to Correct
(1=least, 5=most)
Search results is not presented well
Search page is hard to understand right away
Confirmation/Error messages aren’t obvious
Buttons that look like normal text
Making “Edit Profile” easier to find
Help page is not updated
5
5
5
5
5
5
4
4
3
2
2
1
Carpool key doesn’t match results on map
Tabbing order on sign up page
No back button on sign up page
View Details button doesn’t error check
4
4
4
4
3
2
1
1
Sent mail goes into inbox (no outbox)
Need to reorganize view/edit carpool page
Selected carpool on search page isn’t saved
3
3
3
4
2
2
Can’t add new addresses
No separate logout page
2
2
5
1
Password on create profile page doesn’t star out
Can’t use enter key to click buttons
1
1
5
5
Effect of Results on Final Design
Once we collected our test subject comments, we used the feedback to help improve both
the interface and the backend. Reply for messaging was fixed, as were bugs for the
“Home” button. In addition, we improved the error and confirmation messages to be
more descriptive and obvious to the user. During the redesign process the size interface
size needed to be enlarged, mainly to allow a larger map to be displayed and extra
buttons on the navigation bar. This was done by increasing the resolution from 550X400
to 640X480, and would also help users with bad eyesight and get better pixilation on the
colors.
On the “Login” screen, the “Enter” button was changed to read “Log In”, to remain
uniform with the instructions. In addition, during user testing it was discovered that our
original color scheme was difficult to distinguish buttons from normal text, so the button
font color was changed to blue with a yellow rollover. This can be seen on the “Log In”
and “Sign Up” buttons in Figure 20.
The Sign Up screen was a problem, because user if the user selected “Sign Up”, when
they meant “Log In”, they could not fix the error without reloading the screen. Also the
order for tabbing through the text boxes skipped the “Password” text box. So, we created
a “Back” button on the Sign Up screen and fixed the tab order. As many of the users felt
that that “Edit Profile” should always be available, we decided to put “Edit Profile” tab in
the navigation bar, as seen in Figure 21.
36
Figure 20 Alterations in the login screen
Figure 21 Alterations to the navigation bar
37
One of the aesthetic changes we made was to the navigation bar (see Figure 21). The text
for “View/Edit Carpool” button was changed to “Manage Carpools” for clarity and space.
On the Select Carpool screen, the text of the “Edit Carpool” button was changed to
“View Carpool”, again for clarity. Lastly, the label in the navigation bar was changed
from “Search for Carpool” to “Search/Create Carpool”, so users would know all their
options before they select.
The Search/Create Carpool screen had the most changes, mainly because most of the
interaction happens at this screen. Colors for the result carpools on the map changed to
make it easier to distinguish the routes against the background. Carpools were listed with
radio buttons instead of a drop box and each input box was given an external label to
reduce user error. The rank selection was also moved close to the results list to
emphasize the dynamic effect this has on the results ranking, as seen in Figure 22. The
respective ranking time for each carpool was also added to the right, as this was an issue
with some of the users.
Figure 22 Alterations to the search screen
38
One of the major issues that arose through the usability testing was inadequate user
feedback, particularly in the “Search/Create Carpool” screen. The error and notification
messages to the user were printed in plain text and font 12 at the top of the screen. After
reviewing the results of our usability testing, it quickly became evident that these
messages were not easily found by the user and led to confusion. As a result, we
researched various forms of notification within Flash movies and decided to implement
message pop-ups on the “Search/Create Carpool” screen for our revision.
Users also stated that more functionality for the messaging system would be useful so in
addition to a dynamic list of carpools, we created a dynamic contact list of riders to make
messaging easier and reduce the need to remember usernames. Security was an issue we
had at the beginning of this project, but the messaging system is contained within the
Carpool.UMD system, so users maintain the privacy of their personal email addresses.
Figure 23 Alterations in the create message screen
39
A logout screen was also created, so the users know they are logged out with the option
to log back in, illustrated in Figure 24. This provides users with a sense of closure and
confirmation that they have successfully logged out of the Carpool.UMD system.
Figure 24 Logout screen added
Conclusions
Final Status
The current version of Carpool.UMD has full functionality of the following features:
creating a new account, modifying a profile, modifying carpool information, and
messaging other users. It has partial functionality of the feature: searching for a carpool.
The current limitation is that carpool data is not saved across sessions, so users can only
search for carpools loaded at startup or created during that session. Users may sort their
carpool results based on various ranking functions. Carpools are matched by the day of
the week, proximity to the user's desired arrival time, destination of the carpool, and the
total travel time for the carpool. The total travel time for a carpool is calculated by taking
the distance that the new stop would add to an existing carpool route and arbitrarily
dividing that number by ten. Users may change and save their profiles, as well as send
messages to other riders in their carpools by using the messaging system. Carpool
information can also be changed and saved by the users. Users can also view other users'
profiles and detailed information about carpools.
40
Future Work and Recommendations
The implementation of a dynamic map system to display the routes of carpools and an
additional database to contain addresses would be the next step to improve the system.
Such changes would allow users to dynamically add new addresses to Carpool.UMD and
to actually see where the carpool route goes. The database would solve the current
limitation of searching through carpool data. Another change would be to implement a
calendar visual of a user's carpools on the home screen. We believe adding a calendar
visual to the home screen would help users keep track of their carpools. For future
iterations of Carpool.UMD buttons should be changed to look more like buttons instead
of just strictly text, as well as integrating keyboard shortcuts so that expert users can more
efficiently use the interface. Lastly, while many features of our interface are fully
functional, they do not encompass the full complexity we originally imagine. An
example of this is the user profile, where originally it would also feature the ability to
load a picture and provide personal, optional information. Therefore, other minor
changes that would enhance the overall product would be to go back to the original,
ambitious designs and implement some of the more complex, and more trivial, features.
As a recommendation to future developers of such a system, try using a development
environment that is not as complicated and restrictive as Flash 8. To effectively
implement a carpooling website, it would be best to use a better scripting language such
as PHP or JavaScript, which can easily accommodate Google Maps or another dynamic
map system. Also, when creating the interface, remember to make confirmation and error
messages clearer than a simple text box message on the screen.
Acknowledgements
We would first like to acknowledge the help of our classmate Sally Divita, who assisted
us with the implementation of our first version of the high-fidelity prototype as part of a
class project.
We would also like to acknowledge our usability testers, and our project commentators,
who gave us numerous constructive comments and fresh insights into the various aspects
of our design.
Additionally, we would like to acknowledge our professor, Dr. Ben Shneiderman, and his
teaching assistant, Khoo Yit Phang, who were kind enough to work with us to
accommodate our schedule.
41
References
Carpool Zone. 2006. Smart Commute Association. Accessed: 1 Oct. 2006.
<http://www.carpoolzone.smartcommute.ca/en/my/>.
eRideShare.com Carpool/RideShare Community. 2006. Accessed: 28 Sept. 2006
<http://www.erideshare.com/>.
Flash/JavaScript Integration Kit. 2006. Macromedia.
http://weblogs.macromedia.com/flashjavascript/, accessed 11/10/06.
Giesecke, Simon and Gerriet Reents. “ORISS: A Web-Based Carpooling System.”
Information Systems for Sustainable Development. Ed. Hilty, M. Lorenz,
Eberhard K. Seifert, and Rene Treibert. Hershey: Idea Group Publishing, 2005.
260-276.
Haselkorn Mark, et al. “Bellevue Smart Traveler: Design, Demonstration, and
Assessment.” Washington State Department of Transportation, Report No. FTAWA-0039-95-1. Seattle: University of Washington, Washington State
Transportation Center, 1995
<http://www.itsdocs.fhwa.dot.gov/jpodocs/repts_te/25q01!.pdf>.
Introduction to Developing with Google Maps [Internet], Directions Magazine.
http://www.directionsmag.com/article.php?article_id=2120&trv=1, accessed
09/29/06.
Keenan, Peter and Shane Brodie, “A Prototype Web-based Carpooling System.”
Americas Conference on Information Systems. Long Beach, 2000.
Loukakos, Dimitri and Rosella Picado. “Ridematching.” ITS Decision. 1 Nov. 2000.
University
of California at Berkeley and California Department of
Transportation. Accessed: 1 Oct. 2006
<http://www.calccit.org/itsdecision/serv_and_tech/Ridematching/ridematching_re
port.html>.
Olsson, Marie and Gerald Miller. Parking Discounts and Carpool Formation in Seattle.
Washington D.C.: The Urban Institute, 1978.
PTS: Carpools. 2006. The University of Texas at Austin. Accessed: 28 September 2006
<http://www.utexas.edu/parking/transportation/carpool/>.
Smart Park Carpool Program for Commuter Students. 2006. University of Maryland,
Department of Transportation Services. Accessed: 20 Sept. 2006.
<http://www.transportation.umd.edu/alternative_transportation/students.htm>.
http://www.transportation.umd.edu/alternative_transportation/students.htm
42
Terveen, Loren, et al. “Location-aware community applications: Privacy Issues and User
Interfaces.” Location Privacy Workshop. 2004.
Wash, Rick, Libby Hemphill, and Paul Resnick. “Design Decisions in the RideNow
Project.” 2005 International ACM SIGGROUP Conference on Supporting Group
Work. Sanibel Island: ACM Press, 2005.
43
Appendix A: Usability Questionnaires and Scenarios
Pre-Test Questionnaire
1. Age: __
2. Gender: __ male __ female
3. What is your affiliation with the university?
__ undergraduate student __ faculty
__ graduate student __ staff
4. How many hours per week do you use the Internet?
__ less than 1 __ 10-15
__ 1-5 __ 15-20
__ 5-10 __ more than 20
5. How many hours per week do you spend on social networking websites (such as
Myspace, Friendster, Facebook etc)?
__ less than 1 __ 3-4
__ 1-2 __ 4-5
__ 2-3 __ more than 5
6. Have you ever used a carpooling website in the past ? __ yes __ no
7. How do you currently travel to and from campus (select all that apply):
__ Metro __ car
__ MARC train __ walk
__ bus __ bike
__other:____________
8. Are you familiar with the SmartPark program through the University of Maryland’s
Department of Transportation? __ yes __ no
44
9. Are you currently, or have in the past been, in a carpool? __ yes __ no
10. Have you ever considered joining a carpool? __ yes __ no
11. Do you own a car? __ yes __ no
12. Do you have a driver’s license? __ yes __ no
Do you have any physical impairment (such as reduced vision/hearing, mobility etc)? __
yes __ no
45
Prototype use instructions
Scenario 1:
1. Signup to Carpool.UMD by creating a new profile
a. Use username “ljohnson” and password “password”
b. Set your email as ljohnson@mail.umd.edu
c. Set your first name as Lucy
d. Set your phone number as 301-555-1234
e. Indicate that you can drive
f. Indicate that you are a smoker and are female
g. Set your affiliation with the school (student)
2. Login with username “ljohnson” and password “password”
3. Search for a carpool leaving from Ashton Pond that…
a. Arrives on campus within 30 minutes of 9:00 am on Tuesdays
b. Takes less than 30 minutes
4. Look for potential carpools that have…
a. More than one rider
b. The shortest travel time
5. Join any suitable carpool
6. Repeat search for a carpool leaving from campus on Tuesdays that…
a. Leaves the university within 20 minutes of 5:00 pm and arrives to any of the
addresses listed
b. Takes less than 30 minutes
7. Join any suitable carpool
8. Send message to your carpool notifying that you want to leave campus one hour earlier
9. Change registered email address to ljohnson@gmail.com
10. Logout
Scenario 2:
1. Login as “gsimmons” with password “password”
2. Search for a carpool that…
a. Arrives to campus from Ashton Pond within 20 minutes of 8:40 am on Mondays
b. Takes less than 35 minutes
c. Choose any ranking
3. If none can be found, create a new carpool, else join any suitable carpool
If no carpool can be found:
a. Set name to “AshtonMonday”
b. Leaving from Ashton Pond on Monday
c. Arriving to campus at 8:40 am
d. Change maximum riders to 5
4. Repeat search for Tuesday that leaves from Ashton Pond
a. Arrives on campus at within 20 minutes of 8:40 am
b. Takes less than 35 minutes
c. Adds the smallest amount of time to the other rider’s travel time
46
5. Join any suitable carpool, if none can be found, create a new carpool
6. Logout
Post-Test Questionnaire
1. Would you consider using this website to search for/join carpools? __ yes __ no
Please rate your experience completing the following tasks by circling the number that
most appropriately reflects your impression about using the system. Not Applicable =
NA.
2. Registering/setting up profile (hard->easy)
1 2 3 4 5 6 7 8 9 NA
3. Site navigation (hard->easy)
123456789
4. Searching for a carpool (hard->easy)
123456789
5. Joining a carpool (hard->easy)
1 2 3 4 5 6 7 8 9 NA
6. Proposing a carpool (hard->easy)
1 2 3 4 5 6 7 8 9 NA
7. Modifying a carpool (hard->easy)
1 2 3 4 5 6 7 8 9 NA
8. Sending a message (hard->easy)
1 2 3 4 5 6 7 8 9 NA
9. I can find the page I need to go to (hard->easy)
123456789
10. Please provide any additional comments about the system here:
47
Appendix B: Database Schema
Carpool Database:
Field
carpoolID (unique identifier)
Day
Time
hasDriver
maxRiders
expDate
Proposer
Riders
toUniv
Type
String
String
Time
Boolean
Number
Date
String
Element of Riders Database
Boolean
Messaging Database:
Field
messageIndex (unique identifier)
Recipient
Sender
Subject
Body
Read
sendTime
Type
Number
String
String
String
String
Boolean
Date
Riders Database:
Field
username (unique identifier)
Driver
Loc
Type
String
Boolean
Location
48
Users Database:
Field
username
canDriver
smoker
gender
password
email
phone
firstName
univAffiliation
Type
String
Boolean
Boolean
String
String
String
String
String
String
49