DELTA 35 0 61 SVN3·#·#€·#Work product 3. Detailed Component Specifications Written by Nate Chenette ** Please add your name if you edit this, and indicate which parts you wrote ** The User Interface 1. The initial (main) U/I will be web-based. (Future features may include a standalone application-based U/I or plug-in.) 2. The following states must be implemented (probably with each one as a different page on the site): a. Login page - links to New User page and (given username and password) the View Schedule page b. New User page - allows creation of a new registered user account (with username and password). After new account is created, the new user is automatically logged in and sent to the View Schedule page. c. View Schedule page - allows viewing of schedule, and links to View Meeting/Edit RSVP pages for each meeting invited to; there are two-way links from here to Profile/Preferences, Create/Manage Meetings, and Edit Schedule. d. View Meeting/Edit RSVP - View details about a meeting the user is invited to, and allow user to edit their RSVP. Links back to View Schedule page. e. Edit Schedule - allow the user to add non-meeting events to their schedule, including the setting of "importance coefficients" for each. Links back to View Schedule. e. Profile/Preferences - Allow the user to update their user profile. Links back to View Schedule. e. Create/Manage Meetings - Allow the user to create a new meeting and manage the meetings he/she is the creator of. 3. Unregistered users, when invited to a meeting, are sent (via email) a link to the View Schedule page. Note that, from here, they can only get to the View Meeting/Edit RSVP page and back. 4. The only other way to enter the site is from the Login page. 5. View Schedule is in calendar format. 6. For creating/managing meetings, people can be added to the guest list by specifying an email address. The email address is looked up on the database of registered users. If a match is found, the invitee is treated as that registered user; otherwise, they become an unregistered user. Each new invitee is given an "importance coefficient" by the meeting creator. 7. The Meeting creation/management page allows the meeting creator to suggest times and approve others' proposed times. 8. The only necessary data for Profile/Preferences is an email address. Other options that can be set should include: name, title/position, company, contact info for general viewing, contact info and preferences for meeting reminders. 9. Edit schedule only allows the user to enter non-meeting conflicts (meetings are automatically managed in the calendar when they are created or are edited). 10. View Meeting/Edit RSVP first of all allows the user to see information about the meeting (as specified by the meeting creator). It should also let the user indicate preferences for proposed times, propose other times to the meeting creator, and RSVP to each proposed time (will come/won't come). Server 1. The server contains the database of Users and the database of Meetings. 2. It must respond to the following requests from the U/I, by invoking the appropriate functions of Users and Meetings. Note that all password verification and security is done by the server (not the U/I). a. New User - create a new registered user with the given password b. *Accept registered user login - given a username and password, verify that they correspond to a certain registered User c. *View schedule - return the schedule of a user d. *New/edit schedule - allow the logged-in user to edit their schedule e. *Create/manage meeting - create a new Meeting with the logged-in user as the meeting creator, and allow them to manage it f. View meeting/edit RSVP - allow the user to look at a meeting they are invited to, and edit their RSVP g. *Edit profile/preferences - allow the logged-in user to edit their personal information and contact settings. [* = actions allowed only for registered users] 3. Provide "alarm clock" functionality - remind users of upcoming meetings via their preferred contact settings. User 1. A user is either registered (has a username and password) or unregistered (email address only). 2. Every registered user has a schedule which is editable and can list their weekly conflicts (including links to the meetings controlled by the software). 3. Every user has contact information: a. For an unregistered user (an invitee to a meeting), the contact information is specified by the inviter and must be an email address. b. Registered users can define their preferred contact method or methods, among email, IM, phone text messaging. 4. A registered user also has a profile where personal information such as name, location, title, and contact information can be stored. 5. A registered user should be able to edit their schedule and personal info, view/respond to their meetings, and create new meetings. 6. An unregistered user can only view or respond to their meetings. REASONS for using the registered/unregistered user approach: One of the most important goals of our software is to save time for users. Towards this goal, we have divided our users into two groups. One group, "infrequent users" or "unregistered users," are people who have only been invited to meetings, will probably use the software less than a few times, and therefore would not like to waste the time (or give away personal information) that is necessary to register. The other group, "frequent users" or "registered users," consists of people who wish to create meetings, and/or plan to use the software often. In order to save them the time of re-inputting information about their schedule often, they can input their weekly schedule and have it saved in their profile, along with other useful personal information that they'd like to store. (Also, registered users have the convenience of multiple methods of communication.) NOTE to designer: it might be useful to have registered and unregistered users be separate classes, since they have so many differences. In fact, it might make sense to make the registered user class extend the unregistered user class, because a registered user can do everything an unregistered user can do (but more). Meeting 1. The Meeting has a certain password, which is chosen by the meeting creator when the Meeting is created. 2. For anyone who inputs the correct password, the Meeting should provide access to the following: a. name/description of Meeting b. name of meeting creator c. names of meeting invitees d. URL of meeting page e. proposed and/or finalized meeting times 3. When a Meeting is created or updated, the validity of the added/changed information must be checked. 4. The meeting creator should be able to convey to the Meeting the relative importance that each individual invitee attend the meeting. 5. "Algorithm" - Based on the "importance of invitee" information, and the schedules of invitees (including relative importance of conflicts), the Meeting should be able to suggest good meeting times to the meeting creator. ENDREP DELTA 37 0 1026 SVN‡sˆA h‡$€h5‡>March 30): Discussed current progress Post-meeting 3: Work on individual components Meeting 4 (April 2ENDREP id: q.0.r41/7257 type: file pred: q.0.r40/7355 count: 2 text: 41 0 7089 7075 d2d003caf5184013a2576e290ca020d1 cpath: /architecture_design/component_specifications/detailed_component_specifications.txt copyroot: 0 / PLAIN K 37 detailed_component_specifications.txt V 17 file q.0.r41/7257 K 11 meeting.txt V 16 file n.0.r30/156 K 18 user_interface.txt V 16 file m.0.r30/323 END ENDREP id: l.0.r41/7641 type: dir pred: l.0.r40/7737 count: 3 text: 41 7473 155 155 5ed4c68466cb7b1e54234f7d2de58774 cpath: /architecture_design/component_specifications copyroot: 0 / id: k.0.r41/7819 type: file pred: k.0.r37/1050 count: 3 text: 41 7110 124 1089 efedb554af0b4da7fa5bd90025a70883 cpath: /architecture_design/plan.txt copyroot: 0 / PLAIN K 24 Overall_Archetecture.pdf V 18 file i.0.r27/34985 K 19 UI_Architecture.pdf V 18 file h.0.r27/34708 K 16 architecture.txt V 17 file o.0.r39/1805 K 24 component_specifications V 16 dir l.0.r41/7641 K 14 components.txt V 16 file j.0.r29/314 K 8 plan.txt V 17 file k.0.r41/7819 END ENDREP id: g.0.r41/8278 type: dir pred: g.0.r40/8209 count: 14 text: 41 7983 282 282 ebdc1f6eccd19c966cdc1c8c4bd883e4 cpath: /architecture_design copyroot: 0 / PLAIN K 19 architecture_design V 16 dir g.0.r41/8278 K 22 requirements_documents V 13 dir 1.a.r26/0 END ENDREP id: 0.0.r41/8543 type: dir pred: 0.0.r40/8474 count: 41 text: 41 8432 98 98 4f7c4d3b29038811eab0d96a5239028a cpath: / copyroot: 0 / k.0.t40-1 modify true false /architecture_design/plan.txt q.0.t40-1 modify true false /architecture_design/component_specifications/detailed_component_specifications.txt 8543 8676