diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index 024668cab26..502b4bd7a46 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -480,20 +480,21 @@ Free alternative for tracking interview datetimes, applicant contacts and their Priorities: High (must have) - `* * *`, Medium (nice to have) - `* *`, Low (unlikely to have) - `*` -| Priority | As a …​ | I want to …​ | So that I can…​ | -|----------|----------------------------------------------------------------------|----------------------------------------------------|---------------------------------------------------------------------------| -| `* * *` | new user | see usage instructions | refer to instructions when I forget how to use the Tether | -| `* * *` | user | add a new person (applicant/interviewer) | | -| `* * *` | user | delete a person (applicant/interviewer) | remove person entries that I no longer need | -| `* * *` | user | add a new interview | | -| `* * *` | user | delete an interviewer | remove interview entries that I no longer need | -| `* *` | user with many persons in Tether | find a person by name/email | locate details of a person without having to go through the entire list | -| `* *` | user with many interviews in Tether | filter interviews by date | locate details of interviews without having to go through the entire list | -| `* *` | user with many applicants of varying application status in Tether | tag applicants | identify applicant's application progress | -| `* *` | user with many interviewers of varying availabilities in the company | have a record of interviewer's interview scheduled | identify which interviewers are occupied or available for interviews | -| `* *` | user with many persons of varying application status in Tether | filter persons by status | contact all persons within a specific status group if necessary | -| `* ` | user collaborating with other Tether users | share an applicant's details | update other hiring managers on applicant details | -| `* ` | user who does not want to clutter local hard drive with files | store applicant's resume | view applicant's resume in Tether | +| Priority | As a …​ | I want to …​ | So that I can…​ | +|----------|---------------------------------------------------------------------------------|---------------------------------------------------------------|---------------------------------------------------------------------------| +| `* * *` | new user | see usage instructions | refer to instructions when I forget how to use the Tether | +| `* * *` | user | add a new person (applicant/interviewer) | | +| `* * *` | user | delete a person (applicant/interviewer) | remove person entries that I no longer need | +| `* * *` | user | add a new interview | | +| `* * *` | user | delete an interviewer | remove interview entries that I no longer need | +| `* *` | user with many persons in Tether | find a person by name/email | locate details of a person without having to go through the entire list | +| `* *` | user with many interviews in Tether | filter interviews by date | locate details of interviews without having to go through the entire list | +| `* *` | user with many applicants of varying application status in Tether | record applicants' statuses | identify applicant's application progress | +| `* *` | user with many interviewers of varying availabilities in the company | have a record of interviewer's scheduled interviews | identify which interviewers are occupied or available for interviews | +| `* *` | user with many persons of varying application status in Tether | filter persons by status | contact all persons within a specific status group if necessary | +| `* ` | user collaborating with other Tether users | share an applicant's details | update other hiring managers on applicant details | +| `* ` | user who does not want to clutter local hard drive with files | store applicant's resume | view applicant's resume in Tether | +| `*` | user with multiple ongoing interviews and many applicants/interviewers to track | view overall statistics of applicants/interviewers/interviews | keep abreast of the overall situation at all times | *{More to be added}* @@ -508,6 +509,8 @@ Priorities: High (must have) - `* * *`, Medium (nice to have) - `* *`, Low (unli 1. User requests to list persons 2. System displays list of persons + Use case ends. + **Use case: UC02 - Add a person with name, email and phone number** **MSS** @@ -563,6 +566,7 @@ Priorities: High (must have) - `* * *`, Medium (nice to have) - `* *`, Low (unli Use case resumes at step 1. **Use case: UC05 - Update an applicant's status** + Precondition: There is at least 1 applicant in the system. **MSS** @@ -589,6 +593,7 @@ Precondition: There is at least 1 applicant in the system. Use case resumes at step 1. **Use case: UC06 - Filter by status** + Precondition: There is at least 1 applicant or interviewer in the system. **MSS** @@ -605,14 +610,22 @@ Precondition: There is at least 1 applicant or interviewer in the system. Use case resumes at step 1. -**Use case: UC07 - Add an interview** +**Use case: UC07 - List interviews** **MSS** 1. User requests to list interviews 2. System shows a list of interviews -3. User requests to add a new interview to the list -4. System adds the interview and updates the displayed list + + Use case ends. + +**Use case: UC08 - Add an interview** + +**MSS** + +1. User requests to list interviews (UC07) +2. User requests to add a new interview to the list +3. System adds the interview and updates the displayed list Use case ends. @@ -622,16 +635,15 @@ Precondition: There is at least 1 applicant or interviewer in the system. * 3a1. System shows an error message. - Use case resumes at step 2. + Use case resumes at step 1. -**Use case: UC08 - Delete an interview** +**Use case: UC09 - Delete an interview** **MSS** -1. User requests to list interviews -2. System shows a list of interviews -3. User requests to delete a specific interview in the list -4. System deletes the interview +1. User requests to list interviews (UC07) +2. User requests to delete a specific interview in the list +3. System deletes the interview Use case ends. @@ -641,40 +653,39 @@ Precondition: There is at least 1 applicant or interviewer in the system. * 2a1. System shows an error message. - Use case resumes at step 2. + Use case resumes at step 1. * 3a. The given index is invalid. * 3a1. System shows an error message. - Use case resumes at step 2. + Use case resumes at step 1. -**Use case: UC09 - Filtering interviews by date** +**Use case: UC10 - Filtering interviews by date** **MSS** -1. User requests to list interviews -2. System shows a list of interviews -3. User requests to filter interview by a specified date -4. System updates the list to only display interviews that match the specified date +1. User requests to list interviews (UC07) +2. User requests to filter interview by a specified date +3. System updates the list to only display interviews that match the specified date Use case ends. **Extensions** -* 3a. The given date is invalid. +* 2a. The given date is invalid. - * 3a1. Tether shows an error message. + * 2a1. Tether shows an error message. - Use case resumes at step 2. -* 3b. There are no interviews on the specified date. + Use case resumes at step 1. +* 2b. There are no interviews on the specified date. - * 3b1. Tether shows a no interviews found message. + * 2b1. Tether shows a no interviews found message. - Use case resumes at step 2. + Use case resumes at step 1. -**Use case: UC10 - View overall statistics** +**Use case: UC11 - View overall statistics** **MSS** @@ -925,8 +936,66 @@ testers are expected to do more *exploratory* testing. Given below are the planned enhancements we plan to implement for our application in the future: -1. **To be added** +1. Add group/panel interviews + - **Description:** Currently, each interview can only have one applicant and one interviewer. This can be problematic since it is common for group interviews to occur where there are multiple interviewers/applicants in one interview. + - **Enhancement:** To resolve this, we plan to allow the `add_interview` command to take in more than one applicants/interviewers phone number. + - **Example:** The user can add two applicants and 2 interviewers to an interview by executing`add_interview desc/Group interview date/2024-05-05 st/13:00 et/15:00 a/11111111 a/22222222 i/33333333 i/44444444`. +
+
+2. `AddApplicantStatusCommand` to accommodate custom statuses + * Description: Currently, the `AddApplicantStatusCommand` strictly checks if the status given by the user matches any of 5 preset statuses. This can be problematic since different companies may have different conventions on applicant statuses and thus require adding applicant statuses to be more flexible. + * Enhancement: To resolve this, we plan to change the `AddApplicantStatusCommand` to accommodate custom statuses so long as they still adhere to some basic constraints such as being alphanumeric or ASCII-characters. + * Example: A user may choose to execute `applicant_status 12345678 s/Stage1` instead of `applicant_status 12345678 s/resume review`, depending on their specific label for the first stage of the hiring pipeline. +
+
+3. Shorthand for commands + - **Description:** Currently, some commands can be very long and take some to type out. This can affect the efficiency of the hiring manager. + - **Enhancement:** To resolve this, we plan to add shorter versions of existing commands by modifying the parser classes to take in these shorter commands. + - **Example:** User can filter interviews by `fibd 2024-05-05` instead of typing out the whole `filter_interviews_by_date 2024-05-05`. +
+
+4. `PersonCard` to accommodate dynamic sizing + * Description: Currently, the `PersonCard` encapsulating all the fields of a person (`name`, `email`, `status`...) spills out of bounds when the fields have too long values or when statuses stack up vertically (for interviewers). This can be problematic since it impedes the user view of the application and undermines their interaction with it. + * Enhancement: To resolve this, we plan to calibrate the `PersonCard`s to be more dynamically sized i.e. resize themselves when the information they encapsulate grows out of the current dimensions. +
+
+5. Edit parameters of persons + - **Description:** Currently, the only way to edit a person’s details is to delete the person and re-add the person with the corrected details. This can be problematic as users have to execute multiple commands with repeated parameters just to make a small change. + - **Enhancement:** We plan to abstract these steps into a single edit command which allows users to change specific parameters of a selected person. + - **Example:** Assuming the first person in the list has name Alice and the user wants to change the person’s name to Bob, the command `edit 1 n/Bob` can be executed. +
+
+6. Tagging persons + - **Description:** Currently, applicant and interviewer tags are automatically added when a person object is created and cannot be modified. This can be inconvenient for users who may want to manually append additional information in the tags of existing people, but are unable to do so in the current iteration of Tether. + - **Enhancement:** To resolve this, we plan to modify the currently private add tag functionality into a command that users can input in the command box to add custom tags to persons. + - **Example:** Users can now execute `tag 1 late` to add a late tag to the first person in the list. +
+
+7. More specific error messages + - **Description:** Some of the commands currently are not the most specific when it comes to error messages. Users who enter the parameters wrongly might not be able to tell from a glance what went wrong. One example would be for the add_interview command if the user accidentally swapped the interviewer and applicant’s phone numbers. + - **Enhancement:** We can create a new exception for when the user swaps the interviewer and applicant’s phone numbers. + - **Example:** If the phone numbers are swapped, an error message will be shown: “You seemed to have swapped the interviewer and applicant’s phone numbers”. +
+
+8. Separate Applicant/Interviewer list + - **Description:** Currently, all persons (regardless of applicant or interviewer) are packed in the persons list, with their respective tags. These two different types of persons are not sorted or separated. This might not be convenient when you only want to look at either applicants or interviewers but not both. + - **Enhancement:** We can modify the UI to have a third list, of Interviewers, in the middle. The leftmost list will be list of Applicants, while the rightmost will remain to be the list of interviews. The two persons list will be labelled Applicants and interviewers respectively. + - **Example:** The two different lists will be as described, then the list_persons command will reset all filters for both lists. find_name/phone/email command will also work for both. The Applicant and Interviewer Tag is no longer shown. +
+
+9. Delete Interviews when deleting a person + - **Description:** Currently, when the user tries to delete a person, the system checks whether that person is involved in any existing interviews (be it as an applicant or interviewer). If this is false, the command executes as normal. However, if it is true, the command execution will be blocked and the user will receive a system message stating that he or she will need to delete all interviews corresponding to the person before he or she can delete the person. This might be troublesome if there are many interviews to be deleted. + - **Enhancement:** We plan to add a cascading function that will automatically search for all existing interviews corresponding to the person and delete them, as well as the person. We will also ask the user to confirm this action before proceeding. + - **Example:** If applicant A has 3 existing interviews, when the user deletes this applicant, the system will ask for confirmation first. After confirming, the application will delete applicant A together with all 3 interviews corresponding to A. +
+
+10. Delete multiple people at once + - **Description:** Currently, the user can only delete one person at a time. This may be problematic because the user may want to delete many people at once and this can take up quite some time. + - **Enhancement:** We plan allow the `delete_person` command to take in multiple phone numbers at once. + - **Example:** The user can execute `delete_person 11111111 22222222 33333333` to delete persons with the respective phone numbers. +
+
## **Appendix: Effort** **To be added** diff --git a/docs/UserGuide.md b/docs/UserGuide.md index 3291699e389..1f8a26d8eb7 100644 --- a/docs/UserGuide.md +++ b/docs/UserGuide.md @@ -46,7 +46,7 @@ Ready to make hiring management easy for yourself? Let's get started! - [Clear All Existing Data](#clear-all-existing-data) - [Exiting the Program](#exiting-the-program) - [Saving your Data](#saving-your-data) -- [Planned Enhancements and Known Issues](#planned-enhancements-and-known-issues) +- [Planned Enhancements and Known Limitations](#planned-enhancements-and-known-limitations) - [Glossary](#glossary) - [FAQ](#faq) - [Command Summary](#command-summary) @@ -111,7 +111,8 @@ Before delving into the features, we want you to give you a brief tour on how to * Note that the Result Box may not necessarily refresh everytime a new command is executed. This may happen if, as an example, a command incurs a fatal error before it can generate a result. 4. Person/Interview Card: Where the details of each person **[4]** and interview you add are displayed 5. Path to saved data: The location (i.e. the place you created the _tether_folder_ from earlier) of the folder _data_ in which your person/interview data file _addressbook.json_ is saved. If you followed the instructions in the [Quick Start](#quick-start) closely, when you first run and use the application using `java -jar`, the _data_ folder should be automatically created in the same _tether_folder_ that you created to store the `tether.jar` file. - * **Note**: If you move the _data_ folder or the enclosed _addressbook.json_ file to some other location, the application will **not** load with your existing data. This is because the application searches for the data folder in the **same** location as your `tether.jar` file. The path to saved data will **not** update itself if you move the _data_ folder. To summarize, just do not touch the _data_ folder or the _addressbook.json_ file as doing so would cause issues with your existing data. + * **Note**: If you move the _data_ folder or the enclosed _addressbook.json_ file to some other location, the application will **not** load with your existing data. This is because the application searches for the data folder in the **same** location as your `tether.jar` file. The path to saved data will **not** update itself if you move the _data_ folder. + * To summarize, just do not touch the _data_ folder or the _addressbook.json_ file as doing so would cause issues with your existing data. ## Help yourself! @@ -171,12 +172,12 @@ One of the first steps in the hiring pipeline is when an applicant submits their To record an applicant and their contact details in Tether, simply execute `add_applicant n/NAME p/PHONE e/EMAIL` and the applicant will appear under the _Persons_ column as seen via the example usage below. -**Example usage**: +**Example Usage**: * `add_applicant n/Wesley Yu p/88889999 e/wesleyyu@gmail.com` ![img_3.png](img_3.png) -**Parameter constraints**: +**Parameter Constraints**: * Names can only contain alphanumeric **[6]** characters and spaces, and should not be blank. * Phone numbers must be at least 3 digits long and strictly only contain numbers (i.e. no spaces or dashes). * Emails should be of the format local-part@domain and adhere to the following constraints: @@ -317,12 +318,12 @@ To find a person or persons, execute `find_email/name/phone PARAMETER1 PARAMETER **Example Usage**: -**Single parameter:** +**Single Parameter:** Executing ```find_name Alice``` will list all persons containing the name ```Alice```: ![img.png](images/find-command/base_to_success.png) -**Multiple parameters:** +**Multiple Parameters:** Executing ```find_phone 123 456``` will list all persons with the phone number `123` or `456` as seen below: ![img.png](images/find-command/base_to_multiplesuccess.png) @@ -422,7 +423,7 @@ There is **no need** to save manually. -------------------------------------------------------------------------------------------------------------------- -## Planned Enhancements and Known Issues +## Planned Enhancements and Known Limitations Tether is always a Work-In-Progress as we are constantly refining our application for your needs. Listed below are some of our planned enhancements as well as current limitations, to keep you abreast of the current state of our application. @@ -432,12 +433,15 @@ Tether is always a Work-In-Progress as we are constantly refining our applicatio * A `tag` command and `t/` parameter to add and edit custom tags for persons/interviews. * `undo` and `redo` for commands. * Separate lists in the GUI for Applicants and Interviewers as opposed to displaying them together in one Persons list. + * Custom statuses for applicants. + * Delete multiple persons at once.

3. Interviews * Delete interviews automatically once an applicant or interviewer is deleted. + * Schedule interview involving multiple applicants or interviewers. -### Known Issues +### Known Limitations 1. User Display * In general, we focused on a clean interface with minimal moving parts. For this reason, there are many possible areas for improvement in our UI that we are ready and open to work on * Currently, adding multiple interviews may cause the interviewer's card to expand beyond its bounds.