Description
It's time to finally get back to working on the Assessment Flow! Lot's of things to account for here so this ticket might be a little bit of a lengthy read. For some context, Carter has built a quite fleshed out v0 of this flow last semester.
Please take a look at this video for Carter's explanation on what currently exists.
The main change that needs to be made is that the OA will remain on a SINGLE page. This means that there will be no separate routes and page loads for each question of the OA.
Sidebar
In the MVP of Sarge, OA questions will be linear. This means that when a candidate submits a question, they cannot go back. You will design the state flow with this in mind.
As seen in Carter's video, the useAssessment hook has a lot of logic here already. There are some immediate changes you'll need to make:
fetchAssessments should not simply getAssessments, but instead fetch AssessmentTemplateTasks as this table has the order field that updates when editing an AssessmentTemplate. This will be the order that displays on the sidebar of the assessment. There are a few cases to take note of here:
- If there is a
Text section in an assessment template, if it is first, then the assessment should NOT start counting down until the candidate presses Continue
- Similarly, if there is a
Text section in the assessment template that appears last, the candidate's assessment should END at the last Task, and then the final Text section should appear.
- If there is a
Text section in between Tasks, then it should just act as another question on the sidebar. If they are at the ends, they should not be included in the sidebar.
The sidebar should look like the following:
As you can see there is a few things you need to fetch and take note of:
-
First, questions that are completed/submitted should have that checkmark state. The current question the candidate is on should look like that, and the questions that the candidate has not reached yet should be "locked" as show.
- Please note that we are simply labeling the questions as "1", "2", etc. We are purposely NOT showing the names of the task template.
-
Next is the timer at the top. This total time should be the accumulation of the estimatedTime field in each TaskTemplate in the AssessmentTemplate.
- Don't worry about anything else to do with the timer for now. Ie: Making it red at a certain time and hiding it
Top Bar
- Our logo
- The name of the candidate
- A hyperlink (that should not do anything yet) that states "This is not me"
- Initials of candidate in a profile picture
Full Page
- Lots of these components already exist! Use them. See our
TaskTemplateEditor. However, the test section is different. In the full page, a PUBLIC test cases view can be toggled where the user can see all the public test cases AND their input and output (exactly what is seen in the current component we have), but the test input and output fields are not editable.
- Below the test case toggle, there should be run tests and submit and continue button.
- This PR is not responsible for running tests
- Submit and continue should lock out the current question, and go to the next question. Do not worry about anything database related.
- I would suggest using a strategy similar to
useOnboardingModal to keep track of the different steps within state. Reminder that refreshing the page SHOULD technically end the OA, so we'd like this all to be stateful and not in seperate routes.
Acceptance Criteria
- Implementation matches requirements above.
Description
It's time to finally get back to working on the Assessment Flow! Lot's of things to account for here so this ticket might be a little bit of a lengthy read. For some context, Carter has built a quite fleshed out v0 of this flow last semester.
Please take a look at this video for Carter's explanation on what currently exists.
The main change that needs to be made is that the OA will remain on a SINGLE page. This means that there will be no separate routes and page loads for each question of the OA.
Sidebar
In the MVP of Sarge, OA questions will be linear. This means that when a candidate submits a question, they cannot go back. You will design the state flow with this in mind.
As seen in Carter's video, the
useAssessmenthook has a lot of logic here already. There are some immediate changes you'll need to make:fetchAssessmentsshould not simplygetAssessments, but instead fetchAssessmentTemplateTasks as this table has theorderfield that updates when editing anAssessmentTemplate. This will be the order that displays on the sidebar of the assessment. There are a few cases to take note of here:Textsection in an assessment template, if it is first, then the assessment should NOT start counting down until the candidate presses ContinueTextsection in the assessment template that appears last, the candidate's assessment should END at the lastTask, and then the finalTextsection should appear.Textsection in betweenTasks, then it should just act as another question on the sidebar. If they are at the ends, they should not be included in the sidebar.The sidebar should look like the following:
As you can see there is a few things you need to fetch and take note of:
First, questions that are completed/submitted should have that checkmark state. The current question the candidate is on should look like that, and the questions that the candidate has not reached yet should be "locked" as show.
Next is the timer at the top. This total time should be the accumulation of the
estimatedTimefield in eachTaskTemplatein theAssessmentTemplate.Top Bar
Full Page
TaskTemplateEditor. However, the test section is different. In the full page, a PUBLIC test cases view can be toggled where the user can see all the public test cases AND their input and output (exactly what is seen in the current component we have), but the test input and output fields are not editable.useOnboardingModalto keep track of the different steps within state. Reminder that refreshing the page SHOULD technically end the OA, so we'd like this all to be stateful and not in seperate routes.Acceptance Criteria