Working Paper 04-02
Ridematch Systems 21: The Role of User Feedback in the Design and
Implementation of Registration, Matching and Administrative Subsystems
Chicago Area Transportation Study 300 W. Adams Street, Chicago, IL 60606
Working Paper 04-02
Ridematch Systems 21: The Role of User Feedback in the Design and
Implementation of Registration, Matching and Administrative Subsystems
By Jose Rodriguez, AICP
Senior Rideshare Services Representative
May 2004
RIDEMATCH SYSTEMS 21: The Role of User Feedback in the Design and
Implementation of Registration, Matching and Administrative Subsystems
Ridematch Systems 21 (RM 21) is the Rideshare program’s real-time matching, Inter/Intranet-
accessible carpool/vanpool enrollment and management tool for linking general users, employee
transportation coordinators and service agencies with access to potential ridesharers.
The various functions of RM 21 have been subjected to continuous and rigorous testing through
automated testing processes, randomly selected focus groups, selected employers, and
administrators from local service agencies. The most critical systems under continuous
adjustment were the automated route-making, user match notification and administrative report
generation systems. Accurate routing and prompt user notification will affect the public’s
acceptance of this Web-based system; the utility and responsiveness of administrative report
generation will determine whether employers, often the most effective proponents of rideshare
programs, and service providers — the providers of necessary capital (e.g. vans) — can use
Ridematch Systems 21 as an effective tool in reducing peak period travel congestion and
improving regional air quality.
Each user of the test version of RM 21 has provided valuable feedback to the system’s architect,
the Artificial Intelligence Laboratory at the University of Illinois at Chicago (UIC), and the
Chicago Area Transportation Study, the coordinator of the project. This paper summarizes their
responses to various tests and reveals how their suggestions have molded the final product.
i
TABLE OF CONTENTS
1. Current Practices in Regional Ride-Matching .....................................................1
2. The Forerunner: CAR-A-VAN ............................................................................2
3. Ridematch Systems 21: an Introduction ..............................................................3
4. Working Groups...................................................................................................5
5. CATS and Pace System Integration...................................................................10
6. Focus Group Findings: .......................................................................................10
7. Employer Beta Testing at Discover and CCH ...................................................14
8. System Evaluation Activities .............................................................................15
Bibliography.............................................................................................................16
APPENDIX 1. Completion Status Memo (April 29, 2003) ....................................17
APPENDIX. 2. DRAFT USERS MANUAL, APRIL 2003....................................21
ii
1. Current Practices in Regional Ride-Matching
Increasing the efficiency of the road network is one way to reduce traffic congestion and
improve air quality. Increasing the average number of occupants per vehicle through car/van
pooling and mass transit provides a means of making more efficient use of the roads. CATS
Rideshare Services has provided matching services for interested persons looking for carpools
and vanpools since 1986.
In 1991, CATS Rideshare Services began using POOLMATCH, a stand-alone Unix-based
software package developed by Crain and Associates, to match users based on application
information provided in voice recordings. Users applied for ridematch services by calling the 1-
800-920-RIDE telephone hotline, printing a paper application from the CATS Website,
www.catsmpo.com, or filling out an application online and e-mailing it to
Pre-RM21 ridematching services required a CATS staff member to collect information about
pickup points, destinations, start and stop times and other ride-related preferences received from
each interested applicant and then entering that information into the POOLMATCH system.
Either a match letter (person receives contact information about possible carpool partners), or a
no match letter was generated. The match or no match letter was then mailed to the address
provided by each respective applicant.
During the early 1990s, CATS Rideshare Services operated as a resource for employers who
were required to develop Travel Demand Management (TDM) plans in order to meet standards
established for mobile source emissions reductions in the federal Clean Air Act Amendments
(CAAA) of 1990. This subcomponent of the CAAA was referred to as the Employee Commute
Options (ECO) program. The POOLMATCH system was not only capable of matching
individuals to each other, but also was able to produce batch letters, perform rudimentary cluster
analyses based on X Y grid coordinates and produce select lists of users from queries based on
several user-information based variables. The designation of Employee Transportation
Coordinators (ETCs) by individual employers was a necessity for developing TDM measures:
the ETC played a critical role in assembling match lists, encouraging employees who resided in
close proximity to each other to carpool, and helping to promote the use of transit as a mode of
travel to work by employees living near transit facilities.
In 1995, the federal government discontinued the Employee Commute Options program. CATS
Rideshare Services subsequently recast itself as a promoter of voluntary TDM measures to the
area’s employers. As the region’s MPO and an administrative sub-unit of the Illinois Department
of Transportation, CATS had little difficulty in establishing a nexus between extending the
useful lifespan of existing roadway facilities, reducing peak period work-trip related traffic
congestion and enhancing air quality. To promote a voluntary program, participants (employees)
would have to be shown the cost savings and stress reduction benefits of ridesharing.
The Commuter Choice Parking Cash Out and Employer Transit Benefit programs were
established as a result of the 1998 Transportation Equity Act for the 21st Century (TEA-21).
Commuter Choice provided a means by which employers could provide transportation benefits
1
or cash in lieu of free parking in a manner that provided tax benefits for both the employee and
the employer.1 Commuter Choice benefits were an important step in maximizing the utility of the
more traditional commuter rail, city bus and rapid transit services during the late 1990s and into
the early 2000s. However, vanpool services, which were eligible for reimbursement under many
employer-based Commuter Choice programs, were not being developed as quickly. The largest
vanpool service provider in the area, Pace Suburban Bus, saw a great need to develop a more
visible, more rapid and more accessible system capable of matching persons and building a
market for larger volume ridesharing arrangements.
2. The Forerunner: CAR-A-VAN
In conjunction with the Transportation Management Association (TMA) of Lake Cook, a more
accessible and user-friendly version of POOLMATCH, CAR-A-VAN, was developed by Crain
and Associates from 1997 to 1999. CAR-A-VAN was launched as a stand-alone, kiosk-based
ridematching software system that could be installed in a single computer terminal in a high-
traffic location such as a cafeteria or lobby. Users would receive a real-time ridematch, so long
as there was a preloaded employee database to draw matches from.
CAR-A-VAN, a Visual Basic application, had an MS-DOS version of itself embedded within its
architecture. The system also included a modem-based data connection which enabled individual
employers to exchange the databases of their employees that were interested in carpooling or
vanpooling.
CAR-A-VAN, under the RideGuide name, was deployed with the assistance of CATS and
Transportation Management Association (TMA) of Lake Cook at five employer sites in
Chicago’s northern suburbs between the spring and summer of 2000: CDW, American Hotel
Register, PNC Mortgage, Associates Commerce Solutions and Illinois Student Assistance
Commission. Kiosks with terminals featuring the CAR-A-VAN system were deployed in a
variety of settings: cafeterias, employee benefit centers, break rooms and employee libraries.
Out of a total of 3,339 employees at the five locations, only 196 (5.9%) registered with the CAR-
A-VAN system. A follow-up survey evaluation of 45 respondents indicated that only 35% of
respondents had received match lists2. Testing revealed that no satisfactory electronic method of
data transfer (of employee information) had taken place apart from the unloading and cross-
shipping of floppy disks; modem transfer had not been reliable. This situation drastically reduced
the number of employees available for ride matching through the system at any given time.
During the ECO (Employee Commute Options) era, it had been standard practice for companies
to load entire employee databases for TDM planning. The RideGuide program’s participants
relied on returned surveys to collect information from persons interested in carpooling.
Businesses also began utilizing the Internet and company local area networks (LANs) for nearly
all of their cross-company communication needs.
1 US Department of Transportation, Commuter Choice Primer, Washington D.C. US DOT Federal Highway
Administration, p. 16-172 William Baltutis, RideGuide Final Report, TM A of Lake Cook, 2000, p.7
2
When the RideGuide kiosk application was developed in 1997, many employers in the Lake
Cook corridor — including Walgreen’s, Arthur Andersen, Baxter and Discover Card —
expressed a desire to support such a program. By the year 2000, many of the same employers
had expressed reservations about using a kiosk-based system to match riders and identify target
markets for larger volume HOV arrangements. The kiosk-based system was simply viewed as
outdated: why would employees want to go down to the kiosk in the cafeteria to obtain a carpool
application when they could use the Internet to submit an application and obtain matching and
other information from the comfort of their desks?3 After evaluating the costs of converting
CAR-A-VAN into HTML language for web programming, CATS decided to pursue the
development of a real-time matching Internet-accessible ridematching tool.
3. Ridematch Systems 21: an Introduction
Ridematch Systems 21 is the real-time matching, Inter/Intranet-accessible carpool/vanpool
enrollment and management tool developed by the UIC AI Lab and CATS. It was completed and
available for full utilization by June 30, 2003. CATS, through an Intergovernmental Agreement
(IGA) with UIC that commenced in February 20014, spearheaded an advanced technology
project to improve the communications, matching engine and reporting capabilities of its existing
carpool and vanpool ridematching programs. The project also provides a portal for commuters
and other travelers seeking information about existing transit and rail services, highway networks
and traffic conditions.
This objective of the project is to increase the amount of car/van pooling in the Gary-Chicago-
Milwaukee (GCM) corridor by making the process of finding car/van pool partners as easy and
convenient as possible. This system is available to individuals, employers and transportation
agencies to organize and manage their demand-responsive carpool, vanpool and high occupancy
employee transportation programs. The final product is a user-friendly Inter/Intranet-accessible
ridematching system that provides its users with practically real-time ridematching5.
As outlined in the IGA between CATS and UIC, the anticipated Ridematch System 21 features
the following enhancements:
Communications Environment
User friendly formats for data entry, database development, data retrieval and data
transfer.
Efficient data transfer between employers’ Internet installations, Intranet stations, the
main server and the CATS service and management system.
Communication tools such as fax and e-mail for application, notification, reporting and
update processes.
3 Baltutis, p. 7-84 John F. Dillenburg and Jose Rodriguez, Ridematch System 21: Using Vector-Based Matching to Direct
Ridematching Activities, University of Illinois at Chicago Department of Computer Science and Chicago Area
Transportation Study, October 2002, p. 45 ibid
3
Matching Engine Improvements
Real time, or as close to real time as feasible, ridematching between individuals and
among groups of individuals, as well as improved notification of database participants
when an individual is interested in finding a ridematch.
Access to the system for individuals and managers through current office systems
utilizing Windows-type environments.
Visual map displays for the purpose of geomatching, geocoding and selecting
ridematching areas.
Vector matching (along route), as well as radius match searching.
Report Writing
Incorporation of systems such as MS Word for word processing, Access for database and
Excel for basic spreadsheet analysis, and links to GIS/ARC or equivalent geographic
analysis software for second level analysis.
Applicant survey and purge operations will be automated.
Improved mass-mailing and document printing capabilities.
Travel Information Links
Links to other transportation alternate support systems such as the RTA Itinerary
Planning system and Metra schedule information.
Current highway information systems as contained in the GCM project.
Firm-specific preferred air carrier links.
Figure 1. Welcome Screen of Ridematch System 21 web site
4
During the course of the development of the new software, three very important sources of user
feedback have emerged as critical to the effective design and functionality of Ridematch System
21:
Working Groups composed of employers and the regional vanpool provider (Pace) lent
insight into how potential administrative users of the system envision Ridematch 21 as a tool
for developing comprehensive employer-based rideshare programs and developing larger
scale High Occupancy Vehicle (HOV) commute alternatives such as subscription bus and rail
shuttle services.
Focus Groups composed of a randomly selected sample of current suburb-to-suburb SOV
commuters. Since the outlying suburban areas of the Chicago region continue to account for
an increasing share of the area’s employment opportunities, workers who commute to these
areas would benefit tremendously from the availability of real-time ridematching.
Beta Test Participants culled from Discover Financial Services, CCH, Working Group
members, the occasional participating CATS employee, and others who made use of the
Ridematch 21 test Website for sample ridematches.
4. Working Groups
One of the first major milestones of the Ridematch Systems 21 development process was the
preparation of the Functional Requirements Document, which took place in August 2001. This
document served as assurance (from UIC system architect John F. Dillenburg) that Ridematch 21
would, at a minimum, contain the matching capabilities, query list, clustering, purging and
survey-building capabilities present in the POOLMATCH SYSTEM, as well as several major
enhancements. The architecture of the system is illustrated in Figure 2:
5
LAN
HomeUser
EmployeeUsers
Internet
EmployerAdmin
Content Filter(opt)
RidematchSystem 21
Vanpoolsubsystem
Websubsystem
CATSAdmin
PACEAdmin
Reportingsubsystem
Data storagesubsystem
Figure 2. RideMatch 21 System Architecture 6
The system has been broken down into the following subsystems:
Administration
Data Storage
Matching
Web
Reporting
Survey
Purging
Georeferencing
Vanpool
The status of functional requirement fulfillment for the system through April 2003 can be viewed
on page (20) as addressed in Completion Status Memo (Dillenburg, April 18, 2003 – Appendix
1).
6 John F. Dillenburg, Ridematch System 21: Functional Requirements Document, University of Illinois at Chicago
Department of Computer Science, September 20, 2001, p. 6
6
In September 2001 and July 2002, Ridematch System 21 Working Group meetings were held at
CATS and UIC, respectively. Employers, including Hewitt Associates, Underwriters Laboratory,
Discover Card and Abbott Laboratories, were key participants. Their participation was critical
because these employers operate rideshare programs at various levels of maturity and in
coordination with regional players. Underwriters Laboratory runs an in-house (UL employees
only) matching system and provides company vans to its vanpool groups. Discover Card
maintains a stand-alone kiosk in an employee information booth, and has a part-time ETC
oversee matching and coordinate activities with local transit providers for shuttle bus and rail
service. Discover Card, located in Riverwoods, IL, is a major backer of the TMA of Lake Cook
and one of the largest beneficiaries of its transit initiatives. Abbott Laboratories maintains a
sizable carpool program with an ETC manually performing matches and calling large groups to
generate interest in vanpools. Hewitt Associates promotes the use of its rideshare program to its
7,000 Lake County employees through its company Intranet.
Service providers Metra, Pace and RTA were also represented in the group; Pace’s close
involvement was further explored through the formation of a CATS-Pace System Integration
Working Group (SWIG), consisting of members of Pace’s GIS, marketing development and
Vanpool management staff. Representatives from the Northeast Illinois Planning Commission
(NIPC), the Northwest Indiana Regional Planning Commission (NIRPC), the Illinois
Environmental Protection Agency, the IDOT ITS Office and the Chicagoland Chamber of
Commerce were also on hand to discuss the design of the system and to help ensure that it would
operate smoothly for both users and administrators.
Concerns presented to and answered by the CATS-UIC project team included:
How will users obtain a password? (Hewitt)
Users are assigned a password at initial registration, administrators are assigned a password by
CATS. A security certificate and data encryption was eventually added to the login sequence.
How can users identify a route or location? (Metra)
A map will be provided; this map will depict their “best” route, but will allow users to change
segments of their route to more closely align with their “willingness to pick up” distance (e.g. 3
miles away from route). Accurate route depiction is critical for generating successful matching
algorithms.
Will users traveling downtown be directed to Metra and other resources (RTA)?
Upon receiving a user with a work trip downtown, the system will automatically alert them to
consult the RTA Trip Planner Website.
Will Ridematch 21 be integrated into the GCM, and can users be alerted to construction delays
from the system? (TMA Lake Cook)
7
The system will feature a direct link to the GCM Website, enabling real-time views of the
region’s expressway, tollway and arterial networks.
Will employers be able to limit access to their proprietary databases? (TMA Lake Cook)
Employers can have their employees withheld from general (e.g. CATS) administrative and
matching functions.
The feedback from the working group and its member employers has resulted in the
establishment of a password-accessible comprehensive administrator subsystem capable of
producing cluster maps, generating select employee lists and editing individual employee’s
records.
1. Administrator Home Page and 2. Cluster Map Function
8
1. User Functions Menu; 2. Edit User Query Page; 3. Sample Commuter Listing
9
5. CATS and Pace System Integration
CATS and Pace moved toward assuring integration of available Pace services and provision of
user data mining capabilities for Pace to use to enhance existing vanpool and bus services and
develop new services by establishing a Systems Integration Work Group (SWIG) apart from the
RS 21 Working Group. The SWIG group met on a monthly basis from November 2001 to April
2003.
Staff from Pace’s marketing, vanpool services and information services departments worked
closely with the Ridematch System 21 project team to establish notification protocols for users
who might potentially fill a seat on a Pace van. Vanpool staff will also be enabled to mine the
Ridematch 21 database for potential riders of existing vans or for potential riders in planned
service corridors for buses and shuttles.
Technical improvements in the Ridematch 21 system arising from Pace staff involvement
resulted in a hybrid of the vector matching algorithm which could incorporate a radius element
for van stops. Pace’s work also spurred in great part the development of a standardized file
loading format in February 2003. The file loading format enables the mass importation of
employer databases, van drivers and the legacy database (users from POOLMATCH). Park-and-
Ride lot locations served by Pace express buses will also be accessible to users commuting to
work sites serviced by express Pace buses.
Among other topics touched upon in the Working Group meetings were:
Development of the Intelligent Travel Assistant, the 3G wireless PDA successor to
Ridematch 21.
Establishment of a Commute Club with a comprehensive commuter incentive package for
participants (oil changes, coupons, mortgage instruments for participants of rideshare) and an
area-wide Guaranteed Ride Home (GRH) program.
6. Focus Group Findings:
Focus Group Evaluation exercises were conducted under the direction of Dona J Vitale of
Strategic Focus, Inc. of Chicago:
Alpha Test Version, March 2003
The group consisted of six participants currently working in the Lincolnshire area (3 participants
were from Hewitt Associates) who were walked screen-by-screen through the registration
process, which, at that point, consisted of 7 Web screens.
The focus group embraced several of the Web screen features, especially the use of e-mail as the
primary means of communication between new ridematches. The weekly work schedule entry
screen, which featured optional day-by-day (Monday through Sunday) entry boxes for start and
stop times, received positive feedback from focus group participants, as it had from RS 21
Working Group members. Participants agreed that the Web registration sequence needed to
10
include better general definitions of the concepts of carpooling and vanpooling, including
information on registration, formation and the obligations and responsibilities to be borne by
carpool and vanpool participants. Currently, this information is made available within the /share/
section of www.catsmpo.com.
The route description screen that would allow users to define a linear route received a great deal
of constructive feedback from the focus group; this feature was eventually adopted and refined
significantly for the Beta test version software. All participants were asked to enter the names
used on streets in their route to work. All encountered confusion as to how to enter Illinois and
U.S. highway routes. A few stated that street names changed as they traversed through different
cities, and nearly all (about 5 of the 6) stated that they use different routes to work as traffic
conditions, weather, road construction activity and personal needs (e.g. household errands)
warranted. Two participants claimed they would need more than the eight entry screens provided
in the Alpha test version to accurately depict their lengthy route to work on a street-by-street
basis.
Each of the focus group participants felt that the real-time generation of mapped output,
featuring several choices for their typical route to work (similar to a Mapquest-generated map
with a line from home to work) would be helpful for proper vector matching. Utilizing this
concept, riders would be matched along routes based on their willingness to either pick up riders
or meet drivers within a stated distance indicated on the commuting preferences page (Step 9 of
9 of the current Ridematch 21 User Registration Sequence). This feature was reworked
considerably in advance of Beta version software testing.
Beta Test Version, October 2003
Nine suburb-to-suburb commuters were recruited to test the Beta version of the program at
IDOT’s Intelligent Transportation Systems (ITS) office in Schaumburg. Following is a screen-
by-screen critique of the Beta version’s registration sequence:
Welcome Screen
Inadequate description of Chicago Area Transportation Study.
No explicit connection between CATS Rideshare Services and SharetheDrive.org.
Carpool information does not provide strong reinforcement of personal cost savings one
may realize by carpooling.
No return button to Sign In page from CATS or Carpool Information pages (rectified).
Let’s Go Screen
Make clear that a user’s e-mail address will be provided to those persons that are
determined to be a “Match.”
Registration Step 1 of 9 Screen
Clearer references to the need to create a password and to the fact of user registration-use
the subtitle Registration as opposed to User Registration.
11
Registration Step 2 of 9 Screen
Some users had difficulties with abbreviations and misspellings in city names (e.g. MT
Prospect) - the system would then generate error messages.
Registration Step 3 of 9 Screen
Users thought that maps generated were accurate and easily understandable.
Registration Step 4 of 9 Screen
Direct entry box used for employer name presents little difficulty. Several users skipped
over the Company Name box and went directly to Work Address; several questioned why
a company name was necessary if the drop-off location was the basis of a match. The use
of an employer name is a necessary element for the separation of the general user
database from an employer-administered database. Several of the users had to re-enter
work addresses after error messages were received, four or five times in some cases.
They indicated that if it took them that long to enter a correct work address into the
system, they would probably give up.
Registration Step 5 of 9 Screen
Maps of employer locations accurate, useful and provided useful information about
address entry errors.
Registration Step 6 of 9 Screen
Registration Step 7 of 9 Screen (Manual Route Entry)
At this point, users were allowed to choose between selecting a computer-generated route
to work or entering a route manually. Most users initially accepted the default option
(Screen 6) but were seldom satisfied with the routes given. The routes depicted were, in
some cases, heavily dependent on expressways and major arterials — failing to include
faster shortcut routes — or featured collectors and minor arterials, not accounting for
backtracking by commuters to access higher speed expressways. This observation led the
system architect to reassign weighted values for speed and capacity to each segment of
the road system available in the geographic database.
The screens for manual entry were the most difficult part of the registration process.
When shown both directions of the first street, many users did not know to use the drop-
down button to select a different intersecting street segment. In fact, many became
frustrated with the feature after first attempting to type in the information instead.
The use of street names not recognized by the geographic database was an ongoing
problem which made it nearly impossible for three users to complete their manually-input
routes.
Registration Step 8 of 9
Users responded well to this screen. However, some were confused by the presence of
“Day Off” in the first instance of the Select Arrival Time and Select Departure Time
entry menus. They felt “Day Off” should be changed to “Select Time.” Some users filled
12
in the daily breakdown of schedules even if their hours were the same Monday through
Friday. Some suggested that using a separate drop-down menu for AM and PM would
make the time selection feature easier to use.
Registration Step 9 of 9 Screen
Preferences questions, in regards to carpool partners, were generally well understood.
Match List Screen
Each user was presented with a series of matches, complete with the match’s full name,
e-mail address and work location. Some users would e-mail potential matches without
hesitation, but others wanted more information about the person first. These users were
informed that the full name had a link to a map of the match’s home location (no address
provided) and company. Some users thought it would be better to list either a street
address or a cross-street intersection. Others wanted zoom capabilities for the maps.
Users also indicated that there should be a return button back to Match List Screen from
the map.
Users received matches with scores ranging from 50 to 90 percent. Several of the lower
scoring matches were impractical due to incompatible work schedules. In one case, a user
found a match who had the same route pattern but completely opposite start and end
(work) locations. Users suggested that only the 90% and above matches be shown.
With regard to e-mail notification of matches, users asked the following:
Could the system generate a sample introductory e-mail template for them to send to
a new match, introducing himself and providing some contact information?
Could the system notify users if alternative matches are found?
That they be prompted to remain, update their information or remove themselves
from the database every three to six months.
As a result of participant feedback from the October 2002 focus group, the registration sequence
was reduced from 9 screens to 8. The largest change made by the system architect was the
consolidation of the Route to Work functionality of screens 6 and 7 into a Route to Work display
screen featuring a map showing the user computer-generated “best route” route alongside a
dynamic segment-by-segment list. The dynamic segment list incorporates drop down menus with
alternate routes, enabling users who wish to change their route to do so without moving to
another screen. Changes were made to on-screen commands due to user’s confusion about
instructions and actions necessary to complete the registration process. “What this?” pop-up
boxes were added as an element of each screen, and “Breathe Easy Man” icons (featured in 6
different poses) materialized to indicate actions required by users and to make them aware of any
errors they’d made.
13
7. Employer Beta Testing at Discover and CCH
Employer beta testing was conducted from January 20 to February 27 at Discover Financial
Services and CCH, companies located adjacent to each other in Riverwoods, IL.
Both companies were sent an e-mail to be distributed company-wide, informing their employees
about the availability of the Internet-accessible ridematching service and to provide them with
the URL address for the test Website (http://rm21.ai.uic.edu). User feedback was provided
mainly via e-mails sent directly to John Dillenburg, as opposed to company ETCs. Following is
a compilation of system flaws and deficiencies identified by Discover and CCH employees
during the testing period.
Among the problems encountered during user registration (with action taken to correct problem
by Dillenburg in parantheses):
User felt too much name information was provided in generated matchlist; would prefer that
only FIRST NAME be shown to users who obtained them as a match.
The address 2500 Lake Cook Road was not recognized (required an overhaul of the 2003
version of the Navtech database used for geography).
Users were denied several cross-street options during interactive routing. (Updated Cross
Street Table Loaded into system.)
Return button on keyboard brought people to previous page rather than next page in
registration. (Default switched form BACK to NEXT.)
Matches of less than 90% have had a tendency to include commuters traveling in opposite
directions on same segment of road. (Match notification configured to display only matches
exceeding 90%.)
Security Certificate pop-up encountered prior to page 1 of user registration was confusing to
several new users, causing some hesitancy to enter data. (UIC obtained a “signed” certificate
from a Website authority (e.g. Versign) for protection of data obtained via Web registration;
UIC had been using a self-signed certificate.)
Routing system seems averse to “non-logical” routing -- for example, a person living near
Wisconsin and commuting to Lake Cook Road who travels further north to an arterial road
with an expressway interchange rather that traveling south to an arterial road that leads to
the same expressway.
Website’s geographic coverage area not expansive enough (available geography was
expanded to include southern Wisconsin counties of the Madison and Milwaukee metro
areas, as well as Kenosha, Walworth and Racine counties. This was in addition to the six-
county Chicago metro area, and 29 additional counties in the northern half of Illinois,
14
extending west to Rock Island and south to I-74.) NW Indiana is also included as part of the
geography.
Problems in routing where expressway entrance/exit ramps are used (significant time utilized
in re-coding segments featuring ramps in order to make it easier for users to recognize and
utilize along-the-route creation).
The beta tests conducted at Discover and CCH were not only a referendum of sorts on the
effectiveness of route-based matching and user route creation, but also a forum for evaluating
the effectiveness of the NavTech (Navigation Technologies) geographic database. Discover, with
its more than 4,000 Riverwoods-based employees, has a far-flung employee base whose long
commutes from areas like Rockford and Madison tested the reach of the database. Users who
work at Discover were not pleased when simple street addresses would not code properly, which
made them unable to find their exit ramp.
John Dillenburg was in continuous communication with these users and addressed their
concerns with prompt responses, in terms of reprogramming and geographic updating actions.
Other users have found the NavTech product to be too rigid and in many cases “picky” about
acceptable street addresses needed for matching.
8. System Evaluation Activities
During September and October of 2003, the conversion of the current POOLMATCH-based
carpool database was loaded into Ridematch System 21.
Pace staff attended Vanpool Administration System Training Sessions between June and
October 2003.
Gamma system testing took place between July and October 2003.
Ongoing refinements to vector matching algorithms were made during the summer of 2003.
A major public marketing program kickoff took place in October 2003.
15
Bibliography
U.S. Department of Transportation, Commuter Choice Primer, Washington D.C.: US DOT
Federal Highway Administration, 2003.
Baltutis, William. RideGuide Final Report. Deerfield, IL: TM A of Lake Cook, 2000.
Dillenburg, John F. Ridematch System 21: Functional Requirements Document, University of
Illinois at Chicago Department of Computer Science, September 20, 2001.
Dillenburg, John F. and Rodriguez, Jose. Ridematch System 21: Using Vector-Based Matching
to Direct Ridematching Activities. Chicago: University of Illinois at Chicago Department of
Computer Science and Chicago Area Transportation Study, October 2002.
Vitale, Dona J. Report: Website Usability Test Phase One. Chicago, IL: Strategic Focus, Inc.,
March 18, 2002.
Vitale, Dona J. Report: Website Usability Test Phase Two. Chicago, IL: Strategic Focus, Inc.,
October 21, 2002.
16
APPENDIX 1. Completion Status Memo (April 29, 2003)
Memo
To: Thomas Vick, CATS
From: Dr. John F. Dillenburg, UIC Department of Computer Science
CC: Jose Rodriguez, CATS
Date: 5/17/2004
Re: Completion Report
Tom,
The purpose of this memo is to provide you with up to date information as to the completion
status of the Ride Match System 21 project (Agreement #DOT01-OP-05-IGA). This information
is based on Sections 4 & 5 of the Functional Requirements Document , last updated July 12,
2001. The completion status of each feature is cross-referenced to this Requirements Document,
please refer to it for more detailed information on each feature.
Communications Environment Completion Status
1. Provide a user-friendly format
for data entry, database
development, data retrieval, and
data transfer.
Completed. An Internet
based interface is provided
that allows the system to be
accessed from any web
browser.
2. Transfer data efficiently
between firm’s internet
installations, intranet stations
and the main server and the
CATS service and management
center.
This is accomplished through
the use of the Internet and a
central database for data
storage.
3. Utilize such communication The purging and survey
University of Illinois at Chicago
Artificial Intelligence Lab
851 South Morgan Street (m/c 154)
Chicago, Illinois 60607-7053
17
means as fax and e-mail. subsystems have not yet been
completed. They will be
completed before contract
expires. E-mail will be used
to allow for automated
purging and surveys to be
conducted, something
Poolmatch was incapable of.
4. Link Ridematch System 21 to
other transportation alternate
support systems such as the RTA
Itinerary planning system, Metra
schedule information, etc..
Completed. Users will be
prompted to use the RTA
system if they work within
Chicago central area (CCA).
Links on the website also
allow users to visit Metra,
PACE, VPSI and other
transportation providers.
5. Link Ridematch System 21 to
the current highway information
system in the GCM project.
Completed. The website is
hyperlinked to the new
Gateway system.
6. Provide for firm’s to
customize the initial presentation
and allow for a limited number
of non Ridematch System 21
information portals.
Feature will not be
implemented in current
version.
Matching Engine Features Completion Status
1. Provide capabilities now
contained in the Poolmatch
ridematching system – carpool,
vanpool, express bus and transit
modules as a minimum.
Completed.
2. Provide for real time, or as
approximate as feasible,
ridematching between
individuals and among groups of
individuals.
Park-n-Ride lot module will
be completed, car and
vanpool modules completed
3. Provide for wider
acknowledgement to other
database participants of an
individual interested in finding a
ridematch.
Completed. This is done
through e-mail. Registered
users will be given a list of
users they match to
immediately upon registering
and may communicate via e-
mail.
4. Provide access to the system
for individuals and managers
“Managers” role not defined
or implemented, scheduled
18
through current office systems
utilizing Windows styled
environments.
for completion by project
termination. System
administrator and vanpool
administrator roles are
completed.
5. Provide user visual map
displays for the purpose of
geomatching, geocoding and
selecting ridematching areas.
Visual map displays
completed. Additional
functionalities for zooming
and scrolling will be
completed before project
termination.
Report Writing Features Completion Status
1. Provide for current Poolmatch
report writing capabilities and
enhancement of these
capabilities utilizing such
systems as MS Word for word
processing, Access for database,
and Excel spread sheet for
analysis, or their equivalent.
XML and HTML formats
completed, CSV format
scheduled for completion
before project termination.
2. Incorporate links for data to
GIS/ARC or equivalent
geographic analysis software for
second level analysis.
See above
3. Automate survey and purge
capabilities.
See Communications
Environment comment #3.
4. Provide for mass mailing and
document printing capabilities.
Not completed, scheduled for
completion before project
termination.
Documentation Feature Completion Status
1. Sufficient user and manager
manuals and documentation to
allow for the understanding and
use of the system.
In progress.
Beta Tests Features Completion Status
1. Provide secure firewalls for
data storage to protect the
integrity of individual and
employer information.
Will make use of Gateway
firewall.
2. Support Beta test sites. Completed, beta tests in
progress.
19
Hardware Features Completion Status
1. Provide servers and
necessary peripherals.
Completed
2. Provide work terminals at
CATS.
Taken out of scope of work
3. Assist in developing
communications links.
Completed
Dr. John F. Dillenburg
System Architect
Ride Match System 21
20
APPENDIX. 2 DRAFT USERS MANUAL, APRIL 2003Prepared by Chicago Area Transportation Study (CATS)
Contact: Jose Rodriguez, Project Manager, (312) 793-0419, [email protected]
www.r21.ai.uic.edu/sharethedrive Courtesy of the University of Illinois at Chicago Artificial Intelligence
Laboratory. For more information on site architecture or functions, contact
John Dilllenburg, System Architect, at [email protected]
REGISTRATION PROCESS OVERVIEW
1. Homepage is accessed by www.rm21.ai.uic.edu/sharethedrive -- the new “SharetheDrive.org”
From this point users can register to the system (SIGN UP), LEARN about the benefits of
carpooling, or learn more about Share the Drive and Ridematch System 21’s program sponsors
(WHO are we).
21
2. After selecting SIGN UP, the user is greeted by Breathe Easy Man and invited to register with the
system to find the “best way to where there going”-LET’S GO. Ridematch 21 is primarily a carpool
matching and vanpool building tool, but will not hesitate to direct people to mass transit when they
commute to downtown Chicago. Users can also view the privacy policy of the site.
3. Users may view the security certificate of the site before they proceed to registration.
22
4. Registration consists of eight (8) steps. Step 1 asks for the user’s contact information. E-mail
and password are required: the e-mail and password are the primary components of re-entry,
editing,, and obtaining feedback for the system and from potential ride matches.
5. Next, the user is asked for their home address or nearest intersection. The system can usually
find addresses without the ZIP code field being filled in.
23
6. A map is produced for the user’s inspection to see if their home address or intersection is correct.
7. In Step 4 of Registration, Work Address is entered.
24
8. In Step 5, the user confirms the location of the work site.
25
9. In step 6, the system generates a route for the user to generate matches to. The user can
interactively adjust her/his route based by using draw-down menus to change road segments used
to get from home to work. For example this user may travel down Narragansett Ave. north to to
I-90 and then access I-294 to take north to I-94. They would initiate this change of route by
changing the first box EB on NORTH AV to NB on N NARRAGANSETT; subsequent changes
on the route would occur dynamically based on the change of the first box. The user may either
accept that iteration or continue to make additional changes to route segment.
26
10. In Step 7 of Registration, the user enters their work schedule. She/he can enter the same hours
for the entire work week, or different hours may be entered for each work day. By using their
login (E-mail & Password), users can re-enter the system at any time to change their work
schedule and user preferences (Item 10, Step 8 of 8 of registration.).
11. Commuter Preferences regarding Smoking, Language and interest in Vanpool are indicated in
Step 8 of Registration. Users’ (or Companys’) preferences regarding traveling with fellow
employees and for traveling “off-route” to pick up a carpooler are also solicited in this step.
*Note: Graphics for Items 10 and 11 (Registration pages 7 and 8) differ slightly from what the first-time user will see as part of
their initial registration. Please continue to hit Next as you proceed with registration.
27
12. After completing the 8 steps for Registration, the system will generate either a NO MATCHES
found message or a MATCH list of persons who, based on geographic proximity and ability to
meet along a registrant’s route, are good matches for carpools or a vanpool. The user may contact
the person via e-mail by clicking on their e-mail address.
Since CATS is working with Trustmark and its employees to determine users’ preferences for matching, match lists,
and getting in contact with potential carpool partners, the MATCH list output is currently under re-
programming and is expected to be subject to several revisions throughout the testing period of April and
early May 2003.
Below is a NO MATCHES found message. Note that the user is prompted to obtain transit
information from the RTA Travel Planner Web site (“transit services” hyperlink). To make
changes to their route, work schedule or commute preferences, the user can select EDIT
SETTINGS immediately after not matching, or return to the “Home Page” at any time to LOGIN
and review their information and make appropriate changes.
28
For another user a match is located! First a MATCHES FOUND SCREEN is generated,
Links to a map of the user’s origin and to an e-mail reply interface are generated by a user
clicking on the Name and e-mail, respectively, of his/her match.
29
FIND OUT MORE ABOUT CARPOOLING: “What is Carpooling?
30
CARPOOLING TIPS
WHO WE ARE: Information on Chicago Area Transportation Study (CATS) and its Rideshare Services Division
31
32
