Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2024 - E2492. UI for View submissions/assign grades (except heatgrid)

2024-12-05T23:55:28Z

Sgetahu: /* ReviewTable.test.tsx */

== Introduction ==
=== Project Overview ===

The "View Submissions" project focuses on developing a user interface (UI)
to maintain the score of reviewer submissions.

The Peer Review Summary Page UI is designed to display essential information for each review
assignment in a streamlined and user-friendly format. It provides a clear overview of contributors
and assigned reviewers, with interactive options such as "Unsubmit" and "Delete" to manage
submissions easily. Meta-reviewer options are intentionally excluded to keep the interface
focused solely on core reviewer functionalities. Additional sections are included to display
missing reviews, add grades and comments, and create an efficient and straightforward
interface for managing peer reviews.

== Design Goals ==
The Peer Review Summary Page in this project is designed to display essential information for each review assignment in a streamlined and user-friendly format. The main objectives focus on consistency and clearness, minimalism, flexibility, and intuitivism:

* '''Consistency and clearness: '''The Peer Review Summary Page UI interface should be consistent and clear.

* ''' Minimalism: '''The Peer Review Summary Page UI interface is very cluttered and there is so much going on in the page which makes it hard for a student to navigate through the information that is being displayed. We aim to avoid cluttering the interface with too much information.

* ''' Flexibility: '''The Peer Review Summary Page UI interface should be flexible and avoid clutter. We aim to deliver flexibility by rearranging information around the page to make it more presentable and easy to read.

* '''Intuitivism: '''The Peer Review Summary Page UI interface should be easy to use and understand. At the moment, the UI shows a few confusing and hard-to-understand areas/blocks (such as the "Submitted Work" table). We aim to make these areas less confusing by changing the way these blocks are being displayed.

These objectives ensure that students can efficiently see their grade details for a particular project, such as project title, team name, average peer review score, and peer review scores for each received review, and perform essential actions like show submission, show reviews, show author feedback, and show stats.

Through these design goals, we aim to deliver a more user-friendly solution that enhances the functionality and manageability of grade information for a particular project within the Expertiza system. The project leverages ReactJS and TypeScript to achieve these objectives, ensuring a modern, consistent, and flexible interface.

== Current UI Layout ==
The image below refers to the current UI layout. As shown in the image, the UI looks very cluttered and it is hard to find information in it. It has so many links and descriptions scattered around the page without any order. This makes it hard for a student to find information quickly.

[[File: loyda_layout1.png|900px]]

With the objectives that were mentioned in the previous section and the possible changes that are discussed next, we hope to alleviate the clutter and make the UI more visually appealing.

== Detail Description of Possible and Actual Changes ==

=== 1. Intuitive Display of statistics table: "Submitted Work", "Author Feedback", and "Teammate Review" ===
==== Rationale ====

The statistics table that encompasses the "Submitted Work", "Author Feedback", and "Teammate Review" tables lack contrast which makes them hard to understand and hard to read. Below is a snapshot of their locations in the current UI:

==== Existing Design ====

[[File: loyda_1.png|1200px]]

Notice how hard it is to visualize the tables and how hard it is to follow the information that they are providing. Our goal is to make these tables more visually appealing by introducing 2 possible changes. The changes are highlighted below.

==== Possible Changes ====

* ''' 1. Introduce shading '''
One of the possible approaches to fixing this issue is to Introduce color by filling each table with a different color.

[[File: loyda_2b.png|1200px]]

* ''' 2. Introducing outside borders: '''
Another possible solution to this issue is to add an outside border to each table to make it easier to read and understand. After adding table borders, the tables are expected to be displayed as follows:

[[File: loyda_2a.png|1200px]]

==== Actual Changes ====
The two proposed changes highlighted above were combined to create a new statistics table. Each of the 2 proposed changes introduces good mechanisms for achieving clarity and delivering a visually appealing statistics table to the user. Below is a snapshot of the new statistics table. Notice how easy it is to read and follow the details in the table as opposed to the original table.

[[File: loyda_2c.png|1200px]]

* ''' Updated Files '''

src/pages/ViewTeamGrades/Statistics.tsx [https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/Statisticstsx Statistics.tsx]

=== 2. Change the Location and Format of Team Member List ===
==== Rationale ====
The team member list is a type of information that should be readily available to the user. Instead, it is placed almost at the bottom of the page. Also, the font size is really small which makes it difficult to locate and read.

Furthermore, the "RoundSelector.tsx" file contains a function and its main purpose is to select the review round. However, its function is also to display the team member list. This violates the single responsibility principle. To fix this issue and allow the "RoundSelector" function to perform one function only, which in this case is to select the review round, it would be wise to move the code to gather and display the team information elsewhere — most likely inside the ReviewTable.tsx file.

==== Existing Design ====

Below is a screenshot of where the team member list is located in the UI. The team member list is outlined in red for visibility:

[[File: loyda_3a.png|1200px]]

Notice how small the font size is. Also, the team list should be located at the beginning of the page because it is part of the basic information that should be rendered first.

The current code to gather and display the team member list is located inside the "RoundSelector.tsx" file

[[File: loyda_3b.png|450px]]

Our goal is to change the location of the code snippets that are outlined in red to another location. This change will allow the RoundSelector function to only focus on selecting the review "Rounds"

==== Possible Changes ====

* ''' 1. Place the team list at the top of the page '''
The possible location of the team list will be in between the "Team" and "Average peer review score" information. The text format will also be changed. A larger text size will be introduced. These changes will allow the user to locate the list of the names of his/her team.

* ''' 2. Change the location of the code that gathers and displays the team list elsewhere '''
Changing the location of the code from the "RoundSelector.tsx" file to the "ReviewTable.tsx" file would allow us to fix the violation of the single responsibility principle in "RoundSelector.tsx".

==== Actual Changes ====
Below is a screenshot of the new location of the team member list outlined in red for visibility. Notice that the team member list is easy to locate as well as easy to read.

[[File: loyda_3c.png|1200px]]

Also, we changed the code to gather and display the team member list in the "ReviewTable.tsx" file. The new code snippets added are outlined in red for visibility

[[File: loyda_3d.png]]

The new "RoundSelector.tsx" contains the function that is ONLY focussed on selecting the review "Round" and thus obeys the single responsibility principle. A snapshot of the new function is provided below:

[[File: loyda_3e.png]]

* ''' Updated Files '''

src/pages/ViewTeamGrades/RoundSelector.tsx [https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/RoundSelelctor.tsx RoundSelector.tsx]
src/pages/ViewTeamGrades/ReviewTable.tsx [https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/ReviewTable.tsx ReviewTable.tsx]

=== 3.Export Options for Tables ===

'''Current Limitation:'''
Users cannot save or analyze table data outside the user interface. This makes it difficult to share or process data for further analysis.

'''Proposed Solution:'''
Add export buttons below each table to allow users to download the data as CSV, Excel, or PDF files. This will increase the flexibility and utility of the tables.

'''Implementation Details:'''
‎<br> 1. Export buttons for CSV and Excel are located below the table. ‎<br>
‎<br> 2. Utilizes the SheetJS (xlsx) library to generate exportable files. ‎<br>
‎<br> 3. File structure matches the table's visible data. ‎<br>

'''Supporting Code:'''
const exportTableData = (format: "csv" | "xlsx") => {
const tableData = initialData.map((row) => {
const rowData: Record<string, any> = {};
columns.forEach((col) => {
const accessor = col.id; // Use column `id` for keys
if (accessor) {
rowData[accessor] = row[accessor];
}
});
return rowData;
});

const worksheet = XLSX.utils.json_to_sheet(tableData);
const workbook = XLSX.utils.book_new();
XLSX.utils.book_append_sheet(workbook, worksheet, "TableData");

const fileType = format === "csv" ? "csv" : "xlsx";
XLSX.writeFile(workbook, `table_data.${fileType}`);
};

'''Export Buttons in the UI:'''
<div style={{ marginTop: "10px" }}>
<button
onClick={() => exportTableData("csv")}
className="btn btn-primary me-2"
>
Export to CSV
</button>
<button
onClick={() => exportTableData("xlsx")}
className="btn btn-primary"
>
Export to Excel
</button>
</div>

'''Testing:'''
it("renders export buttons", () => {
render(<Table data={mockData} columns={mockColumns} />);
expect(screen.getByText("Export to CSV")).toBeInTheDocument();
expect(screen.getByText("Export to Excel")).toBeInTheDocument();
});

=== 4.Improved Feedback Indicators ===

'''Current Limitation:'''
Users have no indication of when table data was last updated, leading to potential uncertainty about its accuracy.

'''Proposed Solution:'''
Add "Last Updated" timestamps or live refresh indicators for each table.

'''Implementation Details:'''
‎<br> 1. Include a "Last Updated: [Date/Time]" label below the table. ‎<br>
‎<br> 2. Update the timestamp dynamically whenever the data source is refreshed. ‎<br>
‎<br> 3. Use a subtle spinning loader icon to indicate data refreshing. ‎<br>

'''Supporting Code:'''
const [lastUpdated, setLastUpdated] = useState<Date | null>(null);

const refreshTableData = () => {
setLastUpdated(new Date());
};

=== 5.Extending toggle options ===

==== Rationale ====
While the heat map provides a great visual representation of the users feedback, with the addition of some 'toggles' we can better idea of the different values. Currently, there is only the option to toggle for the questions.

==== Existing Design ====

[[File: old_toggle_sc.png|1200px]]

In this current mode, there is only the option to toggle for the questions.

==== Actual Changes ====

[[File: simon_new_menu_opened.png|650px]]

In the updated version, since more toggle options were added, there is now a heat map option menu, that can be opened and closed. When open, there are 4 different checkboxes to check from that each provide their own way of helping the student better analyze their team grade. When the checkbox are checked, it will add a column to the heat map for the corresponding criteria.

When menu is closed:

[[File: simon_new_menu_closed.png|300px]]

==== Supporting Code for Toggle Options ====

[[File: simon_supporting_code1.png|650px]]

Here is the supporting code for the 3 new toggle options, showToggle10WordComments, showToggle20WordComments, and showToggleCustomWordComment are all boolean values that if their state is set to true filter and count reviews based on the properties of their comments. When they're set to true, it will first ensure that the comments are defined as strings and not undefined (since a user can leave a review without providing a comment), it will then filter over the reviews array within a row and filter and return the total number of comments that meet the respective criteria.

''' Custom Feature Toggle '''

[[File: simon_custom_checkbox_clicked.png|500px]]

In the Heat Map Option panel, there is a custom checkbox, that when clicked, will allow the users to use the arrow to search within the comments to see how many are >= the input value.

==== Supporting Code ====

[[File: simon_supporting_code2.png|500px]]

In the panel, when the checkbox is clicked, it will update the state for showToggleCustomWordComment to be true, which will then render what can be seen in the previous screenshot. When using the input element, since you can use your keyboard to delete the value and type it in, when you delete the value, when it makes the onChange callback, the current empty string will be based to the inputValue set state giving it a NaN value, so if the onChange is an empty string it will set the value back to 0, which is what the confirmInputValue function is doing.

* ''' Updated Files '''

src/pages/ViewTeamGrades/ReviewTable.tsx
src/pages/ViewTeamGrades/ReviewTableRow.tsx

== Frontend (React & TypeScript) ==
=== Files to be potentially modified ===
All files to be modified are located in the src/pages/ViewTeamGrades folder. The files that will potentially be modified are:

* src/pages/ViewTeamGrades/App.tsx
* src/pages/ViewTeamGrades/ReviewTable.tsx

== Use Case Diagram ==

The use case diagram for the "view-team-grades" page after clicking "Grades View" in Expertiza highlights various interactions with the UI. Here's a general outline of possible actors and use cases:

=== Actors: ===

* Student - Primarily interacts with the UI to view all the grading details for an assignment.

=== Use Cases: ===

* View detailed grade of a particular assignment - Including assignment name, team name, average score, etc.
* Show Submission - This link redirects the student to a new page where the student can see his/her submission details.
* Show Stats - This link redirects the student to a new page where the student can see grading statistics.
* Submitted Work - This table shows the average and range of submitted work grades.
**Show Reviews - This link located in the "Submitted Work" table redirects the student to the page that renders all the reviews that the student obtained from his/her peers.
* Author Feedback - This table shows the average and range of author feedback for the submitted work.
**Show Author Feedback - This link located in the "Author Feedback" table redirects the student to the page that renders the author feedback that the student obtained after writing a review.
* Teammate Review - This table shows the average and range of teammate reviews for the submitted work.
* Back - Link that enables the student to go back to the main page
*

[[File: yusufov_d2.png |750px|center]]

==Test Plan==
To validate the newly designed "View Submissions" page's functionality, usability, and performance while meeting the goals of clarity, consistency, flexibility, and intuitivenes.

=== Testing Scope ===
1. Component Validation
* Test individual React components like ReviewTable.tsx and Statistics.tsx.
2. API Integration
* Verify API calls using useAPI.ts to ensure seamless backend integration.
3. Dynamic Features
* Test real-time updates (e.g., "Last Updated" timestamps).

=== Test Cases: ===

{| class="wikitable"
! Test Case ID
! Test Description
! Expected Outcome
! Priority
! Status
|-
| TC001
| Verify assignment name display
| Assignment names appear accurately.
| High
| Pending
|-
| TC002
| Validate "Show Stats" link
| Redirects to accurate grading statistics page.
| Medium
| Pending
|-
| TC003
| Test pagination in tables
| Pagination works correctly for large datasets.
| High
| Pending
|-
| TC004
| Test table export functionality
| CSV and Excel files match table content accurately.
| High
| Pending
|-
| TC005
| Validate data rendering
| Tables display data using mock files like `dummyData.json`.
| High
| Pending
|-
| TC006
| Test error handling for missing data
| UI displays appropriate placeholders or messages for empty datasets.
| Low
| Pending
|-
| TC007
| Verify contributor details
| Names and user IDs are displayed accurately.
| Medium
| Pending
|-
| TC008
| Validate new thresholds for review length
| Dynamic thresholds for word/character counts update and display correctly.
| Medium
| Pending
|}

=== Testing Strategy ===

Unit Testing:
*Write tests for individual components like ReviewTable using Jest.
*Validate utility functions in utils.ts.

Integration Testing:
* Test the interaction between App.tsx and its child components.
* Validate API responses using axios_client.ts.

Performance Testing:
* Simulate exporting large datasets to assess system performance.
* Measure response times for table rendering with dummyData.json.

Accessibility Testing:
*Test keyboard navigation and WCAG 2.1 compliance.

== Actual Testing ==

=== Unit Testing for ReviewTable using Jest ===

*The ReviewTable component is validated using the Jest and React Testing Libraries. Running tests on the ReviewTable component allowed us to determine whether the component rendered without crashing by utilizing the render function provided by the React Testing Library. The ReviewTable component was wrapped inside a Router component imported from react-router-dom, to establish the necessary routing context for components that rely on React Router. This configuration allows the test to simulate the environment in which the component operates accurately. Overall, the test file serves as a quality assurance measure, verifying that the ReviewTable component can render successfully and integrate correctly with the React Router.

====[https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/ReviewTable.test.tsx ReviewTable.test.tsx]====
<pre>
import React from 'react';
import { render} from '@testing-library/react';
import { BrowserRouter as Router } from 'react-router-dom';
import ReviewTable from './ReviewTable';

describe('ReviewTable component', () => {
test('renders without crashing', () => {
render(
<Router> {/* Wrap your component with Router */}
<ReviewTable />
</Router>
);
});

});</pre>

''' Example of another test case '''

This test ensures that the 'Open HeatMap Options' text changes when clicked and is expected to be on the screen again when closed.

<pre>
describe('ReviewTable Toggle Menu', () => {
test('toggle menu name changes when clicked', () => {
render(
<Router>
<ReviewTable />
</Router>
)
const menuTitleOpen = screen.getByText('▼ Open Heatmap Options ▼');
// when rendered it should ask to open
expect(menuTitleOpen).toBeInTheDocument()

fireEvent.click(menuTitleOpen)

const menuTitleClose = screen.getByText('▲ Close Heatmap Options ▲');
// state will change to true, so title should ask to be closed now
expect(menuTitleClose).toBeInTheDocument()

// closing menu should make it go back to to open
fireEvent.click(menuTitleClose)
expect(menuTitleOpen).toBeInTheDocument()

})
</pre>

==== Testing results ====
[[File: loyda_review_testing_results.png]]

=== Unit Testing for Statistics Component using Jest ===

*The Statistics component is validated using the Jest and React Testing Libraries. It employs the Jest and React Testing Library for testing purposes, along with the jest-dom library for custom assertions. The first test "renders the correct labels" ensures that the statistics table renders the correct labels. The second test "renders correct statistical information for each label" ensures that the statistical information is rendered correctly under each label. Lastly, their test "renders correct links" ensures that all the necessary links are rendered. Overall, these tests comprehensively evaluate the rendering and functionality of the Statistics component.

====[https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/Statistics.test.tsx Statistics.test.tsx]====
<pre>
import React from 'react';
import { render, screen } from '@testing-library/react';
import '@testing-library/jest-dom/extend-expect'; // Import jest-dom for custom assertions
import Statistics from './Statistics'; // Import the component to test

describe('Statistics', () => {
test('renders the correct labels', () => {
render(<Statistics average={''} />);
// Find the scores within the underlined spans
const element_1 = screen.getByRole('columnheader', { name: 'Submitted Work' });
const element_2 = screen.getByRole('columnheader', { name: 'Author Feedback' });
const element_3 = screen.getByRole('columnheader', { name: 'Teammate Review' });
const element_4 = screen.getByRole('columnheader', { name: 'Contributor' });

const element_5 = screen.getAllByText(/Average/i);
const element_6 = screen.getAllByText(/Range/i);
const element_7 = screen.getByRole('columnheader', { name: 'Final Score' });

// Assert that the elements are present
expect(element_1).toBeInTheDocument();
expect(element_2).toBeInTheDocument();
expect(element_3).toBeInTheDocument();
expect(element_4).toBeInTheDocument();
expect(element_5[0]).toBeInTheDocument();
expect(element_6[0]).toBeInTheDocument();
expect(element_7).toBeInTheDocument();

});

test('renders correct statistical information for each label', () => {
render(<Statistics average={''} />);
// Find the scores within the underlined spans
const element_1 = screen.getByRole('cell', { name: 'ssshah26 (Siddharth Shah)' });
const element_2 = screen.getByRole('cell', { name: 'Show Reviews (20)' });
const element_3 = screen.getByRole('cell', { name: '99.99% - 100%' });
const element_4 = screen.getByRole('cell', { name: '96.67 Show Author Feedback (10)' });
const element_5 = screen.getByRole('cell', { name: '87% - 100%' });
const element_6 = screen.getByRole('cell', { name: '4.64' });
const element_7 = screen.getByRole('cell', { name: '90% - 100%' });
const element_8 = screen.getByRole('cell', { name: '75% (in Finished)' });

// Assert that the elements are present
expect(element_1).toBeInTheDocument();
expect(element_2).toBeInTheDocument();
expect(element_3).toBeInTheDocument();
expect(element_4).toBeInTheDocument();
expect(element_5).toBeInTheDocument();
expect(element_6).toBeInTheDocument();
expect(element_7).toBeInTheDocument();
expect(element_8).toBeInTheDocument();
});

test('renders correct links', () => {
render(<Statistics average={''} />);
// Find the scores within the underlined spans
const element_1 = screen.getByRole('link', { name: 'show stats' });
const element_2 = screen.getByRole('link', { name: 'ssshah26' });
const element_3 = screen.getByRole('link', { name: 'Show Reviews' });
const element_4 = screen.getByRole('link', { name: 'Show Author Feedback' });

// Assert that the elements are present
expect(element_1).toBeInTheDocument();
expect(element_2).toBeInTheDocument();
expect(element_3).toBeInTheDocument();
expect(element_4).toBeInTheDocument();

});
});</pre>

==== Testing results ====

[[File: loyda_statistics_testing_results.png]]

== User Stories ==

* As a student I want to check all grading details of an assignment so that I can know my grade.
* As a student I want to see my submission of an assignment so that I can check what was submitted for a given assignment.
* As a student I want to see the names of my group team members so that I can know who I worked with.
* As a student I want to see the statistics of my grades so that I know my grade distribution.
* As a student I want to see if I got any late penalties so that I can know whether I got deducted points or not.
* As a student I want to have a way to view all the reviews that I got for the assignment so that I can read the viewer's responses.

== Conclusion ==
This design document introduces a step-by-step plan for updating the "view-team-grades" page on Expertiza, aiming for a user interface that is visually appealing and simple. Using React and TypeScript, the goal is to deliver a more user-friendly solution that enhances the functionality and manageability of grade information for a particular project within the Expertiza system. A clear and flexible UI design makes it not only simple to maintain but also flexible enough for future upgrades.

== List of Project Links ==
GitHub Repository: https://github.com/simong2/reimplementation-front-end

== Project Mentor ==

'''Nainisha Bhallamudi''' (nbhalla@ncsu.edu)

== Team Members ==

* '''Simon Getahun''' (unityid: sgetahu, github: https://github.com/simong2)
* '''Anusha Akkireddy''' (unityid: aakkire, github:https://github.com/akkireddyanusha)
* '''Loyda Yusufova''' (unityid: leyusufo, github: https://github.com/leyusufo)

CSC/ECE 517 Fall 2024 - E2492. UI for View submissions/assign grades (except heatgrid)

2024-12-04T08:51:14Z

Sgetahu: /* ReviewTable.test.tsx */

== Introduction ==
=== Project Overview ===

The "View Submissions" project focuses on developing a user interface (UI)
to maintain the score of reviewer submissions.

The Peer Review Summary Page UI is designed to display essential information for each review
assignment in a streamlined and user-friendly format. It provides a clear overview of contributors
and assigned reviewers, with interactive options such as "Unsubmit" and "Delete" to manage
submissions easily. Meta-reviewer options are intentionally excluded to keep the interface
focused solely on core reviewer functionalities. Additional sections are included to display
missing reviews, add grades and comments, and create an efficient and straightforward
interface for managing peer reviews.

== Design Goals ==
The Peer Review Summary Page in this project is designed to display essential information for each review assignment in a streamlined and user-friendly format. The main objectives focus on consistency and clearness, minimalism, flexibility, and intuitivism:

* '''Consistency and clearness: '''The Peer Review Summary Page UI interface should be consistent and clear.

* ''' Minimalism: '''The Peer Review Summary Page UI interface is very cluttered and there is so much going on in the page which makes it hard for a student to navigate through the information that is being displayed. We aim to avoid cluttering the interface with too much information.

* ''' Flexibility: '''The Peer Review Summary Page UI interface should be flexible and avoid clutter. We aim to deliver flexibility by rearranging information around the page to make it more presentable and easy to read.

* '''Intuitivism: '''The Peer Review Summary Page UI interface should be easy to use and understand. At the moment, the UI shows a few confusing and hard-to-understand areas/blocks (such as the "Submitted Work" table). We aim to make these areas less confusing by changing the way these blocks are being displayed.

These objectives ensure that students can efficiently see their grade details for a particular project, such as project title, team name, average peer review score, and peer review scores for each received review, and perform essential actions like show submission, show reviews, show author feedback, and show stats.

Through these design goals, we aim to deliver a more user-friendly solution that enhances the functionality and manageability of grade information for a particular project within the Expertiza system. The project leverages ReactJS and TypeScript to achieve these objectives, ensuring a modern, consistent, and flexible interface.

== Current UI Layout ==
The image below refers to the current UI layout. As shown in the image, the UI looks very cluttered and it is hard to find information in it. It has so many links and descriptions scattered around the page without any order. This makes it hard for a student to find information quickly.

[[File: loyda_layout1.png|900px]]

With the objectives that were mentioned in the previous section and the possible changes that are discussed next, we hope to alleviate the clutter and make the UI more visually appealing.

== Detail Description of Possible and Actual Changes ==

=== 1. Intuitive Display of statistics table: "Submitted Work", "Author Feedback", and "Teammate Review" ===
==== Rationale ====

The statistics table that encompasses the "Submitted Work", "Author Feedback", and "Teammate Review" tables lack contrast which makes them hard to understand and hard to read. Below is a snapshot of their locations in the current UI:

==== Existing Design ====

[[File: loyda_1.png|1200px]]

Notice how hard it is to visualize the tables and how hard it is to follow the information that they are providing. Our goal is to make these tables more visually appealing by introducing 2 possible changes. The changes are highlighted below.

==== Possible Changes ====

* ''' 1. Introduce shading '''
One of the possible approaches to fixing this issue is to Introduce color by filling each table with a different color.

[[File: loyda_2b.png|1200px]]

* ''' 2. Introducing outside borders: '''
Another possible solution to this issue is to add an outside border to each table to make it easier to read and understand. After adding table borders, the tables are expected to be displayed as follows:

[[File: loyda_2a.png|1200px]]

==== Actual Changes ====
The two proposed changes highlighted above were combined to create a new statistics table. Each of the 2 proposed changes introduces good mechanisms for achieving clarity and delivering a visually appealing statistics table to the user. Below is a snapshot of the new statistics table. Notice how easy it is to read and follow the details in the table as opposed to the original table.

[[File: loyda_2c.png|1200px]]

* ''' Updated Files '''

src/pages/ViewTeamGrades/Statistics.tsx [https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/Statisticstsx Statistics.tsx]

=== 2. Change the Location and Format of Team Member List ===
==== Rationale ====
The team member list is a type of information that should be readily available to the user. Instead, it is placed almost at the bottom of the page. Also, the font size is really small which makes it difficult to locate and read.

Furthermore, the "RoundSelector.tsx" file contains a function and its main purpose is to select the review round. However, its function is also to display the team member list. This violates the single responsibility principle. To fix this issue and allow the "RoundSelector" function to perform one function only, which in this case is to select the review round, it would be wise to move the code to gather and display the team information elsewhere — most likely inside the ReviewTable.tsx file.

==== Existing Design ====

Below is a screenshot of where the team member list is located in the UI. The team member list is outlined in red for visibility:

[[File: loyda_3a.png|1200px]]

Notice how small the font size is. Also, the team list should be located at the beginning of the page because it is part of the basic information that should be rendered first.

The current code to gather and display the team member list is located inside the "RoundSelector.tsx" file

[[File: loyda_3b.png|450px]]

Our goal is to change the location of the code snippets that are outlined in red to another location. This change will allow the RoundSelector function to only focus on selecting the review "Rounds"

==== Possible Changes ====

* ''' 1. Place the team list at the top of the page '''
The possible location of the team list will be in between the "Team" and "Average peer review score" information. The text format will also be changed. A larger text size will be introduced. These changes will allow the user to locate the list of the names of his/her team.

* ''' 2. Change the location of the code that gathers and displays the team list elsewhere '''
Changing the location of the code from the "RoundSelector.tsx" file to the "ReviewTable.tsx" file would allow us to fix the violation of the single responsibility principle in "RoundSelector.tsx".

==== Actual Changes ====
Below is a screenshot of the new location of the team member list outlined in red for visibility. Notice that the team member list is easy to locate as well as easy to read.

[[File: loyda_3c.png|1200px]]

Also, we changed the code to gather and display the team member list in the "ReviewTable.tsx" file. The new code snippets added are outlined in red for visibility

[[File: loyda_3d.png]]

The new "RoundSelector.tsx" contains the function that is ONLY focussed on selecting the review "Round" and thus obeys the single responsibility principle. A snapshot of the new function is provided below:

[[File: loyda_3e.png]]

* ''' Updated Files '''

src/pages/ViewTeamGrades/RoundSelector.tsx [https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/RoundSelelctor.tsx RoundSelector.tsx]
src/pages/ViewTeamGrades/ReviewTable.tsx [https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/ReviewTable.tsx ReviewTable.tsx]

=== 3.Export Options for Tables ===

'''Current Limitation:'''
Users cannot save or analyze table data outside the user interface. This makes it difficult to share or process data for further analysis.

'''Proposed Solution:'''
Add export buttons below each table to allow users to download the data as CSV, Excel, or PDF files. This will increase the flexibility and utility of the tables.

'''Implementation Details:'''
‎<br> 1. Export buttons for CSV and Excel are located below the table. ‎<br>
‎<br> 2. Utilizes the SheetJS (xlsx) library to generate exportable files. ‎<br>
‎<br> 3. File structure matches the table's visible data. ‎<br>

'''Supporting Code:'''
const exportTableData = (format: "csv" | "xlsx") => {
const tableData = initialData.map((row) => {
const rowData: Record<string, any> = {};
columns.forEach((col) => {
const accessor = col.id; // Use column `id` for keys
if (accessor) {
rowData[accessor] = row[accessor];
}
});
return rowData;
});

const worksheet = XLSX.utils.json_to_sheet(tableData);
const workbook = XLSX.utils.book_new();
XLSX.utils.book_append_sheet(workbook, worksheet, "TableData");

const fileType = format === "csv" ? "csv" : "xlsx";
XLSX.writeFile(workbook, `table_data.${fileType}`);
};

'''Export Buttons in the UI:'''
<div style={{ marginTop: "10px" }}>
<button
onClick={() => exportTableData("csv")}
className="btn btn-primary me-2"
>
Export to CSV
</button>
<button
onClick={() => exportTableData("xlsx")}
className="btn btn-primary"
>
Export to Excel
</button>
</div>

'''Testing:'''
it("renders export buttons", () => {
render(<Table data={mockData} columns={mockColumns} />);
expect(screen.getByText("Export to CSV")).toBeInTheDocument();
expect(screen.getByText("Export to Excel")).toBeInTheDocument();
});

=== 4.Improved Feedback Indicators ===

'''Current Limitation:'''
Users have no indication of when table data was last updated, leading to potential uncertainty about its accuracy.

'''Proposed Solution:'''
Add "Last Updated" timestamps or live refresh indicators for each table.

'''Implementation Details:'''
‎<br> 1. Include a "Last Updated: [Date/Time]" label below the table. ‎<br>
‎<br> 2. Update the timestamp dynamically whenever the data source is refreshed. ‎<br>
‎<br> 3. Use a subtle spinning loader icon to indicate data refreshing. ‎<br>

'''Supporting Code:'''
const [lastUpdated, setLastUpdated] = useState<Date | null>(null);

const refreshTableData = () => {
setLastUpdated(new Date());
};

=== 5.Extending toggle options ===

==== Rationale ====
While the heat map provides a great visual representation of the users feedback, with the addition of some 'toggles' we can better idea of the different values. Currently, there is only the option to toggle for the questions.

==== Existing Design ====

[[File: old_toggle_sc.png|1200px]]

In this current mode, there is only the option to toggle for the questions.

==== Actual Changes ====

[[File: simon_new_menu_opened.png|650px]]

In the updated version, since more toggle options were added, there is now a heat map option menu, that can be opened and closed. When open, there are 4 different checkboxes to check from that each provide their own way of helping the student better analyze their team grade. When the checkbox are checked, it will add a column to the heat map for the corresponding criteria.

When menu is closed:

[[File: simon_new_menu_closed.png|300px]]

==== Supporting Code for Toggle Options ====

[[File: simon_supporting_code1.png|650px]]

Here is the supporting code for the 3 new toggle options, showToggle10WordComments, showToggle20WordComments, and showToggleCustomWordComment are all boolean values that if their state is set to true filter and count reviews based on the properties of their comments. When they're set to true, it will first ensure that the comments are defined as strings and not undefined (since a user can leave a review without providing a comment), it will then filter over the reviews array within a row and filter and return the total number of comments that meet the respective criteria.

''' Custom Feature Toggle '''

[[File: simon_custom_checkbox_clicked.png|500px]]

In the Heat Map Option panel, there is a custom checkbox, that when clicked, will allow the users to use the arrow to search within the comments to see how many are >= the input value.

==== Supporting Code ====

[[File: simon_supporting_code2.png|500px]]

In the panel, when the checkbox is clicked, it will update the state for showToggleCustomWordComment to be true, which will then render what can be seen in the previous screenshot. When using the input element, since you can use your keyboard to delete the value and type it in, when you delete the value, when it makes the onChange callback, the current empty string will be based to the inputValue set state giving it a NaN value, so if the onChange is an empty string it will set the value back to 0, which is what the confirmInputValue function is doing.

* ''' Updated Files '''

src/pages/ViewTeamGrades/ReviewTable.tsx
src/pages/ViewTeamGrades/ReviewTableRow.tsx

== Frontend (React & TypeScript) ==
=== Files to be potentially modified ===
All files to be modified are located in the src/pages/ViewTeamGrades folder. The files that will potentially be modified are:

* src/pages/ViewTeamGrades/App.tsx
* src/pages/ViewTeamGrades/ReviewTable.tsx

== Use Case Diagram ==

The use case diagram for the "view-team-grades" page after clicking "Grades View" in Expertiza highlights various interactions with the UI. Here's a general outline of possible actors and use cases:

=== Actors: ===

* Student - Primarily interacts with the UI to view all the grading details for an assignment.

=== Use Cases: ===

* View detailed grade of a particular assignment - Including assignment name, team name, average score, etc.
* Show Submission - This link redirects the student to a new page where the student can see his/her submission details.
* Show Stats - This link redirects the student to a new page where the student can see grading statistics.
* Submitted Work - This table shows the average and range of submitted work grades.
**Show Reviews - This link located in the "Submitted Work" table redirects the student to the page that renders all the reviews that the student obtained from his/her peers.
* Author Feedback - This table shows the average and range of author feedback for the submitted work.
**Show Author Feedback - This link located in the "Author Feedback" table redirects the student to the page that renders the author feedback that the student obtained after writing a review.
* Teammate Review - This table shows the average and range of teammate reviews for the submitted work.
* Back - Link that enables the student to go back to the main page
*

[[File: yusufov_d2.png |750px|center]]

==Test Plan==
To validate the newly designed "View Submissions" page's functionality, usability, and performance while meeting the goals of clarity, consistency, flexibility, and intuitivenes.

=== Testing Scope ===
1. Component Validation
* Test individual React components like ReviewTable.tsx and Statistics.tsx.
2. API Integration
* Verify API calls using useAPI.ts to ensure seamless backend integration.
3. Dynamic Features
* Test real-time updates (e.g., "Last Updated" timestamps).

=== Test Cases: ===

{| class="wikitable"
! Test Case ID
! Test Description
! Expected Outcome
! Priority
! Status
|-
| TC001
| Verify assignment name display
| Assignment names appear accurately.
| High
| Pending
|-
| TC002
| Validate "Show Stats" link
| Redirects to accurate grading statistics page.
| Medium
| Pending
|-
| TC003
| Test pagination in tables
| Pagination works correctly for large datasets.
| High
| Pending
|-
| TC004
| Test table export functionality
| CSV and Excel files match table content accurately.
| High
| Pending
|-
| TC005
| Validate data rendering
| Tables display data using mock files like `dummyData.json`.
| High
| Pending
|-
| TC006
| Test error handling for missing data
| UI displays appropriate placeholders or messages for empty datasets.
| Low
| Pending
|-
| TC007
| Verify contributor details
| Names and user IDs are displayed accurately.
| Medium
| Pending
|-
| TC008
| Validate new thresholds for review length
| Dynamic thresholds for word/character counts update and display correctly.
| Medium
| Pending
|}

=== Testing Strategy ===

Unit Testing:
*Write tests for individual components like ReviewTable using Jest.
*Validate utility functions in utils.ts.

Integration Testing:
* Test the interaction between App.tsx and its child components.
* Validate API responses using axios_client.ts.

Performance Testing:
* Simulate exporting large datasets to assess system performance.
* Measure response times for table rendering with dummyData.json.

Accessibility Testing:
*Test keyboard navigation and WCAG 2.1 compliance.

== Actual Testing ==

=== Unit Testing for ReviewTable using Jest ===

*The ReviewTable component is validated using the Jest and React Testing Libraries. Running tests on the ReviewTable component allowed us to determine whether the component rendered without crashing by utilizing the render function provided by the React Testing Library. The ReviewTable component was wrapped inside a Router component imported from react-router-dom, to establish the necessary routing context for components that rely on React Router. This configuration allows the test to simulate the environment in which the component operates accurately. Overall, the test file serves as a quality assurance measure, verifying that the ReviewTable component can render successfully and integrate correctly with the React Router.

====[https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/ReviewTable.test.tsx ReviewTable.test.tsx]====
<pre>
import React from 'react';
import { render} from '@testing-library/react';
import { BrowserRouter as Router } from 'react-router-dom';
import ReviewTable from './ReviewTable';

describe('ReviewTable component', () => {
test('renders without crashing', () => {
render(
<Router> {/* Wrap your component with Router */}
<ReviewTable />
</Router>
);
});

});</pre>

''' Example of another test case '''

<pre>
describe('ReviewTable Toggle Menu', () => {
test('toggle menu name changes when clicked', () => {
render(
<Router>
<ReviewTable />
</Router>
)
const menuTitleOpen = screen.getByText('▼ Open Heatmap Options ▼');
// when rendered it should ask to open
expect(menuTitleOpen).toBeInTheDocument()

fireEvent.click(menuTitleOpen)

const menuTitleClose = screen.getByText('▲ Close Heatmap Options ▲');
// state will change to true, so title should ask to be closed now
expect(menuTitleClose).toBeInTheDocument()

// closing menu should make it go back to to open
fireEvent.click(menuTitleClose)
expect(menuTitleOpen).toBeInTheDocument()

})
</pre>

==== Testing results ====
[[File: loyda_review_testing_results.png]]

=== Unit Testing for Statistics Component using Jest ===

*The Statistics component is validated using the Jest and React Testing Libraries. It employs the Jest and React Testing Library for testing purposes, along with the jest-dom library for custom assertions. The first test "renders the correct labels" ensures that the statistics table renders the correct labels. The second test "renders correct statistical information for each label" ensures that the statistical information is rendered correctly under each label. Lastly, their test "renders correct links" ensures that all the necessary links are rendered. Overall, these tests comprehensively evaluate the rendering and functionality of the Statistics component.

====[https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/Statistics.test.tsx Statistics.test.tsx]====
<pre>
import React from 'react';
import { render, screen } from '@testing-library/react';
import '@testing-library/jest-dom/extend-expect'; // Import jest-dom for custom assertions
import Statistics from './Statistics'; // Import the component to test

describe('Statistics', () => {
test('renders the correct labels', () => {
render(<Statistics average={''} />);
// Find the scores within the underlined spans
const element_1 = screen.getByRole('columnheader', { name: 'Submitted Work' });
const element_2 = screen.getByRole('columnheader', { name: 'Author Feedback' });
const element_3 = screen.getByRole('columnheader', { name: 'Teammate Review' });
const element_4 = screen.getByRole('columnheader', { name: 'Contributor' });

const element_5 = screen.getAllByText(/Average/i);
const element_6 = screen.getAllByText(/Range/i);
const element_7 = screen.getByRole('columnheader', { name: 'Final Score' });

// Assert that the elements are present
expect(element_1).toBeInTheDocument();
expect(element_2).toBeInTheDocument();
expect(element_3).toBeInTheDocument();
expect(element_4).toBeInTheDocument();
expect(element_5[0]).toBeInTheDocument();
expect(element_6[0]).toBeInTheDocument();
expect(element_7).toBeInTheDocument();

});

test('renders correct statistical information for each label', () => {
render(<Statistics average={''} />);
// Find the scores within the underlined spans
const element_1 = screen.getByRole('cell', { name: 'ssshah26 (Siddharth Shah)' });
const element_2 = screen.getByRole('cell', { name: 'Show Reviews (20)' });
const element_3 = screen.getByRole('cell', { name: '99.99% - 100%' });
const element_4 = screen.getByRole('cell', { name: '96.67 Show Author Feedback (10)' });
const element_5 = screen.getByRole('cell', { name: '87% - 100%' });
const element_6 = screen.getByRole('cell', { name: '4.64' });
const element_7 = screen.getByRole('cell', { name: '90% - 100%' });
const element_8 = screen.getByRole('cell', { name: '75% (in Finished)' });

// Assert that the elements are present
expect(element_1).toBeInTheDocument();
expect(element_2).toBeInTheDocument();
expect(element_3).toBeInTheDocument();
expect(element_4).toBeInTheDocument();
expect(element_5).toBeInTheDocument();
expect(element_6).toBeInTheDocument();
expect(element_7).toBeInTheDocument();
expect(element_8).toBeInTheDocument();
});

test('renders correct links', () => {
render(<Statistics average={''} />);
// Find the scores within the underlined spans
const element_1 = screen.getByRole('link', { name: 'show stats' });
const element_2 = screen.getByRole('link', { name: 'ssshah26' });
const element_3 = screen.getByRole('link', { name: 'Show Reviews' });
const element_4 = screen.getByRole('link', { name: 'Show Author Feedback' });

// Assert that the elements are present
expect(element_1).toBeInTheDocument();
expect(element_2).toBeInTheDocument();
expect(element_3).toBeInTheDocument();
expect(element_4).toBeInTheDocument();

});
});</pre>

==== Testing results ====

[[File: loyda_statistics_testing_results.png]]

== User Stories ==

* As a student I want to check all grading details of an assignment so that I can know my grade.
* As a student I want to see my submission of an assignment so that I can check what was submitted for a given assignment.
* As a student I want to see the names of my group team members so that I can know who I worked with.
* As a student I want to see the statistics of my grades so that I know my grade distribution.
* As a student I want to see if I got any late penalties so that I can know whether I got deducted points or not.
* As a student I want to have a way to view all the reviews that I got for the assignment so that I can read the viewer's responses.

== Conclusion ==
This design document introduces a step-by-step plan for updating the "view-team-grades" page on Expertiza, aiming for a user interface that is visually appealing and simple. Using React and TypeScript, the goal is to deliver a more user-friendly solution that enhances the functionality and manageability of grade information for a particular project within the Expertiza system. A clear and flexible UI design makes it not only simple to maintain but also flexible enough for future upgrades.

== List of Project Links ==
GitHub Repository: https://github.com/simong2/reimplementation-front-end

== Project Mentor ==

'''Nainisha Bhallamudi''' (nbhalla@ncsu.edu)

== Team Members ==

* '''Simon Getahun''' (unityid: sgetahu, github: https://github.com/simong2)
* '''Anusha Akkireddy''' (unityid: aakkire, github:https://github.com/akkireddyanusha)
* '''Loyda Yusufova''' (unityid: leyusufo, github: https://github.com/leyusufo)

CSC/ECE 517 Fall 2024 - E2492. UI for View submissions/assign grades (except heatgrid)

2024-12-04T08:46:22Z

Sgetahu: /* Detail Description of Possible and Actual Changes */

== Introduction ==
=== Project Overview ===

The "View Submissions" project focuses on developing a user interface (UI)
to maintain the score of reviewer submissions.

The Peer Review Summary Page UI is designed to display essential information for each review
assignment in a streamlined and user-friendly format. It provides a clear overview of contributors
and assigned reviewers, with interactive options such as "Unsubmit" and "Delete" to manage
submissions easily. Meta-reviewer options are intentionally excluded to keep the interface
focused solely on core reviewer functionalities. Additional sections are included to display
missing reviews, add grades and comments, and create an efficient and straightforward
interface for managing peer reviews.

== Design Goals ==
The Peer Review Summary Page in this project is designed to display essential information for each review assignment in a streamlined and user-friendly format. The main objectives focus on consistency and clearness, minimalism, flexibility, and intuitivism:

* '''Consistency and clearness: '''The Peer Review Summary Page UI interface should be consistent and clear.

* ''' Minimalism: '''The Peer Review Summary Page UI interface is very cluttered and there is so much going on in the page which makes it hard for a student to navigate through the information that is being displayed. We aim to avoid cluttering the interface with too much information.

* ''' Flexibility: '''The Peer Review Summary Page UI interface should be flexible and avoid clutter. We aim to deliver flexibility by rearranging information around the page to make it more presentable and easy to read.

* '''Intuitivism: '''The Peer Review Summary Page UI interface should be easy to use and understand. At the moment, the UI shows a few confusing and hard-to-understand areas/blocks (such as the "Submitted Work" table). We aim to make these areas less confusing by changing the way these blocks are being displayed.

These objectives ensure that students can efficiently see their grade details for a particular project, such as project title, team name, average peer review score, and peer review scores for each received review, and perform essential actions like show submission, show reviews, show author feedback, and show stats.

Through these design goals, we aim to deliver a more user-friendly solution that enhances the functionality and manageability of grade information for a particular project within the Expertiza system. The project leverages ReactJS and TypeScript to achieve these objectives, ensuring a modern, consistent, and flexible interface.

== Current UI Layout ==
The image below refers to the current UI layout. As shown in the image, the UI looks very cluttered and it is hard to find information in it. It has so many links and descriptions scattered around the page without any order. This makes it hard for a student to find information quickly.

[[File: loyda_layout1.png|900px]]

With the objectives that were mentioned in the previous section and the possible changes that are discussed next, we hope to alleviate the clutter and make the UI more visually appealing.

== Detail Description of Possible and Actual Changes ==

=== 1. Intuitive Display of statistics table: "Submitted Work", "Author Feedback", and "Teammate Review" ===
==== Rationale ====

The statistics table that encompasses the "Submitted Work", "Author Feedback", and "Teammate Review" tables lack contrast which makes them hard to understand and hard to read. Below is a snapshot of their locations in the current UI:

==== Existing Design ====

[[File: loyda_1.png|1200px]]

Notice how hard it is to visualize the tables and how hard it is to follow the information that they are providing. Our goal is to make these tables more visually appealing by introducing 2 possible changes. The changes are highlighted below.

==== Possible Changes ====

* ''' 1. Introduce shading '''
One of the possible approaches to fixing this issue is to Introduce color by filling each table with a different color.

[[File: loyda_2b.png|1200px]]

* ''' 2. Introducing outside borders: '''
Another possible solution to this issue is to add an outside border to each table to make it easier to read and understand. After adding table borders, the tables are expected to be displayed as follows:

[[File: loyda_2a.png|1200px]]

==== Actual Changes ====
The two proposed changes highlighted above were combined to create a new statistics table. Each of the 2 proposed changes introduces good mechanisms for achieving clarity and delivering a visually appealing statistics table to the user. Below is a snapshot of the new statistics table. Notice how easy it is to read and follow the details in the table as opposed to the original table.

[[File: loyda_2c.png|1200px]]

* ''' Updated Files '''

src/pages/ViewTeamGrades/Statistics.tsx [https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/Statisticstsx Statistics.tsx]

=== 2. Change the Location and Format of Team Member List ===
==== Rationale ====
The team member list is a type of information that should be readily available to the user. Instead, it is placed almost at the bottom of the page. Also, the font size is really small which makes it difficult to locate and read.

Furthermore, the "RoundSelector.tsx" file contains a function and its main purpose is to select the review round. However, its function is also to display the team member list. This violates the single responsibility principle. To fix this issue and allow the "RoundSelector" function to perform one function only, which in this case is to select the review round, it would be wise to move the code to gather and display the team information elsewhere — most likely inside the ReviewTable.tsx file.

==== Existing Design ====

Below is a screenshot of where the team member list is located in the UI. The team member list is outlined in red for visibility:

[[File: loyda_3a.png|1200px]]

Notice how small the font size is. Also, the team list should be located at the beginning of the page because it is part of the basic information that should be rendered first.

The current code to gather and display the team member list is located inside the "RoundSelector.tsx" file

[[File: loyda_3b.png|450px]]

Our goal is to change the location of the code snippets that are outlined in red to another location. This change will allow the RoundSelector function to only focus on selecting the review "Rounds"

==== Possible Changes ====

* ''' 1. Place the team list at the top of the page '''
The possible location of the team list will be in between the "Team" and "Average peer review score" information. The text format will also be changed. A larger text size will be introduced. These changes will allow the user to locate the list of the names of his/her team.

* ''' 2. Change the location of the code that gathers and displays the team list elsewhere '''
Changing the location of the code from the "RoundSelector.tsx" file to the "ReviewTable.tsx" file would allow us to fix the violation of the single responsibility principle in "RoundSelector.tsx".

==== Actual Changes ====
Below is a screenshot of the new location of the team member list outlined in red for visibility. Notice that the team member list is easy to locate as well as easy to read.

[[File: loyda_3c.png|1200px]]

Also, we changed the code to gather and display the team member list in the "ReviewTable.tsx" file. The new code snippets added are outlined in red for visibility

[[File: loyda_3d.png]]

The new "RoundSelector.tsx" contains the function that is ONLY focussed on selecting the review "Round" and thus obeys the single responsibility principle. A snapshot of the new function is provided below:

[[File: loyda_3e.png]]

* ''' Updated Files '''

src/pages/ViewTeamGrades/RoundSelector.tsx [https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/RoundSelelctor.tsx RoundSelector.tsx]
src/pages/ViewTeamGrades/ReviewTable.tsx [https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/ReviewTable.tsx ReviewTable.tsx]

=== 3.Export Options for Tables ===

'''Current Limitation:'''
Users cannot save or analyze table data outside the user interface. This makes it difficult to share or process data for further analysis.

'''Proposed Solution:'''
Add export buttons below each table to allow users to download the data as CSV, Excel, or PDF files. This will increase the flexibility and utility of the tables.

'''Implementation Details:'''
‎<br> 1. Export buttons for CSV and Excel are located below the table. ‎<br>
‎<br> 2. Utilizes the SheetJS (xlsx) library to generate exportable files. ‎<br>
‎<br> 3. File structure matches the table's visible data. ‎<br>

'''Supporting Code:'''
const exportTableData = (format: "csv" | "xlsx") => {
const tableData = initialData.map((row) => {
const rowData: Record<string, any> = {};
columns.forEach((col) => {
const accessor = col.id; // Use column `id` for keys
if (accessor) {
rowData[accessor] = row[accessor];
}
});
return rowData;
});

const worksheet = XLSX.utils.json_to_sheet(tableData);
const workbook = XLSX.utils.book_new();
XLSX.utils.book_append_sheet(workbook, worksheet, "TableData");

const fileType = format === "csv" ? "csv" : "xlsx";
XLSX.writeFile(workbook, `table_data.${fileType}`);
};

'''Export Buttons in the UI:'''
<div style={{ marginTop: "10px" }}>
<button
onClick={() => exportTableData("csv")}
className="btn btn-primary me-2"
>
Export to CSV
</button>
<button
onClick={() => exportTableData("xlsx")}
className="btn btn-primary"
>
Export to Excel
</button>
</div>

'''Testing:'''
it("renders export buttons", () => {
render(<Table data={mockData} columns={mockColumns} />);
expect(screen.getByText("Export to CSV")).toBeInTheDocument();
expect(screen.getByText("Export to Excel")).toBeInTheDocument();
});

=== 4.Improved Feedback Indicators ===

'''Current Limitation:'''
Users have no indication of when table data was last updated, leading to potential uncertainty about its accuracy.

'''Proposed Solution:'''
Add "Last Updated" timestamps or live refresh indicators for each table.

'''Implementation Details:'''
‎<br> 1. Include a "Last Updated: [Date/Time]" label below the table. ‎<br>
‎<br> 2. Update the timestamp dynamically whenever the data source is refreshed. ‎<br>
‎<br> 3. Use a subtle spinning loader icon to indicate data refreshing. ‎<br>

'''Supporting Code:'''
const [lastUpdated, setLastUpdated] = useState<Date | null>(null);

const refreshTableData = () => {
setLastUpdated(new Date());
};

=== 5.Extending toggle options ===

==== Rationale ====
While the heat map provides a great visual representation of the users feedback, with the addition of some 'toggles' we can better idea of the different values. Currently, there is only the option to toggle for the questions.

==== Existing Design ====

[[File: old_toggle_sc.png|1200px]]

In this current mode, there is only the option to toggle for the questions.

==== Actual Changes ====

[[File: simon_new_menu_opened.png|650px]]

In the updated version, since more toggle options were added, there is now a heat map option menu, that can be opened and closed. When open, there are 4 different checkboxes to check from that each provide their own way of helping the student better analyze their team grade. When the checkbox are checked, it will add a column to the heat map for the corresponding criteria.

When menu is closed:

[[File: simon_new_menu_closed.png|300px]]

==== Supporting Code for Toggle Options ====

[[File: simon_supporting_code1.png|650px]]

Here is the supporting code for the 3 new toggle options, showToggle10WordComments, showToggle20WordComments, and showToggleCustomWordComment are all boolean values that if their state is set to true filter and count reviews based on the properties of their comments. When they're set to true, it will first ensure that the comments are defined as strings and not undefined (since a user can leave a review without providing a comment), it will then filter over the reviews array within a row and filter and return the total number of comments that meet the respective criteria.

''' Custom Feature Toggle '''

[[File: simon_custom_checkbox_clicked.png|500px]]

In the Heat Map Option panel, there is a custom checkbox, that when clicked, will allow the users to use the arrow to search within the comments to see how many are >= the input value.

==== Supporting Code ====

[[File: simon_supporting_code2.png|500px]]

In the panel, when the checkbox is clicked, it will update the state for showToggleCustomWordComment to be true, which will then render what can be seen in the previous screenshot. When using the input element, since you can use your keyboard to delete the value and type it in, when you delete the value, when it makes the onChange callback, the current empty string will be based to the inputValue set state giving it a NaN value, so if the onChange is an empty string it will set the value back to 0, which is what the confirmInputValue function is doing.

* ''' Updated Files '''

src/pages/ViewTeamGrades/ReviewTable.tsx
src/pages/ViewTeamGrades/ReviewTableRow.tsx

== Frontend (React & TypeScript) ==
=== Files to be potentially modified ===
All files to be modified are located in the src/pages/ViewTeamGrades folder. The files that will potentially be modified are:

* src/pages/ViewTeamGrades/App.tsx
* src/pages/ViewTeamGrades/ReviewTable.tsx

== Use Case Diagram ==

The use case diagram for the "view-team-grades" page after clicking "Grades View" in Expertiza highlights various interactions with the UI. Here's a general outline of possible actors and use cases:

=== Actors: ===

* Student - Primarily interacts with the UI to view all the grading details for an assignment.

=== Use Cases: ===

* View detailed grade of a particular assignment - Including assignment name, team name, average score, etc.
* Show Submission - This link redirects the student to a new page where the student can see his/her submission details.
* Show Stats - This link redirects the student to a new page where the student can see grading statistics.
* Submitted Work - This table shows the average and range of submitted work grades.
**Show Reviews - This link located in the "Submitted Work" table redirects the student to the page that renders all the reviews that the student obtained from his/her peers.
* Author Feedback - This table shows the average and range of author feedback for the submitted work.
**Show Author Feedback - This link located in the "Author Feedback" table redirects the student to the page that renders the author feedback that the student obtained after writing a review.
* Teammate Review - This table shows the average and range of teammate reviews for the submitted work.
* Back - Link that enables the student to go back to the main page
*

[[File: yusufov_d2.png |750px|center]]

==Test Plan==
To validate the newly designed "View Submissions" page's functionality, usability, and performance while meeting the goals of clarity, consistency, flexibility, and intuitivenes.

=== Testing Scope ===
1. Component Validation
* Test individual React components like ReviewTable.tsx and Statistics.tsx.
2. API Integration
* Verify API calls using useAPI.ts to ensure seamless backend integration.
3. Dynamic Features
* Test real-time updates (e.g., "Last Updated" timestamps).

=== Test Cases: ===

{| class="wikitable"
! Test Case ID
! Test Description
! Expected Outcome
! Priority
! Status
|-
| TC001
| Verify assignment name display
| Assignment names appear accurately.
| High
| Pending
|-
| TC002
| Validate "Show Stats" link
| Redirects to accurate grading statistics page.
| Medium
| Pending
|-
| TC003
| Test pagination in tables
| Pagination works correctly for large datasets.
| High
| Pending
|-
| TC004
| Test table export functionality
| CSV and Excel files match table content accurately.
| High
| Pending
|-
| TC005
| Validate data rendering
| Tables display data using mock files like `dummyData.json`.
| High
| Pending
|-
| TC006
| Test error handling for missing data
| UI displays appropriate placeholders or messages for empty datasets.
| Low
| Pending
|-
| TC007
| Verify contributor details
| Names and user IDs are displayed accurately.
| Medium
| Pending
|-
| TC008
| Validate new thresholds for review length
| Dynamic thresholds for word/character counts update and display correctly.
| Medium
| Pending
|}

=== Testing Strategy ===

Unit Testing:
*Write tests for individual components like ReviewTable using Jest.
*Validate utility functions in utils.ts.

Integration Testing:
* Test the interaction between App.tsx and its child components.
* Validate API responses using axios_client.ts.

Performance Testing:
* Simulate exporting large datasets to assess system performance.
* Measure response times for table rendering with dummyData.json.

Accessibility Testing:
*Test keyboard navigation and WCAG 2.1 compliance.

== Actual Testing ==

=== Unit Testing for ReviewTable using Jest ===

*The ReviewTable component is validated using the Jest and React Testing Libraries. Running tests on the ReviewTable component allowed us to determine whether the component rendered without crashing by utilizing the render function provided by the React Testing Library. The ReviewTable component was wrapped inside a Router component imported from react-router-dom, to establish the necessary routing context for components that rely on React Router. This configuration allows the test to simulate the environment in which the component operates accurately. Overall, the test file serves as a quality assurance measure, verifying that the ReviewTable component can render successfully and integrate correctly with the React Router.

====[https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/ReviewTable.test.tsx ReviewTable.test.tsx]====
<pre>
import React from 'react';
import { render} from '@testing-library/react';
import { BrowserRouter as Router } from 'react-router-dom';
import ReviewTable from './ReviewTable';

describe('ReviewTable component', () => {
test('renders without crashing', () => {
render(
<Router> {/* Wrap your component with Router */}
<ReviewTable />
</Router>
);
});

});</pre>

==== Testing results ====
[[File: loyda_review_testing_results.png]]

=== Unit Testing for Statistics Component using Jest ===

*The Statistics component is validated using the Jest and React Testing Libraries. It employs the Jest and React Testing Library for testing purposes, along with the jest-dom library for custom assertions. The first test "renders the correct labels" ensures that the statistics table renders the correct labels. The second test "renders correct statistical information for each label" ensures that the statistical information is rendered correctly under each label. Lastly, their test "renders correct links" ensures that all the necessary links are rendered. Overall, these tests comprehensively evaluate the rendering and functionality of the Statistics component.

====[https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/Statistics.test.tsx Statistics.test.tsx]====
<pre>
import React from 'react';
import { render, screen } from '@testing-library/react';
import '@testing-library/jest-dom/extend-expect'; // Import jest-dom for custom assertions
import Statistics from './Statistics'; // Import the component to test

describe('Statistics', () => {
test('renders the correct labels', () => {
render(<Statistics average={''} />);
// Find the scores within the underlined spans
const element_1 = screen.getByRole('columnheader', { name: 'Submitted Work' });
const element_2 = screen.getByRole('columnheader', { name: 'Author Feedback' });
const element_3 = screen.getByRole('columnheader', { name: 'Teammate Review' });
const element_4 = screen.getByRole('columnheader', { name: 'Contributor' });

const element_5 = screen.getAllByText(/Average/i);
const element_6 = screen.getAllByText(/Range/i);
const element_7 = screen.getByRole('columnheader', { name: 'Final Score' });

// Assert that the elements are present
expect(element_1).toBeInTheDocument();
expect(element_2).toBeInTheDocument();
expect(element_3).toBeInTheDocument();
expect(element_4).toBeInTheDocument();
expect(element_5[0]).toBeInTheDocument();
expect(element_6[0]).toBeInTheDocument();
expect(element_7).toBeInTheDocument();

});

test('renders correct statistical information for each label', () => {
render(<Statistics average={''} />);
// Find the scores within the underlined spans
const element_1 = screen.getByRole('cell', { name: 'ssshah26 (Siddharth Shah)' });
const element_2 = screen.getByRole('cell', { name: 'Show Reviews (20)' });
const element_3 = screen.getByRole('cell', { name: '99.99% - 100%' });
const element_4 = screen.getByRole('cell', { name: '96.67 Show Author Feedback (10)' });
const element_5 = screen.getByRole('cell', { name: '87% - 100%' });
const element_6 = screen.getByRole('cell', { name: '4.64' });
const element_7 = screen.getByRole('cell', { name: '90% - 100%' });
const element_8 = screen.getByRole('cell', { name: '75% (in Finished)' });

// Assert that the elements are present
expect(element_1).toBeInTheDocument();
expect(element_2).toBeInTheDocument();
expect(element_3).toBeInTheDocument();
expect(element_4).toBeInTheDocument();
expect(element_5).toBeInTheDocument();
expect(element_6).toBeInTheDocument();
expect(element_7).toBeInTheDocument();
expect(element_8).toBeInTheDocument();
});

test('renders correct links', () => {
render(<Statistics average={''} />);
// Find the scores within the underlined spans
const element_1 = screen.getByRole('link', { name: 'show stats' });
const element_2 = screen.getByRole('link', { name: 'ssshah26' });
const element_3 = screen.getByRole('link', { name: 'Show Reviews' });
const element_4 = screen.getByRole('link', { name: 'Show Author Feedback' });

// Assert that the elements are present
expect(element_1).toBeInTheDocument();
expect(element_2).toBeInTheDocument();
expect(element_3).toBeInTheDocument();
expect(element_4).toBeInTheDocument();

});
});</pre>

==== Testing results ====

[[File: loyda_statistics_testing_results.png]]

== User Stories ==

* As a student I want to check all grading details of an assignment so that I can know my grade.
* As a student I want to see my submission of an assignment so that I can check what was submitted for a given assignment.
* As a student I want to see the names of my group team members so that I can know who I worked with.
* As a student I want to see the statistics of my grades so that I know my grade distribution.
* As a student I want to see if I got any late penalties so that I can know whether I got deducted points or not.
* As a student I want to have a way to view all the reviews that I got for the assignment so that I can read the viewer's responses.

== Conclusion ==
This design document introduces a step-by-step plan for updating the "view-team-grades" page on Expertiza, aiming for a user interface that is visually appealing and simple. Using React and TypeScript, the goal is to deliver a more user-friendly solution that enhances the functionality and manageability of grade information for a particular project within the Expertiza system. A clear and flexible UI design makes it not only simple to maintain but also flexible enough for future upgrades.

== List of Project Links ==
GitHub Repository: https://github.com/simong2/reimplementation-front-end

== Project Mentor ==

'''Nainisha Bhallamudi''' (nbhalla@ncsu.edu)

== Team Members ==

* '''Simon Getahun''' (unityid: sgetahu, github: https://github.com/simong2)
* '''Anusha Akkireddy''' (unityid: aakkire, github:https://github.com/akkireddyanusha)
* '''Loyda Yusufova''' (unityid: leyusufo, github: https://github.com/leyusufo)

CSC/ECE 517 Fall 2024 - E2492. UI for View submissions/assign grades (except heatgrid)

2024-12-04T08:45:27Z

Sgetahu: /* Actual Changes */

== Introduction ==
=== Project Overview ===

The "View Submissions" project focuses on developing a user interface (UI)
to maintain the score of reviewer submissions.

The Peer Review Summary Page UI is designed to display essential information for each review
assignment in a streamlined and user-friendly format. It provides a clear overview of contributors
and assigned reviewers, with interactive options such as "Unsubmit" and "Delete" to manage
submissions easily. Meta-reviewer options are intentionally excluded to keep the interface
focused solely on core reviewer functionalities. Additional sections are included to display
missing reviews, add grades and comments, and create an efficient and straightforward
interface for managing peer reviews.

== Design Goals ==
The Peer Review Summary Page in this project is designed to display essential information for each review assignment in a streamlined and user-friendly format. The main objectives focus on consistency and clearness, minimalism, flexibility, and intuitivism:

* '''Consistency and clearness: '''The Peer Review Summary Page UI interface should be consistent and clear.

* ''' Minimalism: '''The Peer Review Summary Page UI interface is very cluttered and there is so much going on in the page which makes it hard for a student to navigate through the information that is being displayed. We aim to avoid cluttering the interface with too much information.

* ''' Flexibility: '''The Peer Review Summary Page UI interface should be flexible and avoid clutter. We aim to deliver flexibility by rearranging information around the page to make it more presentable and easy to read.

* '''Intuitivism: '''The Peer Review Summary Page UI interface should be easy to use and understand. At the moment, the UI shows a few confusing and hard-to-understand areas/blocks (such as the "Submitted Work" table). We aim to make these areas less confusing by changing the way these blocks are being displayed.

These objectives ensure that students can efficiently see their grade details for a particular project, such as project title, team name, average peer review score, and peer review scores for each received review, and perform essential actions like show submission, show reviews, show author feedback, and show stats.

Through these design goals, we aim to deliver a more user-friendly solution that enhances the functionality and manageability of grade information for a particular project within the Expertiza system. The project leverages ReactJS and TypeScript to achieve these objectives, ensuring a modern, consistent, and flexible interface.

== Current UI Layout ==
The image below refers to the current UI layout. As shown in the image, the UI looks very cluttered and it is hard to find information in it. It has so many links and descriptions scattered around the page without any order. This makes it hard for a student to find information quickly.

[[File: loyda_layout1.png|900px]]

With the objectives that were mentioned in the previous section and the possible changes that are discussed next, we hope to alleviate the clutter and make the UI more visually appealing.

== Detail Description of Possible and Actual Changes ==

=== 1. Intuitive Display of statistics table: "Submitted Work", "Author Feedback", and "Teammate Review" ===
==== Rationale ====

The statistics table that encompasses the "Submitted Work", "Author Feedback", and "Teammate Review" tables lack contrast which makes them hard to understand and hard to read. Below is a snapshot of their locations in the current UI:

==== Existing Design ====

[[File: loyda_1.png|1200px]]

Notice how hard it is to visualize the tables and how hard it is to follow the information that they are providing. Our goal is to make these tables more visually appealing by introducing 2 possible changes. The changes are highlighted below.

==== Possible Changes ====

* ''' 1. Introduce shading '''
One of the possible approaches to fixing this issue is to Introduce color by filling each table with a different color.

[[File: loyda_2b.png|1200px]]

* ''' 2. Introducing outside borders: '''
Another possible solution to this issue is to add an outside border to each table to make it easier to read and understand. After adding table borders, the tables are expected to be displayed as follows:

[[File: loyda_2a.png|1200px]]

==== Actual Changes ====
The two proposed changes highlighted above were combined to create a new statistics table. Each of the 2 proposed changes introduces good mechanisms for achieving clarity and delivering a visually appealing statistics table to the user. Below is a snapshot of the new statistics table. Notice how easy it is to read and follow the details in the table as opposed to the original table.

[[File: loyda_2c.png|1200px]]

* ''' Updated Files '''

src/pages/ViewTeamGrades/Statistics.tsx [https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/Statisticstsx Statistics.tsx]

=== 2. Change the Location and Format of Team Member List ===
==== Rationale ====
The team member list is a type of information that should be readily available to the user. Instead, it is placed almost at the bottom of the page. Also, the font size is really small which makes it difficult to locate and read.

Furthermore, the "RoundSelector.tsx" file contains a function and its main purpose is to select the review round. However, its function is also to display the team member list. This violates the single responsibility principle. To fix this issue and allow the "RoundSelector" function to perform one function only, which in this case is to select the review round, it would be wise to move the code to gather and display the team information elsewhere — most likely inside the ReviewTable.tsx file.

==== Existing Design ====

Below is a screenshot of where the team member list is located in the UI. The team member list is outlined in red for visibility:

[[File: loyda_3a.png|1200px]]

Notice how small the font size is. Also, the team list should be located at the beginning of the page because it is part of the basic information that should be rendered first.

The current code to gather and display the team member list is located inside the "RoundSelector.tsx" file

[[File: loyda_3b.png|450px]]

Our goal is to change the location of the code snippets that are outlined in red to another location. This change will allow the RoundSelector function to only focus on selecting the review "Rounds"

==== Possible Changes ====

* ''' 1. Place the team list at the top of the page '''
The possible location of the team list will be in between the "Team" and "Average peer review score" information. The text format will also be changed. A larger text size will be introduced. These changes will allow the user to locate the list of the names of his/her team.

* ''' 2. Change the location of the code that gathers and displays the team list elsewhere '''
Changing the location of the code from the "RoundSelector.tsx" file to the "ReviewTable.tsx" file would allow us to fix the violation of the single responsibility principle in "RoundSelector.tsx".

==== Actual Changes ====
Below is a screenshot of the new location of the team member list outlined in red for visibility. Notice that the team member list is easy to locate as well as easy to read.

[[File: loyda_3c.png|1200px]]

Also, we changed the code to gather and display the team member list in the "ReviewTable.tsx" file. The new code snippets added are outlined in red for visibility

[[File: loyda_3d.png]]

The new "RoundSelector.tsx" contains the function that is ONLY focussed on selecting the review "Round" and thus obeys the single responsibility principle. A snapshot of the new function is provided below:

[[File: loyda_3e.png]]

* ''' Updated Files '''

src/pages/ViewTeamGrades/RoundSelector.tsx [https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/RoundSelelctor.tsx RoundSelector.tsx]
src/pages/ViewTeamGrades/ReviewTable.tsx [https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/ReviewTable.tsx ReviewTable.tsx]

=== 3.Export Options for Tables ===

'''Current Limitation:'''
Users cannot save or analyze table data outside the user interface. This makes it difficult to share or process data for further analysis.

'''Proposed Solution:'''
Add export buttons below each table to allow users to download the data as CSV, Excel, or PDF files. This will increase the flexibility and utility of the tables.

'''Implementation Details:'''
‎<br> 1. Export buttons for CSV and Excel are located below the table. ‎<br>
‎<br> 2. Utilizes the SheetJS (xlsx) library to generate exportable files. ‎<br>
‎<br> 3. File structure matches the table's visible data. ‎<br>

'''Supporting Code:'''
const exportTableData = (format: "csv" | "xlsx") => {
const tableData = initialData.map((row) => {
const rowData: Record<string, any> = {};
columns.forEach((col) => {
const accessor = col.id; // Use column `id` for keys
if (accessor) {
rowData[accessor] = row[accessor];
}
});
return rowData;
});

const worksheet = XLSX.utils.json_to_sheet(tableData);
const workbook = XLSX.utils.book_new();
XLSX.utils.book_append_sheet(workbook, worksheet, "TableData");

const fileType = format === "csv" ? "csv" : "xlsx";
XLSX.writeFile(workbook, `table_data.${fileType}`);
};

'''Export Buttons in the UI:'''
<div style={{ marginTop: "10px" }}>
<button
onClick={() => exportTableData("csv")}
className="btn btn-primary me-2"
>
Export to CSV
</button>
<button
onClick={() => exportTableData("xlsx")}
className="btn btn-primary"
>
Export to Excel
</button>
</div>

'''Testing:'''
it("renders export buttons", () => {
render(<Table data={mockData} columns={mockColumns} />);
expect(screen.getByText("Export to CSV")).toBeInTheDocument();
expect(screen.getByText("Export to Excel")).toBeInTheDocument();
});

=== 4.Improved Feedback Indicators ===

'''Current Limitation:'''
Users have no indication of when table data was last updated, leading to potential uncertainty about its accuracy.

'''Proposed Solution:'''
Add "Last Updated" timestamps or live refresh indicators for each table.

'''Implementation Details:'''
‎<br> 1. Include a "Last Updated: [Date/Time]" label below the table. ‎<br>
‎<br> 2. Update the timestamp dynamically whenever the data source is refreshed. ‎<br>
‎<br> 3. Use a subtle spinning loader icon to indicate data refreshing. ‎<br>

'''Supporting Code:'''
const [lastUpdated, setLastUpdated] = useState<Date | null>(null);

const refreshTableData = () => {
setLastUpdated(new Date());
};

=== 5.Extending toggle options ===

==== Rationale ====
While the heat map provides a great visual representation of the users feedback, with the addition of some 'toggles' we can better idea of the different values. Currently, there is only the option to toggle for the questions.

==== Existing Design ====

[[File: old_toggle_sc.png|1200px]]

In this current mode, there is only the option to toggle for the questions.

==== Actual Changes ====

[[File: simon_new_menu_opened.png|650px]]

In the updated version, since more toggle options were added, there is now a heat map option menu, that can be opened and closed. When open, there are 4 different checkboxes to check from that each provide their own way of helping the student better analyze their team grade. When the checkbox are checked, it will add a column to the heat map for the corresponding criteria.

When menu is closed:

[[File: simon_new_menu_closed.png|300px]]

==== Supporting Code for Toggle Options ====

[[File: simon_supporting_code1.png|650px]]

Here is the supporting code for the 3 new toggle options, showToggle10WordComments, showToggle20WordComments, and showToggleCustomWordComment are all boolean values that if their state is set to true filter and count reviews based on the properties of their comments. When they're set to true, it will first ensure that the comments are defined as strings and not undefined (since a user can leave a review without providing a comment), it will then filter over the reviews array within a row and filter and return the total number of comments that meet the respective criteria.

''' Custom Feature Toggle '''

[[File: simon_custom_checkbox_clicked.png|500px]]

In the Heat Map Option panel, there is a custom checkbox, that when clicked, will allow the users to use the arrow to search within the comments to see how many are >= the input value.

==== Supporting Code ====

[[File: simon_supporting_code2.png|500px]]

In the panel, when the checkbox is clicked, it will update the state for showToggleCustomWordComment to be true, which will then render what can be seen in the previous screenshot. When using the input element, since you can use your keyboard to delete the value and type it in, when you delete the value, when it makes the onChange callback, the current empty string will be based to the inputValue set state giving it a NaN value, so if the onChange is an empty string it will set the value back to 0, which is what the confirmInputValue function is doing.

* ''' Updated Files '''

src/pages/ViewTeamGrades/ReviewTable.tsx
src/pages/ViewTeamGrades/ReviewTableRow.tsx

=== 6.Refactoring Code ===
We will work on refactoring some of the code, for example, changing naming conventions along with making sure SOLID principles are being used.

==== Refactoring code 1 ====
Updated naming convention for a toggle option

Previous:unclear state variable name with no comment
<div class="clear"></div>
[[File: supporting_code5.png|600px]]

Refactored: Added a comment to explain what the state was as well as changing the variable name to be more direct.
[[File: supporting_code4.png|600px]]

== Frontend (React & TypeScript) ==
=== Files to be potentially modified ===
All files to be modified are located in the src/pages/ViewTeamGrades folder. The files that will potentially be modified are:

* src/pages/ViewTeamGrades/App.tsx
* src/pages/ViewTeamGrades/ReviewTable.tsx

== Use Case Diagram ==

The use case diagram for the "view-team-grades" page after clicking "Grades View" in Expertiza highlights various interactions with the UI. Here's a general outline of possible actors and use cases:

=== Actors: ===

* Student - Primarily interacts with the UI to view all the grading details for an assignment.

=== Use Cases: ===

* View detailed grade of a particular assignment - Including assignment name, team name, average score, etc.
* Show Submission - This link redirects the student to a new page where the student can see his/her submission details.
* Show Stats - This link redirects the student to a new page where the student can see grading statistics.
* Submitted Work - This table shows the average and range of submitted work grades.
**Show Reviews - This link located in the "Submitted Work" table redirects the student to the page that renders all the reviews that the student obtained from his/her peers.
* Author Feedback - This table shows the average and range of author feedback for the submitted work.
**Show Author Feedback - This link located in the "Author Feedback" table redirects the student to the page that renders the author feedback that the student obtained after writing a review.
* Teammate Review - This table shows the average and range of teammate reviews for the submitted work.
* Back - Link that enables the student to go back to the main page
*

[[File: yusufov_d2.png |750px|center]]

==Test Plan==
To validate the newly designed "View Submissions" page's functionality, usability, and performance while meeting the goals of clarity, consistency, flexibility, and intuitivenes.

=== Testing Scope ===
1. Component Validation
* Test individual React components like ReviewTable.tsx and Statistics.tsx.
2. API Integration
* Verify API calls using useAPI.ts to ensure seamless backend integration.
3. Dynamic Features
* Test real-time updates (e.g., "Last Updated" timestamps).

=== Test Cases: ===

{| class="wikitable"
! Test Case ID
! Test Description
! Expected Outcome
! Priority
! Status
|-
| TC001
| Verify assignment name display
| Assignment names appear accurately.
| High
| Pending
|-
| TC002
| Validate "Show Stats" link
| Redirects to accurate grading statistics page.
| Medium
| Pending
|-
| TC003
| Test pagination in tables
| Pagination works correctly for large datasets.
| High
| Pending
|-
| TC004
| Test table export functionality
| CSV and Excel files match table content accurately.
| High
| Pending
|-
| TC005
| Validate data rendering
| Tables display data using mock files like `dummyData.json`.
| High
| Pending
|-
| TC006
| Test error handling for missing data
| UI displays appropriate placeholders or messages for empty datasets.
| Low
| Pending
|-
| TC007
| Verify contributor details
| Names and user IDs are displayed accurately.
| Medium
| Pending
|-
| TC008
| Validate new thresholds for review length
| Dynamic thresholds for word/character counts update and display correctly.
| Medium
| Pending
|}

=== Testing Strategy ===

Unit Testing:
*Write tests for individual components like ReviewTable using Jest.
*Validate utility functions in utils.ts.

Integration Testing:
* Test the interaction between App.tsx and its child components.
* Validate API responses using axios_client.ts.

Performance Testing:
* Simulate exporting large datasets to assess system performance.
* Measure response times for table rendering with dummyData.json.

Accessibility Testing:
*Test keyboard navigation and WCAG 2.1 compliance.

== Actual Testing ==

=== Unit Testing for ReviewTable using Jest ===

*The ReviewTable component is validated using the Jest and React Testing Libraries. Running tests on the ReviewTable component allowed us to determine whether the component rendered without crashing by utilizing the render function provided by the React Testing Library. The ReviewTable component was wrapped inside a Router component imported from react-router-dom, to establish the necessary routing context for components that rely on React Router. This configuration allows the test to simulate the environment in which the component operates accurately. Overall, the test file serves as a quality assurance measure, verifying that the ReviewTable component can render successfully and integrate correctly with the React Router.

====[https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/ReviewTable.test.tsx ReviewTable.test.tsx]====
<pre>
import React from 'react';
import { render} from '@testing-library/react';
import { BrowserRouter as Router } from 'react-router-dom';
import ReviewTable from './ReviewTable';

describe('ReviewTable component', () => {
test('renders without crashing', () => {
render(
<Router> {/* Wrap your component with Router */}
<ReviewTable />
</Router>
);
});

});</pre>

==== Testing results ====
[[File: loyda_review_testing_results.png]]

=== Unit Testing for Statistics Component using Jest ===

*The Statistics component is validated using the Jest and React Testing Libraries. It employs the Jest and React Testing Library for testing purposes, along with the jest-dom library for custom assertions. The first test "renders the correct labels" ensures that the statistics table renders the correct labels. The second test "renders correct statistical information for each label" ensures that the statistical information is rendered correctly under each label. Lastly, their test "renders correct links" ensures that all the necessary links are rendered. Overall, these tests comprehensively evaluate the rendering and functionality of the Statistics component.

====[https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/Statistics.test.tsx Statistics.test.tsx]====
<pre>
import React from 'react';
import { render, screen } from '@testing-library/react';
import '@testing-library/jest-dom/extend-expect'; // Import jest-dom for custom assertions
import Statistics from './Statistics'; // Import the component to test

describe('Statistics', () => {
test('renders the correct labels', () => {
render(<Statistics average={''} />);
// Find the scores within the underlined spans
const element_1 = screen.getByRole('columnheader', { name: 'Submitted Work' });
const element_2 = screen.getByRole('columnheader', { name: 'Author Feedback' });
const element_3 = screen.getByRole('columnheader', { name: 'Teammate Review' });
const element_4 = screen.getByRole('columnheader', { name: 'Contributor' });

const element_5 = screen.getAllByText(/Average/i);
const element_6 = screen.getAllByText(/Range/i);
const element_7 = screen.getByRole('columnheader', { name: 'Final Score' });

// Assert that the elements are present
expect(element_1).toBeInTheDocument();
expect(element_2).toBeInTheDocument();
expect(element_3).toBeInTheDocument();
expect(element_4).toBeInTheDocument();
expect(element_5[0]).toBeInTheDocument();
expect(element_6[0]).toBeInTheDocument();
expect(element_7).toBeInTheDocument();

});

test('renders correct statistical information for each label', () => {
render(<Statistics average={''} />);
// Find the scores within the underlined spans
const element_1 = screen.getByRole('cell', { name: 'ssshah26 (Siddharth Shah)' });
const element_2 = screen.getByRole('cell', { name: 'Show Reviews (20)' });
const element_3 = screen.getByRole('cell', { name: '99.99% - 100%' });
const element_4 = screen.getByRole('cell', { name: '96.67 Show Author Feedback (10)' });
const element_5 = screen.getByRole('cell', { name: '87% - 100%' });
const element_6 = screen.getByRole('cell', { name: '4.64' });
const element_7 = screen.getByRole('cell', { name: '90% - 100%' });
const element_8 = screen.getByRole('cell', { name: '75% (in Finished)' });

// Assert that the elements are present
expect(element_1).toBeInTheDocument();
expect(element_2).toBeInTheDocument();
expect(element_3).toBeInTheDocument();
expect(element_4).toBeInTheDocument();
expect(element_5).toBeInTheDocument();
expect(element_6).toBeInTheDocument();
expect(element_7).toBeInTheDocument();
expect(element_8).toBeInTheDocument();
});

test('renders correct links', () => {
render(<Statistics average={''} />);
// Find the scores within the underlined spans
const element_1 = screen.getByRole('link', { name: 'show stats' });
const element_2 = screen.getByRole('link', { name: 'ssshah26' });
const element_3 = screen.getByRole('link', { name: 'Show Reviews' });
const element_4 = screen.getByRole('link', { name: 'Show Author Feedback' });

// Assert that the elements are present
expect(element_1).toBeInTheDocument();
expect(element_2).toBeInTheDocument();
expect(element_3).toBeInTheDocument();
expect(element_4).toBeInTheDocument();

});
});</pre>

==== Testing results ====

[[File: loyda_statistics_testing_results.png]]

== User Stories ==

* As a student I want to check all grading details of an assignment so that I can know my grade.
* As a student I want to see my submission of an assignment so that I can check what was submitted for a given assignment.
* As a student I want to see the names of my group team members so that I can know who I worked with.
* As a student I want to see the statistics of my grades so that I know my grade distribution.
* As a student I want to see if I got any late penalties so that I can know whether I got deducted points or not.
* As a student I want to have a way to view all the reviews that I got for the assignment so that I can read the viewer's responses.

== Conclusion ==
This design document introduces a step-by-step plan for updating the "view-team-grades" page on Expertiza, aiming for a user interface that is visually appealing and simple. Using React and TypeScript, the goal is to deliver a more user-friendly solution that enhances the functionality and manageability of grade information for a particular project within the Expertiza system. A clear and flexible UI design makes it not only simple to maintain but also flexible enough for future upgrades.

== List of Project Links ==
GitHub Repository: https://github.com/simong2/reimplementation-front-end

== Project Mentor ==

'''Nainisha Bhallamudi''' (nbhalla@ncsu.edu)

== Team Members ==

* '''Simon Getahun''' (unityid: sgetahu, github: https://github.com/simong2)
* '''Anusha Akkireddy''' (unityid: aakkire, github:https://github.com/akkireddyanusha)
* '''Loyda Yusufova''' (unityid: leyusufo, github: https://github.com/leyusufo)

File:Simon new menu opened.png

2024-12-04T08:43:49Z

Sgetahu: Sgetahu uploaded a new version of File:Simon new menu opened.png

CSC/ECE 517 Fall 2024 - E2492. UI for View submissions/assign grades (except heatgrid)

2024-12-04T08:37:19Z

Sgetahu: /* Supporting Code */

== Introduction ==
=== Project Overview ===

The "View Submissions" project focuses on developing a user interface (UI)
to maintain the score of reviewer submissions.

The Peer Review Summary Page UI is designed to display essential information for each review
assignment in a streamlined and user-friendly format. It provides a clear overview of contributors
and assigned reviewers, with interactive options such as "Unsubmit" and "Delete" to manage
submissions easily. Meta-reviewer options are intentionally excluded to keep the interface
focused solely on core reviewer functionalities. Additional sections are included to display
missing reviews, add grades and comments, and create an efficient and straightforward
interface for managing peer reviews.

== Design Goals ==
The Peer Review Summary Page in this project is designed to display essential information for each review assignment in a streamlined and user-friendly format. The main objectives focus on consistency and clearness, minimalism, flexibility, and intuitivism:

* '''Consistency and clearness: '''The Peer Review Summary Page UI interface should be consistent and clear.

* ''' Minimalism: '''The Peer Review Summary Page UI interface is very cluttered and there is so much going on in the page which makes it hard for a student to navigate through the information that is being displayed. We aim to avoid cluttering the interface with too much information.

* ''' Flexibility: '''The Peer Review Summary Page UI interface should be flexible and avoid clutter. We aim to deliver flexibility by rearranging information around the page to make it more presentable and easy to read.

* '''Intuitivism: '''The Peer Review Summary Page UI interface should be easy to use and understand. At the moment, the UI shows a few confusing and hard-to-understand areas/blocks (such as the "Submitted Work" table). We aim to make these areas less confusing by changing the way these blocks are being displayed.

These objectives ensure that students can efficiently see their grade details for a particular project, such as project title, team name, average peer review score, and peer review scores for each received review, and perform essential actions like show submission, show reviews, show author feedback, and show stats.

Through these design goals, we aim to deliver a more user-friendly solution that enhances the functionality and manageability of grade information for a particular project within the Expertiza system. The project leverages ReactJS and TypeScript to achieve these objectives, ensuring a modern, consistent, and flexible interface.

== Current UI Layout ==
The image below refers to the current UI layout. As shown in the image, the UI looks very cluttered and it is hard to find information in it. It has so many links and descriptions scattered around the page without any order. This makes it hard for a student to find information quickly.

[[File: loyda_layout1.png|900px]]

With the objectives that were mentioned in the previous section and the possible changes that are discussed next, we hope to alleviate the clutter and make the UI more visually appealing.

== Detail Description of Possible and Actual Changes ==

=== 1. Intuitive Display of statistics table: "Submitted Work", "Author Feedback", and "Teammate Review" ===
==== Rationale ====

The statistics table that encompasses the "Submitted Work", "Author Feedback", and "Teammate Review" tables lack contrast which makes them hard to understand and hard to read. Below is a snapshot of their locations in the current UI:

==== Existing Design ====

[[File: loyda_1.png|1200px]]

Notice how hard it is to visualize the tables and how hard it is to follow the information that they are providing. Our goal is to make these tables more visually appealing by introducing 2 possible changes. The changes are highlighted below.

==== Possible Changes ====

* ''' 1. Introduce shading '''
One of the possible approaches to fixing this issue is to Introduce color by filling each table with a different color.

[[File: loyda_2b.png|1200px]]

* ''' 2. Introducing outside borders: '''
Another possible solution to this issue is to add an outside border to each table to make it easier to read and understand. After adding table borders, the tables are expected to be displayed as follows:

[[File: loyda_2a.png|1200px]]

==== Actual Changes ====
The two proposed changes highlighted above were combined to create a new statistics table. Each of the 2 proposed changes introduces good mechanisms for achieving clarity and delivering a visually appealing statistics table to the user. Below is a snapshot of the new statistics table. Notice how easy it is to read and follow the details in the table as opposed to the original table.

[[File: loyda_2c.png|1200px]]

* ''' Updated Files '''

src/pages/ViewTeamGrades/Statistics.tsx [https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/Statisticstsx Statistics.tsx]

=== 2. Change the Location and Format of Team Member List ===
==== Rationale ====
The team member list is a type of information that should be readily available to the user. Instead, it is placed almost at the bottom of the page. Also, the font size is really small which makes it difficult to locate and read.

Furthermore, the "RoundSelector.tsx" file contains a function and its main purpose is to select the review round. However, its function is also to display the team member list. This violates the single responsibility principle. To fix this issue and allow the "RoundSelector" function to perform one function only, which in this case is to select the review round, it would be wise to move the code to gather and display the team information elsewhere — most likely inside the ReviewTable.tsx file.

==== Existing Design ====

Below is a screenshot of where the team member list is located in the UI. The team member list is outlined in red for visibility:

[[File: loyda_3a.png|1200px]]

Notice how small the font size is. Also, the team list should be located at the beginning of the page because it is part of the basic information that should be rendered first.

The current code to gather and display the team member list is located inside the "RoundSelector.tsx" file

[[File: loyda_3b.png|450px]]

Our goal is to change the location of the code snippets that are outlined in red to another location. This change will allow the RoundSelector function to only focus on selecting the review "Rounds"

==== Possible Changes ====

* ''' 1. Place the team list at the top of the page '''
The possible location of the team list will be in between the "Team" and "Average peer review score" information. The text format will also be changed. A larger text size will be introduced. These changes will allow the user to locate the list of the names of his/her team.

* ''' 2. Change the location of the code that gathers and displays the team list elsewhere '''
Changing the location of the code from the "RoundSelector.tsx" file to the "ReviewTable.tsx" file would allow us to fix the violation of the single responsibility principle in "RoundSelector.tsx".

==== Actual Changes ====
Below is a screenshot of the new location of the team member list outlined in red for visibility. Notice that the team member list is easy to locate as well as easy to read.

[[File: loyda_3c.png|1200px]]

Also, we changed the code to gather and display the team member list in the "ReviewTable.tsx" file. The new code snippets added are outlined in red for visibility

[[File: loyda_3d.png]]

The new "RoundSelector.tsx" contains the function that is ONLY focussed on selecting the review "Round" and thus obeys the single responsibility principle. A snapshot of the new function is provided below:

[[File: loyda_3e.png]]

* ''' Updated Files '''

src/pages/ViewTeamGrades/RoundSelector.tsx [https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/RoundSelelctor.tsx RoundSelector.tsx]
src/pages/ViewTeamGrades/ReviewTable.tsx [https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/ReviewTable.tsx ReviewTable.tsx]

=== 3.Export Options for Tables ===

'''Current Limitation:'''
Users cannot save or analyze table data outside the user interface. This makes it difficult to share or process data for further analysis.

'''Proposed Solution:'''
Add export buttons below each table to allow users to download the data as CSV, Excel, or PDF files. This will increase the flexibility and utility of the tables.

'''Implementation Details:'''
‎<br> 1. Export buttons for CSV and Excel are located below the table. ‎<br>
‎<br> 2. Utilizes the SheetJS (xlsx) library to generate exportable files. ‎<br>
‎<br> 3. File structure matches the table's visible data. ‎<br>

'''Supporting Code:'''
const exportTableData = (format: "csv" | "xlsx") => {
const tableData = initialData.map((row) => {
const rowData: Record<string, any> = {};
columns.forEach((col) => {
const accessor = col.id; // Use column `id` for keys
if (accessor) {
rowData[accessor] = row[accessor];
}
});
return rowData;
});

const worksheet = XLSX.utils.json_to_sheet(tableData);
const workbook = XLSX.utils.book_new();
XLSX.utils.book_append_sheet(workbook, worksheet, "TableData");

const fileType = format === "csv" ? "csv" : "xlsx";
XLSX.writeFile(workbook, `table_data.${fileType}`);
};

'''Export Buttons in the UI:'''
<div style={{ marginTop: "10px" }}>
<button
onClick={() => exportTableData("csv")}
className="btn btn-primary me-2"
>
Export to CSV
</button>
<button
onClick={() => exportTableData("xlsx")}
className="btn btn-primary"
>
Export to Excel
</button>
</div>

'''Testing:'''
it("renders export buttons", () => {
render(<Table data={mockData} columns={mockColumns} />);
expect(screen.getByText("Export to CSV")).toBeInTheDocument();
expect(screen.getByText("Export to Excel")).toBeInTheDocument();
});

=== 4.Improved Feedback Indicators ===

'''Current Limitation:'''
Users have no indication of when table data was last updated, leading to potential uncertainty about its accuracy.

'''Proposed Solution:'''
Add "Last Updated" timestamps or live refresh indicators for each table.

'''Implementation Details:'''
‎<br> 1. Include a "Last Updated: [Date/Time]" label below the table. ‎<br>
‎<br> 2. Update the timestamp dynamically whenever the data source is refreshed. ‎<br>
‎<br> 3. Use a subtle spinning loader icon to indicate data refreshing. ‎<br>

'''Supporting Code:'''
const [lastUpdated, setLastUpdated] = useState<Date | null>(null);

const refreshTableData = () => {
setLastUpdated(new Date());
};

=== 5.Extending toggle options ===

==== Rationale ====
While the heat map provides a great visual representation of the users feedback, with the addition of some 'toggles' we can better idea of the different values. Currently, there is only the option to toggle for the questions.

==== Existing Design ====

[[File: old_toggle_sc.png|1200px]]

In this current mode, there is only the option to toggle for the questions.

==== Actual Changes ====

[[File: simon_new_menu_opened.png|650px]]

In the updated version, since more toggle options were added, there is now a heat map option menu, that can be opened and closed. When open, there are 4 different checkboxes to check from that each provide their own way of helping the student better analyze their team grade.

When menu is closed:

[[File: simon_new_menu_closed.png|300px]]

==== Supporting Code for Toggle Options ====

[[File: simon_supporting_code1.png|650px]]

Here is the supporting code for the 3 new toggle options, showToggle10WordComments, showToggle20WordComments, and showToggleCustomWordComment are all boolean values that if their state is set to true filter and count reviews based on the properties of their comments. When they're set to true, it will first ensure that the comments are defined as strings and not undefined (since a user can leave a review without providing a comment), it will then filter over the reviews array within a row and filter and return the total number of comments that meet the respective criteria.

''' Custom Feature Toggle '''

[[File: simon_custom_checkbox_clicked.png|500px]]

In the Heat Map Option panel, there is a custom checkbox, that when clicked, will allow the users to use the arrow to search within the comments to see how many are >= the input value.

==== Supporting Code ====

[[File: simon_supporting_code2.png|500px]]

In the panel, when the checkbox is clicked, it will update the state for showToggleCustomWordComment to be true, which will then render what can be seen in the previous screenshot. When using the input element, since you can use your keyboard to delete the value and type it in, when you delete the value, when it makes the onChange callback, the current empty string will be based to the inputValue set state giving it a NaN value, so if the onChange is an empty string it will set the value back to 0, which is what the confirmInputValue function is doing.

* ''' Updated Files '''

src/pages/ViewTeamGrades/ReviewTable.tsx
src/pages/ViewTeamGrades/ReviewTableRow.tsx

=== 6.Refactoring Code ===
We will work on refactoring some of the code, for example, changing naming conventions along with making sure SOLID principles are being used.

==== Refactoring code 1 ====
Updated naming convention for a toggle option

Previous:unclear state variable name with no comment
<div class="clear"></div>
[[File: supporting_code5.png|600px]]

Refactored: Added a comment to explain what the state was as well as changing the variable name to be more direct.
[[File: supporting_code4.png|600px]]

== Frontend (React & TypeScript) ==
=== Files to be potentially modified ===
All files to be modified are located in the src/pages/ViewTeamGrades folder. The files that will potentially be modified are:

* src/pages/ViewTeamGrades/App.tsx
* src/pages/ViewTeamGrades/ReviewTable.tsx

== Use Case Diagram ==

The use case diagram for the "view-team-grades" page after clicking "Grades View" in Expertiza highlights various interactions with the UI. Here's a general outline of possible actors and use cases:

=== Actors: ===

* Student - Primarily interacts with the UI to view all the grading details for an assignment.

=== Use Cases: ===

* View detailed grade of a particular assignment - Including assignment name, team name, average score, etc.
* Show Submission - This link redirects the student to a new page where the student can see his/her submission details.
* Show Stats - This link redirects the student to a new page where the student can see grading statistics.
* Submitted Work - This table shows the average and range of submitted work grades.
**Show Reviews - This link located in the "Submitted Work" table redirects the student to the page that renders all the reviews that the student obtained from his/her peers.
* Author Feedback - This table shows the average and range of author feedback for the submitted work.
**Show Author Feedback - This link located in the "Author Feedback" table redirects the student to the page that renders the author feedback that the student obtained after writing a review.
* Teammate Review - This table shows the average and range of teammate reviews for the submitted work.
* Back - Link that enables the student to go back to the main page
*

[[File: yusufov_d2.png |750px|center]]

==Test Plan==
To validate the newly designed "View Submissions" page's functionality, usability, and performance while meeting the goals of clarity, consistency, flexibility, and intuitivenes.

=== Testing Scope ===
1. Component Validation
* Test individual React components like ReviewTable.tsx and Statistics.tsx.
2. API Integration
* Verify API calls using useAPI.ts to ensure seamless backend integration.
3. Dynamic Features
* Test real-time updates (e.g., "Last Updated" timestamps).

=== Test Cases: ===

{| class="wikitable"
! Test Case ID
! Test Description
! Expected Outcome
! Priority
! Status
|-
| TC001
| Verify assignment name display
| Assignment names appear accurately.
| High
| Pending
|-
| TC002
| Validate "Show Stats" link
| Redirects to accurate grading statistics page.
| Medium
| Pending
|-
| TC003
| Test pagination in tables
| Pagination works correctly for large datasets.
| High
| Pending
|-
| TC004
| Test table export functionality
| CSV and Excel files match table content accurately.
| High
| Pending
|-
| TC005
| Validate data rendering
| Tables display data using mock files like `dummyData.json`.
| High
| Pending
|-
| TC006
| Test error handling for missing data
| UI displays appropriate placeholders or messages for empty datasets.
| Low
| Pending
|-
| TC007
| Verify contributor details
| Names and user IDs are displayed accurately.
| Medium
| Pending
|-
| TC008
| Validate new thresholds for review length
| Dynamic thresholds for word/character counts update and display correctly.
| Medium
| Pending
|}

=== Testing Strategy ===

Unit Testing:
*Write tests for individual components like ReviewTable using Jest.
*Validate utility functions in utils.ts.

Integration Testing:
* Test the interaction between App.tsx and its child components.
* Validate API responses using axios_client.ts.

Performance Testing:
* Simulate exporting large datasets to assess system performance.
* Measure response times for table rendering with dummyData.json.

Accessibility Testing:
*Test keyboard navigation and WCAG 2.1 compliance.

== Actual Testing ==

=== Unit Testing for ReviewTable using Jest ===

*The ReviewTable component is validated using the Jest and React Testing Libraries. Running tests on the ReviewTable component allowed us to determine whether the component rendered without crashing by utilizing the render function provided by the React Testing Library. The ReviewTable component was wrapped inside a Router component imported from react-router-dom, to establish the necessary routing context for components that rely on React Router. This configuration allows the test to simulate the environment in which the component operates accurately. Overall, the test file serves as a quality assurance measure, verifying that the ReviewTable component can render successfully and integrate correctly with the React Router.

====[https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/ReviewTable.test.tsx ReviewTable.test.tsx]====
<pre>
import React from 'react';
import { render} from '@testing-library/react';
import { BrowserRouter as Router } from 'react-router-dom';
import ReviewTable from './ReviewTable';

describe('ReviewTable component', () => {
test('renders without crashing', () => {
render(
<Router> {/* Wrap your component with Router */}
<ReviewTable />
</Router>
);
});

});</pre>

==== Testing results ====
[[File: loyda_review_testing_results.png]]

=== Unit Testing for Statistics Component using Jest ===

*The Statistics component is validated using the Jest and React Testing Libraries. It employs the Jest and React Testing Library for testing purposes, along with the jest-dom library for custom assertions. The first test "renders the correct labels" ensures that the statistics table renders the correct labels. The second test "renders correct statistical information for each label" ensures that the statistical information is rendered correctly under each label. Lastly, their test "renders correct links" ensures that all the necessary links are rendered. Overall, these tests comprehensively evaluate the rendering and functionality of the Statistics component.

====[https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/Statistics.test.tsx Statistics.test.tsx]====
<pre>
import React from 'react';
import { render, screen } from '@testing-library/react';
import '@testing-library/jest-dom/extend-expect'; // Import jest-dom for custom assertions
import Statistics from './Statistics'; // Import the component to test

describe('Statistics', () => {
test('renders the correct labels', () => {
render(<Statistics average={''} />);
// Find the scores within the underlined spans
const element_1 = screen.getByRole('columnheader', { name: 'Submitted Work' });
const element_2 = screen.getByRole('columnheader', { name: 'Author Feedback' });
const element_3 = screen.getByRole('columnheader', { name: 'Teammate Review' });
const element_4 = screen.getByRole('columnheader', { name: 'Contributor' });

const element_5 = screen.getAllByText(/Average/i);
const element_6 = screen.getAllByText(/Range/i);
const element_7 = screen.getByRole('columnheader', { name: 'Final Score' });

// Assert that the elements are present
expect(element_1).toBeInTheDocument();
expect(element_2).toBeInTheDocument();
expect(element_3).toBeInTheDocument();
expect(element_4).toBeInTheDocument();
expect(element_5[0]).toBeInTheDocument();
expect(element_6[0]).toBeInTheDocument();
expect(element_7).toBeInTheDocument();

});

test('renders correct statistical information for each label', () => {
render(<Statistics average={''} />);
// Find the scores within the underlined spans
const element_1 = screen.getByRole('cell', { name: 'ssshah26 (Siddharth Shah)' });
const element_2 = screen.getByRole('cell', { name: 'Show Reviews (20)' });
const element_3 = screen.getByRole('cell', { name: '99.99% - 100%' });
const element_4 = screen.getByRole('cell', { name: '96.67 Show Author Feedback (10)' });
const element_5 = screen.getByRole('cell', { name: '87% - 100%' });
const element_6 = screen.getByRole('cell', { name: '4.64' });
const element_7 = screen.getByRole('cell', { name: '90% - 100%' });
const element_8 = screen.getByRole('cell', { name: '75% (in Finished)' });

// Assert that the elements are present
expect(element_1).toBeInTheDocument();
expect(element_2).toBeInTheDocument();
expect(element_3).toBeInTheDocument();
expect(element_4).toBeInTheDocument();
expect(element_5).toBeInTheDocument();
expect(element_6).toBeInTheDocument();
expect(element_7).toBeInTheDocument();
expect(element_8).toBeInTheDocument();
});

test('renders correct links', () => {
render(<Statistics average={''} />);
// Find the scores within the underlined spans
const element_1 = screen.getByRole('link', { name: 'show stats' });
const element_2 = screen.getByRole('link', { name: 'ssshah26' });
const element_3 = screen.getByRole('link', { name: 'Show Reviews' });
const element_4 = screen.getByRole('link', { name: 'Show Author Feedback' });

// Assert that the elements are present
expect(element_1).toBeInTheDocument();
expect(element_2).toBeInTheDocument();
expect(element_3).toBeInTheDocument();
expect(element_4).toBeInTheDocument();

});
});</pre>

==== Testing results ====

[[File: loyda_statistics_testing_results.png]]

== User Stories ==

* As a student I want to check all grading details of an assignment so that I can know my grade.
* As a student I want to see my submission of an assignment so that I can check what was submitted for a given assignment.
* As a student I want to see the names of my group team members so that I can know who I worked with.
* As a student I want to see the statistics of my grades so that I know my grade distribution.
* As a student I want to see if I got any late penalties so that I can know whether I got deducted points or not.
* As a student I want to have a way to view all the reviews that I got for the assignment so that I can read the viewer's responses.

== Conclusion ==
This design document introduces a step-by-step plan for updating the "view-team-grades" page on Expertiza, aiming for a user interface that is visually appealing and simple. Using React and TypeScript, the goal is to deliver a more user-friendly solution that enhances the functionality and manageability of grade information for a particular project within the Expertiza system. A clear and flexible UI design makes it not only simple to maintain but also flexible enough for future upgrades.

== List of Project Links ==
GitHub Repository: https://github.com/simong2/reimplementation-front-end

== Project Mentor ==

'''Nainisha Bhallamudi''' (nbhalla@ncsu.edu)

== Team Members ==

* '''Simon Getahun''' (unityid: sgetahu, github: https://github.com/simong2)
* '''Anusha Akkireddy''' (unityid: aakkire, github:https://github.com/akkireddyanusha)
* '''Loyda Yusufova''' (unityid: leyusufo, github: https://github.com/leyusufo)

CSC/ECE 517 Fall 2024 - E2492. UI for View submissions/assign grades (except heatgrid)

2024-12-04T08:35:14Z

Sgetahu: /* Supporting Code */

== Introduction ==
=== Project Overview ===

The "View Submissions" project focuses on developing a user interface (UI)
to maintain the score of reviewer submissions.

The Peer Review Summary Page UI is designed to display essential information for each review
assignment in a streamlined and user-friendly format. It provides a clear overview of contributors
and assigned reviewers, with interactive options such as "Unsubmit" and "Delete" to manage
submissions easily. Meta-reviewer options are intentionally excluded to keep the interface
focused solely on core reviewer functionalities. Additional sections are included to display
missing reviews, add grades and comments, and create an efficient and straightforward
interface for managing peer reviews.

== Design Goals ==
The Peer Review Summary Page in this project is designed to display essential information for each review assignment in a streamlined and user-friendly format. The main objectives focus on consistency and clearness, minimalism, flexibility, and intuitivism:

* '''Consistency and clearness: '''The Peer Review Summary Page UI interface should be consistent and clear.

* ''' Minimalism: '''The Peer Review Summary Page UI interface is very cluttered and there is so much going on in the page which makes it hard for a student to navigate through the information that is being displayed. We aim to avoid cluttering the interface with too much information.

* ''' Flexibility: '''The Peer Review Summary Page UI interface should be flexible and avoid clutter. We aim to deliver flexibility by rearranging information around the page to make it more presentable and easy to read.

* '''Intuitivism: '''The Peer Review Summary Page UI interface should be easy to use and understand. At the moment, the UI shows a few confusing and hard-to-understand areas/blocks (such as the "Submitted Work" table). We aim to make these areas less confusing by changing the way these blocks are being displayed.

These objectives ensure that students can efficiently see their grade details for a particular project, such as project title, team name, average peer review score, and peer review scores for each received review, and perform essential actions like show submission, show reviews, show author feedback, and show stats.

Through these design goals, we aim to deliver a more user-friendly solution that enhances the functionality and manageability of grade information for a particular project within the Expertiza system. The project leverages ReactJS and TypeScript to achieve these objectives, ensuring a modern, consistent, and flexible interface.

== Current UI Layout ==
The image below refers to the current UI layout. As shown in the image, the UI looks very cluttered and it is hard to find information in it. It has so many links and descriptions scattered around the page without any order. This makes it hard for a student to find information quickly.

[[File: loyda_layout1.png|900px]]

With the objectives that were mentioned in the previous section and the possible changes that are discussed next, we hope to alleviate the clutter and make the UI more visually appealing.

== Detail Description of Possible and Actual Changes ==

=== 1. Intuitive Display of statistics table: "Submitted Work", "Author Feedback", and "Teammate Review" ===
==== Rationale ====

The statistics table that encompasses the "Submitted Work", "Author Feedback", and "Teammate Review" tables lack contrast which makes them hard to understand and hard to read. Below is a snapshot of their locations in the current UI:

==== Existing Design ====

[[File: loyda_1.png|1200px]]

Notice how hard it is to visualize the tables and how hard it is to follow the information that they are providing. Our goal is to make these tables more visually appealing by introducing 2 possible changes. The changes are highlighted below.

==== Possible Changes ====

* ''' 1. Introduce shading '''
One of the possible approaches to fixing this issue is to Introduce color by filling each table with a different color.

[[File: loyda_2b.png|1200px]]

* ''' 2. Introducing outside borders: '''
Another possible solution to this issue is to add an outside border to each table to make it easier to read and understand. After adding table borders, the tables are expected to be displayed as follows:

[[File: loyda_2a.png|1200px]]

==== Actual Changes ====
The two proposed changes highlighted above were combined to create a new statistics table. Each of the 2 proposed changes introduces good mechanisms for achieving clarity and delivering a visually appealing statistics table to the user. Below is a snapshot of the new statistics table. Notice how easy it is to read and follow the details in the table as opposed to the original table.

[[File: loyda_2c.png|1200px]]

* ''' Updated Files '''

src/pages/ViewTeamGrades/Statistics.tsx [https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/Statisticstsx Statistics.tsx]

=== 2. Change the Location and Format of Team Member List ===
==== Rationale ====
The team member list is a type of information that should be readily available to the user. Instead, it is placed almost at the bottom of the page. Also, the font size is really small which makes it difficult to locate and read.

Furthermore, the "RoundSelector.tsx" file contains a function and its main purpose is to select the review round. However, its function is also to display the team member list. This violates the single responsibility principle. To fix this issue and allow the "RoundSelector" function to perform one function only, which in this case is to select the review round, it would be wise to move the code to gather and display the team information elsewhere — most likely inside the ReviewTable.tsx file.

==== Existing Design ====

Below is a screenshot of where the team member list is located in the UI. The team member list is outlined in red for visibility:

[[File: loyda_3a.png|1200px]]

Notice how small the font size is. Also, the team list should be located at the beginning of the page because it is part of the basic information that should be rendered first.

The current code to gather and display the team member list is located inside the "RoundSelector.tsx" file

[[File: loyda_3b.png|450px]]

Our goal is to change the location of the code snippets that are outlined in red to another location. This change will allow the RoundSelector function to only focus on selecting the review "Rounds"

==== Possible Changes ====

* ''' 1. Place the team list at the top of the page '''
The possible location of the team list will be in between the "Team" and "Average peer review score" information. The text format will also be changed. A larger text size will be introduced. These changes will allow the user to locate the list of the names of his/her team.

* ''' 2. Change the location of the code that gathers and displays the team list elsewhere '''
Changing the location of the code from the "RoundSelector.tsx" file to the "ReviewTable.tsx" file would allow us to fix the violation of the single responsibility principle in "RoundSelector.tsx".

==== Actual Changes ====
Below is a screenshot of the new location of the team member list outlined in red for visibility. Notice that the team member list is easy to locate as well as easy to read.

[[File: loyda_3c.png|1200px]]

Also, we changed the code to gather and display the team member list in the "ReviewTable.tsx" file. The new code snippets added are outlined in red for visibility

[[File: loyda_3d.png]]

The new "RoundSelector.tsx" contains the function that is ONLY focussed on selecting the review "Round" and thus obeys the single responsibility principle. A snapshot of the new function is provided below:

[[File: loyda_3e.png]]

* ''' Updated Files '''

src/pages/ViewTeamGrades/RoundSelector.tsx [https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/RoundSelelctor.tsx RoundSelector.tsx]
src/pages/ViewTeamGrades/ReviewTable.tsx [https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/ReviewTable.tsx ReviewTable.tsx]

=== 3.Export Options for Tables ===

'''Current Limitation:'''
Users cannot save or analyze table data outside the user interface. This makes it difficult to share or process data for further analysis.

'''Proposed Solution:'''
Add export buttons below each table to allow users to download the data as CSV, Excel, or PDF files. This will increase the flexibility and utility of the tables.

'''Implementation Details:'''
‎<br> 1. Export buttons for CSV and Excel are located below the table. ‎<br>
‎<br> 2. Utilizes the SheetJS (xlsx) library to generate exportable files. ‎<br>
‎<br> 3. File structure matches the table's visible data. ‎<br>

'''Supporting Code:'''
const exportTableData = (format: "csv" | "xlsx") => {
const tableData = initialData.map((row) => {
const rowData: Record<string, any> = {};
columns.forEach((col) => {
const accessor = col.id; // Use column `id` for keys
if (accessor) {
rowData[accessor] = row[accessor];
}
});
return rowData;
});

const worksheet = XLSX.utils.json_to_sheet(tableData);
const workbook = XLSX.utils.book_new();
XLSX.utils.book_append_sheet(workbook, worksheet, "TableData");

const fileType = format === "csv" ? "csv" : "xlsx";
XLSX.writeFile(workbook, `table_data.${fileType}`);
};

'''Export Buttons in the UI:'''
<div style={{ marginTop: "10px" }}>
<button
onClick={() => exportTableData("csv")}
className="btn btn-primary me-2"
>
Export to CSV
</button>
<button
onClick={() => exportTableData("xlsx")}
className="btn btn-primary"
>
Export to Excel
</button>
</div>

'''Testing:'''
it("renders export buttons", () => {
render(<Table data={mockData} columns={mockColumns} />);
expect(screen.getByText("Export to CSV")).toBeInTheDocument();
expect(screen.getByText("Export to Excel")).toBeInTheDocument();
});

=== 4.Improved Feedback Indicators ===

'''Current Limitation:'''
Users have no indication of when table data was last updated, leading to potential uncertainty about its accuracy.

'''Proposed Solution:'''
Add "Last Updated" timestamps or live refresh indicators for each table.

'''Implementation Details:'''
‎<br> 1. Include a "Last Updated: [Date/Time]" label below the table. ‎<br>
‎<br> 2. Update the timestamp dynamically whenever the data source is refreshed. ‎<br>
‎<br> 3. Use a subtle spinning loader icon to indicate data refreshing. ‎<br>

'''Supporting Code:'''
const [lastUpdated, setLastUpdated] = useState<Date | null>(null);

const refreshTableData = () => {
setLastUpdated(new Date());
};

=== 5.Extending toggle options ===

==== Rationale ====
While the heat map provides a great visual representation of the users feedback, with the addition of some 'toggles' we can better idea of the different values. Currently, there is only the option to toggle for the questions.

==== Existing Design ====

[[File: old_toggle_sc.png|1200px]]

In this current mode, there is only the option to toggle for the questions.

==== Actual Changes ====

[[File: simon_new_menu_opened.png|650px]]

In the updated version, since more toggle options were added, there is now a heat map option menu, that can be opened and closed. When open, there are 4 different checkboxes to check from that each provide their own way of helping the student better analyze their team grade.

When menu is closed:

[[File: simon_new_menu_closed.png|300px]]

==== Supporting Code ====

[[File: simon_supporting_code1.png|650px]]

Here is the supporting code for the 3 new toggle options, showToggle10WordComments, showToggle20WordComments, and showToggleCustomWordComment are all boolean values that if their state is set to true filter and count reviews based on the properties of their comments. When they're set to true, it will first ensure that the comments are defined as strings and not undefined (since a user can leave a review without providing a comment), it will then filter over the reviews array within a row and filter and return the total number of comments that meet the respective criteria.

''' Custom Feature Toggle '''

[[File: simon_custom_checkbox_clicked.png|500px]]

In the Heat Map Option panel, there is a custom checkbox, that when clicked, will allow the users to use the arrow to search within the comments to see how many are >= the input value.

==== Supporting Code ====

[[File: simon_supporting_code2.png|500px]]

In the panel, when the checkbox is clicked, it will update the state for showToggleCustomWordComment to be true, which will then render what can be seen in the previous screenshot. When using the input element, since you can use your keyboard to delete the value and type it in, when you delete the value, when it makes the onChange callback, the current empty string will be based to the inputValue set state giving it a NaN value, so if the onChange is an empty string it will set the value back to 0, which is what the confirmInputValue function is doing.

* ''' Updated Files '''

src/pages/ViewTeamGrades/ReviewTable.tsx
src/pages/ViewTeamGrades/ReviewTableRow.tsx

=== 6.Refactoring Code ===
We will work on refactoring some of the code, for example, changing naming conventions along with making sure SOLID principles are being used.

==== Refactoring code 1 ====
Updated naming convention for a toggle option

Previous:unclear state variable name with no comment
<div class="clear"></div>
[[File: supporting_code5.png|600px]]

Refactored: Added a comment to explain what the state was as well as changing the variable name to be more direct.
[[File: supporting_code4.png|600px]]

== Frontend (React & TypeScript) ==
=== Files to be potentially modified ===
All files to be modified are located in the src/pages/ViewTeamGrades folder. The files that will potentially be modified are:

* src/pages/ViewTeamGrades/App.tsx
* src/pages/ViewTeamGrades/ReviewTable.tsx

== Use Case Diagram ==

The use case diagram for the "view-team-grades" page after clicking "Grades View" in Expertiza highlights various interactions with the UI. Here's a general outline of possible actors and use cases:

=== Actors: ===

* Student - Primarily interacts with the UI to view all the grading details for an assignment.

=== Use Cases: ===

* View detailed grade of a particular assignment - Including assignment name, team name, average score, etc.
* Show Submission - This link redirects the student to a new page where the student can see his/her submission details.
* Show Stats - This link redirects the student to a new page where the student can see grading statistics.
* Submitted Work - This table shows the average and range of submitted work grades.
**Show Reviews - This link located in the "Submitted Work" table redirects the student to the page that renders all the reviews that the student obtained from his/her peers.
* Author Feedback - This table shows the average and range of author feedback for the submitted work.
**Show Author Feedback - This link located in the "Author Feedback" table redirects the student to the page that renders the author feedback that the student obtained after writing a review.
* Teammate Review - This table shows the average and range of teammate reviews for the submitted work.
* Back - Link that enables the student to go back to the main page
*

[[File: yusufov_d2.png |750px|center]]

==Test Plan==
To validate the newly designed "View Submissions" page's functionality, usability, and performance while meeting the goals of clarity, consistency, flexibility, and intuitivenes.

=== Testing Scope ===
1. Component Validation
* Test individual React components like ReviewTable.tsx and Statistics.tsx.
2. API Integration
* Verify API calls using useAPI.ts to ensure seamless backend integration.
3. Dynamic Features
* Test real-time updates (e.g., "Last Updated" timestamps).

=== Test Cases: ===

{| class="wikitable"
! Test Case ID
! Test Description
! Expected Outcome
! Priority
! Status
|-
| TC001
| Verify assignment name display
| Assignment names appear accurately.
| High
| Pending
|-
| TC002
| Validate "Show Stats" link
| Redirects to accurate grading statistics page.
| Medium
| Pending
|-
| TC003
| Test pagination in tables
| Pagination works correctly for large datasets.
| High
| Pending
|-
| TC004
| Test table export functionality
| CSV and Excel files match table content accurately.
| High
| Pending
|-
| TC005
| Validate data rendering
| Tables display data using mock files like `dummyData.json`.
| High
| Pending
|-
| TC006
| Test error handling for missing data
| UI displays appropriate placeholders or messages for empty datasets.
| Low
| Pending
|-
| TC007
| Verify contributor details
| Names and user IDs are displayed accurately.
| Medium
| Pending
|-
| TC008
| Validate new thresholds for review length
| Dynamic thresholds for word/character counts update and display correctly.
| Medium
| Pending
|}

=== Testing Strategy ===

Unit Testing:
*Write tests for individual components like ReviewTable using Jest.
*Validate utility functions in utils.ts.

Integration Testing:
* Test the interaction between App.tsx and its child components.
* Validate API responses using axios_client.ts.

Performance Testing:
* Simulate exporting large datasets to assess system performance.
* Measure response times for table rendering with dummyData.json.

Accessibility Testing:
*Test keyboard navigation and WCAG 2.1 compliance.

== Actual Testing ==

=== Unit Testing for ReviewTable using Jest ===

*The ReviewTable component is validated using the Jest and React Testing Libraries. Running tests on the ReviewTable component allowed us to determine whether the component rendered without crashing by utilizing the render function provided by the React Testing Library. The ReviewTable component was wrapped inside a Router component imported from react-router-dom, to establish the necessary routing context for components that rely on React Router. This configuration allows the test to simulate the environment in which the component operates accurately. Overall, the test file serves as a quality assurance measure, verifying that the ReviewTable component can render successfully and integrate correctly with the React Router.

====[https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/ReviewTable.test.tsx ReviewTable.test.tsx]====
<pre>
import React from 'react';
import { render} from '@testing-library/react';
import { BrowserRouter as Router } from 'react-router-dom';
import ReviewTable from './ReviewTable';

describe('ReviewTable component', () => {
test('renders without crashing', () => {
render(
<Router> {/* Wrap your component with Router */}
<ReviewTable />
</Router>
);
});

});</pre>

==== Testing results ====
[[File: loyda_review_testing_results.png]]

=== Unit Testing for Statistics Component using Jest ===

*The Statistics component is validated using the Jest and React Testing Libraries. It employs the Jest and React Testing Library for testing purposes, along with the jest-dom library for custom assertions. The first test "renders the correct labels" ensures that the statistics table renders the correct labels. The second test "renders correct statistical information for each label" ensures that the statistical information is rendered correctly under each label. Lastly, their test "renders correct links" ensures that all the necessary links are rendered. Overall, these tests comprehensively evaluate the rendering and functionality of the Statistics component.

====[https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/Statistics.test.tsx Statistics.test.tsx]====
<pre>
import React from 'react';
import { render, screen } from '@testing-library/react';
import '@testing-library/jest-dom/extend-expect'; // Import jest-dom for custom assertions
import Statistics from './Statistics'; // Import the component to test

describe('Statistics', () => {
test('renders the correct labels', () => {
render(<Statistics average={''} />);
// Find the scores within the underlined spans
const element_1 = screen.getByRole('columnheader', { name: 'Submitted Work' });
const element_2 = screen.getByRole('columnheader', { name: 'Author Feedback' });
const element_3 = screen.getByRole('columnheader', { name: 'Teammate Review' });
const element_4 = screen.getByRole('columnheader', { name: 'Contributor' });

const element_5 = screen.getAllByText(/Average/i);
const element_6 = screen.getAllByText(/Range/i);
const element_7 = screen.getByRole('columnheader', { name: 'Final Score' });

// Assert that the elements are present
expect(element_1).toBeInTheDocument();
expect(element_2).toBeInTheDocument();
expect(element_3).toBeInTheDocument();
expect(element_4).toBeInTheDocument();
expect(element_5[0]).toBeInTheDocument();
expect(element_6[0]).toBeInTheDocument();
expect(element_7).toBeInTheDocument();

});

test('renders correct statistical information for each label', () => {
render(<Statistics average={''} />);
// Find the scores within the underlined spans
const element_1 = screen.getByRole('cell', { name: 'ssshah26 (Siddharth Shah)' });
const element_2 = screen.getByRole('cell', { name: 'Show Reviews (20)' });
const element_3 = screen.getByRole('cell', { name: '99.99% - 100%' });
const element_4 = screen.getByRole('cell', { name: '96.67 Show Author Feedback (10)' });
const element_5 = screen.getByRole('cell', { name: '87% - 100%' });
const element_6 = screen.getByRole('cell', { name: '4.64' });
const element_7 = screen.getByRole('cell', { name: '90% - 100%' });
const element_8 = screen.getByRole('cell', { name: '75% (in Finished)' });

// Assert that the elements are present
expect(element_1).toBeInTheDocument();
expect(element_2).toBeInTheDocument();
expect(element_3).toBeInTheDocument();
expect(element_4).toBeInTheDocument();
expect(element_5).toBeInTheDocument();
expect(element_6).toBeInTheDocument();
expect(element_7).toBeInTheDocument();
expect(element_8).toBeInTheDocument();
});

test('renders correct links', () => {
render(<Statistics average={''} />);
// Find the scores within the underlined spans
const element_1 = screen.getByRole('link', { name: 'show stats' });
const element_2 = screen.getByRole('link', { name: 'ssshah26' });
const element_3 = screen.getByRole('link', { name: 'Show Reviews' });
const element_4 = screen.getByRole('link', { name: 'Show Author Feedback' });

// Assert that the elements are present
expect(element_1).toBeInTheDocument();
expect(element_2).toBeInTheDocument();
expect(element_3).toBeInTheDocument();
expect(element_4).toBeInTheDocument();

});
});</pre>

==== Testing results ====

[[File: loyda_statistics_testing_results.png]]

== User Stories ==

* As a student I want to check all grading details of an assignment so that I can know my grade.
* As a student I want to see my submission of an assignment so that I can check what was submitted for a given assignment.
* As a student I want to see the names of my group team members so that I can know who I worked with.
* As a student I want to see the statistics of my grades so that I know my grade distribution.
* As a student I want to see if I got any late penalties so that I can know whether I got deducted points or not.
* As a student I want to have a way to view all the reviews that I got for the assignment so that I can read the viewer's responses.

== Conclusion ==
This design document introduces a step-by-step plan for updating the "view-team-grades" page on Expertiza, aiming for a user interface that is visually appealing and simple. Using React and TypeScript, the goal is to deliver a more user-friendly solution that enhances the functionality and manageability of grade information for a particular project within the Expertiza system. A clear and flexible UI design makes it not only simple to maintain but also flexible enough for future upgrades.

== List of Project Links ==
GitHub Repository: https://github.com/simong2/reimplementation-front-end

== Project Mentor ==

'''Nainisha Bhallamudi''' (nbhalla@ncsu.edu)

== Team Members ==

* '''Simon Getahun''' (unityid: sgetahu, github: https://github.com/simong2)
* '''Anusha Akkireddy''' (unityid: aakkire, github:https://github.com/akkireddyanusha)
* '''Loyda Yusufova''' (unityid: leyusufo, github: https://github.com/leyusufo)

File:Simon supporting code2.png

2024-12-04T08:16:46Z

Sgetahu:

File:Simon custom checkbox clicked.png

2024-12-04T08:16:32Z

Sgetahu:

CSC/ECE 517 Fall 2024 - E2492. UI for View submissions/assign grades (except heatgrid)

2024-12-04T08:12:00Z

Sgetahu: /* Actual Changes */

== Introduction ==
=== Project Overview ===

The "View Submissions" project focuses on developing a user interface (UI)
to maintain the score of reviewer submissions.

The Peer Review Summary Page UI is designed to display essential information for each review
assignment in a streamlined and user-friendly format. It provides a clear overview of contributors
and assigned reviewers, with interactive options such as "Unsubmit" and "Delete" to manage
submissions easily. Meta-reviewer options are intentionally excluded to keep the interface
focused solely on core reviewer functionalities. Additional sections are included to display
missing reviews, add grades and comments, and create an efficient and straightforward
interface for managing peer reviews.

== Design Goals ==
The Peer Review Summary Page in this project is designed to display essential information for each review assignment in a streamlined and user-friendly format. The main objectives focus on consistency and clearness, minimalism, flexibility, and intuitivism:

* '''Consistency and clearness: '''The Peer Review Summary Page UI interface should be consistent and clear.

* ''' Minimalism: '''The Peer Review Summary Page UI interface is very cluttered and there is so much going on in the page which makes it hard for a student to navigate through the information that is being displayed. We aim to avoid cluttering the interface with too much information.

* ''' Flexibility: '''The Peer Review Summary Page UI interface should be flexible and avoid clutter. We aim to deliver flexibility by rearranging information around the page to make it more presentable and easy to read.

* '''Intuitivism: '''The Peer Review Summary Page UI interface should be easy to use and understand. At the moment, the UI shows a few confusing and hard-to-understand areas/blocks (such as the "Submitted Work" table). We aim to make these areas less confusing by changing the way these blocks are being displayed.

These objectives ensure that students can efficiently see their grade details for a particular project, such as project title, team name, average peer review score, and peer review scores for each received review, and perform essential actions like show submission, show reviews, show author feedback, and show stats.

Through these design goals, we aim to deliver a more user-friendly solution that enhances the functionality and manageability of grade information for a particular project within the Expertiza system. The project leverages ReactJS and TypeScript to achieve these objectives, ensuring a modern, consistent, and flexible interface.

== Current UI Layout ==
The image below refers to the current UI layout. As shown in the image, the UI looks very cluttered and it is hard to find information in it. It has so many links and descriptions scattered around the page without any order. This makes it hard for a student to find information quickly.

[[File: loyda_layout1.png|900px]]

With the objectives that were mentioned in the previous section and the possible changes that are discussed next, we hope to alleviate the clutter and make the UI more visually appealing.

== Detail Description of Possible and Actual Changes ==

=== 1. Intuitive Display of statistics table: "Submitted Work", "Author Feedback", and "Teammate Review" ===
==== Rationale ====

The statistics table that encompasses the "Submitted Work", "Author Feedback", and "Teammate Review" tables lack contrast which makes them hard to understand and hard to read. Below is a snapshot of their locations in the current UI:

==== Existing Design ====

[[File: loyda_1.png|1200px]]

Notice how hard it is to visualize the tables and how hard it is to follow the information that they are providing. Our goal is to make these tables more visually appealing by introducing 2 possible changes. The changes are highlighted below.

==== Possible Changes ====

* ''' 1. Introduce shading '''
One of the possible approaches to fixing this issue is to Introduce color by filling each table with a different color.

[[File: loyda_2b.png|1200px]]

* ''' 2. Introducing outside borders: '''
Another possible solution to this issue is to add an outside border to each table to make it easier to read and understand. After adding table borders, the tables are expected to be displayed as follows:

[[File: loyda_2a.png|1200px]]

==== Actual Changes ====
The two proposed changes highlighted above were combined to create a new statistics table. Each of the 2 proposed changes introduces good mechanisms for achieving clarity and delivering a visually appealing statistics table to the user. Below is a snapshot of the new statistics table. Notice how easy it is to read and follow the details in the table as opposed to the original table.

[[File: loyda_2c.png|1200px]]

* ''' Updated Files '''

src/pages/ViewTeamGrades/Statistics.tsx [https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/Statisticstsx Statistics.tsx]

=== 2. Change the Location and Format of Team Member List ===
==== Rationale ====
The team member list is a type of information that should be readily available to the user. Instead, it is placed almost at the bottom of the page. Also, the font size is really small which makes it difficult to locate and read.

Furthermore, the "RoundSelector.tsx" file contains a function and its main purpose is to select the review round. However, its function is also to display the team member list. This violates the single responsibility principle. To fix this issue and allow the "RoundSelector" function to perform one function only, which in this case is to select the review round, it would be wise to move the code to gather and display the team information elsewhere — most likely inside the ReviewTable.tsx file.

==== Existing Design ====

Below is a screenshot of where the team member list is located in the UI. The team member list is outlined in red for visibility:

[[File: loyda_3a.png|1200px]]

Notice how small the font size is. Also, the team list should be located at the beginning of the page because it is part of the basic information that should be rendered first.

The current code to gather and display the team member list is located inside the "RoundSelector.tsx" file

[[File: loyda_3b.png|450px]]

Our goal is to change the location of the code snippets that are outlined in red to another location. This change will allow the RoundSelector function to only focus on selecting the review "Rounds"

==== Possible Changes ====

* ''' 1. Place the team list at the top of the page '''
The possible location of the team list will be in between the "Team" and "Average peer review score" information. The text format will also be changed. A larger text size will be introduced. These changes will allow the user to locate the list of the names of his/her team.

* ''' 2. Change the location of the code that gathers and displays the team list elsewhere '''
Changing the location of the code from the "RoundSelector.tsx" file to the "ReviewTable.tsx" file would allow us to fix the violation of the single responsibility principle in "RoundSelector.tsx".

==== Actual Changes ====
Below is a screenshot of the new location of the team member list outlined in red for visibility. Notice that the team member list is easy to locate as well as easy to read.

[[File: loyda_3c.png|1200px]]

Also, we changed the code to gather and display the team member list in the "ReviewTable.tsx" file. The new code snippets added are outlined in red for visibility

[[File: loyda_3d.png]]

The new "RoundSelector.tsx" contains the function that is ONLY focussed on selecting the review "Round" and thus obeys the single responsibility principle. A snapshot of the new function is provided below:

[[File: loyda_3e.png]]

* ''' Updated Files '''

src/pages/ViewTeamGrades/RoundSelector.tsx [https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/RoundSelelctor.tsx RoundSelector.tsx]
src/pages/ViewTeamGrades/ReviewTable.tsx [https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/ReviewTable.tsx ReviewTable.tsx]

=== 3.Export Options for Tables ===

'''Current Limitation:'''
Users cannot save or analyze table data outside the user interface. This makes it difficult to share or process data for further analysis.

'''Proposed Solution:'''
Add export buttons below each table to allow users to download the data as CSV, Excel, or PDF files. This will increase the flexibility and utility of the tables.

'''Implementation Details:'''
‎<br> 1. Export buttons for CSV and Excel are located below the table. ‎<br>
‎<br> 2. Utilizes the SheetJS (xlsx) library to generate exportable files. ‎<br>
‎<br> 3. File structure matches the table's visible data. ‎<br>

'''Supporting Code:'''
const exportTableData = (format: "csv" | "xlsx") => {
const tableData = initialData.map((row) => {
const rowData: Record<string, any> = {};
columns.forEach((col) => {
const accessor = col.id; // Use column `id` for keys
if (accessor) {
rowData[accessor] = row[accessor];
}
});
return rowData;
});

const worksheet = XLSX.utils.json_to_sheet(tableData);
const workbook = XLSX.utils.book_new();
XLSX.utils.book_append_sheet(workbook, worksheet, "TableData");

const fileType = format === "csv" ? "csv" : "xlsx";
XLSX.writeFile(workbook, `table_data.${fileType}`);
};

'''Export Buttons in the UI:'''
<div style={{ marginTop: "10px" }}>
<button
onClick={() => exportTableData("csv")}
className="btn btn-primary me-2"
>
Export to CSV
</button>
<button
onClick={() => exportTableData("xlsx")}
className="btn btn-primary"
>
Export to Excel
</button>
</div>

'''Testing:'''
it("renders export buttons", () => {
render(<Table data={mockData} columns={mockColumns} />);
expect(screen.getByText("Export to CSV")).toBeInTheDocument();
expect(screen.getByText("Export to Excel")).toBeInTheDocument();
});

=== 4.Improved Feedback Indicators ===

'''Current Limitation:'''
Users have no indication of when table data was last updated, leading to potential uncertainty about its accuracy.

'''Proposed Solution:'''
Add "Last Updated" timestamps or live refresh indicators for each table.

'''Implementation Details:'''
‎<br> 1. Include a "Last Updated: [Date/Time]" label below the table. ‎<br>
‎<br> 2. Update the timestamp dynamically whenever the data source is refreshed. ‎<br>
‎<br> 3. Use a subtle spinning loader icon to indicate data refreshing. ‎<br>

'''Supporting Code:'''
const [lastUpdated, setLastUpdated] = useState<Date | null>(null);

const refreshTableData = () => {
setLastUpdated(new Date());
};

=== 5.Extending toggle options ===

==== Rationale ====
While the heat map provides a great visual representation of the users feedback, with the addition of some 'toggles' we can better idea of the different values. Currently, there is only the option to toggle for the questions.

==== Existing Design ====

[[File: old_toggle_sc.png|1200px]]

In this current mode, there is only the option to toggle for the questions.

==== Actual Changes ====

[[File: simon_new_menu_opened.png|650px]]

In the updated version, since more toggle options were added, there is now a heat map option menu, that can be opened and closed. When open, there are 4 different checkboxes to check from that each provide their own way of helping the student better analyze their team grade.

When menu is closed:

[[File: simon_new_menu_closed.png|300px]]

==== Supporting Code ====

[[File: simon_supporting_closed.png|650px]]

Here is the supporting code for the 3 new toggle options, showToggle10WordComments, showToggle20WordComments, and showToggleCustomWordComment are all boolean values that if their state is set to true filter and count reviews based on the properties of their comments. When they're set to true, it will first ensure that the comments are defined as strings and not undefined (since a user can leave a review without providing a comment), it will then filter over the reviews array within a row and filter and return the total number of comments that meet the respective criteria.

* ''' Updated Files '''

src/pages/ViewTeamGrades/ReviewTable.tsx
src/pages/ViewTeamGrades/ReviewTableRow.tsx

=== 6.Refactoring Code ===
We will work on refactoring some of the code, for example, changing naming conventions along with making sure SOLID principles are being used.

==== Refactoring code 1 ====
Updated naming convention for a toggle option

Previous:unclear state variable name with no comment
<div class="clear"></div>
[[File: supporting_code5.png|600px]]

Refactored: Added a comment to explain what the state was as well as changing the variable name to be more direct.
[[File: supporting_code4.png|600px]]

== Frontend (React & TypeScript) ==
=== Files to be potentially modified ===
All files to be modified are located in the src/pages/ViewTeamGrades folder. The files that will potentially be modified are:

* src/pages/ViewTeamGrades/App.tsx
* src/pages/ViewTeamGrades/ReviewTable.tsx

== Use Case Diagram ==

The use case diagram for the "view-team-grades" page after clicking "Grades View" in Expertiza highlights various interactions with the UI. Here's a general outline of possible actors and use cases:

=== Actors: ===

* Student - Primarily interacts with the UI to view all the grading details for an assignment.

=== Use Cases: ===

* View detailed grade of a particular assignment - Including assignment name, team name, average score, etc.
* Show Submission - This link redirects the student to a new page where the student can see his/her submission details.
* Show Stats - This link redirects the student to a new page where the student can see grading statistics.
* Submitted Work - This table shows the average and range of submitted work grades.
**Show Reviews - This link located in the "Submitted Work" table redirects the student to the page that renders all the reviews that the student obtained from his/her peers.
* Author Feedback - This table shows the average and range of author feedback for the submitted work.
**Show Author Feedback - This link located in the "Author Feedback" table redirects the student to the page that renders the author feedback that the student obtained after writing a review.
* Teammate Review - This table shows the average and range of teammate reviews for the submitted work.
* Back - Link that enables the student to go back to the main page
*

[[File: yusufov_d2.png |750px|center]]

==Test Plan==
To validate the newly designed "View Submissions" page's functionality, usability, and performance while meeting the goals of clarity, consistency, flexibility, and intuitivenes.

=== Testing Scope ===
1. Component Validation
* Test individual React components like ReviewTable.tsx and Statistics.tsx.
2. API Integration
* Verify API calls using useAPI.ts to ensure seamless backend integration.
3. Dynamic Features
* Test real-time updates (e.g., "Last Updated" timestamps).

=== Test Cases: ===

{| class="wikitable"
! Test Case ID
! Test Description
! Expected Outcome
! Priority
! Status
|-
| TC001
| Verify assignment name display
| Assignment names appear accurately.
| High
| Pending
|-
| TC002
| Validate "Show Stats" link
| Redirects to accurate grading statistics page.
| Medium
| Pending
|-
| TC003
| Test pagination in tables
| Pagination works correctly for large datasets.
| High
| Pending
|-
| TC004
| Test table export functionality
| CSV and Excel files match table content accurately.
| High
| Pending
|-
| TC005
| Validate data rendering
| Tables display data using mock files like `dummyData.json`.
| High
| Pending
|-
| TC006
| Test error handling for missing data
| UI displays appropriate placeholders or messages for empty datasets.
| Low
| Pending
|-
| TC007
| Verify contributor details
| Names and user IDs are displayed accurately.
| Medium
| Pending
|-
| TC008
| Validate new thresholds for review length
| Dynamic thresholds for word/character counts update and display correctly.
| Medium
| Pending
|}

=== Testing Strategy ===

Unit Testing:
*Write tests for individual components like ReviewTable using Jest.
*Validate utility functions in utils.ts.

Integration Testing:
* Test the interaction between App.tsx and its child components.
* Validate API responses using axios_client.ts.

Performance Testing:
* Simulate exporting large datasets to assess system performance.
* Measure response times for table rendering with dummyData.json.

Accessibility Testing:
*Test keyboard navigation and WCAG 2.1 compliance.

== Actual Testing ==

=== Unit Testing for ReviewTable using Jest ===

*The ReviewTable component is validated using the Jest and React Testing Libraries. Running tests on the ReviewTable component allowed us to determine whether the component rendered without crashing by utilizing the render function provided by the React Testing Library. The ReviewTable component was wrapped inside a Router component imported from react-router-dom, to establish the necessary routing context for components that rely on React Router. This configuration allows the test to simulate the environment in which the component operates accurately. Overall, the test file serves as a quality assurance measure, verifying that the ReviewTable component can render successfully and integrate correctly with the React Router.

====[https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/ReviewTable.test.tsx ReviewTable.test.tsx]====
<pre>
import React from 'react';
import { render} from '@testing-library/react';
import { BrowserRouter as Router } from 'react-router-dom';
import ReviewTable from './ReviewTable';

describe('ReviewTable component', () => {
test('renders without crashing', () => {
render(
<Router> {/* Wrap your component with Router */}
<ReviewTable />
</Router>
);
});

});</pre>

==== Testing results ====
[[File: loyda_review_testing_results.png]]

=== Unit Testing for Statistics Component using Jest ===

*The Statistics component is validated using the Jest and React Testing Libraries. It employs the Jest and React Testing Library for testing purposes, along with the jest-dom library for custom assertions. The first test "renders the correct labels" ensures that the statistics table renders the correct labels. The second test "renders correct statistical information for each label" ensures that the statistical information is rendered correctly under each label. Lastly, their test "renders correct links" ensures that all the necessary links are rendered. Overall, these tests comprehensively evaluate the rendering and functionality of the Statistics component.

====[https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/Statistics.test.tsx Statistics.test.tsx]====
<pre>
import React from 'react';
import { render, screen } from '@testing-library/react';
import '@testing-library/jest-dom/extend-expect'; // Import jest-dom for custom assertions
import Statistics from './Statistics'; // Import the component to test

describe('Statistics', () => {
test('renders the correct labels', () => {
render(<Statistics average={''} />);
// Find the scores within the underlined spans
const element_1 = screen.getByRole('columnheader', { name: 'Submitted Work' });
const element_2 = screen.getByRole('columnheader', { name: 'Author Feedback' });
const element_3 = screen.getByRole('columnheader', { name: 'Teammate Review' });
const element_4 = screen.getByRole('columnheader', { name: 'Contributor' });

const element_5 = screen.getAllByText(/Average/i);
const element_6 = screen.getAllByText(/Range/i);
const element_7 = screen.getByRole('columnheader', { name: 'Final Score' });

// Assert that the elements are present
expect(element_1).toBeInTheDocument();
expect(element_2).toBeInTheDocument();
expect(element_3).toBeInTheDocument();
expect(element_4).toBeInTheDocument();
expect(element_5[0]).toBeInTheDocument();
expect(element_6[0]).toBeInTheDocument();
expect(element_7).toBeInTheDocument();

});

test('renders correct statistical information for each label', () => {
render(<Statistics average={''} />);
// Find the scores within the underlined spans
const element_1 = screen.getByRole('cell', { name: 'ssshah26 (Siddharth Shah)' });
const element_2 = screen.getByRole('cell', { name: 'Show Reviews (20)' });
const element_3 = screen.getByRole('cell', { name: '99.99% - 100%' });
const element_4 = screen.getByRole('cell', { name: '96.67 Show Author Feedback (10)' });
const element_5 = screen.getByRole('cell', { name: '87% - 100%' });
const element_6 = screen.getByRole('cell', { name: '4.64' });
const element_7 = screen.getByRole('cell', { name: '90% - 100%' });
const element_8 = screen.getByRole('cell', { name: '75% (in Finished)' });

// Assert that the elements are present
expect(element_1).toBeInTheDocument();
expect(element_2).toBeInTheDocument();
expect(element_3).toBeInTheDocument();
expect(element_4).toBeInTheDocument();
expect(element_5).toBeInTheDocument();
expect(element_6).toBeInTheDocument();
expect(element_7).toBeInTheDocument();
expect(element_8).toBeInTheDocument();
});

test('renders correct links', () => {
render(<Statistics average={''} />);
// Find the scores within the underlined spans
const element_1 = screen.getByRole('link', { name: 'show stats' });
const element_2 = screen.getByRole('link', { name: 'ssshah26' });
const element_3 = screen.getByRole('link', { name: 'Show Reviews' });
const element_4 = screen.getByRole('link', { name: 'Show Author Feedback' });

// Assert that the elements are present
expect(element_1).toBeInTheDocument();
expect(element_2).toBeInTheDocument();
expect(element_3).toBeInTheDocument();
expect(element_4).toBeInTheDocument();

});
});</pre>

==== Testing results ====

[[File: loyda_statistics_testing_results.png]]

== User Stories ==

* As a student I want to check all grading details of an assignment so that I can know my grade.
* As a student I want to see my submission of an assignment so that I can check what was submitted for a given assignment.
* As a student I want to see the names of my group team members so that I can know who I worked with.
* As a student I want to see the statistics of my grades so that I know my grade distribution.
* As a student I want to see if I got any late penalties so that I can know whether I got deducted points or not.
* As a student I want to have a way to view all the reviews that I got for the assignment so that I can read the viewer's responses.

== Conclusion ==
This design document introduces a step-by-step plan for updating the "view-team-grades" page on Expertiza, aiming for a user interface that is visually appealing and simple. Using React and TypeScript, the goal is to deliver a more user-friendly solution that enhances the functionality and manageability of grade information for a particular project within the Expertiza system. A clear and flexible UI design makes it not only simple to maintain but also flexible enough for future upgrades.

== List of Project Links ==
GitHub Repository: https://github.com/simong2/reimplementation-front-end

== Project Mentor ==

'''Nainisha Bhallamudi''' (nbhalla@ncsu.edu)

== Team Members ==

* '''Simon Getahun''' (unityid: sgetahu, github: https://github.com/simong2)
* '''Anusha Akkireddy''' (unityid: aakkire, github:https://github.com/akkireddyanusha)
* '''Loyda Yusufova''' (unityid: leyusufo, github: https://github.com/leyusufo)

File:Simon supporting closed.png

2024-12-04T08:09:42Z

Sgetahu:

CSC/ECE 517 Fall 2024 - E2492. UI for View submissions/assign grades (except heatgrid)

2024-12-04T07:59:37Z

Sgetahu: /* Actual Changes */

== Introduction ==
=== Project Overview ===

The "View Submissions" project focuses on developing a user interface (UI)
to maintain the score of reviewer submissions.

The Peer Review Summary Page UI is designed to display essential information for each review
assignment in a streamlined and user-friendly format. It provides a clear overview of contributors
and assigned reviewers, with interactive options such as "Unsubmit" and "Delete" to manage
submissions easily. Meta-reviewer options are intentionally excluded to keep the interface
focused solely on core reviewer functionalities. Additional sections are included to display
missing reviews, add grades and comments, and create an efficient and straightforward
interface for managing peer reviews.

== Design Goals ==
The Peer Review Summary Page in this project is designed to display essential information for each review assignment in a streamlined and user-friendly format. The main objectives focus on consistency and clearness, minimalism, flexibility, and intuitivism:

* '''Consistency and clearness: '''The Peer Review Summary Page UI interface should be consistent and clear.

* ''' Minimalism: '''The Peer Review Summary Page UI interface is very cluttered and there is so much going on in the page which makes it hard for a student to navigate through the information that is being displayed. We aim to avoid cluttering the interface with too much information.

* ''' Flexibility: '''The Peer Review Summary Page UI interface should be flexible and avoid clutter. We aim to deliver flexibility by rearranging information around the page to make it more presentable and easy to read.

* '''Intuitivism: '''The Peer Review Summary Page UI interface should be easy to use and understand. At the moment, the UI shows a few confusing and hard-to-understand areas/blocks (such as the "Submitted Work" table). We aim to make these areas less confusing by changing the way these blocks are being displayed.

These objectives ensure that students can efficiently see their grade details for a particular project, such as project title, team name, average peer review score, and peer review scores for each received review, and perform essential actions like show submission, show reviews, show author feedback, and show stats.

Through these design goals, we aim to deliver a more user-friendly solution that enhances the functionality and manageability of grade information for a particular project within the Expertiza system. The project leverages ReactJS and TypeScript to achieve these objectives, ensuring a modern, consistent, and flexible interface.

== Current UI Layout ==
The image below refers to the current UI layout. As shown in the image, the UI looks very cluttered and it is hard to find information in it. It has so many links and descriptions scattered around the page without any order. This makes it hard for a student to find information quickly.

[[File: loyda_layout1.png|900px]]

With the objectives that were mentioned in the previous section and the possible changes that are discussed next, we hope to alleviate the clutter and make the UI more visually appealing.

== Detail Description of Possible and Actual Changes ==

=== 1. Intuitive Display of statistics table: "Submitted Work", "Author Feedback", and "Teammate Review" ===
==== Rationale ====

The statistics table that encompasses the "Submitted Work", "Author Feedback", and "Teammate Review" tables lack contrast which makes them hard to understand and hard to read. Below is a snapshot of their locations in the current UI:

==== Existing Design ====

[[File: loyda_1.png|1200px]]

Notice how hard it is to visualize the tables and how hard it is to follow the information that they are providing. Our goal is to make these tables more visually appealing by introducing 2 possible changes. The changes are highlighted below.

==== Possible Changes ====

* ''' 1. Introduce shading '''
One of the possible approaches to fixing this issue is to Introduce color by filling each table with a different color.

[[File: loyda_2b.png|1200px]]

* ''' 2. Introducing outside borders: '''
Another possible solution to this issue is to add an outside border to each table to make it easier to read and understand. After adding table borders, the tables are expected to be displayed as follows:

[[File: loyda_2a.png|1200px]]

==== Actual Changes ====
The two proposed changes highlighted above were combined to create a new statistics table. Each of the 2 proposed changes introduces good mechanisms for achieving clarity and delivering a visually appealing statistics table to the user. Below is a snapshot of the new statistics table. Notice how easy it is to read and follow the details in the table as opposed to the original table.

[[File: loyda_2c.png|1200px]]

* ''' Updated Files '''

src/pages/ViewTeamGrades/Statistics.tsx [https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/Statisticstsx Statistics.tsx]

=== 2. Change the Location and Format of Team Member List ===
==== Rationale ====
The team member list is a type of information that should be readily available to the user. Instead, it is placed almost at the bottom of the page. Also, the font size is really small which makes it difficult to locate and read.

Furthermore, the "RoundSelector.tsx" file contains a function and its main purpose is to select the review round. However, its function is also to display the team member list. This violates the single responsibility principle. To fix this issue and allow the "RoundSelector" function to perform one function only, which in this case is to select the review round, it would be wise to move the code to gather and display the team information elsewhere — most likely inside the ReviewTable.tsx file.

==== Existing Design ====

Below is a screenshot of where the team member list is located in the UI. The team member list is outlined in red for visibility:

[[File: loyda_3a.png|1200px]]

Notice how small the font size is. Also, the team list should be located at the beginning of the page because it is part of the basic information that should be rendered first.

The current code to gather and display the team member list is located inside the "RoundSelector.tsx" file

[[File: loyda_3b.png|450px]]

Our goal is to change the location of the code snippets that are outlined in red to another location. This change will allow the RoundSelector function to only focus on selecting the review "Rounds"

==== Possible Changes ====

* ''' 1. Place the team list at the top of the page '''
The possible location of the team list will be in between the "Team" and "Average peer review score" information. The text format will also be changed. A larger text size will be introduced. These changes will allow the user to locate the list of the names of his/her team.

* ''' 2. Change the location of the code that gathers and displays the team list elsewhere '''
Changing the location of the code from the "RoundSelector.tsx" file to the "ReviewTable.tsx" file would allow us to fix the violation of the single responsibility principle in "RoundSelector.tsx".

==== Actual Changes ====
Below is a screenshot of the new location of the team member list outlined in red for visibility. Notice that the team member list is easy to locate as well as easy to read.

[[File: loyda_3c.png|1200px]]

Also, we changed the code to gather and display the team member list in the "ReviewTable.tsx" file. The new code snippets added are outlined in red for visibility

[[File: loyda_3d.png]]

The new "RoundSelector.tsx" contains the function that is ONLY focussed on selecting the review "Round" and thus obeys the single responsibility principle. A snapshot of the new function is provided below:

[[File: loyda_3e.png]]

* ''' Updated Files '''

src/pages/ViewTeamGrades/RoundSelector.tsx [https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/RoundSelelctor.tsx RoundSelector.tsx]
src/pages/ViewTeamGrades/ReviewTable.tsx [https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/ReviewTable.tsx ReviewTable.tsx]

=== 3.Export Options for Tables ===

'''Current Limitation:'''
Users cannot save or analyze table data outside the user interface. This makes it difficult to share or process data for further analysis.

'''Proposed Solution:'''
Add export buttons below each table to allow users to download the data as CSV, Excel, or PDF files. This will increase the flexibility and utility of the tables.

'''Implementation Details:'''
‎<br> 1. Export buttons for CSV and Excel are located below the table. ‎<br>
‎<br> 2. Utilizes the SheetJS (xlsx) library to generate exportable files. ‎<br>
‎<br> 3. File structure matches the table's visible data. ‎<br>

'''Supporting Code:'''
const exportTableData = (format: "csv" | "xlsx") => {
const tableData = initialData.map((row) => {
const rowData: Record<string, any> = {};
columns.forEach((col) => {
const accessor = col.id; // Use column `id` for keys
if (accessor) {
rowData[accessor] = row[accessor];
}
});
return rowData;
});

const worksheet = XLSX.utils.json_to_sheet(tableData);
const workbook = XLSX.utils.book_new();
XLSX.utils.book_append_sheet(workbook, worksheet, "TableData");

const fileType = format === "csv" ? "csv" : "xlsx";
XLSX.writeFile(workbook, `table_data.${fileType}`);
};

'''Export Buttons in the UI:'''
<div style={{ marginTop: "10px" }}>
<button
onClick={() => exportTableData("csv")}
className="btn btn-primary me-2"
>
Export to CSV
</button>
<button
onClick={() => exportTableData("xlsx")}
className="btn btn-primary"
>
Export to Excel
</button>
</div>

'''Testing:'''
it("renders export buttons", () => {
render(<Table data={mockData} columns={mockColumns} />);
expect(screen.getByText("Export to CSV")).toBeInTheDocument();
expect(screen.getByText("Export to Excel")).toBeInTheDocument();
});

=== 4.Improved Feedback Indicators ===

'''Current Limitation:'''
Users have no indication of when table data was last updated, leading to potential uncertainty about its accuracy.

'''Proposed Solution:'''
Add "Last Updated" timestamps or live refresh indicators for each table.

'''Implementation Details:'''
‎<br> 1. Include a "Last Updated: [Date/Time]" label below the table. ‎<br>
‎<br> 2. Update the timestamp dynamically whenever the data source is refreshed. ‎<br>
‎<br> 3. Use a subtle spinning loader icon to indicate data refreshing. ‎<br>

'''Supporting Code:'''
const [lastUpdated, setLastUpdated] = useState<Date | null>(null);

const refreshTableData = () => {
setLastUpdated(new Date());
};

=== 5.Extending toggle options ===

==== Rationale ====
While the heat map provides a great visual representation of the users feedback, with the addition of some 'toggles' we can better idea of the different values. Currently, there is only the option to toggle for the questions.

==== Existing Design ====

[[File: old_toggle_sc.png|1200px]]

In this current mode, there is only the option to toggle for the questions.

==== Actual Changes ====

[[File: simon_new_menu_opened.png|650px]]

In the updated version, since more toggle options were added, there is now a heat map option menu, that can be opened and closed. When open, there are 4 different checkboxes to check from that each provide their own way of helping the student better analyze their team grade.

When menu is closed:

[[File: simon_supporting_closed.png|250px]]

''' Supporting Code: '''

[[File: simon_supporting_closed.png|250px]]

Here is the supporting code for the 3 new toggle options, showToggle10WordComments, showToggle20WordComments, and showToggleCustomWordComment are all boolean values that if their state is set to true filter and count reviews based on the properties of their comments. When they're set to true, it will first ensure that the comments are defined as strings and not undefined (since a user can leave a review without providing a comment), it will then filter over the reviews array within a row and filter and return the total number of comments that meet the respective criteria.

* ''' Updated Files '''

src/pages/ViewTeamGrades/ReviewTable.tsx
src/pages/ViewTeamGrades/ReviewTableRow.tsx

=== 6.Refactoring Code ===
We will work on refactoring some of the code, for example, changing naming conventions along with making sure SOLID principles are being used.

==== Refactoring code 1 ====
Updated naming convention for a toggle option

Previous:unclear state variable name with no comment
<div class="clear"></div>
[[File: supporting_code5.png|600px]]

Refactored: Added a comment to explain what the state was as well as changing the variable name to be more direct.
[[File: supporting_code4.png|600px]]

== Frontend (React & TypeScript) ==
=== Files to be potentially modified ===
All files to be modified are located in the src/pages/ViewTeamGrades folder. The files that will potentially be modified are:

* src/pages/ViewTeamGrades/App.tsx
* src/pages/ViewTeamGrades/ReviewTable.tsx

== Use Case Diagram ==

The use case diagram for the "view-team-grades" page after clicking "Grades View" in Expertiza highlights various interactions with the UI. Here's a general outline of possible actors and use cases:

=== Actors: ===

* Student - Primarily interacts with the UI to view all the grading details for an assignment.

=== Use Cases: ===

* View detailed grade of a particular assignment - Including assignment name, team name, average score, etc.
* Show Submission - This link redirects the student to a new page where the student can see his/her submission details.
* Show Stats - This link redirects the student to a new page where the student can see grading statistics.
* Submitted Work - This table shows the average and range of submitted work grades.
**Show Reviews - This link located in the "Submitted Work" table redirects the student to the page that renders all the reviews that the student obtained from his/her peers.
* Author Feedback - This table shows the average and range of author feedback for the submitted work.
**Show Author Feedback - This link located in the "Author Feedback" table redirects the student to the page that renders the author feedback that the student obtained after writing a review.
* Teammate Review - This table shows the average and range of teammate reviews for the submitted work.
* Back - Link that enables the student to go back to the main page
*

[[File: yusufov_d2.png |750px|center]]

==Test Plan==
To validate the newly designed "View Submissions" page's functionality, usability, and performance while meeting the goals of clarity, consistency, flexibility, and intuitivenes.

=== Testing Scope ===
1. Component Validation
* Test individual React components like ReviewTable.tsx and Statistics.tsx.
2. API Integration
* Verify API calls using useAPI.ts to ensure seamless backend integration.
3. Dynamic Features
* Test real-time updates (e.g., "Last Updated" timestamps).

=== Test Cases: ===

{| class="wikitable"
! Test Case ID
! Test Description
! Expected Outcome
! Priority
! Status
|-
| TC001
| Verify assignment name display
| Assignment names appear accurately.
| High
| Pending
|-
| TC002
| Validate "Show Stats" link
| Redirects to accurate grading statistics page.
| Medium
| Pending
|-
| TC003
| Test pagination in tables
| Pagination works correctly for large datasets.
| High
| Pending
|-
| TC004
| Test table export functionality
| CSV and Excel files match table content accurately.
| High
| Pending
|-
| TC005
| Validate data rendering
| Tables display data using mock files like `dummyData.json`.
| High
| Pending
|-
| TC006
| Test error handling for missing data
| UI displays appropriate placeholders or messages for empty datasets.
| Low
| Pending
|-
| TC007
| Verify contributor details
| Names and user IDs are displayed accurately.
| Medium
| Pending
|-
| TC008
| Validate new thresholds for review length
| Dynamic thresholds for word/character counts update and display correctly.
| Medium
| Pending
|}

=== Testing Strategy ===

Unit Testing:
*Write tests for individual components like ReviewTable using Jest.
*Validate utility functions in utils.ts.

Integration Testing:
* Test the interaction between App.tsx and its child components.
* Validate API responses using axios_client.ts.

Performance Testing:
* Simulate exporting large datasets to assess system performance.
* Measure response times for table rendering with dummyData.json.

Accessibility Testing:
*Test keyboard navigation and WCAG 2.1 compliance.

== Actual Testing ==

=== Unit Testing for ReviewTable using Jest ===

*The ReviewTable component is validated using the Jest and React Testing Libraries. Running tests on the ReviewTable component allowed us to determine whether the component rendered without crashing by utilizing the render function provided by the React Testing Library. The ReviewTable component was wrapped inside a Router component imported from react-router-dom, to establish the necessary routing context for components that rely on React Router. This configuration allows the test to simulate the environment in which the component operates accurately. Overall, the test file serves as a quality assurance measure, verifying that the ReviewTable component can render successfully and integrate correctly with the React Router.

====[https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/ReviewTable.test.tsx ReviewTable.test.tsx]====
<pre>
import React from 'react';
import { render} from '@testing-library/react';
import { BrowserRouter as Router } from 'react-router-dom';
import ReviewTable from './ReviewTable';

describe('ReviewTable component', () => {
test('renders without crashing', () => {
render(
<Router> {/* Wrap your component with Router */}
<ReviewTable />
</Router>
);
});

});</pre>

==== Testing results ====
[[File: loyda_review_testing_results.png]]

=== Unit Testing for Statistics Component using Jest ===

*The Statistics component is validated using the Jest and React Testing Libraries. It employs the Jest and React Testing Library for testing purposes, along with the jest-dom library for custom assertions. The first test "renders the correct labels" ensures that the statistics table renders the correct labels. The second test "renders correct statistical information for each label" ensures that the statistical information is rendered correctly under each label. Lastly, their test "renders correct links" ensures that all the necessary links are rendered. Overall, these tests comprehensively evaluate the rendering and functionality of the Statistics component.

====[https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/Statistics.test.tsx Statistics.test.tsx]====
<pre>
import React from 'react';
import { render, screen } from '@testing-library/react';
import '@testing-library/jest-dom/extend-expect'; // Import jest-dom for custom assertions
import Statistics from './Statistics'; // Import the component to test

describe('Statistics', () => {
test('renders the correct labels', () => {
render(<Statistics average={''} />);
// Find the scores within the underlined spans
const element_1 = screen.getByRole('columnheader', { name: 'Submitted Work' });
const element_2 = screen.getByRole('columnheader', { name: 'Author Feedback' });
const element_3 = screen.getByRole('columnheader', { name: 'Teammate Review' });
const element_4 = screen.getByRole('columnheader', { name: 'Contributor' });

const element_5 = screen.getAllByText(/Average/i);
const element_6 = screen.getAllByText(/Range/i);
const element_7 = screen.getByRole('columnheader', { name: 'Final Score' });

// Assert that the elements are present
expect(element_1).toBeInTheDocument();
expect(element_2).toBeInTheDocument();
expect(element_3).toBeInTheDocument();
expect(element_4).toBeInTheDocument();
expect(element_5[0]).toBeInTheDocument();
expect(element_6[0]).toBeInTheDocument();
expect(element_7).toBeInTheDocument();

});

test('renders correct statistical information for each label', () => {
render(<Statistics average={''} />);
// Find the scores within the underlined spans
const element_1 = screen.getByRole('cell', { name: 'ssshah26 (Siddharth Shah)' });
const element_2 = screen.getByRole('cell', { name: 'Show Reviews (20)' });
const element_3 = screen.getByRole('cell', { name: '99.99% - 100%' });
const element_4 = screen.getByRole('cell', { name: '96.67 Show Author Feedback (10)' });
const element_5 = screen.getByRole('cell', { name: '87% - 100%' });
const element_6 = screen.getByRole('cell', { name: '4.64' });
const element_7 = screen.getByRole('cell', { name: '90% - 100%' });
const element_8 = screen.getByRole('cell', { name: '75% (in Finished)' });

// Assert that the elements are present
expect(element_1).toBeInTheDocument();
expect(element_2).toBeInTheDocument();
expect(element_3).toBeInTheDocument();
expect(element_4).toBeInTheDocument();
expect(element_5).toBeInTheDocument();
expect(element_6).toBeInTheDocument();
expect(element_7).toBeInTheDocument();
expect(element_8).toBeInTheDocument();
});

test('renders correct links', () => {
render(<Statistics average={''} />);
// Find the scores within the underlined spans
const element_1 = screen.getByRole('link', { name: 'show stats' });
const element_2 = screen.getByRole('link', { name: 'ssshah26' });
const element_3 = screen.getByRole('link', { name: 'Show Reviews' });
const element_4 = screen.getByRole('link', { name: 'Show Author Feedback' });

// Assert that the elements are present
expect(element_1).toBeInTheDocument();
expect(element_2).toBeInTheDocument();
expect(element_3).toBeInTheDocument();
expect(element_4).toBeInTheDocument();

});
});</pre>

==== Testing results ====

[[File: loyda_statistics_testing_results.png]]

== User Stories ==

* As a student I want to check all grading details of an assignment so that I can know my grade.
* As a student I want to see my submission of an assignment so that I can check what was submitted for a given assignment.
* As a student I want to see the names of my group team members so that I can know who I worked with.
* As a student I want to see the statistics of my grades so that I know my grade distribution.
* As a student I want to see if I got any late penalties so that I can know whether I got deducted points or not.
* As a student I want to have a way to view all the reviews that I got for the assignment so that I can read the viewer's responses.

== Conclusion ==
This design document introduces a step-by-step plan for updating the "view-team-grades" page on Expertiza, aiming for a user interface that is visually appealing and simple. Using React and TypeScript, the goal is to deliver a more user-friendly solution that enhances the functionality and manageability of grade information for a particular project within the Expertiza system. A clear and flexible UI design makes it not only simple to maintain but also flexible enough for future upgrades.

== List of Project Links ==
GitHub Repository: https://github.com/simong2/reimplementation-front-end

== Project Mentor ==

'''Nainisha Bhallamudi''' (nbhalla@ncsu.edu)

== Team Members ==

* '''Simon Getahun''' (unityid: sgetahu, github: https://github.com/simong2)
* '''Anusha Akkireddy''' (unityid: aakkire, github:https://github.com/akkireddyanusha)
* '''Loyda Yusufova''' (unityid: leyusufo, github: https://github.com/leyusufo)

CSC/ECE 517 Fall 2024 - E2492. UI for View submissions/assign grades (except heatgrid)

2024-12-04T07:57:28Z

Sgetahu: /* Actual Changes */

== Introduction ==
=== Project Overview ===

The "View Submissions" project focuses on developing a user interface (UI)
to maintain the score of reviewer submissions.

The Peer Review Summary Page UI is designed to display essential information for each review
assignment in a streamlined and user-friendly format. It provides a clear overview of contributors
and assigned reviewers, with interactive options such as "Unsubmit" and "Delete" to manage
submissions easily. Meta-reviewer options are intentionally excluded to keep the interface
focused solely on core reviewer functionalities. Additional sections are included to display
missing reviews, add grades and comments, and create an efficient and straightforward
interface for managing peer reviews.

== Design Goals ==
The Peer Review Summary Page in this project is designed to display essential information for each review assignment in a streamlined and user-friendly format. The main objectives focus on consistency and clearness, minimalism, flexibility, and intuitivism:

* '''Consistency and clearness: '''The Peer Review Summary Page UI interface should be consistent and clear.

* ''' Minimalism: '''The Peer Review Summary Page UI interface is very cluttered and there is so much going on in the page which makes it hard for a student to navigate through the information that is being displayed. We aim to avoid cluttering the interface with too much information.

* ''' Flexibility: '''The Peer Review Summary Page UI interface should be flexible and avoid clutter. We aim to deliver flexibility by rearranging information around the page to make it more presentable and easy to read.

* '''Intuitivism: '''The Peer Review Summary Page UI interface should be easy to use and understand. At the moment, the UI shows a few confusing and hard-to-understand areas/blocks (such as the "Submitted Work" table). We aim to make these areas less confusing by changing the way these blocks are being displayed.

These objectives ensure that students can efficiently see their grade details for a particular project, such as project title, team name, average peer review score, and peer review scores for each received review, and perform essential actions like show submission, show reviews, show author feedback, and show stats.

Through these design goals, we aim to deliver a more user-friendly solution that enhances the functionality and manageability of grade information for a particular project within the Expertiza system. The project leverages ReactJS and TypeScript to achieve these objectives, ensuring a modern, consistent, and flexible interface.

== Current UI Layout ==
The image below refers to the current UI layout. As shown in the image, the UI looks very cluttered and it is hard to find information in it. It has so many links and descriptions scattered around the page without any order. This makes it hard for a student to find information quickly.

[[File: loyda_layout1.png|900px]]

With the objectives that were mentioned in the previous section and the possible changes that are discussed next, we hope to alleviate the clutter and make the UI more visually appealing.

== Detail Description of Possible and Actual Changes ==

=== 1. Intuitive Display of statistics table: "Submitted Work", "Author Feedback", and "Teammate Review" ===
==== Rationale ====

The statistics table that encompasses the "Submitted Work", "Author Feedback", and "Teammate Review" tables lack contrast which makes them hard to understand and hard to read. Below is a snapshot of their locations in the current UI:

==== Existing Design ====

[[File: loyda_1.png|1200px]]

Notice how hard it is to visualize the tables and how hard it is to follow the information that they are providing. Our goal is to make these tables more visually appealing by introducing 2 possible changes. The changes are highlighted below.

==== Possible Changes ====

* ''' 1. Introduce shading '''
One of the possible approaches to fixing this issue is to Introduce color by filling each table with a different color.

[[File: loyda_2b.png|1200px]]

* ''' 2. Introducing outside borders: '''
Another possible solution to this issue is to add an outside border to each table to make it easier to read and understand. After adding table borders, the tables are expected to be displayed as follows:

[[File: loyda_2a.png|1200px]]

==== Actual Changes ====
The two proposed changes highlighted above were combined to create a new statistics table. Each of the 2 proposed changes introduces good mechanisms for achieving clarity and delivering a visually appealing statistics table to the user. Below is a snapshot of the new statistics table. Notice how easy it is to read and follow the details in the table as opposed to the original table.

[[File: loyda_2c.png|1200px]]

* ''' Updated Files '''

src/pages/ViewTeamGrades/Statistics.tsx [https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/Statisticstsx Statistics.tsx]

=== 2. Change the Location and Format of Team Member List ===
==== Rationale ====
The team member list is a type of information that should be readily available to the user. Instead, it is placed almost at the bottom of the page. Also, the font size is really small which makes it difficult to locate and read.

Furthermore, the "RoundSelector.tsx" file contains a function and its main purpose is to select the review round. However, its function is also to display the team member list. This violates the single responsibility principle. To fix this issue and allow the "RoundSelector" function to perform one function only, which in this case is to select the review round, it would be wise to move the code to gather and display the team information elsewhere — most likely inside the ReviewTable.tsx file.

==== Existing Design ====

Below is a screenshot of where the team member list is located in the UI. The team member list is outlined in red for visibility:

[[File: loyda_3a.png|1200px]]

Notice how small the font size is. Also, the team list should be located at the beginning of the page because it is part of the basic information that should be rendered first.

The current code to gather and display the team member list is located inside the "RoundSelector.tsx" file

[[File: loyda_3b.png|450px]]

Our goal is to change the location of the code snippets that are outlined in red to another location. This change will allow the RoundSelector function to only focus on selecting the review "Rounds"

==== Possible Changes ====

* ''' 1. Place the team list at the top of the page '''
The possible location of the team list will be in between the "Team" and "Average peer review score" information. The text format will also be changed. A larger text size will be introduced. These changes will allow the user to locate the list of the names of his/her team.

* ''' 2. Change the location of the code that gathers and displays the team list elsewhere '''
Changing the location of the code from the "RoundSelector.tsx" file to the "ReviewTable.tsx" file would allow us to fix the violation of the single responsibility principle in "RoundSelector.tsx".

==== Actual Changes ====
Below is a screenshot of the new location of the team member list outlined in red for visibility. Notice that the team member list is easy to locate as well as easy to read.

[[File: loyda_3c.png|1200px]]

Also, we changed the code to gather and display the team member list in the "ReviewTable.tsx" file. The new code snippets added are outlined in red for visibility

[[File: loyda_3d.png]]

The new "RoundSelector.tsx" contains the function that is ONLY focussed on selecting the review "Round" and thus obeys the single responsibility principle. A snapshot of the new function is provided below:

[[File: loyda_3e.png]]

* ''' Updated Files '''

src/pages/ViewTeamGrades/RoundSelector.tsx [https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/RoundSelelctor.tsx RoundSelector.tsx]
src/pages/ViewTeamGrades/ReviewTable.tsx [https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/ReviewTable.tsx ReviewTable.tsx]

=== 3.Export Options for Tables ===

'''Current Limitation:'''
Users cannot save or analyze table data outside the user interface. This makes it difficult to share or process data for further analysis.

'''Proposed Solution:'''
Add export buttons below each table to allow users to download the data as CSV, Excel, or PDF files. This will increase the flexibility and utility of the tables.

'''Implementation Details:'''
‎<br> 1. Export buttons for CSV and Excel are located below the table. ‎<br>
‎<br> 2. Utilizes the SheetJS (xlsx) library to generate exportable files. ‎<br>
‎<br> 3. File structure matches the table's visible data. ‎<br>

'''Supporting Code:'''
const exportTableData = (format: "csv" | "xlsx") => {
const tableData = initialData.map((row) => {
const rowData: Record<string, any> = {};
columns.forEach((col) => {
const accessor = col.id; // Use column `id` for keys
if (accessor) {
rowData[accessor] = row[accessor];
}
});
return rowData;
});

const worksheet = XLSX.utils.json_to_sheet(tableData);
const workbook = XLSX.utils.book_new();
XLSX.utils.book_append_sheet(workbook, worksheet, "TableData");

const fileType = format === "csv" ? "csv" : "xlsx";
XLSX.writeFile(workbook, `table_data.${fileType}`);
};

'''Export Buttons in the UI:'''
<div style={{ marginTop: "10px" }}>
<button
onClick={() => exportTableData("csv")}
className="btn btn-primary me-2"
>
Export to CSV
</button>
<button
onClick={() => exportTableData("xlsx")}
className="btn btn-primary"
>
Export to Excel
</button>
</div>

'''Testing:'''
it("renders export buttons", () => {
render(<Table data={mockData} columns={mockColumns} />);
expect(screen.getByText("Export to CSV")).toBeInTheDocument();
expect(screen.getByText("Export to Excel")).toBeInTheDocument();
});

=== 4.Improved Feedback Indicators ===

'''Current Limitation:'''
Users have no indication of when table data was last updated, leading to potential uncertainty about its accuracy.

'''Proposed Solution:'''
Add "Last Updated" timestamps or live refresh indicators for each table.

'''Implementation Details:'''
‎<br> 1. Include a "Last Updated: [Date/Time]" label below the table. ‎<br>
‎<br> 2. Update the timestamp dynamically whenever the data source is refreshed. ‎<br>
‎<br> 3. Use a subtle spinning loader icon to indicate data refreshing. ‎<br>

'''Supporting Code:'''
const [lastUpdated, setLastUpdated] = useState<Date | null>(null);

const refreshTableData = () => {
setLastUpdated(new Date());
};

=== 5.Extending toggle options ===

==== Rationale ====
While the heat map provides a great visual representation of the users feedback, with the addition of some 'toggles' we can better idea of the different values. Currently, there is only the option to toggle for the questions.

==== Existing Design ====

[[File: old_toggle_sc.png|1200px]]

In this current mode, there is only the option to toggle for the questions.

==== Actual Changes ====

[[File: simon_new_menu_opened.png|650px]]

In the updated version, since more toggle options were added, there is now a heat map option menu, that can be opened and closed. When open, there are 4 different checkboxes to check from that each provide their own way of helping the student better analyze their team grade.

When menu is closed:
[[File: simon_supporting_closed.png|250px]]

'''Supporting Code:'''

[[File: simon_supporting_code1.png|650px]]

Here is the supporting code for the 3 new toggle options, showToggle10WordComments, showToggle20WordComments, and showToggleCustomWordComment are all boolean values that if their state is set to true filter and count reviews based on the properties of their comments. When they're set to true, it will first ensure that the comments are defined as strings and not undefined (since a user can leave a review without providing a comment), it will then filter over the reviews array within a row and filter and return the total number of comments that meet the respective criteria.

* ''' Updated Files '''

src/pages/ViewTeamGrades/ReviewTable.tsx
src/pages/ViewTeamGrades/ReviewTableRow.tsx

=== 6.Refactoring Code ===
We will work on refactoring some of the code, for example, changing naming conventions along with making sure SOLID principles are being used.

==== Refactoring code 1 ====
Updated naming convention for a toggle option

Previous:unclear state variable name with no comment
<div class="clear"></div>
[[File: supporting_code5.png|600px]]

Refactored: Added a comment to explain what the state was as well as changing the variable name to be more direct.
[[File: supporting_code4.png|600px]]

== Frontend (React & TypeScript) ==
=== Files to be potentially modified ===
All files to be modified are located in the src/pages/ViewTeamGrades folder. The files that will potentially be modified are:

* src/pages/ViewTeamGrades/App.tsx
* src/pages/ViewTeamGrades/ReviewTable.tsx

== Use Case Diagram ==

The use case diagram for the "view-team-grades" page after clicking "Grades View" in Expertiza highlights various interactions with the UI. Here's a general outline of possible actors and use cases:

=== Actors: ===

* Student - Primarily interacts with the UI to view all the grading details for an assignment.

=== Use Cases: ===

* View detailed grade of a particular assignment - Including assignment name, team name, average score, etc.
* Show Submission - This link redirects the student to a new page where the student can see his/her submission details.
* Show Stats - This link redirects the student to a new page where the student can see grading statistics.
* Submitted Work - This table shows the average and range of submitted work grades.
**Show Reviews - This link located in the "Submitted Work" table redirects the student to the page that renders all the reviews that the student obtained from his/her peers.
* Author Feedback - This table shows the average and range of author feedback for the submitted work.
**Show Author Feedback - This link located in the "Author Feedback" table redirects the student to the page that renders the author feedback that the student obtained after writing a review.
* Teammate Review - This table shows the average and range of teammate reviews for the submitted work.
* Back - Link that enables the student to go back to the main page
*

[[File: yusufov_d2.png |750px|center]]

==Test Plan==
To validate the newly designed "View Submissions" page's functionality, usability, and performance while meeting the goals of clarity, consistency, flexibility, and intuitivenes.

=== Testing Scope ===
1. Component Validation
* Test individual React components like ReviewTable.tsx and Statistics.tsx.
2. API Integration
* Verify API calls using useAPI.ts to ensure seamless backend integration.
3. Dynamic Features
* Test real-time updates (e.g., "Last Updated" timestamps).

=== Test Cases: ===

{| class="wikitable"
! Test Case ID
! Test Description
! Expected Outcome
! Priority
! Status
|-
| TC001
| Verify assignment name display
| Assignment names appear accurately.
| High
| Pending
|-
| TC002
| Validate "Show Stats" link
| Redirects to accurate grading statistics page.
| Medium
| Pending
|-
| TC003
| Test pagination in tables
| Pagination works correctly for large datasets.
| High
| Pending
|-
| TC004
| Test table export functionality
| CSV and Excel files match table content accurately.
| High
| Pending
|-
| TC005
| Validate data rendering
| Tables display data using mock files like `dummyData.json`.
| High
| Pending
|-
| TC006
| Test error handling for missing data
| UI displays appropriate placeholders or messages for empty datasets.
| Low
| Pending
|-
| TC007
| Verify contributor details
| Names and user IDs are displayed accurately.
| Medium
| Pending
|-
| TC008
| Validate new thresholds for review length
| Dynamic thresholds for word/character counts update and display correctly.
| Medium
| Pending
|}

=== Testing Strategy ===

Unit Testing:
*Write tests for individual components like ReviewTable using Jest.
*Validate utility functions in utils.ts.

Integration Testing:
* Test the interaction between App.tsx and its child components.
* Validate API responses using axios_client.ts.

Performance Testing:
* Simulate exporting large datasets to assess system performance.
* Measure response times for table rendering with dummyData.json.

Accessibility Testing:
*Test keyboard navigation and WCAG 2.1 compliance.

== Actual Testing ==

=== Unit Testing for ReviewTable using Jest ===

*The ReviewTable component is validated using the Jest and React Testing Libraries. Running tests on the ReviewTable component allowed us to determine whether the component rendered without crashing by utilizing the render function provided by the React Testing Library. The ReviewTable component was wrapped inside a Router component imported from react-router-dom, to establish the necessary routing context for components that rely on React Router. This configuration allows the test to simulate the environment in which the component operates accurately. Overall, the test file serves as a quality assurance measure, verifying that the ReviewTable component can render successfully and integrate correctly with the React Router.

====[https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/ReviewTable.test.tsx ReviewTable.test.tsx]====
<pre>
import React from 'react';
import { render} from '@testing-library/react';
import { BrowserRouter as Router } from 'react-router-dom';
import ReviewTable from './ReviewTable';

describe('ReviewTable component', () => {
test('renders without crashing', () => {
render(
<Router> {/* Wrap your component with Router */}
<ReviewTable />
</Router>
);
});

});</pre>

==== Testing results ====
[[File: loyda_review_testing_results.png]]

=== Unit Testing for Statistics Component using Jest ===

*The Statistics component is validated using the Jest and React Testing Libraries. It employs the Jest and React Testing Library for testing purposes, along with the jest-dom library for custom assertions. The first test "renders the correct labels" ensures that the statistics table renders the correct labels. The second test "renders correct statistical information for each label" ensures that the statistical information is rendered correctly under each label. Lastly, their test "renders correct links" ensures that all the necessary links are rendered. Overall, these tests comprehensively evaluate the rendering and functionality of the Statistics component.

====[https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/Statistics.test.tsx Statistics.test.tsx]====
<pre>
import React from 'react';
import { render, screen } from '@testing-library/react';
import '@testing-library/jest-dom/extend-expect'; // Import jest-dom for custom assertions
import Statistics from './Statistics'; // Import the component to test

describe('Statistics', () => {
test('renders the correct labels', () => {
render(<Statistics average={''} />);
// Find the scores within the underlined spans
const element_1 = screen.getByRole('columnheader', { name: 'Submitted Work' });
const element_2 = screen.getByRole('columnheader', { name: 'Author Feedback' });
const element_3 = screen.getByRole('columnheader', { name: 'Teammate Review' });
const element_4 = screen.getByRole('columnheader', { name: 'Contributor' });

const element_5 = screen.getAllByText(/Average/i);
const element_6 = screen.getAllByText(/Range/i);
const element_7 = screen.getByRole('columnheader', { name: 'Final Score' });

// Assert that the elements are present
expect(element_1).toBeInTheDocument();
expect(element_2).toBeInTheDocument();
expect(element_3).toBeInTheDocument();
expect(element_4).toBeInTheDocument();
expect(element_5[0]).toBeInTheDocument();
expect(element_6[0]).toBeInTheDocument();
expect(element_7).toBeInTheDocument();

});

test('renders correct statistical information for each label', () => {
render(<Statistics average={''} />);
// Find the scores within the underlined spans
const element_1 = screen.getByRole('cell', { name: 'ssshah26 (Siddharth Shah)' });
const element_2 = screen.getByRole('cell', { name: 'Show Reviews (20)' });
const element_3 = screen.getByRole('cell', { name: '99.99% - 100%' });
const element_4 = screen.getByRole('cell', { name: '96.67 Show Author Feedback (10)' });
const element_5 = screen.getByRole('cell', { name: '87% - 100%' });
const element_6 = screen.getByRole('cell', { name: '4.64' });
const element_7 = screen.getByRole('cell', { name: '90% - 100%' });
const element_8 = screen.getByRole('cell', { name: '75% (in Finished)' });

// Assert that the elements are present
expect(element_1).toBeInTheDocument();
expect(element_2).toBeInTheDocument();
expect(element_3).toBeInTheDocument();
expect(element_4).toBeInTheDocument();
expect(element_5).toBeInTheDocument();
expect(element_6).toBeInTheDocument();
expect(element_7).toBeInTheDocument();
expect(element_8).toBeInTheDocument();
});

test('renders correct links', () => {
render(<Statistics average={''} />);
// Find the scores within the underlined spans
const element_1 = screen.getByRole('link', { name: 'show stats' });
const element_2 = screen.getByRole('link', { name: 'ssshah26' });
const element_3 = screen.getByRole('link', { name: 'Show Reviews' });
const element_4 = screen.getByRole('link', { name: 'Show Author Feedback' });

// Assert that the elements are present
expect(element_1).toBeInTheDocument();
expect(element_2).toBeInTheDocument();
expect(element_3).toBeInTheDocument();
expect(element_4).toBeInTheDocument();

});
});</pre>

==== Testing results ====

[[File: loyda_statistics_testing_results.png]]

== User Stories ==

* As a student I want to check all grading details of an assignment so that I can know my grade.
* As a student I want to see my submission of an assignment so that I can check what was submitted for a given assignment.
* As a student I want to see the names of my group team members so that I can know who I worked with.
* As a student I want to see the statistics of my grades so that I know my grade distribution.
* As a student I want to see if I got any late penalties so that I can know whether I got deducted points or not.
* As a student I want to have a way to view all the reviews that I got for the assignment so that I can read the viewer's responses.

== Conclusion ==
This design document introduces a step-by-step plan for updating the "view-team-grades" page on Expertiza, aiming for a user interface that is visually appealing and simple. Using React and TypeScript, the goal is to deliver a more user-friendly solution that enhances the functionality and manageability of grade information for a particular project within the Expertiza system. A clear and flexible UI design makes it not only simple to maintain but also flexible enough for future upgrades.

== List of Project Links ==
GitHub Repository: https://github.com/simong2/reimplementation-front-end

== Project Mentor ==

'''Nainisha Bhallamudi''' (nbhalla@ncsu.edu)

== Team Members ==

* '''Simon Getahun''' (unityid: sgetahu, github: https://github.com/simong2)
* '''Anusha Akkireddy''' (unityid: aakkire, github:https://github.com/akkireddyanusha)
* '''Loyda Yusufova''' (unityid: leyusufo, github: https://github.com/leyusufo)

CSC/ECE 517 Fall 2024 - E2492. UI for View submissions/assign grades (except heatgrid)

2024-12-04T07:56:43Z

Sgetahu: /* Detail Description of Possible and Actual Changes */

== Introduction ==
=== Project Overview ===

The "View Submissions" project focuses on developing a user interface (UI)
to maintain the score of reviewer submissions.

The Peer Review Summary Page UI is designed to display essential information for each review
assignment in a streamlined and user-friendly format. It provides a clear overview of contributors
and assigned reviewers, with interactive options such as "Unsubmit" and "Delete" to manage
submissions easily. Meta-reviewer options are intentionally excluded to keep the interface
focused solely on core reviewer functionalities. Additional sections are included to display
missing reviews, add grades and comments, and create an efficient and straightforward
interface for managing peer reviews.

== Design Goals ==
The Peer Review Summary Page in this project is designed to display essential information for each review assignment in a streamlined and user-friendly format. The main objectives focus on consistency and clearness, minimalism, flexibility, and intuitivism:

* '''Consistency and clearness: '''The Peer Review Summary Page UI interface should be consistent and clear.

* ''' Minimalism: '''The Peer Review Summary Page UI interface is very cluttered and there is so much going on in the page which makes it hard for a student to navigate through the information that is being displayed. We aim to avoid cluttering the interface with too much information.

* ''' Flexibility: '''The Peer Review Summary Page UI interface should be flexible and avoid clutter. We aim to deliver flexibility by rearranging information around the page to make it more presentable and easy to read.

* '''Intuitivism: '''The Peer Review Summary Page UI interface should be easy to use and understand. At the moment, the UI shows a few confusing and hard-to-understand areas/blocks (such as the "Submitted Work" table). We aim to make these areas less confusing by changing the way these blocks are being displayed.

These objectives ensure that students can efficiently see their grade details for a particular project, such as project title, team name, average peer review score, and peer review scores for each received review, and perform essential actions like show submission, show reviews, show author feedback, and show stats.

Through these design goals, we aim to deliver a more user-friendly solution that enhances the functionality and manageability of grade information for a particular project within the Expertiza system. The project leverages ReactJS and TypeScript to achieve these objectives, ensuring a modern, consistent, and flexible interface.

== Current UI Layout ==
The image below refers to the current UI layout. As shown in the image, the UI looks very cluttered and it is hard to find information in it. It has so many links and descriptions scattered around the page without any order. This makes it hard for a student to find information quickly.

[[File: loyda_layout1.png|900px]]

With the objectives that were mentioned in the previous section and the possible changes that are discussed next, we hope to alleviate the clutter and make the UI more visually appealing.

== Detail Description of Possible and Actual Changes ==

=== 1. Intuitive Display of statistics table: "Submitted Work", "Author Feedback", and "Teammate Review" ===
==== Rationale ====

The statistics table that encompasses the "Submitted Work", "Author Feedback", and "Teammate Review" tables lack contrast which makes them hard to understand and hard to read. Below is a snapshot of their locations in the current UI:

==== Existing Design ====

[[File: loyda_1.png|1200px]]

Notice how hard it is to visualize the tables and how hard it is to follow the information that they are providing. Our goal is to make these tables more visually appealing by introducing 2 possible changes. The changes are highlighted below.

==== Possible Changes ====

* ''' 1. Introduce shading '''
One of the possible approaches to fixing this issue is to Introduce color by filling each table with a different color.

[[File: loyda_2b.png|1200px]]

* ''' 2. Introducing outside borders: '''
Another possible solution to this issue is to add an outside border to each table to make it easier to read and understand. After adding table borders, the tables are expected to be displayed as follows:

[[File: loyda_2a.png|1200px]]

==== Actual Changes ====
The two proposed changes highlighted above were combined to create a new statistics table. Each of the 2 proposed changes introduces good mechanisms for achieving clarity and delivering a visually appealing statistics table to the user. Below is a snapshot of the new statistics table. Notice how easy it is to read and follow the details in the table as opposed to the original table.

[[File: loyda_2c.png|1200px]]

* ''' Updated Files '''

src/pages/ViewTeamGrades/Statistics.tsx [https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/Statisticstsx Statistics.tsx]

=== 2. Change the Location and Format of Team Member List ===
==== Rationale ====
The team member list is a type of information that should be readily available to the user. Instead, it is placed almost at the bottom of the page. Also, the font size is really small which makes it difficult to locate and read.

Furthermore, the "RoundSelector.tsx" file contains a function and its main purpose is to select the review round. However, its function is also to display the team member list. This violates the single responsibility principle. To fix this issue and allow the "RoundSelector" function to perform one function only, which in this case is to select the review round, it would be wise to move the code to gather and display the team information elsewhere — most likely inside the ReviewTable.tsx file.

==== Existing Design ====

Below is a screenshot of where the team member list is located in the UI. The team member list is outlined in red for visibility:

[[File: loyda_3a.png|1200px]]

Notice how small the font size is. Also, the team list should be located at the beginning of the page because it is part of the basic information that should be rendered first.

The current code to gather and display the team member list is located inside the "RoundSelector.tsx" file

[[File: loyda_3b.png|450px]]

Our goal is to change the location of the code snippets that are outlined in red to another location. This change will allow the RoundSelector function to only focus on selecting the review "Rounds"

==== Possible Changes ====

* ''' 1. Place the team list at the top of the page '''
The possible location of the team list will be in between the "Team" and "Average peer review score" information. The text format will also be changed. A larger text size will be introduced. These changes will allow the user to locate the list of the names of his/her team.

* ''' 2. Change the location of the code that gathers and displays the team list elsewhere '''
Changing the location of the code from the "RoundSelector.tsx" file to the "ReviewTable.tsx" file would allow us to fix the violation of the single responsibility principle in "RoundSelector.tsx".

==== Actual Changes ====
Below is a screenshot of the new location of the team member list outlined in red for visibility. Notice that the team member list is easy to locate as well as easy to read.

[[File: loyda_3c.png|1200px]]

Also, we changed the code to gather and display the team member list in the "ReviewTable.tsx" file. The new code snippets added are outlined in red for visibility

[[File: loyda_3d.png]]

The new "RoundSelector.tsx" contains the function that is ONLY focussed on selecting the review "Round" and thus obeys the single responsibility principle. A snapshot of the new function is provided below:

[[File: loyda_3e.png]]

* ''' Updated Files '''

src/pages/ViewTeamGrades/RoundSelector.tsx [https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/RoundSelelctor.tsx RoundSelector.tsx]
src/pages/ViewTeamGrades/ReviewTable.tsx [https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/ReviewTable.tsx ReviewTable.tsx]

=== 3.Export Options for Tables ===

'''Current Limitation:'''
Users cannot save or analyze table data outside the user interface. This makes it difficult to share or process data for further analysis.

'''Proposed Solution:'''
Add export buttons below each table to allow users to download the data as CSV, Excel, or PDF files. This will increase the flexibility and utility of the tables.

'''Implementation Details:'''
‎<br> 1. Export buttons for CSV and Excel are located below the table. ‎<br>
‎<br> 2. Utilizes the SheetJS (xlsx) library to generate exportable files. ‎<br>
‎<br> 3. File structure matches the table's visible data. ‎<br>

'''Supporting Code:'''
const exportTableData = (format: "csv" | "xlsx") => {
const tableData = initialData.map((row) => {
const rowData: Record<string, any> = {};
columns.forEach((col) => {
const accessor = col.id; // Use column `id` for keys
if (accessor) {
rowData[accessor] = row[accessor];
}
});
return rowData;
});

const worksheet = XLSX.utils.json_to_sheet(tableData);
const workbook = XLSX.utils.book_new();
XLSX.utils.book_append_sheet(workbook, worksheet, "TableData");

const fileType = format === "csv" ? "csv" : "xlsx";
XLSX.writeFile(workbook, `table_data.${fileType}`);
};

'''Export Buttons in the UI:'''
<div style={{ marginTop: "10px" }}>
<button
onClick={() => exportTableData("csv")}
className="btn btn-primary me-2"
>
Export to CSV
</button>
<button
onClick={() => exportTableData("xlsx")}
className="btn btn-primary"
>
Export to Excel
</button>
</div>

'''Testing:'''
it("renders export buttons", () => {
render(<Table data={mockData} columns={mockColumns} />);
expect(screen.getByText("Export to CSV")).toBeInTheDocument();
expect(screen.getByText("Export to Excel")).toBeInTheDocument();
});

=== 4.Improved Feedback Indicators ===

'''Current Limitation:'''
Users have no indication of when table data was last updated, leading to potential uncertainty about its accuracy.

'''Proposed Solution:'''
Add "Last Updated" timestamps or live refresh indicators for each table.

'''Implementation Details:'''
‎<br> 1. Include a "Last Updated: [Date/Time]" label below the table. ‎<br>
‎<br> 2. Update the timestamp dynamically whenever the data source is refreshed. ‎<br>
‎<br> 3. Use a subtle spinning loader icon to indicate data refreshing. ‎<br>

'''Supporting Code:'''
const [lastUpdated, setLastUpdated] = useState<Date | null>(null);

const refreshTableData = () => {
setLastUpdated(new Date());
};

=== 5.Extending toggle options ===

==== Rationale ====
While the heat map provides a great visual representation of the users feedback, with the addition of some 'toggles' we can better idea of the different values. Currently, there is only the option to toggle for the questions.

==== Existing Design ====

[[File: old_toggle_sc.png|1200px]]

In this current mode, there is only the option to toggle for the questions.

==== Actual Changes ====

[[File: simon_new_menu_opened.png|650px]]

In the updated version, since more toggle options were added, there is now a heat map option menu, that can be opened and closed. When open, there are 4 different checkboxes to check from that each provide their own way of helping the student better analyze their team grade.

When menu is closed:
[[File: simon_supporting_closed.png|250px]]

'''Supporting Code:'''

[[File: simon_supporting_code1.png|650px]]

Here is the supporting code for the 3 new toggle options, showToggle10WordComments, showToggle20WordComments, and showToggleCustomWordComment are all boolean values that if true filter and count reviews based on the properties of their comments. When they're set to true, it will first ensure that the comments are defined as strings and not undefined (since a user can leave a review without providing a comment), it will then filter over the reviews array within a row and filter and return the total number of comments that meet the respective criteria.

* ''' Updated Files '''

src/pages/ViewTeamGrades/ReviewTable.tsx
src/pages/ViewTeamGrades/ReviewTableRow.tsx

=== 6.Refactoring Code ===
We will work on refactoring some of the code, for example, changing naming conventions along with making sure SOLID principles are being used.

==== Refactoring code 1 ====
Updated naming convention for a toggle option

Previous:unclear state variable name with no comment
<div class="clear"></div>
[[File: supporting_code5.png|600px]]

Refactored: Added a comment to explain what the state was as well as changing the variable name to be more direct.
[[File: supporting_code4.png|600px]]

== Frontend (React & TypeScript) ==
=== Files to be potentially modified ===
All files to be modified are located in the src/pages/ViewTeamGrades folder. The files that will potentially be modified are:

* src/pages/ViewTeamGrades/App.tsx
* src/pages/ViewTeamGrades/ReviewTable.tsx

== Use Case Diagram ==

The use case diagram for the "view-team-grades" page after clicking "Grades View" in Expertiza highlights various interactions with the UI. Here's a general outline of possible actors and use cases:

=== Actors: ===

* Student - Primarily interacts with the UI to view all the grading details for an assignment.

=== Use Cases: ===

* View detailed grade of a particular assignment - Including assignment name, team name, average score, etc.
* Show Submission - This link redirects the student to a new page where the student can see his/her submission details.
* Show Stats - This link redirects the student to a new page where the student can see grading statistics.
* Submitted Work - This table shows the average and range of submitted work grades.
**Show Reviews - This link located in the "Submitted Work" table redirects the student to the page that renders all the reviews that the student obtained from his/her peers.
* Author Feedback - This table shows the average and range of author feedback for the submitted work.
**Show Author Feedback - This link located in the "Author Feedback" table redirects the student to the page that renders the author feedback that the student obtained after writing a review.
* Teammate Review - This table shows the average and range of teammate reviews for the submitted work.
* Back - Link that enables the student to go back to the main page
*

[[File: yusufov_d2.png |750px|center]]

==Test Plan==
To validate the newly designed "View Submissions" page's functionality, usability, and performance while meeting the goals of clarity, consistency, flexibility, and intuitivenes.

=== Testing Scope ===
1. Component Validation
* Test individual React components like ReviewTable.tsx and Statistics.tsx.
2. API Integration
* Verify API calls using useAPI.ts to ensure seamless backend integration.
3. Dynamic Features
* Test real-time updates (e.g., "Last Updated" timestamps).

=== Test Cases: ===

{| class="wikitable"
! Test Case ID
! Test Description
! Expected Outcome
! Priority
! Status
|-
| TC001
| Verify assignment name display
| Assignment names appear accurately.
| High
| Pending
|-
| TC002
| Validate "Show Stats" link
| Redirects to accurate grading statistics page.
| Medium
| Pending
|-
| TC003
| Test pagination in tables
| Pagination works correctly for large datasets.
| High
| Pending
|-
| TC004
| Test table export functionality
| CSV and Excel files match table content accurately.
| High
| Pending
|-
| TC005
| Validate data rendering
| Tables display data using mock files like `dummyData.json`.
| High
| Pending
|-
| TC006
| Test error handling for missing data
| UI displays appropriate placeholders or messages for empty datasets.
| Low
| Pending
|-
| TC007
| Verify contributor details
| Names and user IDs are displayed accurately.
| Medium
| Pending
|-
| TC008
| Validate new thresholds for review length
| Dynamic thresholds for word/character counts update and display correctly.
| Medium
| Pending
|}

=== Testing Strategy ===

Unit Testing:
*Write tests for individual components like ReviewTable using Jest.
*Validate utility functions in utils.ts.

Integration Testing:
* Test the interaction between App.tsx and its child components.
* Validate API responses using axios_client.ts.

Performance Testing:
* Simulate exporting large datasets to assess system performance.
* Measure response times for table rendering with dummyData.json.

Accessibility Testing:
*Test keyboard navigation and WCAG 2.1 compliance.

== Actual Testing ==

=== Unit Testing for ReviewTable using Jest ===

*The ReviewTable component is validated using the Jest and React Testing Libraries. Running tests on the ReviewTable component allowed us to determine whether the component rendered without crashing by utilizing the render function provided by the React Testing Library. The ReviewTable component was wrapped inside a Router component imported from react-router-dom, to establish the necessary routing context for components that rely on React Router. This configuration allows the test to simulate the environment in which the component operates accurately. Overall, the test file serves as a quality assurance measure, verifying that the ReviewTable component can render successfully and integrate correctly with the React Router.

====[https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/ReviewTable.test.tsx ReviewTable.test.tsx]====
<pre>
import React from 'react';
import { render} from '@testing-library/react';
import { BrowserRouter as Router } from 'react-router-dom';
import ReviewTable from './ReviewTable';

describe('ReviewTable component', () => {
test('renders without crashing', () => {
render(
<Router> {/* Wrap your component with Router */}
<ReviewTable />
</Router>
);
});

});</pre>

==== Testing results ====
[[File: loyda_review_testing_results.png]]

=== Unit Testing for Statistics Component using Jest ===

*The Statistics component is validated using the Jest and React Testing Libraries. It employs the Jest and React Testing Library for testing purposes, along with the jest-dom library for custom assertions. The first test "renders the correct labels" ensures that the statistics table renders the correct labels. The second test "renders correct statistical information for each label" ensures that the statistical information is rendered correctly under each label. Lastly, their test "renders correct links" ensures that all the necessary links are rendered. Overall, these tests comprehensively evaluate the rendering and functionality of the Statistics component.

====[https://github.com/simong2/reimplementation-front-end/blob/main/src/pages/ViewTeamGrades/Statistics.test.tsx Statistics.test.tsx]====
<pre>
import React from 'react';
import { render, screen } from '@testing-library/react';
import '@testing-library/jest-dom/extend-expect'; // Import jest-dom for custom assertions
import Statistics from './Statistics'; // Import the component to test

describe('Statistics', () => {
test('renders the correct labels', () => {
render(<Statistics average={''} />);
// Find the scores within the underlined spans
const element_1 = screen.getByRole('columnheader', { name: 'Submitted Work' });
const element_2 = screen.getByRole('columnheader', { name: 'Author Feedback' });
const element_3 = screen.getByRole('columnheader', { name: 'Teammate Review' });
const element_4 = screen.getByRole('columnheader', { name: 'Contributor' });

const element_5 = screen.getAllByText(/Average/i);
const element_6 = screen.getAllByText(/Range/i);
const element_7 = screen.getByRole('columnheader', { name: 'Final Score' });

// Assert that the elements are present
expect(element_1).toBeInTheDocument();
expect(element_2).toBeInTheDocument();
expect(element_3).toBeInTheDocument();
expect(element_4).toBeInTheDocument();
expect(element_5[0]).toBeInTheDocument();
expect(element_6[0]).toBeInTheDocument();
expect(element_7).toBeInTheDocument();

});

test('renders correct statistical information for each label', () => {
render(<Statistics average={''} />);
// Find the scores within the underlined spans
const element_1 = screen.getByRole('cell', { name: 'ssshah26 (Siddharth Shah)' });
const element_2 = screen.getByRole('cell', { name: 'Show Reviews (20)' });
const element_3 = screen.getByRole('cell', { name: '99.99% - 100%' });
const element_4 = screen.getByRole('cell', { name: '96.67 Show Author Feedback (10)' });
const element_5 = screen.getByRole('cell', { name: '87% - 100%' });
const element_6 = screen.getByRole('cell', { name: '4.64' });
const element_7 = screen.getByRole('cell', { name: '90% - 100%' });
const element_8 = screen.getByRole('cell', { name: '75% (in Finished)' });

// Assert that the elements are present
expect(element_1).toBeInTheDocument();
expect(element_2).toBeInTheDocument();
expect(element_3).toBeInTheDocument();
expect(element_4).toBeInTheDocument();
expect(element_5).toBeInTheDocument();
expect(element_6).toBeInTheDocument();
expect(element_7).toBeInTheDocument();
expect(element_8).toBeInTheDocument();
});

test('renders correct links', () => {
render(<Statistics average={''} />);
// Find the scores within the underlined spans
const element_1 = screen.getByRole('link', { name: 'show stats' });
const element_2 = screen.getByRole('link', { name: 'ssshah26' });
const element_3 = screen.getByRole('link', { name: 'Show Reviews' });
const element_4 = screen.getByRole('link', { name: 'Show Author Feedback' });

// Assert that the elements are present
expect(element_1).toBeInTheDocument();
expect(element_2).toBeInTheDocument();
expect(element_3).toBeInTheDocument();
expect(element_4).toBeInTheDocument();

});
});</pre>

==== Testing results ====

[[File: loyda_statistics_testing_results.png]]

== User Stories ==

* As a student I want to check all grading details of an assignment so that I can know my grade.
* As a student I want to see my submission of an assignment so that I can check what was submitted for a given assignment.
* As a student I want to see the names of my group team members so that I can know who I worked with.
* As a student I want to see the statistics of my grades so that I know my grade distribution.
* As a student I want to see if I got any late penalties so that I can know whether I got deducted points or not.
* As a student I want to have a way to view all the reviews that I got for the assignment so that I can read the viewer's responses.

== Conclusion ==
This design document introduces a step-by-step plan for updating the "view-team-grades" page on Expertiza, aiming for a user interface that is visually appealing and simple. Using React and TypeScript, the goal is to deliver a more user-friendly solution that enhances the functionality and manageability of grade information for a particular project within the Expertiza system. A clear and flexible UI design makes it not only simple to maintain but also flexible enough for future upgrades.

== List of Project Links ==
GitHub Repository: https://github.com/simong2/reimplementation-front-end

== Project Mentor ==

'''Nainisha Bhallamudi''' (nbhalla@ncsu.edu)

== Team Members ==

* '''Simon Getahun''' (unityid: sgetahu, github: https://github.com/simong2)
* '''Anusha Akkireddy''' (unityid: aakkire, github:https://github.com/akkireddyanusha)
* '''Loyda Yusufova''' (unityid: leyusufo, github: https://github.com/leyusufo)

File:Simon supporting code1.png

2024-12-04T07:38:45Z

Sgetahu:

File:Simon new menu opened.png

2024-12-04T07:26:57Z

Sgetahu:

File:Simon new menu closed.png

2024-12-04T07:14:29Z

Sgetahu:

CSC/ECE 517 Fall 2024 - E2492. UI for View submissions/assign grades (except heatgrid)

2024-12-01T07:50:17Z

Sgetahu: /* Actual Changes */

CSC/ECE 517 Fall 2024 - E2492. UI for View submissions/assign grades (except heatgrid)

2024-12-01T07:49:26Z

Sgetahu: /* Actual Changes */

CSC/ECE 517 Fall 2024 - E2492. UI for View submissions/assign grades (except heatgrid)

2024-12-01T07:48:13Z

Sgetahu: /* Detail Description of Possible and Actual Changes */

File:Supporting code4.png

2024-12-01T07:45:37Z

Sgetahu:

File:Supporting code5.png

2024-12-01T07:45:20Z

Sgetahu:

File:Supporting code.png

2024-12-01T07:27:16Z

Sgetahu:

File:New toggle sc.png

2024-12-01T07:26:05Z

Sgetahu: Sgetahu uploaded a new version of File:New toggle sc.png

File:Old toggle sc.png

2024-12-01T07:14:17Z

Sgetahu:

File:New toggle sc.png

2024-12-01T07:13:53Z

Sgetahu:

CSC/ECE 517 Fall 2024 - E2492. UI for View submissions/assign grades (except heatgrid)

2024-11-13T04:51:33Z

Sgetahu: /* 4.Extend feature in view team grade page */

CSC/ECE 517 Fall 2024 - E2492. UI for View submissions/assign grades (except heatgrid)

2024-11-13T04:50:11Z

Sgetahu: /* Detail Description of Possible Changes */

CSC/ECE 517 Fall 2024 - E2460 Mentor-Meeting Management

2024-10-30T08:17:36Z

Sgetahu: /* Email Notifications */

__TOC__

==Background==
Expertiza is an open-source course management web application, that is maintained by students and teaching staff across NC State and other universities. Specifically, Expertiza is used as a platform to help students learn how to work collaboratively on large Object Oriented Programming Assignments. If you would like to learn more about Expertiza, please check the Expertiza wiki[1], or the GitHub page [2]. For our project in particular, we were tasked with improving the mentor management system within Expertiza.

== What is a Mentor? ==
On Expertiza some users are known as mentors. These mentors can both be added to teams manually and automatically assigned if the assignment moderator chooses to select an option where mentors are automatically assigned to teams above 50% capacity. In practice, this means that if you have a max team size of 3, and 2 teammates have been added to team X then team X will automatically be given a mentor.

== Problem Statement ==
The problem we have been faced with is multifaceted. First, we found that when teams are automatically built, students are not getting notified of when they are added to a team. Even more alarming is that when mentors are being added to teams, they aren't getting any type of specialized notification letting them know. Mentors should know when they are mentoring a new team, and students should know when they've been added to a team. Team listing should be improved to be sortable by team name, mentor name, or meeting date.

Expertiza doesn’t know when mentors met with teams, so there would have to be text fields where this information could be entered.

The page would have to be accessible to all mentors and course instructors, but a mentor could only enter meetings for the teams they mentored (except that the instructor could edit any of the meeting dates for any mentor).

Our project sought to fix these issues.

== Tasks ==
=== Email Notifications ===
# Changed mailer function for team addition confirmation
# Add HTML partials for dual role
# Correct mailer function calls when users/mentors are added
# Add tests

=== Mentor Meeting Management ===
# Create a view showing teams, members, and mentors, with meeting date fields.
# Add input fields for each team where mentors and instructors can enter new, view, edit dates when mentor meetings were conducted.
# Instructors can edit all dates for mentor meetings regardless of the team.
# Mentors can also edit dates but only for the team they are mentoring.
# Add more than three dates for the mentor meetings easily by pressing the + icon at the end of the view.
# The meeting dates should not be editable for teams having capacity less than 50%.

=== Backend Controller Updates ===
# Implement a new controller to handle CRUD operations for mentor meetings
# Update models to manage mentor meetings and trigger notifications.

== Implementation ==
=== Email Notifications ===

Here is the previous PR created of the add_member function. The goal of this was to send a notification when members were added.
[[File:Add member email.png|900px|left|alt=Description of image]]
<div style="clear: both;"></div>

Based on the professor's feedback that a mentor can also be a participant, we adjusted the role checking logic to account for all use cases.
[[File:add_member_snippet_code.png|900px|left|alt=Description of image]]
<div style="clear: both;"></div>

The code now checks if a user is both a mentor and a participant using MentorManagement.user_a_mentor?(user) and user.is_a?(Participant). If the user is a mentor but not a participant, it sends the mentor notification. If the user is only a participant (not a mentor), it sends the participant notification.
If the user is both a mentor and a participant, it sends a single notification email to say that they hold both roles.

New HTML partial format for dual role:
[[File:dual_role_html_partial.png|900px|left|alt=Description of image]]
<div style="clear: both;"></div>

The remaining implementation follows this style by fixing the conditional logic for sending emails to the correct user and adding a test for the new dual role route.

[[File:test_dual_role.png|900px|left|alt=Description of image]]
<div style="clear: both;"></div>

=== Mentor Meeting Management ===

==== Code Changes in Views ====
=====_team.html.erb=====
We reinstituted some of what the previous group did from their pull request to render a new view, refactoring to improve clarity.

[[File:Previous group - refactored.png|1000px|left|alt=Description of image]]

<div style="clear: both;"></div>

We then added on top of it the conditionals requested of us by our scope. The view code below accomplishes most of the prompt's points.
*Establishes mentor and instructor functionality to add/edit meeting dates for their teams/all teams accordingly
*Disables the date field for under capacity teams
*Includes a button to add and remove meeting dates
*includes join functionality for under capacity teams

[[File:Capacity and +.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

This final bit of code in the _team viewfinishes up coverage for dynamically adding meeting dates with the "+" button

[[File:meeting date functionality.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

==== Code Changes in Controllers ====

===== mentor_meeting_controller.rb =====
Made modifications to add the private parameters to be passed through the model.

[[File:meeting parameters.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

==== Code Changes in Test ====
===== mentor_management_spec.rb =====
The previous groups covered much of the testing pretty thoroughly aside from confirming that a mentor is not auto assigned when auto_assign_mentor is false. This is just a tag along to the existing codebase.

[[File:test_auto_assign_mentor.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

=== Backend Controller Updates ===

Code changes in the controller
We added a new controller(mentor_meeting.rb) to perform the CRUD operations on the mentor meeting table.
Implemented the necessary actions (get_dates, add_date, edit_date, delete_date) in the MentorMeetingController.

[[File:Screenshot_2024-10-29_175157.jpg]]

Created a new file, mentor_meeting_notifications.rb
Added the subscription code in that initializer file.
This file allows subscription to the notifications, which will allow handling of any follow-up actions (logging and emails) when meetings are created, updated, or deleted.

Controller Tests
Created a new file, mentor_meeting_controller_spec.rb, in the spec/controllers directory to test the MentorMeetingController

[[File:tests in new file mentor_meeting_controller_spec.jpg]]

Model (Validation Updates)
The MentorMeeting model was updated with basic validations to ensure that required fields (team_id and meeting_date) are present. Validations for team_id and meeting_date ensure data integrity when saving a meeting.

Triggering Notifications
Updated the add_date method to trigger a notification after successfully creating a meeting.
Notifications triggered via ActiveSupport::Notifications.

Helper code
We also wrote a helper code to map all the team IDs in the mentor meeting table to the appropriate meeting dates.

== Relevant Links ==
*Github Repository: https://github.com/ExtremeMachine12/expertiza
*Pull Request: https://github.com/ExtremeMachine12/expertiza/pull/21

== Team ==
===Mentor===
* Nainisha Bhallamudi

=== Members ===
* Anusha Akkireddy (aakkire)
* Simon Getahun (sgetahu)
* Gavin Teague (gwteague)

File:Test dual role.png

2024-10-30T08:17:22Z

Sgetahu:

CSC/ECE 517 Fall 2024 - E2460 Mentor-Meeting Management

2024-10-30T08:13:50Z

Sgetahu: /* Email Notifications */

__TOC__

==Background==
Expertiza is an open-source course management web application, that is maintained by students and teaching staff across NC State and other universities. Specifically, Expertiza is used as a platform to help students learn how to work collaboratively on large Object Oriented Programming Assignments. If you would like to learn more about Expertiza, please check the Expertiza wiki[1], or the GitHub page [2]. For our project in particular, we were tasked with improving the mentor management system within Expertiza.

== What is a Mentor? ==
On Expertiza some users are known as mentors. These mentors can both be added to teams manually and automatically assigned if the assignment moderator chooses to select an option where mentors are automatically assigned to teams above 50% capacity. In practice, this means that if you have a max team size of 3, and 2 teammates have been added to team X then team X will automatically be given a mentor.

== Problem Statement ==
The problem we have been faced with is multifaceted. First, we found that when teams are automatically built, students are not getting notified of when they are added to a team. Even more alarming is that when mentors are being added to teams, they aren't getting any type of specialized notification letting them know. Mentors should know when they are mentoring a new team, and students should know when they've been added to a team. Team listing should be improved to be sortable by team name, mentor name, or meeting date.

Expertiza doesn’t know when mentors met with teams, so there would have to be text fields where this information could be entered.

The page would have to be accessible to all mentors and course instructors, but a mentor could only enter meetings for the teams they mentored (except that the instructor could edit any of the meeting dates for any mentor).

Our project sought to fix these issues.

== Tasks ==
=== Email Notifications ===
# Changed mailer function for team addition confirmation
# Add HTML partials for dual role
# Correct mailer function calls when users/mentors are added
# Add tests

=== Mentor Meeting Management ===
# Create a view showing teams, members, and mentors, with meeting date fields.
# Add input fields for each team where mentors and instructors can enter new, view, edit dates when mentor meetings were conducted.
# Instructors can edit all dates for mentor meetings regardless of the team.
# Mentors can also edit dates but only for the team they are mentoring.
# Add more than three dates for the mentor meetings easily by pressing the + icon at the end of the view.
# The meeting dates should not be editable for teams having capacity less than 50%.

=== Backend Controller Updates ===
# Implement a new controller to handle CRUD operations for mentor meetings
# Update models to manage mentor meetings and trigger notifications.

== Implementation ==
=== Email Notifications ===

Here is the previous PR created of the add_member function. The goal of this was to send a notification when members were added.
[[File:Add member email.png|900px|left|alt=Description of image]]
<div style="clear: both;"></div>

Based on the professor's feedback that a mentor can also be a participant, we adjusted the role checking logic to account for all use cases.
[[File:add_member_snippet_code.png|900px|left|alt=Description of image]]
<div style="clear: both;"></div>

The code now checks if a user is both a mentor and a participant using MentorManagement.user_a_mentor?(user) and user.is_a?(Participant). If the user is a mentor but not a participant, it sends the mentor notification. If the user is only a participant (not a mentor), it sends the participant notification.
If the user is both a mentor and a participant, it sends a single notification email to say that they hold both roles.

New HTML partial format for dual role:
[[File:dual_role_html_partial.png|900px|left|alt=Description of image]]
<div style="clear: both;"></div>

=== Mentor Meeting Management ===

==== Code Changes in Views ====
=====_team.html.erb=====
We reinstituted some of what the previous group did from their pull request to render a new view, refactoring to improve clarity.

[[File:Previous group - refactored.png|1000px|left|alt=Description of image]]

<div style="clear: both;"></div>

We then added on top of it the conditionals requested of us by our scope. The view code below accomplishes most of the prompt's points.
*Establishes mentor and instructor functionality to add/edit meeting dates for their teams/all teams accordingly
*Disables the date field for under capacity teams
*Includes a button to add and remove meeting dates
*includes join functionality for under capacity teams

[[File:Capacity and +.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

This final bit of code in the _team viewfinishes up coverage for dynamically adding meeting dates with the "+" button

[[File:meeting date functionality.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

==== Code Changes in Controllers ====

===== mentor_meeting_controller.rb =====
Made modifications to add the private parameters to be passed through the model.

[[File:meeting parameters.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

==== Code Changes in Test ====
===== mentor_management_spec.rb =====
The previous groups covered much of the testing pretty thoroughly aside from confirming that a mentor is not auto assigned when auto_assign_mentor is false. This is just a tag along to the existing codebase.

[[File:test_auto_assign_mentor.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

=== Backend Controller Updates ===

Code changes in the controller
We added a new controller(mentor_meeting.rb) to perform the CRUD operations on the mentor meeting table.
Implemented the necessary actions (get_dates, add_date, edit_date, delete_date) in the MentorMeetingController.

[[File:Screenshot_2024-10-29_175157.jpg]]

Created a new file, mentor_meeting_notifications.rb
Added the subscription code in that initializer file.
This file allows subscription to the notifications, which will allow handling of any follow-up actions (logging and emails) when meetings are created, updated, or deleted.

Controller Tests
Created a new file, mentor_meeting_controller_spec.rb, in the spec/controllers directory to test the MentorMeetingController

[[File:tests in new file mentor_meeting_controller_spec.jpg]]

Model (Validation Updates)
The MentorMeeting model was updated with basic validations to ensure that required fields (team_id and meeting_date) are present. Validations for team_id and meeting_date ensure data integrity when saving a meeting.

Triggering Notifications
Updated the add_date method to trigger a notification after successfully creating a meeting.
Notifications triggered via ActiveSupport::Notifications.

Helper code
We also wrote a helper code to map all the team IDs in the mentor meeting table to the appropriate meeting dates.

== Relevant Links ==
*Github Repository: https://github.com/ExtremeMachine12/expertiza
*Pull Request: https://github.com/ExtremeMachine12/expertiza/pull/21

== Team ==
===Mentor===
* Nainisha Bhallamudi

=== Members ===
* Anusha Akkireddy (aakkire)
* Simon Getahun (sgetahu)
* Gavin Teague (gwteague)

CSC/ECE 517 Fall 2024 - E2460 Mentor-Meeting Management

2024-10-30T08:13:16Z

Sgetahu: /* Email Notifications */

__TOC__

==Background==
Expertiza is an open-source course management web application, that is maintained by students and teaching staff across NC State and other universities. Specifically, Expertiza is used as a platform to help students learn how to work collaboratively on large Object Oriented Programming Assignments. If you would like to learn more about Expertiza, please check the Expertiza wiki[1], or the GitHub page [2]. For our project in particular, we were tasked with improving the mentor management system within Expertiza.

== What is a Mentor? ==
On Expertiza some users are known as mentors. These mentors can both be added to teams manually and automatically assigned if the assignment moderator chooses to select an option where mentors are automatically assigned to teams above 50% capacity. In practice, this means that if you have a max team size of 3, and 2 teammates have been added to team X then team X will automatically be given a mentor.

== Problem Statement ==
The problem we have been faced with is multifaceted. First, we found that when teams are automatically built, students are not getting notified of when they are added to a team. Even more alarming is that when mentors are being added to teams, they aren't getting any type of specialized notification letting them know. Mentors should know when they are mentoring a new team, and students should know when they've been added to a team. Team listing should be improved to be sortable by team name, mentor name, or meeting date.

Expertiza doesn’t know when mentors met with teams, so there would have to be text fields where this information could be entered.

The page would have to be accessible to all mentors and course instructors, but a mentor could only enter meetings for the teams they mentored (except that the instructor could edit any of the meeting dates for any mentor).

Our project sought to fix these issues.

== Tasks ==
=== Email Notifications ===
# Changed mailer function for team addition confirmation
# Add HTML partials for dual role
# Correct mailer function calls when users/mentors are added
# Add tests

=== Mentor Meeting Management ===
# Create a view showing teams, members, and mentors, with meeting date fields.
# Add input fields for each team where mentors and instructors can enter new, view, edit dates when mentor meetings were conducted.
# Instructors can edit all dates for mentor meetings regardless of the team.
# Mentors can also edit dates but only for the team they are mentoring.
# Add more than three dates for the mentor meetings easily by pressing the + icon at the end of the view.
# The meeting dates should not be editable for teams having capacity less than 50%.

=== Backend Controller Updates ===
# Implement a new controller to handle CRUD operations for mentor meetings
# Update models to manage mentor meetings and trigger notifications.

== Implementation ==
=== Email Notifications ===

Here is the previous PR created of the add_member function. The goal of this was to send a notification when members were added.
[[File:Add member email.png|900px|left|alt=Description of image]]
<div style="clear: both;"></div>

Based on the professor's feedback that a mentor can also be a participant, we adjusted the role checking logic to account for all use cases.
[[File:add_member_snippet_code.png|900px|left|alt=Description of image]]
<div style="clear: both;"></div>

The code now checks if a user is both a mentor and a participant using MentorManagement.user_a_mentor?(user) and user.is_a?(Participant). If the user is a mentor but not a participant, it sends the mentor notification. If the user is only a participant (not a mentor), it sends the participant notification.
If the user is both a mentor and a participant, it sends a single notification email to say that they hold both roles.

New HTML partial format for dual role:
[[File:dual_role_html_partial.png|900px|left|alt=Description of image]]
<div style="clear: both;"></div>

The remaining implementations follow this style by fixing the conditional logic for sending emails to the correct user and adding a test for the new dual role route.

=== Mentor Meeting Management ===

==== Code Changes in Views ====
=====_team.html.erb=====
We reinstituted some of what the previous group did from their pull request to render a new view, refactoring to improve clarity.

[[File:Previous group - refactored.png|1000px|left|alt=Description of image]]

<div style="clear: both;"></div>

We then added on top of it the conditionals requested of us by our scope. The view code below accomplishes most of the prompt's points.
*Establishes mentor and instructor functionality to add/edit meeting dates for their teams/all teams accordingly
*Disables the date field for under capacity teams
*Includes a button to add and remove meeting dates
*includes join functionality for under capacity teams

[[File:Capacity and +.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

This final bit of code in the _team viewfinishes up coverage for dynamically adding meeting dates with the "+" button

[[File:meeting date functionality.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

==== Code Changes in Controllers ====

===== mentor_meeting_controller.rb =====
Made modifications to add the private parameters to be passed through the model.

[[File:meeting parameters.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

==== Code Changes in Test ====
===== mentor_management_spec.rb =====
The previous groups covered much of the testing pretty thoroughly aside from confirming that a mentor is not auto assigned when auto_assign_mentor is false. This is just a tag along to the existing codebase.

[[File:test_auto_assign_mentor.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

=== Backend Controller Updates ===

Code changes in the controller
We added a new controller(mentor_meeting.rb) to perform the CRUD operations on the mentor meeting table.
Implemented the necessary actions (get_dates, add_date, edit_date, delete_date) in the MentorMeetingController.

[[File:Screenshot_2024-10-29_175157.jpg]]

Created a new file, mentor_meeting_notifications.rb
Added the subscription code in that initializer file.
This file allows subscription to the notifications, which will allow handling of any follow-up actions (logging and emails) when meetings are created, updated, or deleted.

Controller Tests
Created a new file, mentor_meeting_controller_spec.rb, in the spec/controllers directory to test the MentorMeetingController

[[File:tests in new file mentor_meeting_controller_spec.jpg]]

Model (Validation Updates)
The MentorMeeting model was updated with basic validations to ensure that required fields (team_id and meeting_date) are present. Validations for team_id and meeting_date ensure data integrity when saving a meeting.

Triggering Notifications
Updated the add_date method to trigger a notification after successfully creating a meeting.
Notifications triggered via ActiveSupport::Notifications.

Helper code
We also wrote a helper code to map all the team IDs in the mentor meeting table to the appropriate meeting dates.

== Relevant Links ==
*Github Repository: https://github.com/ExtremeMachine12/expertiza
*Pull Request: https://github.com/ExtremeMachine12/expertiza/pull/21

== Team ==
===Mentor===
* Nainisha Bhallamudi

=== Members ===
* Anusha Akkireddy (aakkire)
* Simon Getahun (sgetahu)
* Gavin Teague (gwteague)

CSC/ECE 517 Fall 2024 - E2460 Mentor-Meeting Management

2024-10-30T08:05:04Z

Sgetahu: /* Email Notifications */

__TOC__

==Background==
Expertiza is an open-source course management web application, that is maintained by students and teaching staff across NC State and other universities. Specifically, Expertiza is used as a platform to help students learn how to work collaboratively on large Object Oriented Programming Assignments. If you would like to learn more about Expertiza, please check the Expertiza wiki[1], or the GitHub page [2]. For our project in particular, we were tasked with improving the mentor management system within Expertiza.

== What is a Mentor? ==
On Expertiza some users are known as mentors. These mentors can both be added to teams manually and automatically assigned if the assignment moderator chooses to select an option where mentors are automatically assigned to teams above 50% capacity. In practice, this means that if you have a max team size of 3, and 2 teammates have been added to team X then team X will automatically be given a mentor.

== Problem Statement ==
The problem we have been faced with is multifaceted. First, we found that when teams are automatically built, students are not getting notified of when they are added to a team. Even more alarming is that when mentors are being added to teams, they aren't getting any type of specialized notification letting them know. Mentors should know when they are mentoring a new team, and students should know when they've been added to a team. Team listing should be improved to be sortable by team name, mentor name, or meeting date.

Expertiza doesn’t know when mentors met with teams, so there would have to be text fields where this information could be entered.

The page would have to be accessible to all mentors and course instructors, but a mentor could only enter meetings for the teams they mentored (except that the instructor could edit any of the meeting dates for any mentor).

Our project sought to fix these issues.

== Tasks ==
=== Email Notifications ===
# Changed mailer function for team addition confirmation
# Add HTML partials for dual role
# Correct mailer function calls when users/mentors are added
# Add tests

=== Mentor Meeting Management ===
# Create a view showing teams, members, and mentors, with meeting date fields.
# Add input fields for each team where mentors and instructors can enter new, view, edit dates when mentor meetings were conducted.
# Instructors can edit all dates for mentor meetings regardless of the team.
# Mentors can also edit dates but only for the team they are mentoring.
# Add more than three dates for the mentor meetings easily by pressing the + icon at the end of the view.
# The meeting dates should not be editable for teams having capacity less than 50%.

=== Backend Controller Updates ===
# Implement a new controller to handle CRUD operations for mentor meetings
# Update models to manage mentor meetings and trigger notifications.

== Implementation ==
=== Email Notifications ===

Here is the previous PR created of the add_member function. The goal of this was to send a notification when members were added.
[[File:Add member email.png|900px|left|alt=Description of image]]
<div style="clear: both;"></div>

Based on the professor's feedback that a mentor can also be a participant, we adjusted the role checking logic to account for all use cases.
[[File:add_member_snippet_code.png|900px|left|alt=Description of image]]
<div style="clear: both;"></div>

The code now checks if a user is both a mentor and a participant using MentorManagement.user_a_mentor?(user) and user.is_a?(Participant). If the user is a mentor but not a participant, it sends the mentor notification. If the user is only a participant (not a mentor), it sends the participant notification.
If the user is both a mentor and a participant, it sends a single notification email to say that they hold both roles.

New HTML partial format for dual role:
[[File:dual_role_html_partial.png|900px|left|alt=Description of image]]
<div style="clear: both;"></div>

=== Mentor Meeting Management ===

==== Code Changes in Views ====
=====_team.html.erb=====
We reinstituted some of what the previous group did from their pull request to render a new view, refactoring to improve clarity.

[[File:Previous group - refactored.png|1000px|left|alt=Description of image]]

<div style="clear: both;"></div>

We then added on top of it the conditionals requested of us by our scope. The view code below accomplishes most of the prompt's points.
*Establishes mentor and instructor functionality to add/edit meeting dates for their teams/all teams accordingly
*Disables the date field for under capacity teams
*Includes a button to add and remove meeting dates
*includes join functionality for under capacity teams

[[File:Capacity and +.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

This final bit of code in the _team viewfinishes up coverage for dynamically adding meeting dates with the "+" button

[[File:meeting date functionality.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

==== Code Changes in Controllers ====

===== mentor_meeting_controller.rb =====
Made modifications to add the private parameters to be passed through the model.

[[File:meeting parameters.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

==== Code Changes in Test ====
===== mentor_management_spec.rb =====
The previous groups covered much of the testing pretty thoroughly aside from confirming that a mentor is not auto assigned when auto_assign_mentor is false. This is just a tag along to the existing codebase.

[[File:test_auto_assign_mentor.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

=== Backend Controller Updates ===

Code changes in the controller
We added a new controller(mentor_meeting.rb) to perform the CRUD operations on the mentor meeting table.
Implemented the necessary actions (get_dates, add_date, edit_date, delete_date) in the MentorMeetingController.

[[File:Screenshot_2024-10-29_175157.jpg]]

Created a new file, mentor_meeting_notifications.rb
Added the subscription code in that initializer file.
This file allows subscription to the notifications, which will allow handling of any follow-up actions (logging and emails) when meetings are created, updated, or deleted.

Controller Tests
Created a new file, mentor_meeting_controller_spec.rb, in the spec/controllers directory to test the MentorMeetingController

[[File:tests in new file mentor_meeting_controller_spec.jpg]]

Model (Validation Updates)
The MentorMeeting model was updated with basic validations to ensure that required fields (team_id and meeting_date) are present. Validations for team_id and meeting_date ensure data integrity when saving a meeting.

Triggering Notifications
Updated the add_date method to trigger a notification after successfully creating a meeting.
Notifications triggered via ActiveSupport::Notifications.

Helper code
We also wrote a helper code to map all the team IDs in the mentor meeting table to the appropriate meeting dates.

== Relevant Links ==
*Github Repository: https://github.com/ExtremeMachine12/expertiza
*Pull Request: https://github.com/ExtremeMachine12/expertiza/pull/21

== Team ==
===Mentor===
* Nainisha Bhallamudi

=== Members ===
* Anusha Akkireddy (aakkire)
* Simon Getahun (sgetahu)
* Gavin Teague (gwteague)

File:Dual role html partial.png

2024-10-30T08:04:35Z

Sgetahu:

CSC/ECE 517 Fall 2024 - E2460 Mentor-Meeting Management

2024-10-30T03:08:40Z

Sgetahu: /* Email Notifications */

__TOC__

==Background==
Expertiza is an open-source course management web application, that is maintained by students and teaching staff across NC State and other universities. Specifically, Expertiza is used as a platform to help students learn how to work collaboratively on large Object Oriented Programming Assignments. If you would like to learn more about Expertiza, please check the Expertiza wiki[1], or the GitHub page [2]. For our project in particular, we were tasked with improving the mentor management system within Expertiza.

== What is a Mentor? ==
On Expertiza some users are known as mentors. These mentors can both be added to teams manually and automatically assigned if the assignment moderator chooses to select an option where mentors are automatically assigned to teams above 50% capacity. In practice, this means that if you have a max team size of 3, and 2 teammates have been added to team X then team X will automatically be given a mentor.

== Problem Statement ==
The problem we have been faced with is multifaceted. First, we found that when teams are automatically built, students are not getting notified of when they are added to a team. Even more alarming is that when mentors are being added to teams, they aren't getting any type of specialized notification letting them know. Mentors should know when they are mentoring a new team, and students should know when they've been added to a team. Team listing should be improved to be sortable by team name, mentor name, or meeting date.

Expertiza doesn’t know when mentors met with teams, so there would have to be text fields where this information could be entered.

The page would have to be accessible to all mentors and course instructors, but a mentor could only enter meetings for the teams they mentored (except that the instructor could edit any of the meeting dates for any mentor).

Our project sought to fix these issues.

== Tasks ==
=== Email Notifications ===
# Changed mailer function for team addition confirmation
# Add HTML partials for dual role
# Correct mailer function calls when users/mentors are added
# Add tests

=== Mentor Meeting Management ===
# Create a view showing teams, members, and mentors, with meeting date fields.
# Add input fields for each team where mentors and instructors can enter new, view, edit dates when mentor meetings were conducted.
# Instructors can edit all dates for mentor meetings regardless of the team.
# Mentors can also edit dates but only for the team they are mentoring.
# Add more than three dates for the mentor meetings easily by pressing the + icon at the end of the view.
# The meeting dates should not be editable for teams having capacity less than 50%.

=== Backend Controller Updates ===
# Implement a new controller to handle CRUD operations for mentor meetings
# Update models to manage mentor meetings and trigger notifications.

== Implementation ==
=== Email Notifications ===

Here is the previous PR created of the add_member function. The goal of this was to send a notification when members were added.
[[File:Add member email.png|900px|left|alt=Description of image]]
<div style="clear: both;"></div>

Based on the professor's feedback that a mentor can also be a participant, we adjusted the role checking logic to account for all use cases.
[[File:add_member_snippet_code.png|900px|left|alt=Description of image]]
<div style="clear: both;"></div>

=== Mentor Meeting Management ===

==== Code Changes in Views ====
=====_team.html.erb=====
We reinstituted some of what the previous group did from their pull request to render a new view, refactoring to improve clarity.

[[File:Previous group - refactored.png|1000px|left|alt=Description of image]]

<div style="clear: both;"></div>

We then added on top of it the conditionals requested of us by our scope. The view code below accomplishes most of the prompt's points.
*Establishes mentor and instructor functionality to add/edit meeting dates for their teams/all teams accordingly
*Disables the date field for under capacity teams
*Includes a button to add and remove meeting dates
*includes join functionality for under capacity teams

[[File:Capacity and +.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

This final bit of code in the _team viewfinishes up coverage for dynamically adding meeting dates with the "+" button

[[File:meeting date functionality.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

==== Code Changes in Controllers ====

===== mentor_meeting_controller.rb =====
Made modifications to add the private parameters to be passed through the model.

[[File:meeting parameters.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

==== Code Changes in Test ====
===== mentor_management_spec.rb =====
The previous groups covered much of the testing pretty thoroughly aside from confirming that a mentor is not auto assigned when auto_assign_mentor is false. This is just a tag along to the existing codebase.

[[File:test_auto_assign_mentor.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

=== Backend Controller Updates ===

Code changes in the controller
We added a new controller(mentor_meeting.rb) to perform the CRUD operations on the mentor meeting table.
Implemented the necessary actions (get_dates, add_date, edit_date, delete_date) in the MentorMeetingController.

[[File:Screenshot_2024-10-29_175157.jpg]]

Created a new file, mentor_meeting_notifications.rb
Added the subscription code in that initializer file.
This file allows subscription to the notifications, which will allow handling of any follow-up actions (logging and emails) when meetings are created, updated, or deleted.

Controller Tests
Created a new file, mentor_meeting_controller_spec.rb, in the spec/controllers directory to test the MentorMeetingController

[[File:tests in new file mentor_meeting_controller_spec.jpg]]

Model (Validation Updates)
The MentorMeeting model was updated with basic validations to ensure that required fields (team_id and meeting_date) are present. Validations for team_id and meeting_date ensure data integrity when saving a meeting.

Triggering Notifications
Updated the add_date method to trigger a notification after successfully creating a meeting.
Notifications triggered via ActiveSupport::Notifications.

Helper code
We also wrote a helper code to map all the team IDs in the mentor meeting table to the appropriate meeting dates.

== Relevant Links ==
*Github Repository: https://github.com/ExtremeMachine12/expertiza
*Pull Request: https://github.com/ExtremeMachine12/expertiza/pull/21

== Team ==
===Mentor===
* Nainisha Bhallamudi

=== Members ===
* Anusha Akkireddy (aakkire)
* Simon Getahun (sgetahu)
* Gavin Teague (gwteague)

CSC/ECE 517 Fall 2024 - E2460 Mentor-Meeting Management

2024-10-30T03:08:29Z

Sgetahu: /* Email Notifications */

__TOC__

==Background==
Expertiza is an open-source course management web application, that is maintained by students and teaching staff across NC State and other universities. Specifically, Expertiza is used as a platform to help students learn how to work collaboratively on large Object Oriented Programming Assignments. If you would like to learn more about Expertiza, please check the Expertiza wiki[1], or the GitHub page [2]. For our project in particular, we were tasked with improving the mentor management system within Expertiza.

== What is a Mentor? ==
On Expertiza some users are known as mentors. These mentors can both be added to teams manually and automatically assigned if the assignment moderator chooses to select an option where mentors are automatically assigned to teams above 50% capacity. In practice, this means that if you have a max team size of 3, and 2 teammates have been added to team X then team X will automatically be given a mentor.

== Problem Statement ==
The problem we have been faced with is multifaceted. First, we found that when teams are automatically built, students are not getting notified of when they are added to a team. Even more alarming is that when mentors are being added to teams, they aren't getting any type of specialized notification letting them know. Mentors should know when they are mentoring a new team, and students should know when they've been added to a team. Team listing should be improved to be sortable by team name, mentor name, or meeting date.

Expertiza doesn’t know when mentors met with teams, so there would have to be text fields where this information could be entered.

The page would have to be accessible to all mentors and course instructors, but a mentor could only enter meetings for the teams they mentored (except that the instructor could edit any of the meeting dates for any mentor).

Our project sought to fix these issues.

== Tasks ==
=== Email Notifications ===
# Changed mailer function for team addition confirmation
# Add HTML partials for dual role
# Correct mailer function calls when users/mentors are added
# Add tests

=== Mentor Meeting Management ===
# Create a view showing teams, members, and mentors, with meeting date fields.
# Add input fields for each team where mentors and instructors can enter new, view, edit dates when mentor meetings were conducted.
# Instructors can edit all dates for mentor meetings regardless of the team.
# Mentors can also edit dates but only for the team they are mentoring.
# Add more than three dates for the mentor meetings easily by pressing the + icon at the end of the view.
# The meeting dates should not be editable for teams having capacity less than 50%.

=== Backend Controller Updates ===
# Implement a new controller to handle CRUD operations for mentor meetings
# Update models to manage mentor meetings and trigger notifications.

== Implementation ==
=== Email Notifications ===

Here is the previous PR created of the add_member function. The goal of this was to send a notification when members were added.
[[File:Add member email.png|900px|left|alt=Description of image]]
<div style="clear: both;"></div>

Based on the professor's feedback that a mentor can also be a participant, we adjusted the role checking logic to account for all use cases.
[[File:add_member_snippet_code.png|900px|left|alt=Description of image]]

=== Mentor Meeting Management ===

==== Code Changes in Views ====
=====_team.html.erb=====
We reinstituted some of what the previous group did from their pull request to render a new view, refactoring to improve clarity.

[[File:Previous group - refactored.png|1000px|left|alt=Description of image]]

<div style="clear: both;"></div>

We then added on top of it the conditionals requested of us by our scope. The view code below accomplishes most of the prompt's points.
*Establishes mentor and instructor functionality to add/edit meeting dates for their teams/all teams accordingly
*Disables the date field for under capacity teams
*Includes a button to add and remove meeting dates
*includes join functionality for under capacity teams

[[File:Capacity and +.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

This final bit of code in the _team viewfinishes up coverage for dynamically adding meeting dates with the "+" button

[[File:meeting date functionality.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

==== Code Changes in Controllers ====

===== mentor_meeting_controller.rb =====
Made modifications to add the private parameters to be passed through the model.

[[File:meeting parameters.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

==== Code Changes in Test ====
===== mentor_management_spec.rb =====
The previous groups covered much of the testing pretty thoroughly aside from confirming that a mentor is not auto assigned when auto_assign_mentor is false. This is just a tag along to the existing codebase.

[[File:test_auto_assign_mentor.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

=== Backend Controller Updates ===

Code changes in the controller
We added a new controller(mentor_meeting.rb) to perform the CRUD operations on the mentor meeting table.
Implemented the necessary actions (get_dates, add_date, edit_date, delete_date) in the MentorMeetingController.

[[File:Screenshot_2024-10-29_175157.jpg]]

Created a new file, mentor_meeting_notifications.rb
Added the subscription code in that initializer file.
This file allows subscription to the notifications, which will allow handling of any follow-up actions (logging and emails) when meetings are created, updated, or deleted.

Controller Tests
Created a new file, mentor_meeting_controller_spec.rb, in the spec/controllers directory to test the MentorMeetingController

[[File:tests in new file mentor_meeting_controller_spec.jpg]]

Model (Validation Updates)
The MentorMeeting model was updated with basic validations to ensure that required fields (team_id and meeting_date) are present. Validations for team_id and meeting_date ensure data integrity when saving a meeting.

Triggering Notifications
Updated the add_date method to trigger a notification after successfully creating a meeting.
Notifications triggered via ActiveSupport::Notifications.

Helper code
We also wrote a helper code to map all the team IDs in the mentor meeting table to the appropriate meeting dates.

== Relevant Links ==
*Github Repository: https://github.com/ExtremeMachine12/expertiza
*Pull Request: https://github.com/ExtremeMachine12/expertiza/pull/21

== Team ==
===Mentor===
* Nainisha Bhallamudi

=== Members ===
* Anusha Akkireddy (aakkire)
* Simon Getahun (sgetahu)
* Gavin Teague (gwteague)

File:Add member snippet code.png

2024-10-30T03:08:04Z

Sgetahu:

CSC/ECE 517 Fall 2024 - E2460 Mentor-Meeting Management

2024-10-30T03:01:12Z

Sgetahu: /* Email Notifications */

__TOC__

==Background==
Expertiza is an open-source course management web application, that is maintained by students and teaching staff across NC State and other universities. Specifically, Expertiza is used as a platform to help students learn how to work collaboratively on large Object Oriented Programming Assignments. If you would like to learn more about Expertiza, please check the Expertiza wiki[1], or the GitHub page [2]. For our project in particular, we were tasked with improving the mentor management system within Expertiza.

== What is a Mentor? ==
On Expertiza some users are known as mentors. These mentors can both be added to teams manually and automatically assigned if the assignment moderator chooses to select an option where mentors are automatically assigned to teams above 50% capacity. In practice, this means that if you have a max team size of 3, and 2 teammates have been added to team X then team X will automatically be given a mentor.

== Problem Statement ==
The problem we have been faced with is multifaceted. First, we found that when teams are automatically built, students are not getting notified of when they are added to a team. Even more alarming is that when mentors are being added to teams, they aren't getting any type of specialized notification letting them know. Mentors should know when they are mentoring a new team, and students should know when they've been added to a team. Team listing should be improved to be sortable by team name, mentor name, or meeting date.

Expertiza doesn’t know when mentors met with teams, so there would have to be text fields where this information could be entered.

The page would have to be accessible to all mentors and course instructors, but a mentor could only enter meetings for the teams they mentored (except that the instructor could edit any of the meeting dates for any mentor).

Our project sought to fix these issues.

== Tasks ==
=== Email Notifications ===
# Changed mailer function for team addition confirmation
# Add HTML partials for dual role
# Correct mailer function calls when users/mentors are added
# Add tests

=== Mentor Meeting Management ===
# Create a view showing teams, members, and mentors, with meeting date fields.
# Add input fields for each team where mentors and instructors can enter new, view, edit dates when mentor meetings were conducted.
# Instructors can edit all dates for mentor meetings regardless of the team.
# Mentors can also edit dates but only for the team they are mentoring.
# Add more than three dates for the mentor meetings easily by pressing the + icon at the end of the view.
# The meeting dates should not be editable for teams having capacity less than 50%.

=== Backend Controller Updates ===
# Implement a new controller to handle CRUD operations for mentor meetings
# Update models to manage mentor meetings and trigger notifications.

== Implementation ==
=== Email Notifications ===
[[File:Add member email.png|900px|left|alt=Description of image]]
<div style="clear: both;"></div>

=== Mentor Meeting Management ===

==== Code Changes in Views ====
=====_team.html.erb=====
We reinstituted some of what the previous group did from their pull request to render a new view, refactoring to improve clarity.

[[File:Previous group - refactored.png|1000px|left|alt=Description of image]]

<div style="clear: both;"></div>

We then added on top of it the conditionals requested of us by our scope. The view code below accomplishes most of the prompt's points.
*Establishes mentor and instructor functionality to add/edit meeting dates for their teams/all teams accordingly
*Disables the date field for under capacity teams
*Includes a button to add and remove meeting dates
*includes join functionality for under capacity teams

[[File:Capacity and +.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

This final bit of code in the _team viewfinishes up coverage for dynamically adding meeting dates with the "+" button

[[File:meeting date functionality.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

==== Code Changes in Controllers ====

===== mentor_meeting_controller.rb =====
Made modifications to add the private parameters to be passed through the model.

[[File:meeting parameters.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

==== Code Changes in Test ====
===== mentor_management_spec.rb =====
The previous groups covered much of the testing pretty thoroughly aside from confirming that a mentor is not auto assigned when auto_assign_mentor is false. This is just a tag along to the existing codebase.

[[File:test_auto_assign_mentor.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

=== Backend Controller Updates ===

Code changes in the controller
We added a new controller(mentor_meeting.rb) to perform the CRUD operations on the mentor meeting table.
Implemented the necessary actions (get_dates, add_date, edit_date, delete_date) in the MentorMeetingController.

[[File:Screenshot_2024-10-29_175157.jpg]]

Created a new file, mentor_meeting_notifications.rb
Added the subscription code in that initializer file.
This file allows subscription to the notifications, which will allow handling of any follow-up actions (logging and emails) when meetings are created, updated, or deleted.

Controller Tests
Created a new file, mentor_meeting_controller_spec.rb, in the spec/controllers directory to test the MentorMeetingController

[[File:tests in new file mentor_meeting_controller_spec.jpg]]

Model (Validation Updates)
The MentorMeeting model was updated with basic validations to ensure that required fields (team_id and meeting_date) are present. Validations for team_id and meeting_date ensure data integrity when saving a meeting.

Triggering Notifications
Updated the add_date method to trigger a notification after successfully creating a meeting.
Notifications triggered via ActiveSupport::Notifications.

Helper code
We also wrote a helper code to map all the team IDs in the mentor meeting table to the appropriate meeting dates.

== Relevant Links ==
*Github Repository: https://github.com/ExtremeMachine12/expertiza
*Pull Request: https://github.com/ExtremeMachine12/expertiza/pull/21

== Team ==
===Mentor===
* Nainisha Bhallamudi

=== Members ===
* Anusha Akkireddy (aakkire)
* Simon Getahun (sgetahu)
* Gavin Teague (gwteague)

CSC/ECE 517 Fall 2024 - E2460 Mentor-Meeting Management

2024-10-30T02:57:06Z

Sgetahu: /* Email Notifications */

__TOC__

==Background==
Expertiza is an open-source course management web application, that is maintained by students and teaching staff across NC State and other universities. Specifically, Expertiza is used as a platform to help students learn how to work collaboratively on large Object Oriented Programming Assignments. If you would like to learn more about Expertiza, please check the Expertiza wiki[1], or the GitHub page [2]. For our project in particular, we were tasked with improving the mentor management system within Expertiza.

== What is a Mentor? ==
On Expertiza some users are known as mentors. These mentors can both be added to teams manually and automatically assigned if the assignment moderator chooses to select an option where mentors are automatically assigned to teams above 50% capacity. In practice, this means that if you have a max team size of 3, and 2 teammates have been added to team X then team X will automatically be given a mentor.

== Problem Statement ==
The problem we have been faced with is multifaceted. First, we found that when teams are automatically built, students are not getting notified of when they are added to a team. Even more alarming is that when mentors are being added to teams, they aren't getting any type of specialized notification letting them know. Mentors should know when they are mentoring a new team, and students should know when they've been added to a team. Team listing should be improved to be sortable by team name, mentor name, or meeting date.

Expertiza doesn’t know when mentors met with teams, so there would have to be text fields where this information could be entered.

The page would have to be accessible to all mentors and course instructors, but a mentor could only enter meetings for the teams they mentored (except that the instructor could edit any of the meeting dates for any mentor).

Our project sought to fix these issues.

== Tasks ==
=== Email Notifications ===
# Changed mailer function for team addition confirmation
# Add HTML partials for dual role
# Correct mailer function calls when users/mentors are added
# Add tests

=== Mentor Meeting Management ===
# Create a view showing teams, members, and mentors, with meeting date fields.
# Add input fields for each team where mentors and instructors can enter new, view, edit dates when mentor meetings were conducted.
# Instructors can edit all dates for mentor meetings regardless of the team.
# Mentors can also edit dates but only for the team they are mentoring.
# Add more than three dates for the mentor meetings easily by pressing the + icon at the end of the view.
# The meeting dates should not be editable for teams having capacity less than 50%.

=== Backend Controller Updates ===
# Implement a new controller to handle CRUD operations for mentor meetings
# Update models to manage mentor meetings and trigger notifications.

== Implementation ==
=== Email Notifications ===
[[File:add_member_code.png|900px|left|alt=Description of image]]
<div style="clear: both;"></div>

=== Mentor Meeting Management ===

==== Code Changes in Views ====
=====_team.html.erb=====
We reinstituted some of what the previous group did from their pull request to render a new view, refactoring to improve clarity.

[[File:Previous group - refactored.png|1000px|left|alt=Description of image]]

<div style="clear: both;"></div>

We then added on top of it the conditionals requested of us by our scope. The view code below accomplishes most of the prompt's points.
*Establishes mentor and instructor functionality to add/edit meeting dates for their teams/all teams accordingly
*Disables the date field for under capacity teams
*Includes a button to add and remove meeting dates
*includes join functionality for under capacity teams

[[File:Capacity and +.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

This final bit of code in the _team viewfinishes up coverage for dynamically adding meeting dates with the "+" button

[[File:meeting date functionality.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

==== Code Changes in Controllers ====

===== mentor_meeting_controller.rb =====
Made modifications to add the private parameters to be passed through the model.

[[File:meeting parameters.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

==== Code Changes in Test ====
===== mentor_management_spec.rb =====
The previous groups covered much of the testing pretty thoroughly aside from confirming that a mentor is not auto assigned when auto_assign_mentor is false. This is just a tag along to the existing codebase.

[[File:test_auto_assign_mentor.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

=== Backend Controller Updates ===

Code changes in the controller
We added a new controller(mentor_meeting.rb) to perform the CRUD operations on the mentor meeting table.
Implemented the necessary actions (get_dates, add_date, edit_date, delete_date) in the MentorMeetingController.

[[File:Screenshot_2024-10-29_175157.jpg]]

Created a new file, mentor_meeting_notifications.rb
Added the subscription code in that initializer file.
This file allows subscription to the notifications, which will allow handling of any follow-up actions (logging and emails) when meetings are created, updated, or deleted.

Controller Tests
Created a new file, mentor_meeting_controller_spec.rb, in the spec/controllers directory to test the MentorMeetingController

[[File:tests in new file mentor_meeting_controller_spec.jpg]]

Model (Validation Updates)
The MentorMeeting model was updated with basic validations to ensure that required fields (team_id and meeting_date) are present. Validations for team_id and meeting_date ensure data integrity when saving a meeting.

Triggering Notifications
Updated the add_date method to trigger a notification after successfully creating a meeting.
Notifications triggered via ActiveSupport::Notifications.

Helper code
We also wrote a helper code to map all the team IDs in the mentor meeting table to the appropriate meeting dates.

== Relevant Links ==
*Github Repository: https://github.com/ExtremeMachine12/expertiza
*Pull Request: https://github.com/ExtremeMachine12/expertiza/pull/21

== Team ==
===Mentor===
* Nainisha Bhallamudi

=== Members ===
* Anusha Akkireddy (aakkire)
* Simon Getahun (sgetahu)
* Gavin Teague (gwteague)

CSC/ECE 517 Fall 2024 - E2460 Mentor-Meeting Management

2024-10-30T02:56:44Z

Sgetahu: /* Email Notifications */

__TOC__

==Background==
Expertiza is an open-source course management web application, that is maintained by students and teaching staff across NC State and other universities. Specifically, Expertiza is used as a platform to help students learn how to work collaboratively on large Object Oriented Programming Assignments. If you would like to learn more about Expertiza, please check the Expertiza wiki[1], or the GitHub page [2]. For our project in particular, we were tasked with improving the mentor management system within Expertiza.

== What is a Mentor? ==
On Expertiza some users are known as mentors. These mentors can both be added to teams manually and automatically assigned if the assignment moderator chooses to select an option where mentors are automatically assigned to teams above 50% capacity. In practice, this means that if you have a max team size of 3, and 2 teammates have been added to team X then team X will automatically be given a mentor.

== Problem Statement ==
The problem we have been faced with is multifaceted. First, we found that when teams are automatically built, students are not getting notified of when they are added to a team. Even more alarming is that when mentors are being added to teams, they aren't getting any type of specialized notification letting them know. Mentors should know when they are mentoring a new team, and students should know when they've been added to a team. Team listing should be improved to be sortable by team name, mentor name, or meeting date.

Expertiza doesn’t know when mentors met with teams, so there would have to be text fields where this information could be entered.

The page would have to be accessible to all mentors and course instructors, but a mentor could only enter meetings for the teams they mentored (except that the instructor could edit any of the meeting dates for any mentor).

Our project sought to fix these issues.

== Tasks ==
=== Email Notifications ===
# Changed mailer function for team addition confirmation
# Add HTML partials for dual role
# Correct mailer function calls when users/mentors are added
# Add tests

=== Mentor Meeting Management ===
# Create a view showing teams, members, and mentors, with meeting date fields.
# Add input fields for each team where mentors and instructors can enter new, view, edit dates when mentor meetings were conducted.
# Instructors can edit all dates for mentor meetings regardless of the team.
# Mentors can also edit dates but only for the team they are mentoring.
# Add more than three dates for the mentor meetings easily by pressing the + icon at the end of the view.
# The meeting dates should not be editable for teams having capacity less than 50%.

=== Backend Controller Updates ===
# Implement a new controller to handle CRUD operations for mentor meetings
# Update models to manage mentor meetings and trigger notifications.

== Implementation ==
=== Email Notifications ===
[[File:add_member_code.png|900px|left|alt=Description of image]]

=== Mentor Meeting Management ===

==== Code Changes in Views ====
=====_team.html.erb=====
We reinstituted some of what the previous group did from their pull request to render a new view, refactoring to improve clarity.

[[File:Previous group - refactored.png|1000px|left|alt=Description of image]]

<div style="clear: both;"></div>

We then added on top of it the conditionals requested of us by our scope. The view code below accomplishes most of the prompt's points.
*Establishes mentor and instructor functionality to add/edit meeting dates for their teams/all teams accordingly
*Disables the date field for under capacity teams
*Includes a button to add and remove meeting dates
*includes join functionality for under capacity teams

[[File:Capacity and +.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

This final bit of code in the _team viewfinishes up coverage for dynamically adding meeting dates with the "+" button

[[File:meeting date functionality.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

==== Code Changes in Controllers ====

===== mentor_meeting_controller.rb =====
Made modifications to add the private parameters to be passed through the model.

[[File:meeting parameters.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

==== Code Changes in Test ====
===== mentor_management_spec.rb =====
The previous groups covered much of the testing pretty thoroughly aside from confirming that a mentor is not auto assigned when auto_assign_mentor is false. This is just a tag along to the existing codebase.

[[File:test_auto_assign_mentor.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

=== Backend Controller Updates ===

Code changes in the controller
We added a new controller(mentor_meeting.rb) to perform the CRUD operations on the mentor meeting table.
Implemented the necessary actions (get_dates, add_date, edit_date, delete_date) in the MentorMeetingController.

[[File:Screenshot_2024-10-29_175157.jpg]]

Created a new file, mentor_meeting_notifications.rb
Added the subscription code in that initializer file.
This file allows subscription to the notifications, which will allow handling of any follow-up actions (logging and emails) when meetings are created, updated, or deleted.

Controller Tests
Created a new file, mentor_meeting_controller_spec.rb, in the spec/controllers directory to test the MentorMeetingController

[[File:tests in new file mentor_meeting_controller_spec.jpg]]

Model (Validation Updates)
The MentorMeeting model was updated with basic validations to ensure that required fields (team_id and meeting_date) are present. Validations for team_id and meeting_date ensure data integrity when saving a meeting.

Triggering Notifications
Updated the add_date method to trigger a notification after successfully creating a meeting.
Notifications triggered via ActiveSupport::Notifications.

Helper code
We also wrote a helper code to map all the team IDs in the mentor meeting table to the appropriate meeting dates.

== Relevant Links ==
*Github Repository: https://github.com/ExtremeMachine12/expertiza
*Pull Request: https://github.com/ExtremeMachine12/expertiza/pull/21

== Team ==
===Mentor===
* Nainisha Bhallamudi

=== Members ===
* Anusha Akkireddy (aakkire)
* Simon Getahun (sgetahu)
* Gavin Teague (gwteague)

CSC/ECE 517 Fall 2024 - E2460 Mentor-Meeting Management

2024-10-30T02:55:21Z

Sgetahu: /* Email Notifications */

__TOC__

==Background==
Expertiza is an open-source course management web application, that is maintained by students and teaching staff across NC State and other universities. Specifically, Expertiza is used as a platform to help students learn how to work collaboratively on large Object Oriented Programming Assignments. If you would like to learn more about Expertiza, please check the Expertiza wiki[1], or the GitHub page [2]. For our project in particular, we were tasked with improving the mentor management system within Expertiza.

== What is a Mentor? ==
On Expertiza some users are known as mentors. These mentors can both be added to teams manually and automatically assigned if the assignment moderator chooses to select an option where mentors are automatically assigned to teams above 50% capacity. In practice, this means that if you have a max team size of 3, and 2 teammates have been added to team X then team X will automatically be given a mentor.

== Problem Statement ==
The problem we have been faced with is multifaceted. First, we found that when teams are automatically built, students are not getting notified of when they are added to a team. Even more alarming is that when mentors are being added to teams, they aren't getting any type of specialized notification letting them know. Mentors should know when they are mentoring a new team, and students should know when they've been added to a team. Team listing should be improved to be sortable by team name, mentor name, or meeting date.

Expertiza doesn’t know when mentors met with teams, so there would have to be text fields where this information could be entered.

The page would have to be accessible to all mentors and course instructors, but a mentor could only enter meetings for the teams they mentored (except that the instructor could edit any of the meeting dates for any mentor).

Our project sought to fix these issues.

== Tasks ==
=== Email Notifications ===
# Changed mailer function for team addition confirmation
# Add HTML partials for dual role
# Correct mailer function calls when users/mentors are added
# Add tests

=== Mentor Meeting Management ===
# Create a view showing teams, members, and mentors, with meeting date fields.
# Add input fields for each team where mentors and instructors can enter new, view, edit dates when mentor meetings were conducted.
# Instructors can edit all dates for mentor meetings regardless of the team.
# Mentors can also edit dates but only for the team they are mentoring.
# Add more than three dates for the mentor meetings easily by pressing the + icon at the end of the view.
# The meeting dates should not be editable for teams having capacity less than 50%.

=== Backend Controller Updates ===
# Implement a new controller to handle CRUD operations for mentor meetings
# Update models to manage mentor meetings and trigger notifications.

== Implementation ==
=== Email Notifications ===
[[File:add_member_code.png|1000px|left|alt=Description of image]]

=== Mentor Meeting Management ===

==== Code Changes in Views ====
=====_team.html.erb=====
We reinstituted some of what the previous group did from their pull request to render a new view, refactoring to improve clarity.

[[File:Previous group - refactored.png|1000px|left|alt=Description of image]]

<div style="clear: both;"></div>

We then added on top of it the conditionals requested of us by our scope. The view code below accomplishes most of the prompt's points.
*Establishes mentor and instructor functionality to add/edit meeting dates for their teams/all teams accordingly
*Disables the date field for under capacity teams
*Includes a button to add and remove meeting dates
*includes join functionality for under capacity teams

[[File:Capacity and +.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

This final bit of code in the _team viewfinishes up coverage for dynamically adding meeting dates with the "+" button

[[File:meeting date functionality.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

==== Code Changes in Controllers ====

===== mentor_meeting_controller.rb =====
Made modifications to add the private parameters to be passed through the model.

[[File:meeting parameters.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

==== Code Changes in Test ====
===== mentor_management_spec.rb =====
The previous groups covered much of the testing pretty thoroughly aside from confirming that a mentor is not auto assigned when auto_assign_mentor is false. This is just a tag along to the existing codebase.

[[File:test_auto_assign_mentor.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

=== Backend Controller Updates ===

Code changes in the controller
We added a new controller(mentor_meeting.rb) to perform the CRUD operations on the mentor meeting table.
Implemented the necessary actions (get_dates, add_date, edit_date, delete_date) in the MentorMeetingController.

[[File:Screenshot_2024-10-29_175157.jpg]]

Created a new file, mentor_meeting_notifications.rb
Added the subscription code in that initializer file.
This file allows subscription to the notifications, which will allow handling of any follow-up actions (logging and emails) when meetings are created, updated, or deleted.

Controller Tests
Created a new file, mentor_meeting_controller_spec.rb, in the spec/controllers directory to test the MentorMeetingController

[[File:tests in new file mentor_meeting_controller_spec.jpg]]

Model (Validation Updates)
The MentorMeeting model was updated with basic validations to ensure that required fields (team_id and meeting_date) are present. Validations for team_id and meeting_date ensure data integrity when saving a meeting.

Triggering Notifications
Updated the add_date method to trigger a notification after successfully creating a meeting.
Notifications triggered via ActiveSupport::Notifications.

Helper code
We also wrote a helper code to map all the team IDs in the mentor meeting table to the appropriate meeting dates.

== Relevant Links ==
*Github Repository: https://github.com/ExtremeMachine12/expertiza
*Pull Request: https://github.com/ExtremeMachine12/expertiza/pull/21

== Team ==
===Mentor===
* Nainisha Bhallamudi

=== Members ===
* Anusha Akkireddy (aakkire)
* Simon Getahun (sgetahu)
* Gavin Teague (gwteague)

File:Add member code.png

2024-10-30T02:54:35Z

Sgetahu:

CSC/ECE 517 Fall 2024 - E2460 Mentor-Meeting Management

2024-10-30T02:50:45Z

Sgetahu: /* Email Notifications */

__TOC__

==Background==
Expertiza is an open-source course management web application, that is maintained by students and teaching staff across NC State and other universities. Specifically, Expertiza is used as a platform to help students learn how to work collaboratively on large Object Oriented Programming Assignments. If you would like to learn more about Expertiza, please check the Expertiza wiki[1], or the GitHub page [2]. For our project in particular, we were tasked with improving the mentor management system within Expertiza.

== What is a Mentor? ==
On Expertiza some users are known as mentors. These mentors can both be added to teams manually and automatically assigned if the assignment moderator chooses to select an option where mentors are automatically assigned to teams above 50% capacity. In practice, this means that if you have a max team size of 3, and 2 teammates have been added to team X then team X will automatically be given a mentor.

== Problem Statement ==
The problem we have been faced with is multifaceted. First, we found that when teams are automatically built, students are not getting notified of when they are added to a team. Even more alarming is that when mentors are being added to teams, they aren't getting any type of specialized notification letting them know. Mentors should know when they are mentoring a new team, and students should know when they've been added to a team. Team listing should be improved to be sortable by team name, mentor name, or meeting date.

Expertiza doesn’t know when mentors met with teams, so there would have to be text fields where this information could be entered.

The page would have to be accessible to all mentors and course instructors, but a mentor could only enter meetings for the teams they mentored (except that the instructor could edit any of the meeting dates for any mentor).

Our project sought to fix these issues.

== Tasks ==
=== Email Notifications ===
# Changed mailer function for team addition confirmation
# Add HTML partials for dual role
# Correct mailer function calls when users/mentors are added
# Add tests

=== Mentor Meeting Management ===
# Create a view showing teams, members, and mentors, with meeting date fields.
# Add input fields for each team where mentors and instructors can enter new, view, edit dates when mentor meetings were conducted.
# Instructors can edit all dates for mentor meetings regardless of the team.
# Mentors can also edit dates but only for the team they are mentoring.
# Add more than three dates for the mentor meetings easily by pressing the + icon at the end of the view.
# The meeting dates should not be editable for teams having capacity less than 50%.

=== Backend Controller Updates ===
# Implement a new controller to handle CRUD operations for mentor meetings
# Update models to manage mentor meetings and trigger notifications.

== Implementation ==
=== Email Notifications ===

=== Mentor Meeting Management ===

==== Code Changes in Views ====
=====_team.html.erb=====
We reinstituted some of what the previous group did from their pull request to render a new view, refactoring to improve clarity.

[[File:Previous group - refactored.png|1000px|left|alt=Description of image]]

<div style="clear: both;"></div>

We then added on top of it the conditionals requested of us by our scope. The view code below accomplishes most of the prompt's points.
*Establishes mentor and instructor functionality to add/edit meeting dates for their teams/all teams accordingly
*Disables the date field for under capacity teams
*Includes a button to add and remove meeting dates
*includes join functionality for under capacity teams

[[File:Capacity and +.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

This final bit of code in the _team viewfinishes up coverage for dynamically adding meeting dates with the "+" button

[[File:meeting date functionality.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

==== Code Changes in Controllers ====

===== mentor_meeting_controller.rb =====
Made modifications to add the private parameters to be passed through the model.

[[File:meeting parameters.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

==== Code Changes in Test ====
===== mentor_management_spec.rb =====
The previous groups covered much of the testing pretty thoroughly aside from confirming that a mentor is not auto assigned when auto_assign_mentor is false. This is just a tag along to the existing codebase.

[[File:test_auto_assign_mentor.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

=== Backend Controller Updates ===

Code changes in the controller
We added a new controller(mentor_meeting.rb) to perform the CRUD operations on the mentor meeting table.
Implemented the necessary actions (get_dates, add_date, edit_date, delete_date) in the MentorMeetingController.

[[File:Screenshot_2024-10-29_175157.jpg]]

Created a new file, mentor_meeting_notifications.rb
Added the subscription code in that initializer file.
This file allows subscription to the notifications, which will allow handling of any follow-up actions (logging and emails) when meetings are created, updated, or deleted.

Controller Tests
Created a new file, mentor_meeting_controller_spec.rb, in the spec/controllers directory to test the MentorMeetingController

[[File:tests in new file mentor_meeting_controller_spec.jpg]]

Model (Validation Updates)
The MentorMeeting model was updated with basic validations to ensure that required fields (team_id and meeting_date) are present. Validations for team_id and meeting_date ensure data integrity when saving a meeting.

Triggering Notifications
Updated the add_date method to trigger a notification after successfully creating a meeting.
Notifications triggered via ActiveSupport::Notifications.

Helper code
We also wrote a helper code to map all the team IDs in the mentor meeting table to the appropriate meeting dates.

== Relevant Links ==
*Github Repository: https://github.com/ExtremeMachine12/expertiza
*Pull Request: https://github.com/expertiza/expertiza/pull/2769
*Pull Request: https://github.com/expertiza/expertiza/pull/2772

== Team ==
===Mentor===
* Nainisha Bhallamudi

=== Members ===
* Anusha Akkireddy (aakkire)
* Simon Getahun (sgetahu)
* Gavin Teague (gwteague)

CSC/ECE 517 Fall 2024 - E2460 Mentor-Meeting Management

2024-10-30T02:50:23Z

Sgetahu: /* Email Notifications */

__TOC__

==Background==
Expertiza is an open-source course management web application, that is maintained by students and teaching staff across NC State and other universities. Specifically, Expertiza is used as a platform to help students learn how to work collaboratively on large Object Oriented Programming Assignments. If you would like to learn more about Expertiza, please check the Expertiza wiki[1], or the GitHub page [2]. For our project in particular, we were tasked with improving the mentor management system within Expertiza.

== What is a Mentor? ==
On Expertiza some users are known as mentors. These mentors can both be added to teams manually and automatically assigned if the assignment moderator chooses to select an option where mentors are automatically assigned to teams above 50% capacity. In practice, this means that if you have a max team size of 3, and 2 teammates have been added to team X then team X will automatically be given a mentor.

== Problem Statement ==
The problem we have been faced with is multifaceted. First, we found that when teams are automatically built, students are not getting notified of when they are added to a team. Even more alarming is that when mentors are being added to teams, they aren't getting any type of specialized notification letting them know. Mentors should know when they are mentoring a new team, and students should know when they've been added to a team. Team listing should be improved to be sortable by team name, mentor name, or meeting date.

Expertiza doesn’t know when mentors met with teams, so there would have to be text fields where this information could be entered.

The page would have to be accessible to all mentors and course instructors, but a mentor could only enter meetings for the teams they mentored (except that the instructor could edit any of the meeting dates for any mentor).

Our project sought to fix these issues.

== Tasks ==
=== Email Notifications ===
# Changed mailer function for team addition confirmation
# Add HTML partials for dual role
# Corrected mailer function calls when users/mentors were added
# Add tests

=== Mentor Meeting Management ===
# Create a view showing teams, members, and mentors, with meeting date fields.
# Add input fields for each team where mentors and instructors can enter new, view, edit dates when mentor meetings were conducted.
# Instructors can edit all dates for mentor meetings regardless of the team.
# Mentors can also edit dates but only for the team they are mentoring.
# Add more than three dates for the mentor meetings easily by pressing the + icon at the end of the view.
# The meeting dates should not be editable for teams having capacity less than 50%.

=== Backend Controller Updates ===
# Implement a new controller to handle CRUD operations for mentor meetings
# Update models to manage mentor meetings and trigger notifications.

== Implementation ==
=== Email Notifications ===

=== Mentor Meeting Management ===

==== Code Changes in Views ====
=====_team.html.erb=====
We reinstituted some of what the previous group did from their pull request to render a new view, refactoring to improve clarity.

[[File:Previous group - refactored.png|1000px|left|alt=Description of image]]

<div style="clear: both;"></div>

We then added on top of it the conditionals requested of us by our scope. The view code below accomplishes most of the prompt's points.
*Establishes mentor and instructor functionality to add/edit meeting dates for their teams/all teams accordingly
*Disables the date field for under capacity teams
*Includes a button to add and remove meeting dates
*includes join functionality for under capacity teams

[[File:Capacity and +.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

This final bit of code in the _team viewfinishes up coverage for dynamically adding meeting dates with the "+" button

[[File:meeting date functionality.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

==== Code Changes in Controllers ====

===== mentor_meeting_controller.rb =====
Made modifications to add the private parameters to be passed through the model.

[[File:meeting parameters.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

==== Code Changes in Test ====
===== mentor_management_spec.rb =====
The previous groups covered much of the testing pretty thoroughly aside from confirming that a mentor is not auto assigned when auto_assign_mentor is false. This is just a tag along to the existing codebase.

[[File:test_auto_assign_mentor.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

=== Backend Controller Updates ===

Code changes in the controller
We added a new controller(mentor_meeting.rb) to perform the CRUD operations on the mentor meeting table.
Implemented the necessary actions (get_dates, add_date, edit_date, delete_date) in the MentorMeetingController.

[[File:Screenshot_2024-10-29_175157.jpg]]

Created a new file, mentor_meeting_notifications.rb
Added the subscription code in that initializer file.
This file allows subscription to the notifications, which will allow handling of any follow-up actions (logging and emails) when meetings are created, updated, or deleted.

Controller Tests
Created a new file, mentor_meeting_controller_spec.rb, in the spec/controllers directory to test the MentorMeetingController

[[File:tests in new file mentor_meeting_controller_spec.jpg]]

Model (Validation Updates)
The MentorMeeting model was updated with basic validations to ensure that required fields (team_id and meeting_date) are present. Validations for team_id and meeting_date ensure data integrity when saving a meeting.

Triggering Notifications
Updated the add_date method to trigger a notification after successfully creating a meeting.
Notifications triggered via ActiveSupport::Notifications.

Helper code
We also wrote a helper code to map all the team IDs in the mentor meeting table to the appropriate meeting dates.

== Relevant Links ==
*Github Repository: https://github.com/ExtremeMachine12/expertiza
*Pull Request: https://github.com/expertiza/expertiza/pull/2769
*Pull Request: https://github.com/expertiza/expertiza/pull/2772

== Team ==
===Mentor===
* Nainisha Bhallamudi

=== Members ===
* Anusha Akkireddy (aakkire)
* Simon Getahun (sgetahu)
* Gavin Teague (gwteague)

CSC/ECE 517 Fall 2024 - E2460 Mentor-Meeting Management

2024-10-30T02:50:03Z

Sgetahu: /* Email Notifications */

__TOC__

==Background==
Expertiza is an open-source course management web application, that is maintained by students and teaching staff across NC State and other universities. Specifically, Expertiza is used as a platform to help students learn how to work collaboratively on large Object Oriented Programming Assignments. If you would like to learn more about Expertiza, please check the Expertiza wiki[1], or the GitHub page [2]. For our project in particular, we were tasked with improving the mentor management system within Expertiza.

== What is a Mentor? ==
On Expertiza some users are known as mentors. These mentors can both be added to teams manually and automatically assigned if the assignment moderator chooses to select an option where mentors are automatically assigned to teams above 50% capacity. In practice, this means that if you have a max team size of 3, and 2 teammates have been added to team X then team X will automatically be given a mentor.

== Problem Statement ==
The problem we have been faced with is multifaceted. First, we found that when teams are automatically built, students are not getting notified of when they are added to a team. Even more alarming is that when mentors are being added to teams, they aren't getting any type of specialized notification letting them know. Mentors should know when they are mentoring a new team, and students should know when they've been added to a team. Team listing should be improved to be sortable by team name, mentor name, or meeting date.

Expertiza doesn’t know when mentors met with teams, so there would have to be text fields where this information could be entered.

The page would have to be accessible to all mentors and course instructors, but a mentor could only enter meetings for the teams they mentored (except that the instructor could edit any of the meeting dates for any mentor).

Our project sought to fix these issues.

== Tasks ==
=== Email Notifications ===
1. Changed mailer function for team addition confirmation
2. Add HTML partials for dual role
3. Corrected mailer function calls when users/mentors were added
4. Add tests

=== Mentor Meeting Management ===
# Create a view showing teams, members, and mentors, with meeting date fields.
# Add input fields for each team where mentors and instructors can enter new, view, edit dates when mentor meetings were conducted.
# Instructors can edit all dates for mentor meetings regardless of the team.
# Mentors can also edit dates but only for the team they are mentoring.
# Add more than three dates for the mentor meetings easily by pressing the + icon at the end of the view.
# The meeting dates should not be editable for teams having capacity less than 50%.

=== Backend Controller Updates ===
# Implement a new controller to handle CRUD operations for mentor meetings
# Update models to manage mentor meetings and trigger notifications.

== Implementation ==
=== Email Notifications ===

=== Mentor Meeting Management ===

==== Code Changes in Views ====
=====_team.html.erb=====
We reinstituted some of what the previous group did from their pull request to render a new view, refactoring to improve clarity.

[[File:Previous group - refactored.png|1000px|left|alt=Description of image]]

<div style="clear: both;"></div>

We then added on top of it the conditionals requested of us by our scope. The view code below accomplishes most of the prompt's points.
*Establishes mentor and instructor functionality to add/edit meeting dates for their teams/all teams accordingly
*Disables the date field for under capacity teams
*Includes a button to add and remove meeting dates
*includes join functionality for under capacity teams

[[File:Capacity and +.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

This final bit of code in the _team viewfinishes up coverage for dynamically adding meeting dates with the "+" button

[[File:meeting date functionality.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

==== Code Changes in Controllers ====

===== mentor_meeting_controller.rb =====
Made modifications to add the private parameters to be passed through the model.

[[File:meeting parameters.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

==== Code Changes in Test ====
===== mentor_management_spec.rb =====
The previous groups covered much of the testing pretty thoroughly aside from confirming that a mentor is not auto assigned when auto_assign_mentor is false. This is just a tag along to the existing codebase.

[[File:test_auto_assign_mentor.png|750px|left|alt=Description of image]]

<div style="clear: both;"></div>

=== Backend Controller Updates ===

Code changes in the controller
We added a new controller(mentor_meeting.rb) to perform the CRUD operations on the mentor meeting table.
Implemented the necessary actions (get_dates, add_date, edit_date, delete_date) in the MentorMeetingController.

[[File:Screenshot_2024-10-29_175157.jpg]]

Created a new file, mentor_meeting_notifications.rb
Added the subscription code in that initializer file.
This file allows subscription to the notifications, which will allow handling of any follow-up actions (logging and emails) when meetings are created, updated, or deleted.

Controller Tests
Created a new file, mentor_meeting_controller_spec.rb, in the spec/controllers directory to test the MentorMeetingController

[[File:tests in new file mentor_meeting_controller_spec.jpg]]

Model (Validation Updates)
The MentorMeeting model was updated with basic validations to ensure that required fields (team_id and meeting_date) are present. Validations for team_id and meeting_date ensure data integrity when saving a meeting.

Triggering Notifications
Updated the add_date method to trigger a notification after successfully creating a meeting.
Notifications triggered via ActiveSupport::Notifications.

Helper code
We also wrote a helper code to map all the team IDs in the mentor meeting table to the appropriate meeting dates.

== Relevant Links ==
*Github Repository: https://github.com/ExtremeMachine12/expertiza
*Pull Request: https://github.com/expertiza/expertiza/pull/2769
*Pull Request: https://github.com/expertiza/expertiza/pull/2772

== Team ==
===Mentor===
* Nainisha Bhallamudi

=== Members ===
* Anusha Akkireddy (aakkire)
* Simon Getahun (sgetahu)
* Gavin Teague (gwteague)