Expertiza_Wiki - User contributions [en]

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

2024-12-04T03:52:51Z

Aakkire: /* 4.Improved Feedback Indicators */

== 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: new_toggle_sc.png|1200px]]

Here, we can see some extended features for showcasing how many reviews left a comment with greater 10 or 20 words. In addition, we added a title to to give some clarity for a better UI/UX experience as well as adding some padding between the toggle form and heat map.

==== Supporting code ====
[[File: supporting_code.png|600px]]

'showToggle10WordComments' and 'showToggle20WordComments' are boolean values that, if true, will filter over the reviews. When iterating over each review, it first confirms if there is a comment (since comments are defined as a string or undefined). If the comment is a string, it will then filter through each comment to check if its word count is greater than the toggle option (10 or 20). The filter() method returns the number of such comments using the .length property.

* ''' 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-04T03:52:26Z

Aakkire: /* 3.Export Options for Tables */

== 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:'''
‎<br> Last Updated: {lastUpdated ? lastUpdated.toLocaleString() : "Never"} <br>
‎<br> <button onClick={refreshTableData}>Refresh Data</button> <br>

=== 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: new_toggle_sc.png|1200px]]

Here, we can see some extended features for showcasing how many reviews left a comment with greater 10 or 20 words. In addition, we added a title to to give some clarity for a better UI/UX experience as well as adding some padding between the toggle form and heat map.

==== Supporting code ====
[[File: supporting_code.png|600px]]

'showToggle10WordComments' and 'showToggle20WordComments' are boolean values that, if true, will filter over the reviews. When iterating over each review, it first confirms if there is a comment (since comments are defined as a string or undefined). If the comment is a string, it will then filter through each comment to check if its word count is greater than the toggle option (10 or 20). The filter() method returns the number of such comments using the .length property.

* ''' 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-04T03:51:27Z

Aakkire: /* 3.Export Options for Tables */

== 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>

=== 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:'''
‎<br> Last Updated: {lastUpdated ? lastUpdated.toLocaleString() : "Never"} <br>
‎<br> <button onClick={refreshTableData}>Refresh Data</button> <br>

=== 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: new_toggle_sc.png|1200px]]

Here, we can see some extended features for showcasing how many reviews left a comment with greater 10 or 20 words. In addition, we added a title to to give some clarity for a better UI/UX experience as well as adding some padding between the toggle form and heat map.

==== Supporting code ====
[[File: supporting_code.png|600px]]

'showToggle10WordComments' and 'showToggle20WordComments' are boolean values that, if true, will filter over the reviews. When iterating over each review, it first confirms if there is a comment (since comments are defined as a string or undefined). If the comment is a string, it will then filter through each comment to check if its word count is greater than the toggle option (10 or 20). The filter() method returns the number of such comments using the .length property.

* ''' 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-04T03:51:10Z

Aakkire: /* 3.Export Options for Tables */

== 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>

=== 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:'''
‎<br> Last Updated: {lastUpdated ? lastUpdated.toLocaleString() : "Never"} <br>
‎<br> <button onClick={refreshTableData}>Refresh Data</button> <br>

=== 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: new_toggle_sc.png|1200px]]

Here, we can see some extended features for showcasing how many reviews left a comment with greater 10 or 20 words. In addition, we added a title to to give some clarity for a better UI/UX experience as well as adding some padding between the toggle form and heat map.

==== Supporting code ====
[[File: supporting_code.png|600px]]

'showToggle10WordComments' and 'showToggle20WordComments' are boolean values that, if true, will filter over the reviews. When iterating over each review, it first confirms if there is a comment (since comments are defined as a string or undefined). If the comment is a string, it will then filter through each comment to check if its word count is greater than the toggle option (10 or 20). The filter() method returns the number of such comments using the .length property.

* ''' 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-04T03:49:32Z

Aakkire: /* 3.Export Options for Tables */

== 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}`);
};

=== 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:'''
‎<br> Last Updated: {lastUpdated ? lastUpdated.toLocaleString() : "Never"} <br>
‎<br> <button onClick={refreshTableData}>Refresh Data</button> <br>

=== 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: new_toggle_sc.png|1200px]]

Here, we can see some extended features for showcasing how many reviews left a comment with greater 10 or 20 words. In addition, we added a title to to give some clarity for a better UI/UX experience as well as adding some padding between the toggle form and heat map.

==== Supporting code ====
[[File: supporting_code.png|600px]]

'showToggle10WordComments' and 'showToggle20WordComments' are boolean values that, if true, will filter over the reviews. When iterating over each review, it first confirms if there is a comment (since comments are defined as a string or undefined). If the comment is a string, it will then filter through each comment to check if its word count is greater than the toggle option (10 or 20). The filter() method returns the number of such comments using the .length property.

* ''' 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-04T03:48:57Z

Aakkire: /* 3.Export Options for Tables */

== 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:'''
‎<br>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}`);
};
‎<br>
‎<br><button onClick={() => exportTableData('xlsx')}>Export to Excel</button> ‎<br>

=== 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:'''
‎<br> Last Updated: {lastUpdated ? lastUpdated.toLocaleString() : "Never"} <br>
‎<br> <button onClick={refreshTableData}>Refresh Data</button> <br>

=== 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: new_toggle_sc.png|1200px]]

Here, we can see some extended features for showcasing how many reviews left a comment with greater 10 or 20 words. In addition, we added a title to to give some clarity for a better UI/UX experience as well as adding some padding between the toggle form and heat map.

==== Supporting code ====
[[File: supporting_code.png|600px]]

'showToggle10WordComments' and 'showToggle20WordComments' are boolean values that, if true, will filter over the reviews. When iterating over each review, it first confirms if there is a comment (since comments are defined as a string or undefined). If the comment is a string, it will then filter through each comment to check if its word count is greater than the toggle option (10 or 20). The filter() method returns the number of such comments using the .length property.

* ''' 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-02T23:30:05Z

Aakkire: /* 3.Export Options for Tables */

== 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

=== 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
src/pages/ViewTeamGrades/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:'''
‎<br><button onClick={() => exportTableData('csv')}>Export to CSV</button> ‎<br>
‎<br><button onClick={() => exportTableData('xlsx')}>Export to Excel</button> ‎<br>

=== 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:'''
‎<br> Last Updated: {lastUpdated ? lastUpdated.toLocaleString() : "Never"} <br>
‎<br> <button onClick={refreshTableData}>Refresh Data</button> <br>

=== 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: new_toggle_sc.png|1200px]]

Here, we can see some extended features for showcasing how many reviews left a comment with greater 10 or 20 words. In addition, we added a title to to give some clarity for a better UI/UX experience as well as adding some padding between the toggle form and heat map.

==== Supporting code ====
[[File: supporting_code.png|600px]]

'showToggle10WordComments' and 'showToggle20WordComments' are boolean values that, if true, will filter over the reviews. When iterating over each review, it first confirms if there is a comment (since comments are defined as a string or undefined). If the comment is a string, it will then filter through each comment to check if its word count is greater than the toggle option (10 or 20). The filter() method returns the number of such comments using the .length property.

* ''' 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.

== 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-11-19T03:36:19Z

Aakkire: /* Test Cases: */

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

2024-11-19T03:36:06Z

Aakkire: /* Testing Scope */

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

2024-11-19T03:33:58Z

Aakkire: /* Test Plan */

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

2024-11-19T03:32:16Z

Aakkire: /* Test Plan */

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

2024-11-13T01:38:18Z

Aakkire: /* 3.Improved Feedback Indicators */

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

2024-11-13T01:37:48Z

Aakkire: /* 3.Improved Feedback Indicators */

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

2024-11-13T01:08:40Z

Aakkire: /* 3.Improved Feedback Indicators */

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

2024-11-13T01:08:19Z

Aakkire: /* 3.Improved Feedback Indicators */

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

2024-11-13T01:08:10Z

Aakkire: /* 3.Improved Feedback Indicators */

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

2024-11-13T01:07:55Z

Aakkire: /* 3.Improved Feedback Indicators */

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

2024-11-13T01:07:38Z

Aakkire: /* 3.Improved Feedback Indicators */

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

2024-11-13T01:07:08Z

Aakkire: /* 3.Improved Feedback Indicators */

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

2024-11-13T01:06:32Z

Aakkire: /* 3.Improved Feedback Indicators */

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

2024-11-13T01:04:27Z

Aakkire: /* 2.Export Options for Tables */

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

2024-11-13T01:04:14Z

Aakkire: /* 2.Export Options for Tables */

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

2024-11-13T01:03:04Z

Aakkire: /* 3.Improved Feedback Indicators */

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

2024-11-13T01:02:18Z

Aakkire: /* 3.Improved Feedback Indicators */

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

2024-11-13T01:01:26Z

Aakkire: /* 2.Export Options for Tables */

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

2024-11-13T01:00:57Z

Aakkire: /* 2.Export Options for Tables */

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

2024-11-13T00:59:57Z

Aakkire: /* 2.Export Options for Tables */

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

2024-11-13T00:49:19Z

Aakkire: /* Team Members */

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

2024-11-13T00:44:59Z

Aakkire: /* 3.Improved Feedback Indicators */

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

2024-11-13T00:44:10Z

Aakkire: /* 3.Improved Feedback Indicators */

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

2024-11-13T00:43:58Z

Aakkire: /* 2.Export Options for Tables */

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

2024-11-13T00:43:24Z

Aakkire: /* Detail Description of Possible Changes */

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

2024-11-13T00:43:00Z

Aakkire: /* Detail Description of Possible Changes */

CSC/ECE 517 Fall 2024 - E2460 Mentor-Meeting Management

2024-10-29T23:00:12Z

Aakkire: /* Backend Controller Updates */

__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 ===
# understand and reimplement previous team's code (or improve upon it)

=== 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)

File:Tests in new file mentor meeting controller spec.jpg

2024-10-29T23:00:05Z

Aakkire:

CSC/ECE 517 Fall 2024 - E2460 Mentor-Meeting Management

2024-10-29T21:52:41Z

Aakkire: /* Backend Controller Updates */

__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 ===
# understand and reimplement previous team's code (or improve upon it)

=== 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.

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)

File:Screenshot 2024-10-29 175157.jpg

2024-10-29T21:52:22Z

Aakkire:

CSC/ECE 517 Fall 2024 - E2460 Mentor-Meeting Management

2024-10-29T21:46:13Z

Aakkire: /* Backend Controller Updates */

__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 ===
# understand and reimplement previous team's code (or improve upon it)

=== 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 173235.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.

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-29T21:41:44Z

Aakkire: /* Backend Controller Updates */

__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 ===
# understand and reimplement previous team's code (or improve upon it)

=== 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 173235.png|200px|thumb|left|Caption]]

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.

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-29T21:39:50Z

Aakkire: /* Backend Controller Updates */

__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 ===
# understand and reimplement previous team's code (or improve upon it)

=== 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 173235.png|750px|left|alt=Description of image]]

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.

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-29T21:38:46Z

Aakkire: /* Backend Controller Updates */

__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 ===
# understand and reimplement previous team's code (or improve upon it)

=== 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.

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.

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)

File:Screenshot 2024-10-29 173235.jpg

2024-10-29T21:32:51Z

Aakkire:

CSC/ECE 517 Fall 2024 - E2460 Mentor-Meeting Management

2024-10-29T21:32:04Z

Aakkire: /* Backend Controller Updates */

__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 ===
# understand and reimplement previous team's code (or improve upon it)

=== 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.

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.

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-29T21:24:21Z

Aakkire: /* Backend Controller Updates */

__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 ===
# understand and reimplement previous team's code (or improve upon it)

=== 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.

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.

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)