CS3302 Project Notebook Design Document

Yakko Wakko and Dot Dayplan

Design Document


Winter Quarter 1996
February 8, 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
Technical Writer: Eugene Liang
Programmer Consultant: Anind Dey


  1. Scope
  2. Applicable Documents
  3. High-Level Architecture
  4. Modules
  5. User Interface Description
  6. Test Provisions


I. Scope

The scope of our design document can be found here.


[ Scope | Docs | Architecture | Modules | Interface | Test Provisions ]

II. Applicable Documents

The following are documents relating to Java applets that our group uses for tutorial and references.


[ Scope | Docs | Architecture | Modules | Interface | Test Provisions ]

III. High-Level Architecture

The YWD Dayplanner is in the form of a Java Applet. When the "Open Dayplanner" command is executed, the WWW Server downloads the applet to the client. The client receives the download, compile the applet, and execute the program. Within the applet exists five components of the dayplanner. As the user uses various functions in the dayplanner, different component work together to provide services to the user.

The Dayplanner Parser is the object which contains all the information. It is the provider of information to the various modules. As modules requests information from the Dayplanner Parser, the Dayplanner Parser returns the necessary information the client needs. When the dayplanner is first executed, the Dayplanner parser communicates to the HTTP Server for the .dayplan information fron the user's account. The .dayplan is then parsed and applicable data is stored within the Dayplanner Parser object. At this point, the Dayplanner will hold the all of the user's schedule information.

If the user requests an overlay on another person's schedule, the Dayplanner Parser will once again request the HTTP Server for information regarding the person's calendar. The HTTP Server returns the information that the Parser requested. The Parser then provides the new overlay data to the Overlay Display.

The Month Display, at startup, receives the current month information from the Parser. The Month Display then displays the information at the Month Display section of the Dayplanner.

The Daily Display receives the information from the Parser. The Daily Display then take the list of schedules and display the time section and the free-text of the Daily Display. The Scheduled Time and Free-Text are linked such that if the user clicks on a time, the free-text section will scroll to the specified time with description on the appointment that is taking place.

The Overlay Display receives information from the Dayplanner regarding the list of schedules for overlay. At startup, the overlay receives only the user's schedule. The Overlay Display then shows the block of time the user has appointments and also shows the free time block available.

The Group Overlay option, when invoked, sends the group that the user wishes to display overlay information for to the Dayplanner Parser. The Dayplanner Parser, after receiving the information from the HTTP Server, sends the information to the Overlay Display to display.

The Add Calendar option, when invoked, sends the URL of the person that the user wishes to add to the Overlay Display. The Dayplanner Parser then sends the request to the HTTP Server. After receiving the schedule information from the server, the Dayplanner Parser then sends the new overlay to the Overlay Display for viewing.


[ Scope | Docs | Architecture | Modules | Interface | Test Provisions ]

IV. Modules (Object Oriented Analysis)

A. Problem Domain Component: read .dayplan format files

B. User Interface Component: display information as a calendar


[ Scope | Docs | Architecture | Modules | Interface | Test Provisions ]

V. User Interface

This section presents a general overview of the user interface design for the Yakko, Wakko, and Dot Dayplanner. The physical environment and the specific screen design is outlined. The semantic and syntactic details of the user interface design are explained as well.

  1. User Interface Rationale
  2. The World Wide Web provides a medium where the user can use any platform to access information. By creating an application that is accessible via the WWW, we eliminate the problem of platform compatibility. Also, since the information on the WWW is stored electronically, the user do not have to worry about losing the dayplanner, unlike the problem people faces when using the paper/pencil dayplanner.

    By placing the calendar on the WWW, the user can access his/her calendar anywhere in the world as long as there exists an internet connection and a web browser. The Java applet is a newly introduced program that provides security to the server. This reduces the chance an unauthorized user receives access to someone else's calendar.

    The YWD Dayplanner is designed for anyone to use with ease. No previous knowledge of (or experience with) computers is required in using the YWD Dayplanner. It is of utmost importance for the interface to be easily understandable. Anyone who use any type of dayplanner will be able to understand how to view, edit, and overlay various schedule.

  3. Screen Interface
  4. Many functionalities exists for the user interface. When the user first enters the system. The user will see the Dayplanner Screen.

    The following are detailed descriptions of the user interface:
    (Note: Postscript Format, 1 Page Each)

    1. Monthly View Display Interface.
    2. Daily View Display Interface.
    3. Overlay View Display Interface.


[ Scope | Docs | Architecture | Modules | Interface | Test Provisions ]

VI. Test Provisions

The problem domain component of the project has three simple test cases. Each case will be composed of a number of dayplan format files. The files will vary in size from tiny to fairly large.


[ Scope | Docs | Architecture | Modules | Interface | Test Provisions ]
Top Plan Req
Doc
Design
Doc
Prototype History Revision

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