Winter Quarter 1996 January 28, 1996 Document Author: Eugene Liang Project Sponsor: Gregory Abowd

Yakko Wakko and Dot Profile Team: Manager: Harry Marlin Architect: Tom Moss Programmer: Mark Canup Programmer: Roy Rodenstein Programmer: Anind Dey Technical Writer: Eugene Liang

1. Scope
2. Applicable Documents
3. Scenario Descriptions
4. Storyboard
5. Functional Requirements
6. Non-Functional Requirements
7. Platform and Network Environment
8. Risk Analysis

I. Scope

Yakko Wakko and Dot Profile (YWD Profile) project team is a subgroup of the Java as Desktop project. Our project is focused on building a Java calendar browser applet. The College of Computing currently uses two calendar programs: Now Up-to-Date and the X utility "plan". The Now Up-to-Date application runs on MacIntosh platform while the "plan" utility runs on Unix workstations. People with accounts in the College of Computing have the option to create a publicly readable calendar file. Our Java calendar applet must be able to read and display the information in the calendar file, allow updates to the calendar from Java, and be able to browse other people's calendar and schedule appointments.

There are several precursor systems that attempts to do the same tasks. This project team will study these other works to gain insight on the inner-working and pros and cons of the system. By studying the existing systems we will be able to create a new system that is an improvement from the existing ones. The precursor systems to be studied are: Netscape Calendar, DISCS, and previous Java Prototypes.

The Netscape Calendar was created by a College of Computing undergraduate. The application uses Hypertext Markup Language along with Perl to produce a browse-able calendar on Netscape. DISCS is a continuing project as part of the Real-World Lab (CS 4310/1/2) that implements a calendar system for the Office of Information Technology (OIT). Several College of Computing graduates have done initial Java prototypes for an edit-able calendar.

Many of the previous systems that we are going to study are written in HTML. The limited functions in HTML places many constraints on what the system can provide. Building a calendar program with Java applets provides us with more functionality and options. With the more powerful Java applet, the new calendar will be a vast improvement from previous systems.

We have discovered that a College of Computing graduate student named Anind Dey is also working on a similiar project. With Dr. Abowd's approval, Anind has joined our group and will work as the third programmer for this project. Anind joins our group at the beginning of the project. He will be included in our training sessions. By starting together at the beginning, Anind will be a great asset to our team.

II. Applicable Documents

The following are documents relating to Java applets that our group uses for tutorial and references.
• "plan" Manual Page
• Java(tm): Programming for the Internet
• Making Sense of Java
• Shlurrrpp.....Java
• Trail Map: The Java Language Tutorial

III. Scenario Description

• Scenario One: John, manager of a company, often travels to various parts of the world to negotiate with clients. He uses the YWD dayplanner to manage his schedule. With the YWD dayplanner, John can easily view his schedule by connecting his laptop to the WWW. John's secretary updates his calendar at the home office whenever a meeting is required. John can instantly see the changes his secretary did and plan accordingly. With the YWD dayplanner, John can see the time and place his meeting is going to take place and also last minute cancellations. Not only can John view his meeting schedules, he can check on the time of the flight that his secretary scheduled (and updated on his calendar) for him.

• Scenario Two: Russ Shackelford, professor for cs1501 and cs1502 at the Georgia Institute of Technology needs to schedule a time where all his teaching assistants can meet, discuss, and update him on the progress of the students. Russ uses an option in the YWD planner which gathers a list of people's calendar (in this case, his TA's), overlays them, and display the overlay in an easily understandable manner. Russ can then easily find the slot where all the TAs are available. Upon viewing the overlay, Russ sees that the only time slot available for everyone is Tuesday at 3 a.m., so he schedules the TA meeting then.

• Scenario Three: Allison registered her classes for next quarter. After her class schedules are finalized, she wants to update her YWD dayplanner. Instead of updating her schedule day by day, she selects all the Monday, Wednesday, and Friday 10 a.m. slots for the next ten weeks and entered her class that is taught at that time. The YWD dayplanner modifies all the slots that she selected for the next ten weeks.

IV. Storyboard

• Storyboard Version 2 (2/6/96)
  (Postscript Format, 9 Pages)

• Storyboard Version 1 (1/27/96)
  (Postscript Format, 4 Pages, Please View with Seascape Orientation)

V. Functional Requirements

• Dayplanner Display

  1. Daily View (High Priority)

     The user should be able to view their schedule by hours where their appointments are displayed next to the hour that it is taking place. For example, if someone has a ten o'clock cs3302 class, the YWD dayplanner should display the class name and location beside the 10 o'clock slot.

  2. Weekly View (Medium Priority)

     The user should be able to view their schedule in an week-by-week fashion where summary of the daily appointments are display for the day slots within the week. For example, when the student who have four classes on Monday views the weekly display, all the classes that are on monday should be displayed. If the user wishes to view the exact time when the classes take place, he or she can click on the slot and enter the daily viewing mode.

  3. Monthly View (High Priority)

     The user should be able to view the days in the month. There will be no information displayed in the monthly view; however, the user can easily go into the daily view by clicking on a date.

  4. Yearly View (Very Low Priority)

     The user will be able to view the past or future years. This is used if someone wishes to schedule to the future years or view the appointments for past years.

• Managing the Dayplanner

  1. Add a Single Appointment (High Priority)

     The user should be able to select a date and add an appointment for a specific time.

  2. Add Multiple Appointments (Medium Priority)

     The user should be able to select a range of dates and add an appointment that applies to all those dates. For example, a student who have cs3302 at 10 a.m. on Monday, Wednesday, and Friday should be able to select M, W, F for the next ten weeks and schedule 10 a.m. for attending classes. The user can also select infinite range for a date such as Birthdate or Anniversary.

• Overlay Dayplanners

  1. Overlay multiple schedules (High Priority)

     The user will be able to overlay multiple schedules and view a list of time slots that are available for everyone. The overlay display can also count the number of conflicts and show the user the time slot that have the least number of conflicts. When one first execute the calendar, the overlay information will display only the user in the overlay. This will show the blocks of time the user have free.

     The user will be able to add an URL of the calendar he/she wishes to overlay. Once the URL is entered, the calendar specified is retrieved and display in the overlay information.

     The user will also have the option to select a group of people he/she configured. When one select the group option, a list of group names will be retrieved and the user can then select the group he/she wishes to overlay. The group information is stored in a configuration file in the user's account that is publically readable. If the user wishes to add or change the configuration file, he/she must edit that file in the account.

VI. Non-Functional Requirements

• Interface to .dayplan

  1. Read From .dayplan Format (High Priority)

     The YWD dayplanner should be compatible with the X window utility - "plan". The "plan" program creates a .dayplan file that is publically readable. The program should be able to read and display information stored in the .dayplan file.

  2. Write .dayplan Format (Low Priority)

     The YWD dayplanner should be able to write to the .dayplan file in the same format as the ones created by the "plan" program.

  3. Create the File .dayplan (Low Priority)

     If the .dayplan file does not exist, the YWD dayplanner should be able to create a new .dayplan file for the user.

• Response to the planner

  1. Reasonable Response Time (High Priority)

     The system should return the YWD dayplanner when the user requests it in a reasonable amount of time. Currently, we leave such task to the browsers. The browsers have a set amount of time before the request times out. That is the time we are going to go by unless faster response is needed. Since the applet is a fairly small program, we can be certain that under a reasonable working condition, the applet download will complete before the network timeout.

  2. Correct Date Range (High Priority)

     The YWD dayplanner will get the day/month/year information from the server system. The system need to return a correct information. The YWD dayplanner will have mechanism to detect day/month/year that are out of range; however, it does not have a clocking mechanism. We are depending on the machine to have the correct date and time. If the machine have the wrong date or time, then when the calendar is executed, the default date/time that it displays will also be wrong.

VII. Platform and Network Environment

• Viewing the Calendar

  The following network environment are required in order to use the YWD dayplanner:

  1. An Internet connection.
  2. A World Wide Web browser that supports Java Beta 2. Such as Netscape Communication Navigator 2.0 or later.

  The Java applets are independent of platforms; therefore, user can use any platform to run their YWD dayplanner as long as they satisfy the network environment.

• Development Platform

  The Java Development Kit 1.0 on Solaris will be used to write the dayplanner applets.

• Information Storage

  Since the builtin security will not allow us to store the information in the client's machine, the dayplanner will be stored on the same server from which we download the Java applet. This will be the method used until we find a way to store information in client's machine.

VIII. Risk Analysis

• Storing Dayplanner Information

  The HotJava browser is not widely distributed yet. Many users are simply updating the popular Netscape 1.12 to Netscape 2.0. The applets are considered "untrusted program running on trusted environment." Netscape's security management does not allow the "untrusted program" to write to the client machine. This presents a problem for us when we need to store the dayplanner information to the user's machine.

  Currently, we discussed three solutions:

  1. Open a socket from the client machine to the server and communicate via the socket.
     
  2. Use cgi-bin programs to execute the updates.
     
  3. Store all information at the server machine.
     

  The purpose of the applets is to move away from the use of the cgi-bin. We are going to avoid using the cgi-bin and move toward socket communication. Until the Netscape security manager changes, this is the major risk we have to deal with. The socket solution and the solution in which we store all the information at the server's machine is in essence the same; however, we did not know if there was a builtin method that would be different from manually opening a socket, that is the reason for distinguishing the two.

• Java Applet Bug

  Since the Java applets are a fairly new development, bugs in the language itself could contribute to problems while developing the system. We will keep ourselves updated with any bug reports or patch programs that are available to avoid being affected with the problem in the language.

• Network Response

  System response is another risk. There are many things that can contribute to system failure. Server crashes, the user account no longer exist, the address of the machine is unreachable, or the day/month/year are out of range. The system should provide ways to give error in an easily understandable fashion, thus avoiding many hours spent on finding where the problem originate from.

• Ineffective Training

  The programmers, given little time to learn Java, might run into difficulties when programming due to the lack of time available for training. This is a major risk we have to consider. The group is trying to avoid such disaster with Java training sessions and Java Jam (a way to gather people who knows Java together in hope that when problem occurs, people can help each other out).

• Member Dropping the Course

  Unlike the working environment, a student can easily avoid the responsibilities in the class by dropping the course. Such risk always appear in an academic environment. If the unfortunate happens, there will be a major reorganization and the project will continue as planned (hopefully with minor delays).

• Network Dependability

  There always exist a possibility of a network error. There could be a problem in storage such that part or all of our works are deleted. (This did happen, when I was writing the requirements document.) We hope to have dependable daily backups from the College of Computing and Office of Information Technology. Also, we will have multiple copies of our work in various machine. This will reduce the delay time if such event occurs.

Top	Plan	Req Doc	Design Doc	Prototype	History	Revision

---

Last modified: February 7, 1996 by Eugene Liang (eugene@cc.gatech.edu)