Agnes Natasya - Project Portfolio

About the Project

HireLah! is targeted to bring greater convenience to interviewers who can type quickly and prefer typing over mouse commands. Additionally, we included customised features in our desktop apps to help interviewers to manage interviews.

Role

My contribution to the project includes implementation of command to open an interview report, exporting an interview report and command for navigation to a certain part of the interview report. I also implemented the parser for most of the commands, with test coverage increase of 93% in class, 88% in method and 90% in line amount. I was also involved in building the implementing the transcript of an interviewee.

I also contributed to the UserGuide, which includes a total of 6 different sections in the User Guide and DeveloperGuide, which includes detailed implementation of the state validity of the application, with a total of 7 UML diagrams.

Summary of Contributions

Major enhancement #1: Implemented export report command for exporting a particular interview report as a PDF.
- What it does: allows the user to export the report of a particular interviewee in a distributable and highly useful form, which is PDF.
- Justification: These features are very useful for the user as it allows them to retain a copy of the interview report outside the application itself and it is exported in a distributable form.
- Highlights: This enhancement are very challenging and tedious. I used Apache PDF Box library and it does not have a lot of support in text wrapping, positioning and pagination. Thus, I have to manually calculate and split sentences that are to be written in the PDF. In addition, I need to manually split paragraphs or sections that could not fit into the current page. Furthermore, for every line that is written, I have to manually calculate the x and y coordinate of the starting point of this line.
Major enhancement #2: Implemented open report command for opening a particular interview report.
- What it does: allows the user to open the report of a particular interviewee.
- Justification: These features are useful for the user because it allows them to retrieve the interview report or result after he/she has interviewed a particular interviewee.
- Highlights: This enhancement are totally new and was not part of the codebase.
Major enhancement #3: Implemented navigation commands for navigating in an interview report.
- What it does: allows the user to perform navigate to a certain remark of an interview report according to time or question number when the user is currently opening the report of a particular interviewee.
- Justification: These features are useful for the user because it allows them to directly refer to a particular remark that he/she is interested at, instead of scrolling up and down through the whole remarks of an interview report to go to a particular time or answer to a question.
- Highlights: This enhancement are totally new and was not part of the codebase. The implementation needs careful consideration of the current interviewee, the bounds and input format given by the user.
Major enhancement #4: Implemented the parser for create, update, and delete commands of attributes, interviewees, and questions
- What it does: allows the user to perform an addition, deletion and edition of attributes, interviewees, and questions of an interview session according to input message to the CLI
- Justification: These features are a crucial part of the application as it allows the user to add properties to the interview session in order to be able to start the interview.
- Highlights: This enhancement are totally new and was not part of the codebase. The implementation too was challenging as it required careful considerations on the different possible input received from the user and to handle incorrect and correct input formats properly. I also added unit tests that covers most of the cases in these parser.
Minor enhancement #1: Implemented the building block of the interviewee transcript, which is the placeholder of all information of a particular interview with an interviewee, including the remarks, the attributes and the score associated with it, as well as remarks associated as the answer to a particular question.
Code contributed: [Collated code]
Other contributions:
- Project management (team-based tasks and review contribution):
  - Created issues for respective milestones from v1.1 to v1.4 and assign them to my teammates.
  - Report bugs discovered in the app and issue it to the team (e.g. #197)
  - Reviewed pull requests from other members of the team (e.g. #186, #121, #96, #81)
  - Created the logo for HireLah!
- Documentation:
  - Enhanced user guide and developer guide to document things specific to our application (e.g. #128, #110, #119. #122, #136)
  - Documented a total of 6 sections describing the features of HireLah! in the User Guide.
  - Documented the detail of state validity and finalise feature of HireLah! in the Developer Guide, with a total of 7 UML diagrams created.
  - Removed irrelevant documentation of the codebase.
- Community:
  - Reported bugs in other teams project and gave suggestions to remove them (e.g. 158, 151)

Contributions to the User Guide

I contributed to the user guide to make it comply with our application function. I wrote parts in user guide specifically for the add, edit and delete commands of attributes, questions and interviewees. I also added guide for the feature to open an interview report, exporting an interview report and navigation to a certain part of the interview report feature.

In addition, I also provides screenshots of the result of all commands execution that is included in the user guide to increase understandability and readability by the user. I also contributed to the summary of all the commands available in the application. Here are some of the example of my contributions to the User Guide.

Open Report Command

Viewing Interviewee Reports

After interviewing a candidate, you can view the interview transcript any time by doing an open command. To close the report, you can use a close command.

*Command

open <interviewee>
close report

Example

> open Jane Doe

Action: Shows the entire list of remarks made during the interview, with their timestamps.

Output:

Successfully opened Interviewee report: Jane Doe

Export Command

Exporting Interviewee Reports to PDF

After interviewing a candidate, you can also export the report of the interviewee in the form of a PDF.

Command

export <interviewee>

Example

> export Jane Doe

Action: Exports the interview report of a particular interviewee in PDF.

Output:

Report of Anna exported in /Users/jane/main with file name "2.pdf".

Working in an Interviewee Report

After opening a report, you can scroll up and down to navigate through the remarks you made during the interview. In addition, you can zoom in on a particular moment in the interview by question number, or by the interview time.

Navigating by Question Number

Jumps to the point when the interviewee was answering the given question (marked by the :start q<question number> command).

Command

goto q<question number>

Example

> goto q2

Output:

Here is the remark of question 2!

Navigating by Timestamp

Scrolls the list of remarks to the given time. The user can scroll up and down to see the rest of the remarks.

Command

goto <time>

Example

> goto 2.00

Output:

Here is the remark at time 2.00!

Contributions to the Developer Guide

My contributions to the developer guide includes providing one of the most important feature in the application which is state validity and finalise feature. I also remade the UML diagram for ModelClassDiagram, as well as editing the descriptions and instructions in the developer guide that was customised for the codebase instead of our current application. In total, I created 7 UML diagrams in the developer guide.

State Validity and Finalise Feature

Description

HireLah! can process numerous different inputs from the user, starting from adding an interviewee, adding a metric, opening the report of an interviewee, etc. However, not all inputs are valid at any point of time. So, we need to make sure that the right commands are accepted at the right phase. In addition, we also need to check that the input received is also valid such that the Model component of our application is always in a valid state.

A feature in our application that supports this state validity is the Finalise feature, the feature used to finalise the attributes and questions of an interview session, after the user has finished their CRUD operations to the attributes and questions. After finalising, the user can no longer change the attributes and questions of this interview session.

Implementation

Validity of our application state is achieved through three ways, which includes:

Separation of the application into 3 different phases
Command validation by the Parser and Model component
Implementation of Finalise feature

Separation of the application into 3 different phases

There are 3 different phases in our application, pre-session, normal, and interview phase. At any point of time, our application is in one of these 3 states, and this information is stored inside the model, and it can be retrieved by calling model.getAppPhase(). The reason behind the separation of the application into 3 different phases is because we need to prevent the user from entering invalid commands at any point of time. For example, you cannot start interviewing person B while you are interviewing person A. You need to end your interview with person A then you can interview person B.

When the application had just opened, it will immediately enter into the pre-session phase, where the user are not allowed to do anything except creating a new session or opening other previously-made sessions.

When the user had entered into a session, the application enter the normal phase. In this phase, the user can prompt the application to execute all of the features in the application, except opening a new session and adding interview-related information specific to an interviewee (e.g. adding a remark to person A).

When the application is in the normal phase and the user decided to interview a particular interviewee, the application will enter to the interview phase. During this phase, the user are only allowed to execute commands related to the interview process of an interviewee, which includes adding remark, scoring the attribute and adding remarks as the answer to a particular question, and toggling view between attributes, questions, or metrics.

The implementation of these 3 different phases is achieved through the presence of 3 different parsers in our application. After retrieving the current phase of the application from the Model, the Logic component will then decide which parser of these 3 should be used to parse the input. Through this, we make sure that only appropriate and valid commands at a particular phase are accepted at any point of time.

Given below are several examples of usage scenarios when the user prompts for some commands at a certain phase of the application:

Scenario 1. When the user provides a command which is not recognized by the parser that is associated with the current phase of the application, the respective parser will throw a ParseException, informing the user that this command is unknown. Suppose the app is currently at the PreSession phase, and the user tries to add a new interviewee, add interviewee Jane Doe.

Scenario 2 (Ideal Scenario). When the user provides a command which is recognized by the parser that is associated with the current phase of the application, the respective parser will parser the command and execute the respective CommandResult to the model. For an example, see [AddSequenceDiagram].

Command Validation by the Parser and Model component

By the separation of the application into 3 different phases, we had make sure that the input that is accepted at any particular point if time are input that are appropriate at the current application phase. However, this does not guarantee that this input will be valid according to the current state of the Model. For example, if the application is currently at the normal phase, it will be able to accept the command to interview an interviewee. However, if this interviewee has been interviewed before, doing an interview to the same person should not be allowed.

Assuming that the prompt inserted by the user is accepted at the current phase of the application, given below are several examples of usage scenarios:

Scenario 1. When the user provides a command that is recognized by the current phase of the app but it is missing compulsory fields , the respective parser will check against it and throw ParseException, informing that the prompt is incomplete. For an example, see [Scenario-1-Best-Interviewee-Feature].

Scenario 2. When the user provides a complete and valid command that is recognized by the current phase of the application but is not valid for the current state, the Model will check the command and throw a CommandException, informing the user that this command is invalid for the current state. For an example, see [Scenario-2-Best-Interviewee-Feature].

Scenario 3 (Ideal Scenario). When the user provides a complete and valid command that is recognized by the current phase of the application and is valid for the current state. For an example, see [Scenario-Ideal-Best-Interviewee-Feature].

Finalise Feature

Even with all of these implementations of command accepting according to the current phase and command checking in a particular phase, there is another possibility of invalid state in our application, which happens through the modification of the interview session’s attributes and questions. For example, a metric which takes in attribute leadership and integrity has been created. Later, the user can possibly delete the attribute leadership. This makes the metric create not valid anymore.

Thus, we need a feature that can indicate that the interview session has been finalised, which means that all CRUD operations to the attributes and questions of this interview session is disallowed. CRUD operations to the attributes and questions are originally accepted in the normal phase and if the CRUD operation is valid. However, if the application has entered the finalised state, this disablement happens regardless of the validity of the phase and command.

The finalised state can be achieved through the Finalise Command when the user inputs the word finalise. Before the application is finalised the user is not allowed to hold any interview with any interviewee, create any metric and find any best interviewees. If the application has reached finalised state, the user are allowed to do so.

Assuming that the user is currently on the normal phase, the phase which accepts CRUD operations for the attributes and questions, and assuming that the given CRUD operation is valid (e.g. delete attribute leadership and attribute leadership was there previously), given below are several examples of usage scenarios when the user prompts are related to Finalise Feature:

Scenario 1. If the application has not been finalised finalised and the user tries to interview an interviewee, interview Jane Doe, the Normal Parser will parse the input and create an instance of StartInterviewCommand. The LogicManager will try to execute this StartInterviewCommand toward the model, but because it has not been finalised, it will throw a CommandException error.

Scenario 2. If the application has been finalised and the user tries to do add a new attribute, add attribute leadership, the Normal Parser will parse the input and create an instance of AddAttributeCommand. The LogicManager will try to execute this AddAttributeCommand toward the model, but because it has been finalised, it will throw a CommandException error.

Scenario 3 (Ideal Scenario). If the application has been finalised and the user tries to interview an interviewee, interview Jane Doe, the Normal Parser will parse the input and create an instance of StartInterviewCommand. The LogicManager will execute this StartInterviewCommand toward the model, and the result is returned.

Scenario 4 (Ideal Scenario). If the application has not been finalised and the user tries to do add a new attribute, add attribute leadership, the Normal Parser will parse the input and create an instance of AddAttributeCommand. The LogicManager will execute this AddAttributeCommand towards the model and the result is returned.

The following activity diagram shows the sequence of activities happening after finalise command.

Design Considerations

Aspect: Maintaining the consistency of application state

Alternative 1 (current choice): Have finalise command and disallow CRUD operation to attributes and questions
- Pros: There will no be any invalid values or states, like an attribute score assigned to null.
- Cons: Once the user decide to finalise, the user can no longer edit the attributes and questions. THe user will need to create a new session if the user wants to.
Alternative 2: Do not have a finalise command. User can perform CRUD operation to attributes and questions at any time, including after interview has been done or some metrics have been created. Deleted attributes and questions will be removed from any part of the application, and newly created attributes will have null score and newly created questions will be assigned to no answers.
- Pros: More flexibility for the user if the user wants to change the attributes and questions.
- Cons: The user might not be aware about the consequence of deleting one attribute or question, which might lead to deletion of the all the metrics that uses this attribute `, removal of all `remarks associated as the answer of a question. As new attribute are assigned to null score, these interviewees could not be compared with the others with regards to this feature when the user is using the best interviewee feature. User might need to assign the score value of this newly added attribute to every single interviewees that has been interviewed before this addition, which is a tedious and unfriendly operation.
Alternative 3: Do not have a finalise command. User can perform CRUD operation to attributes and questions at any time, including after interview has been done or some metrics have been created. Deleted attributes and questions will be removed from any part of the application, and newly created attributes will have a default score and newly created questions will be assigned to no answers.
- Pros: More flexibility for the user if the user wants to change the attributes and questions.
- Cons: The user might not be aware about the consequence of deleting one attribute or question, which might lead to deletion of the all the metrics that uses this attribute `, removal of all `remarks associated as the answer of a question. As new attribute are assigned to default score, the result of comparison between this interviewee and the others might not be accurate anymore.

Model

Model component

Figure 1. Structure of the Model Component

API : Model.java

The Model,

stores a UserPref object that represents the user’s preferences.
stores the session data including questions, attributes, metrics, and interviewees including their interview transcripts.
stores the current app state, including whether the user has finalised the attributes and questions, the current phase that the app is in (pre-session, in the normal phase or in an interview), the current session and the current interviewee in focus, whether being interviewed or whose report is being viewed.
exposes an unmodifiable ObservableList<Attribute>, ObservableList<Question>, ObservableList<Metric>, ObservableList<Interviewee> that can be 'observed' e.g. the UI can be bound to this list so that the UI automatically updates when the data in the list change.