Project Name:MeetUp

Project Manager: Greg Hyde (ghyde@)

Group Members: Ashish Gupta (akgupta@), William Song(junhos@)

Overview:

This project is designed to improve existing systems for scheduling events. Current systems do adequately resolve conflicts among groups of people; each user has to enter their conflicts manually on the creation of each new meeting or event, which is time-consuming and cumbersome. Moreover, this often deters individuals from even filling out the form, which reduces the functionality of the program. Our goal is to create a streamlined system that solves these problems while also using a much more sophisticated optimization scheme.

Our scheduling application will include several major features. Instead of a simple intersection search, the program will use a more advanced optimization to find the best meeting time for the group. In addition, it will give users to import schedules from iCal and Google Calendar, saving them the hassle of manually re-inputting conflicts. It will also allow users to both prioritize conflicts and add, change, and remove conflicts as they arise. Furthermore, it can send e-mail and text notifications as the scheduled time approaches as a reminder of the meeting.

This application will be a website where the group leader makes an account. The group leader will then invite the group members to join the group and input their conflicts/calendars (manually, via iCal/gCal, or both). We will formulate the general problem as a LP, and will most likely use AMPL as the backbone of the optimization. We will probably use python for the importing and processing of the conflicts and calendars. The foundation of our program will be the Google Web Toolkit, which will help us create widgets for the interface and convert Java into Javascript.

Functional Specifications:

Scenario 1: I am a leader of a group, trying to organize an event for my group. I go to the website and login. At that point, I am faced with the main site, which consists of basic information for my group and a button to create an event. When the user creates the event, they are faced with a form. It will have fields specifying basic information of the event (for instance, a date and time range for the event, duration), and then they can enter the name and contact information of people who will be in the event. Leader can also choose the last possible date for each user to add their conflicts. At that point, the application will email each invited person a unique URL.

Scenario 2: I am a member of a group that needs to meet. The leader of my group uses our site. I receive an email from the site saying that the group leader is trying to organize an event. I click on the URL that the email gave me, and it brings me to a form with a calendar on it. It will contain the same information that the leader entered about the potential time and name of the event. If I have previously imported my calendar from ical or google calendar, there will be a calendar widget that shows my existing events, and I can just hit confirm that the calendar has all of my potential conflicts. I can also adjust the priority of my potential conflicts by clicking on the event. If I have not previously imported my calendar, there will be an option to import a calendar (which will prompt the person to upload a .ics file), as well as a way to just add conflicts to the day(s)/time in question. Once I am done, I can confirm that I have input all of my conflicts.

Once everyone has either created the event or input their conflicts, the engine will run and find an optimal meeting time. It will then send an email to all people meeting to confirm the meeting time. At a set time before the event, it will send a text message reminder.

Design:

Database Schema:

iCalendar and Google Calendar can both be exported to a form that allows us to parse them. We will mostly likely write a few Python scripts to transfer these calendars into the database.

The database queries will be done in Java using the MySQL libraries, and the website's functionality will be written using Google Web Toolkit.

There are two distinct types of users in our current model. The first is the group leader, who creates a group and manages events. The second is the group member, who fills out his/her conflicts and receives notifications from the scheduler. When the group leader gets to the site, he/she will need to invite the group members (by providing the application with their e-mail addresses), and the application will send out unique weblink. This will probably be done using the unique time stamp of when the user clicks on the link.

We hope to implement the linear programming aspect of the problem in AMPL, since it provides a simple and natural representation of the problem. However, if it is too difficult to integrate, we may also use existing Java CPLEX libraries.

Python will also be used to extract information from the database, and back to the user.

The core of the interface will be in JavaScript. Many of the features of the website will come from the Google Web Toolkit. We might also have to use a little bit of HTML/CSS to format the layout of the pages.

Risks and Open Issues:
There are a few issues that we might encounter as the project develops. First of all, there is a potential problem with calendars growing stale. For instance, if someone imports a calendar for iCal or gCal, we don't them to have to reimport every time they are coordinating conflicts for an event. Both google and apple have methods for making the calendars public, which we could make to user do for full functionality in the worst case, but hopefully we can find a way to get enough permission to update the calendar without forcing them to make it completely public.

We will also have to deal with the privacy issues associated with creating accounts. We will need to hash the passwords and avoid storing the passwords. There are also privacy issues with seeing other people's events, so we will have to minimize that while making enough information transparent to be useful.

There may also be problems associated with Google Web Toolkit's resource allocation. We saw in class that some GWT processes can go rogue, so we will need to look into potential memory management problems.

Most of the programming will be in Java, which all of us are very familiar with. Other programming will be done in AMPL or Python, which we have enough familiarity to be functional.

We have set up a Git repository for source control. This will save us a lot of time and headaches.