Our Time – Overview Document

Identification

Members: Alice Fuller (aafuller@), JT Glaze (jglaze@), Luke Massa (lmassa@), Adam Stasiw (astasiw@) and Clayton Whetung (cwhetung@)

Project Manager: Clayton Whetung (cwhetung@)

Overview:

Our project will be to design a calendar based web application that will allow users to form social groups and share their calendars with those groups. Our application will then find all times when all users are available and return that info to the users (in the format desired by them). The aim of this project is provide users with an easy and worry free application with which to manage any form of social commitment.

We have noticed that students on campus are committed to many clubs, plays, classes and social groups and that finding a common time to meet that will fit all participants schedule can be very difficult. The traditional method is to simply ask every person of there are free at a desired time and just keep trying until a time that works is found or someone has to be left out. This is how other applications like doodle.com work, but there are also applications like whenisgood.net that is similar in its functionality but requires a new calendar to be filled out for each new event. We aim to be different with our major feature.

Major features of our application:

· Community: Allow users to form groups for ANY purpose and finds common free time for the group’s members

· Integration: Pull calendar data from a user’s common calendar applications such as iCal and also retrieve Facebook event info and deliver output to e-mail, sms or calendar as desired by the user

· Automation: Require no extra input from users to find common time other than updating their regular calendar application and forming groups

· Simplicity: Aim to a supplementary application that provides extra information to the user at little personal cost rather than replace any heavily used system

·

These features will create a worry free system that is functional and helpful without bogging the user down with another program to worry about.

The program itself will be built as a web application which uses AJAX in the browser, while running Java on a Linux server and MySQL as database management.

Functionality:

Theater Production Rehearsal:

Rehearsing for a production requires the synchronization of sometimes dozens of schedules of overbooked students. This is currently achieved by either sending conflicts in an email in text form, or filling out forms on whenisgood.net. The biggest problem here is that people’s schedules change very rapidly, and it is hard for the person scheduling to gather all this information. This application would allow this to happen in real time as people updated their personal calendars. What this also means is that a person does not need to fill out forms on whenisgood.net constantly and for all the productions they are in, but rather just stay on top of keeping their calendar up-to-date. Also, since the process is automated, certain features like text message alerts or cross-checking with availability of practice rooms are possible.

Office hours with a busy professor:

Suppose the user desperately needs office hours with a professor but has class during the regularly scheduled times. This can be remedied simply by having the professor create a class group such that each student’s calendar only looks for free time with his/hers. Also, the professor could schedule extra office hours anytime they were free, same with the course preceptors so that students would only find common time during these allotments. The student seeking help could simply look at our application, find a common time and e-mail the professor or book time through our application, saving time and hassle.

Game night with friends:

You have just picked up a brand new copy of Scrabble: The Awakening of Qtxkulku and you are desperate to play! Unfortunately, all of your friends are in bee keeping club, Go club, Triangle, thesis mode, and have many more commitments. This solution is easily remedied by our application. Just form a group with your close friends and it will be constantly up to date with your schedules. At the last minute you can check and see that everyone will be free in 15 minutes for an hour, just enough time for a game. So through our application with the click of a button you can send an e-mail and SMS message to your friends suggesting the event and in 15 minutes you can all be together for a game with very little effort on anyone’s part.

Design:

Our program will implement the Google Web Toolkit to generate AJAX and JavaScript code, all of our logic systems will be made using Java, and we will perform database management using MySQL. Client operating system should not matter as our project will simply be a website, and we will test it on major browsers to assure functionality. Interfacing between the browser and the database will be carried out by a Java-based logic system, which will retrieve, store, and analyze the necessary information (described in further detail below). The database will store User, Group, and Event data, which will be accessed from the Java logic system using MySQL commands. The system will be stored on a Linux server, acquired through the CS department.

The user interface of our program will be built using the Google Web Toolkit to generate JavaScript and AJAX code. Using the Toolkit we will be able to build the user interface and logic systems in Java with ease. Using the Toolkit we will also be able to develop mobile versions of the site easily. Our user interface offers two primary options to the user. Also, for the calendar UI we can simply use the GWT and Google calendar APIs to create a custom AJAX implementation of the Google Calendar. The user will be able to either view a detailed calendar view or simply retrieve the free time slots. These formats will be easy to switch between and manage with a simple toggle. For example our mobile site will likely just show free time slots, rather than a full calendar due to screen space restraints. The user can view a group page, which will list show group events and will have a wall where group members can post text. The users will also be able to view a list of the group members and easily suggest meeting times or book meetings directly into their calendars. The use of AJAX allows the calendar to update in real time and provide up to date information on each user’s schedule and availability.

The application will store a variety of information about users, groups, and events, in order to provide a combined functionality as a scheduling application and a social networking tool. This information will include user’s ID number, the scheduling information for each user, and the user’s name, profile picture, password, email, phone number, and other personal information; the group’s ID number, name, group members, wall posts, and other group info; the event’s ID number, name, time, associated group, attending members, description, and alerts. This information will be largely generated by the users, as they provide personal information, and create groups and events. In addition, the scheduling information will be taken from the user’s Google Calendar account, using Google Calendar API described here: https://developers.google.com/google-apps/calendar/v3/reference/. The information provided by Google will then be parsed and stored in our database. In our current database schema, we have four information tables for users, groups, events, and wall posts, as well as three relational tables for group members, event members, and posts on group’s walls. To manage user accounts and make bulk database updates we will need to implement an admin interface that has total access to the database entries. Since we are not using Django to develop our web interface, this admin interface will need to be built from scratch.

The interface options available to the user will be simple and direct. The user will be able to query for a free time slot, suggest a time slot or book a slot. Querying a time slot is simple. Our logic code, written in Java, will process the scheduling information of the members upon request and determine all free times. This will be done by retrieving group event data from the database using MySQL and processing that data into open time slots. The user will also be able to query for any number of individuals in the group, this process will likely be done upon request due to the number of possible input combinations. Once all appropriate time slots have been found the system will return a list of available slots to the front page of the user who performed the query. From there they will be able to book a time slot, and a message will be sent out to group members suggesting that time be allotted to meet. This will not depend on each user’s schedule since any time slot is suggestible. For this query, the only database interaction will be the retrieval of each user’s e-mail address. Finally booking a time slot will be the most complicated query. To do this we will implement a logic system that retrieves each user’s Google calendar information from the database and then implements the Google Calendar API to add that event to each member’s personal calendar, and in turn update all the other user’s groups.

As described above, the UI will interface with an underlying Java logic system, with different UI requests prompting different commands in the Java system. The Java system will then run some logic, potentially requesting or posting data to/from either Google Calenders or our database. All requests will be built as Java function calls, so that changes to the database or Java structure can be made without needing to change much of the rest of the application. Google Calender requests will be formatted as URI’s in Representation State Transfer (REST) format, and returned as the appropriate Java data type. Database requests will be formatted as MySQL statements, and mostly returned as strings. A basic schema of our database is listed below, although many of these elements are subject to change. A few sample MySQL requests have been listed as well to demonstrate how the database will function.

OurTime Database Schema v1.0:

UserInfo:

UserID, TimeSlots, FirstName, LastName, Picture, Description, Password, Email, Phone#

GroupInfo:

GroupID, WallID, Picture, Description, Name

EventInfo:

EventID, GroupID, Time, Date, Name, Place, Description, Alerts

GroupMembers:

GroupID, UserID, ContributorStatus

EventMembers:

EventID, UserID, ContributorStatus

WallPosts:

WallID, PostID

PostInfo:

PostID, UserID, Text

Sample MySQL commands (to be executed through Java):

Get UserIDs of all members of a group with GroupID = X:

“select UserInfo.UserID from GroupMembers, UserInfo where GroupMembers.GroupID = X and GroupMembers.UserID = UserInfo.UserID”

Get time conflicts from all members of a group with GroupID = X:

“select UserInfo.TimeSlots from GroupMembers, UserInfo where GroupMembers.GroupID = X and GroupMembers.UserID = UserInfo.UserID”

Get the last 50 wall posts from the wall of a group with GroupID = X:

“select PostInfo.Text, PostInfo.UserID from PostInfo, WallPosts, GroupInfo LIMIT 0,50 where GroupInfo.GroupID = X and GroupInfo.WallID = WallPosts.WallID and WallPosts.PostID = PostInfo.PostID”

Milestones:

Wed. Feb 29^th – Initial dinner, brainstormed project ideas, discussed concepts and features of a social calendar application at length

Fri. March 9^th – Meeting with Professor Kernighan, excited and interested in social calendar idea, suggested adding cell phone alerts and a mobile version

Mon. March 12^th – Second meeting – Made broad design implementation decisions: Java, AJAX and JavaScript, MySQL.

Fri. March 16^th – Completed design doc, built initial website, wrote elevator speech. Mapped out the fine design details and set goals, built database schema, named the project “OurTime”

Fri. March 23^rd – Spring Break – build basic database and Google calendar post/retrieval methods in Java; obtain access to cs.princeton database; host very basic website for query and retrieval

Fri. March 30^th – First TA Meeting – Implement groups and events along with post/retrieval methods; build scheduling logic; implement calendar UI

Fri. April 13^th – Project Prototype – Add wall posts to the database and the user interface; build the admin interface

Fri. April 20^th – Add alerts; enable events to be pushed to Google calendar; add pictures and descriptions for users and groups

Fri. April 27^th – Alpha Test – Finish UI features; begin alpha testing; begin written documentation

Fri. May 4^th – Beta Test – Beta test with friends/colleagues before actual beta test; create presentation; continue written documentation

Tues.-Fri. May 8^th-11^th – Project Presentations – Give presentation; finish written documentation

Tues. May 15^th – Dean’s Date – submit all materials by 5:00 PM.

Risks and Open Issues:

One of our largest hurdles will be overcoming a lack of familiarity with our Toolkits and databases. None of us have any experience with GWT, AJAX, JavaScript, MySQL or database management. However, we are confident that this lack of experience will be easy to overcome.

Some of the earliest challenges we will face getting started is obtaining access to the appropriate systems. We will need to host our website from the Princeton domain, as well as obtain access to a Princeton CS database. This usually takes a few days of processing in the CS department.

In addition, we will need to be careful with our usage of various systems and the amount of data we are storing and retrieving. There is a starting quota of 10MB for a Princeton database, and we will need to either avoid storing too much information or request for more storage space. If you maintain your database over quota for more than a few days, the CS department will revoke your write privileges to the account. If this happens, it would effectively shut down our application, so we will need to monitor our usage throughout the project. Google also limits the number of queries per day you can make using the Google Calender API. The default limit is 10,000 – we don’t anticipate going over this limit, but we should be aware of its presence so we don’t make 100 queries per hour per user or another equally reckless rate.

Google also requires authorization through their OAuth2.0 authorization protocol in order to access Calendar information. We will have to handle how to obtain access to a user’s Google Calendar, and then maintain the authorization for access to that calendar long term.