Progress Report: Scheduler A fully text-based event list

I.

Introduction: As a task list software which operates on PC platform, Scheduler is designed to work independently of mouse/ track-pad or any input device other than the keyboard. Scheduler specifically targets users who work in typing intensive environments, e.g secretaries, programmers, etc. The development of Scheduler spans over thirteen weeks, starting from mid-January 2014 and expecting result at the end of April 2014. This report summarizes (1) the planning stage of the project, (2) coding progress of the project over the first six weeks, (3) problems encountered along the way. This report also suggests viable strategies to be adopted in the coming stages of the project and solutions to existing problems.

II. Discussion: 1. Planning: The planning stage took place during the first three weeks. Meetings were conducted regularly with the following objectives: - Creating user stories. - Devise software architecture. - Define application programming interface (API). - Division of labor. - Set timeline for components completion. 1.1) User stories: During this stage, we put ourselves in the shoes of potential end users of Scheduler and came up with scenarios where certain features of Scheduler will be of use to end users. From these scenarios, we identified: (1) features that must be implemented (basic utilities add/delete/search/display tasks), (2) features that should be implemented to entail Schedulers vision (unique utilities hotkey navigation, flexible commands) and (3) features that can be implemented given enough time (extra utilities undo/redo commands, graphical user interface (GUI)). Status: Completed 1.2) Software architecture: After all the features had been identified, we moved on to brainstorm a structure for Scheduler to adhere to. In particular, we came up with smaller elements of the software which specialize in handling a single functionality each. (See Figure 1.) Coming up with an architecture allowed us to see the broad landscape of the project. At the same time, the architecture devised also provided us with an easy schema for labor division: Separate components would be developed separately and tested independently from each other.

Command Processor TextUI

User GUI Scheduler Logic

Figure 1. Simplified Schedulers Architecture

Status: Completed 1.3) API APIs are the relationship between components. They are methods (functions) that can be accessed from any class (component) of the program. The basic APIs were first identified as we worked out the architecture of the software. Afterwards, there were several revisions to the original APIs as we found some to be unfit for implementation. We planned to have a final revision in the coming week in order to begin integrating individual codes. Status: Partially completed Awaiting further update. 1.4) Division of labor: Division of labor were mostly based on the devised architecture. Each member is responsible for a component of the software. We also took into account other commitments and coding skill of each member to ensure maximal utility overall. Component Logic Unit User Interface (Text UI + Graphical UI) File Handler Command Parser Log Unit (New component) Team member Hoang Quang Minh Jeremy Tan Nguyen Le Minh Dat Zhang Mengdi To be assigned

Status: Completed

1.5) Timeline: Feature \ Release version V0.1 V0.2 V0.3 V0.4 V0.5

Add task Delete task Search task Display task Modify task Add timed task Mark task as done Unmark task as done Postpone task Undo command Redo command Hot key navigation Working GUI Demo video * Sync task to GCal Deadline 07/03/2014 21/03/2014 28/03/2014 03/04/2014 05/04/2014 (*): Extra feature, will be implemented if there is no constraint on time. Figure 2. Project timeline, expected feature completion and deadlines. 2. Coding Progress: 2.1) Logic Unit: This unit executes the commands input by users. One instance of this unit takes in a single command (pre-processed into usable form by other units) and implement the change towards the task list intended by this command. This unit interacts strongly with all other units, and would potentially generate the most bugs after integration. The implementation of this unit needs careful planning. Status: Basic features completed Extra features pending 2.2) File Processor Unit: This unit deals with retrieving and writing data to storage file. One instance of this unit takes an instruction from Logic Unit and either (a) returns the working task list stored in data file or (b) writes the working task list to data file. Originally, we planned to use plain text file as storage. After final revision, we decided to employ excel as the method of storage for efficient retrieval. Status: Completed

2.3) User Interface Unit: This unit interacts with the end user. One instance of this unit either (a) reads a user command and passes it to Command Parser to determine command type, or (b) display the result of the command to user.

Figure 3. Proposed User Interface Status: Completed 2.4) Command Parser Unit: This unit deals with pre-processing the raw user commands to a form usable by Logic Unit. Currently, we still need to figure out a way to implement flexible commands (i.e user can give command in many possible formats). However, it is stated in the guideline that Natural Language Processing is unnecessary. The most viable solution as of now is to artificially inject keywords into Schedulers dictionary (solution by exhaustion). This is not hard to implement, however will require much efforts and time. Status: Basic features completed Flexible commands pending

2.5) Log Unit: This unit deals with recording the sequence of user commands in a chronological order. Its main purpose is to facilitate undo and redo feature. This feature will not be implemented until V0.2 of the project. As such, it is currently unassigned to any team member. After V0.1 demo, we would look into the implementation of this unit. Status: Pending

3. Problems: Along the way, we encountered some problems in communication and several technical issues. First of all, each of us has a different coding style and hence a different visualization of the project implementation. III. Recommendation: IV. Conclusion: