CISC474, A10, CISC474

An Improved Scheduling Application

In your lettered groups, create an improved scheduling application.

Required Features

This application should have the following required features:

1. The first screen presented to the user is a login screen. On this screen the user can either
   • type in a username and password, which if correct, takes the user to the "main menu", or if incorrect takes the user back to the login screen with an error message, or
   • click a "create account" button to go to the "create account" screen.
2. On the "create account" screen, the user is asked for a username, password, password confirmation, and an email address. Clicking submit should:
   • check to see if the username does not already exist, if the password and password confirmation match, and if the email address has the correct format for an email address. If so, the account should be created, and the user should be taking back to the login screen with a message that the account was created. If not, the user stays on the "create account" screen, with an error message indicating what was wrong.
3. On the main menu, a user can choose any of the following options:
   • enter/change his/her schedule (takes you to "schedule entry screen")
   • lookup someone's schedule (takes you to "schedule lookup screen")
   • find common free times for a list of users (takes you to "common free time screen")
   • logout (takes you back to login screen)
   Alternatively, the default view could be the "schedule entry screen", and "navigation links" for all the other screens could be in a menu somewhere on the screen (these navigation links would appear in the same place on every screen.)
4. On the schedule entry screen, you can add/delete busy times for a given user. The busy times should allow either arbitrary start/end times, or start/end times in blocks no smaller than 5 minutes blocks (e.g. 10:10am-11:00am or 1:25pm-2:15pm need to be valid start and end times for blocks.) The exact user interface is left to the group's discretion. This screen should have either global navigation, or links for "main menu" and "logout".
5. On the "lookup schedule", the user can lookup a schedule for any user in the system. This access is read only. This screen should have either global navigation, or links for "main menu" and "logout".
6. On the "find common free times", the user can choose users (e.g. ) from a drop down list by multiple selection, or by typing in a comma separated list of usernames. On clicking submit, the user is then presented with a schedule indicating common free times (or, if any of the usernames is not found, with a suitable error message). This screen should provide global navigation, or links for "main menu" and "logout".

In addition, to get an "A" grade, your group need to implement at least one or two of the optional features listed below. (Otherwise your maximum grade will be a B.

You may also submit other ideas for optional features.

Required style for final submission

• The app should use the MVC design pattern where appropriate
• A tar file containing a build.xml, global.properties, and README.txt file that explain how to compile the application into a WAR file that can be dropped into a Tomcat implementation.
• The README should explain any configuration that needs to be done in the global.properties and/or the web.xml file (e.g. database URLs, passwords, etc.) as well as any bootstrapping of the SQL tables that needs to be done.
• The bootstrapping of the SQL tables can be done from either a script (i.e. a text file containing SQL commands) or from a Servlet included for that purpose.
• The build.xml file should echo a menu of targets by default. Among those targets should be ones that
  • compile the code,
  • run JUnit tests on any model classes you have,
  • build a WAR file,
  • build Javadoc
  • clean out the development environment of everything not in the original tar,
• All Java code should include Javadoc style comments as well as other comments explaining the code's operation.

Groups will demo their applications during the week of May 15-19

Grading:

• 100 points of "required" part of your final course grade.
  • 50 points for demo
  • 50 points for code

Optional Features

Verifying Email Address

1. A confirmation email should be sent to the user's account when an account is successfully created.
2. Even better, there should be a field in the database indicating whether the user has verified his/her email address. The values can be "pending", "verified", or "not verified". A field in the user table in the database is initialized with a random number. The confirmation email contains a link to a URL for a "verify email address" servlet, that takes that random number as a parameter, the username, and the email address, and checks if the number matches the number for that account. If so, the email address is marked as verified. If not, the email address is marked as not verified.
3. Add a screen accessible from the main menu that lets you reverify your email address—clicking the link generates a new email, and verification number.
4. Add a time limit to verifying email addresses—in addition to the random number, there is also a time-limit on clicking on the link in the confirmation email. If you click after the deadline expires, you get an error message inviting you to re-verify your email address.

Groups, and Levels of Privacy

1. Allow users to share their schedule with everyone, or only with certain users. Provide another screen where user is given a list of all users in the system, and can check off which users should be allowed to see their schedule. In the user interface, provide buttons for "allow all", "clear all", as well as the ability to toggle individual access.
2. Allow users to create groups. Add a group creation screen. User is asked for the name of a group. If that group doesn't already exist, the group is created, that user is added to the group, and becomes the "group owner". The group owner can then add users to the group, or delete users from the group, or delete the group entirely.
3. Allow users to list which groups they belong to, and to indicate which groups they want to share their schedule with.
4. Allow "groups" to be entered as an abbrevation for a list of users on the "common free time" screen.
5. Allow group owners to designate other users as co-owners of the group. Co-owners can do all the same functions as the original owner including add member/delete member/delete group (i.e. no distinction between the original owner and co-owners).
6. Add the concept of "inviting" someone into a group, and "accepting" an invitation. Provide a screen where users can see which groups they've been invited to join, and can accept (in which case they are added to the group immediately) or decline. On that same screen, the users should be able to see which of their own invitations have been accepted or declined. Users should be able to click on accepted and/or declined invitations to clear them from the database.
7. Once an invitation system is working, remove the ability of regular users to add/delete members from groups, but perhaps retain this capability for certain user accounts designated as "administrator" accounts. Bootstrap the system with one adminstrator account called "admin", and allow any administrator account the ability to change other user accounts to have admin privileges.

Common Free Time Calculator Enhancements

1. Provide the option for both text and graphical output of the common free time schedule
2. Provide an option for emailing the free time list to the verified email addresses of the users the free times were calculated for
3. Provide an option for a "complete" calculation... i.e., for each block of time, show exactly how many of the users are free, and which ones those are. Use a color code where each color indicates a different number of users free (e.g. red = 0, orange = 1, yellow = 2, green = 3, blue = 4).

Review Session Calculator

1. Provide the option to calculate a review session schedule. For this schedule, ask for the name of one instructor, a minimum length of time for the review sesssion, and a list of students.that want to attend a review session. Find the best time in the week for a review session, i.e. the one that the largest number of students can attend that is at least as long as the minimum length. Then remove all those students from the list, and repeat the process. In the end, show a scheduled with multiple review session times, a list of the students that can attend each one, and a list of students that were not able to attend any review session with the instructor.

Interface with Google Calendar

1. Add an option to import the busy times from the XML file that is made available by Google Calendar (see, for example, the XML file associated with my Google Calendar). This could be tricky, because you will probably want to find some way to look at the ongoing events and figure out whether they should be included or not.