SCORE Project: Travlendar
Title: A Travel-Time-Aware Calendar
Sponsor: Christine Julien
Many endeavors require scheduling meetings at various locations all across a city, whether in support of a mobile job or a busy parent. The goal of this project is to create a calendar interface (either by extending something like google calendar or as a standalone application) that automatically computes and accounts for travel time between appointments to make sure that you're never late for an appointment. Locations of meetings are required to create meetings, and when meetings are created at locations that are unreachable in the allotted time, a warning is created. The application should also suggest travel means by appointment (e.g., perhaps you drive to the office in the morning but the bus is a better choice between a pair of afternoon meetings) and by day (e.g., the app should suggest that you leave your home via car in the morning because meetings during the day will not be doable via public transportation). The application should be user customizable (e.g., the user should be able to select preferred (or non-preferred) means of transportation). Additional features could also be envisioned, for instance allowing a user to specify a flexible "lunch". For instance, a user could be able to specify that lunch must be possible every day between 11:30-2:30, and it must be at least a half an hour long, but the specific timing is flexible. The app would then be sure to reserve at least 30 minutes for lunch each day. Similarly other types of breaks might be scheduled in a customizable way.
Project Description
Travlendar will provide flexible and fully-featured calendar support that considers the travel time between meetings. Travlendar should support a multitude of travel means, including walking, biking, public transportation, and driving. A particular user may globally activate or deactivate each travel means (e.g., a user who does not own a bicycle would deactivate biking). A user should also be able to provide reasonable constraints on different travel means (e.g., walking distances should be less than a given distance, or public transportation should not be used after a given time of day). When a user interacts with Travlendar, the application should:
- compute travel times between meetings (or proposed meetings) and prevent scheduling meetings whose start/end times conflict as a result of inability to travel
- explicitly but subtly add "travel time" to the calendar between meetings, reserving the required amount of time on the calendar, and suggesting the "best" option of travel between each meeting.
- create overall compatible schedules on a day-basis, considering that a user who does not leave the house with his bicycle or car in the morning cannot use it to move between meetings during the day.
On a given day, a user's car (or bicycle, skateboard, etc.) should start and end at the user's home. The implementation of Travlendar should consider different types of users, including people who work "on the road", traveling from meeting to meeting throughout the day as well as busy parents shuttling kids to and fro.
Project Scope
The project should support the features described above. In addition, optional features could be added to the application at the team's discretion, but these features should not supplant the required features nor should they interfere with the required features. For instance, the calendar could be made dynamic to consider the weather forecast, it could consider the cost of each transportation means, or it could provide users more substantial ability to provide preferences related to transportation modes. To better support families, Travlendar could support calendar and transportation mode sharing (e.g., consider a family with just one car that has to be shared between two adults).
The project must include high quality documentation, including documents on the process (see below) and a (brief) user manual that describes how to get started with the application.
Process Requirements
Teams can adopt any development process. Project artifacts must be stored in a public repository with issue tracking facilities (e.g., GitHub). The team should also perform some formal project tracking, including defining milestones in advance, assigning roles to team members, developing a testing plan, etc.
Environmental Constraints
The application should be web-based and must run on most modern browsers (e.g., Chrome, Firefox, Internet Explorer). Backend platforms to be used are up to the team to determine. Design that is compatible with use on a smartphone is encouraged.
Level of Sponsor Involvement
The sponsor of this project will accept questions via email about the project topic at any time. Brief Skype meetings can be arranged on demand if necessary.
Sponsor contact: c (dot) julien (at) utexas (dot) edu
Project Restrictions
None.
Project FAQ
Answers to selected questions will appear here.