Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2024 - E2494. UI for Teammate Review View

2024-12-04T14:46:47Z

Atapkir:

== Overview ==
After the previous design document submission, we changed projects, with the suggestion and approval of our mentor and Dr. Gehringer, to a reimplementation of the UI for Teammate Review view, which has a larger scope than our previous project. The previous implementation of this UI proposed changes to not only the view files, but the controller and model files as well. This was beyond the scope of the project and complicated the integration of the UI to the existing Expertiza. Thus, our current project will focus on reimplementing the Teammate Review view isolated from other components of the current Expertiza application. Additionally, we focus on implementing a clear and user-friendly UI for both students and instructors. Following the current review display, our main display will show the numerical scores with an associated color as a heat map.

== Previous Design ==
=== Specifications ===
*Display teammate reviews as a colormap corresponding to the numerical scores
*Students should be able to view reviews they have given to their teammates and the reviews their teammates have given them
*There should be a clear indication in the view which reviews the student is viewing (i.e. those they have given or those they have received)
*Instructors should also be able to view a student's reviews from their teammates and the reviews a student has given to their teammates
*The instructor should be able to choose whether teammate reviews are visible to the student or not by a checkbox
*An average score should be shown, for all the relevant reviews, in a clear and useful way
*There should be an anonymized view option where the names of the reviewers should not be shown

=== Design ===
The previous implementation focussed on a few main improvements to the view.
*Displaying the average score for instructors based on the following:
**A student's average received teammate score
**A student's average score given to teammates
*Improving the functionality of the automized view for students when selected by the instructor
**Use case diagram for the anonymized view:
[[File:uml_1.PNG|500px|UML for Anonymized]]

=== Testing ===
Main components to the testing plan included:
*Verifying the different displays for students vs. instructors
*Verifying login credentials
*Improvement in unit tests
*Addition of tests for calculating the average score
*Manual testing of the main display with the correct functionality

== Proposed Design ==

=== Specifications ===
Following the previous project specifications, our project will focus on further development of the user experience and testing, with particular emphasis on team collaboration features.

*Review Interface Layout
**Clean tabbed interface separating "Reviews given" and "Reviews received"
**Toggle controls for showing/hiding review details
**Comprehensive data grid with:
***Question numbers for easy reference
***Question text column
***Individual reviewer columns
***Average score column
***Color-coded scoring cells for visual feedback

*Interactive Elements
**Toggle switches for feature controls
**Hide/Show functionality for review details
**Anonymous mode toggle with visual indicator
**Click-through navigation between different review states

*Visual Hierarchy
**Clear section headers and subheaders
**Consistent spacing and alignment
**Data-dense yet readable table design
**Score highlighting using appropriate color coding:
***Green for high scores
***Orange for medium scores
***Red for attention areas

*Responsive Components
**Flexible grid system for review displays
**Adaptive table layout for different screen sizes
**Maintainable component structure for future extensions
**Consistent padding and margin systems

=== Design ===
Core Architecture

*The system follows a component-based architecture with five key components:
**TeammateReview (Root)**: Main container component managing application state and user roles
**CompositeScore**: Handles score aggregation and display
**ReviewToggle**: Controls view switching between given/received reviews
**TeammateHeatmap**: Visualizes review data in a color-coded matrix
**ShowReviews**: Displays detailed review information

Design Decisions

*State Management
**Redux for global authentication state
**React hooks for local component state
**Local storage for persistent user preferences

*Role-Based Access
**Distinct views for instructors, and students
**Feature toggling based on user roles
**Anonymous review mode option

UML Design

*Instructor: Has full access to manage and view all team reviews, including the ability to view all students' reviews and control students' access permissions to view reviews.
*Student: Can view their own received teammate reviews only if granted permission by the instructor, with no access to other students' review information.
[[File:Teammate view uml.jpg|800px]]

=== Control Flow to access the concerned screens ===
From the student's perspective, they can see the comments he made to his teammates and there is a button available to choose to hide information or view details.

[[File:Teammate view student off.jpg|800px]]

When the student presses the button.

[[File:Teammate view student on.jpg|800px]]

When the instructor grants students permission to view teammate reviews, students can see score and comments from their teammates.

[[File:Teammate view student recevied.jpg|800px]]

In the instructor view, the instructor can choose to enable teammate review visibility permissions.

[[File:Teammate instructor view.jpg|800px]]

== Testing Overview ==
Our testing suite utilizes **React Testing Library (RTL)** with **Jest** as the test runner, focusing on component-level testing that prioritizes user interaction patterns over implementation details. The testing stack includes:
* *React Testing Library* for DOM manipulation and assertions
* *Jest* as the testing framework and runner
* *Redux Mock Store* for simulating Redux state in tests
* *@testing-library/react* for React-specific testing utilities

=== Test Coverage ===
Our test suite covers several key areas:

==== Component Rendering ====
* Verification of component mounting and proper display of UI elements
* Testing of conditional rendering based on props
* Validation of anonymous vs. identified user displays

==== User Interactions ====
* Toggle functionality between different view modes
* Button click handlers and state changes
* Form interactions and user input handling

==== State Management ====
* Redux store integration testing
* State changes based on user roles (Student vs. Instructor)
* Component state management for features like anonymous mode

==== Edge Cases ====
* Empty data handling
* Extreme score values
* Permission-based rendering differences
* Anonymous mode functionality
* Missing or incomplete data scenarios

The tests follow RTL's best practices by focusing on user-centric behavior rather than implementation details, ensuring our components remain maintainable and resilient to refactoring while maintaining their expected functionality from an end-user perspective.

== Test Files Overview ==

=== TeammateHeatmap.test.tsx ===
Tests the heatmap visualization component that displays peer review scores. This component is responsible for showing a matrix of review scores with optional anonymization.

* Renders review scores in a heatmap format
* Handles anonymous mode by masking reviewer names
* Manages empty data states
* Displays question text when enabled
* Shows column averages correctly

[[File:cap1.png]]

=== CompositeScore.test.tsx ===
Tests the component that calculates and displays aggregate scores for both given and received reviews.

* Renders all score sections (given, received, overall)
* Handles empty review sets appropriately
* Correctly calculates scores for extreme cases (0 and 5)
* Displays formatted scores with proper decimal places
* Maintains correct score calculations across different review types

[[File:cap2.png]]

=== ReviewToggle.test.tsx ===
Tests the toggle mechanism that switches between "Reviews Given" and "Reviews Received" views.

* Renders appropriate buttons based on user permissions
* Handles toggle state changes correctly
* Shows/hides received reviews based on permissions
* Special handling for instructor views
* Maintains correct active states for buttons

[[File:cap3.png]]

=== TeammateReview.test.tsx ===
Tests the main container component that orchestrates the entire teammate review feature.

* Renders the main interface elements
* Toggles between review views (given/received)
* Controls question list visibility
* Manages anonymous mode
* Handles different user roles (student/instructor)
* Shows/hides review sections
* Integrates with Redux store

[[File:cap4.png]]

=== ShowReviews.test.tsx ===
Tests the component responsible for displaying individual review entries with comments and scores.

* Renders review content correctly
* Handles anonymous mode for reviewer names
* Manages empty review states
* Displays comments and scores appropriately
* Integrates with Redux for user authentication

== Common Testing Patterns ==
All files share several common testing patterns:
* Use of `beforeEach` for test setup
* Mock data initialization
* Edge case handling
* Role-based permission testing
* Integration with Redux store where needed
* Consistent use of RTL's query methods
* Focus on user-centric behavior testing

These tests ensure robust functionality across the teammate review system while maintaining good testing practices and comprehensive coverage of both happy paths and edge cases.

== Team ==
===Mentor===
* Sahil Sawant

=== Members ===
* Arlee Shelby (ashelby@ncsu.edu)
* Aryan Tapkire (atapkir@ncsu.edu)
* Haojie Zhou (hzhou33@ncsu.edu)

==Links ==
*Github Repository: https://github.com/arlee-shelby/expertiza
*Pull Request: https://github.com/expertiza/reimplementation-front-end/pull/82

==References==
[1]https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page

[2]https://github.com/expertiza/reimplementation-front-end

[3]https://github.com/expertiza/reimplementation-back-end

CSC/ECE 517 Fall 2024 - E2494. UI for Teammate Review View

2024-12-04T14:44:43Z

Atapkir:

== Overview ==
After the previous design document submission, we changed projects, with the suggestion and approval of our mentor and Dr. Gehringer, to a reimplementation of the UI for Teammate Review view, which has a larger scope than our previous project. The previous implementation of this UI proposed changes to not only the view files, but the controller and model files as well. This was beyond the scope of the project and complicated the integration of the UI to the existing Expertiza. Thus, our current project will focus on reimplementing the Teammate Review view isolated from other components of the current Expertiza application. Additionally, we focus on implementing a clear and user-friendly UI for both students and instructors. Following the current review display, our main display will show the numerical scores with an associated color as a heat-map.

== Previous Design ==
=== Specifications ===
*Display teammate reviews as a colormap corresponding to the numerical scores
*Students should be able to view reviews they have given to their teammates and the reviews their teammates have given them
**There should be a clear indication in the view which reviews the student is viewing (i.e. those they have given or those they have received)
*Instructors should also be able to view a student's reviews from their teammates and the reviews a student has given for their teammates
*The instructor should be able to chose whether teammate reviews are visible to the student or not by a checkbox
*An average score should be shown, for all the relevant reviews, in a clear and useful way
*There should be an anonymized view option where the names of the reviewer should not be shown

=== Design ===
The previous implementation focussed on a few main improvements to the view.
*Displaying the average score for instructors based on:
**A student's average received teammate score
**A student's average score given to teammates
*Improving the functionality of the automized view for students when selected by the instructor
**Use case diagram for the anonymized view:
[[File:uml_1.PNG|500px|UML for Anonymized]]

=== Testing ===
Main components to the testing plan included:
*Verifying the different displays for students vs. instructors
*Verifying login credentials
*Improvement in unit tests
*Addition of tests for calculating the average score
*Manual testing of the main display with the correct functionality

== Proposed Design ==

=== Specifications ===
Following the previous project specifications, our project will focus on further development of the user experience and testing, with particular emphasis on team collaboration features.

*Review Interface Layout
**Clean tabbed interface separating "Reviews given" and "Reviews received"
**Toggle controls for showing/hiding review details
**Comprehensive data grid with:
***Question numbers for easy reference
***Question text column
***Individual reviewer columns
***Average score column
***Color-coded scoring cells for visual feedback

*Interactive Elements
**Toggle switches for feature controls
**Hide/Show functionality for review details
**Anonymous mode toggle with visual indicator
**Click-through navigation between different review states

*Visual Hierarchy
**Clear section headers and subheaders
**Consistent spacing and alignment
**Data-dense yet readable table design
**Score highlighting using appropriate color coding:
***Green for high scores
***Orange for medium scores
***Red for attention areas

*Responsive Components
**Flexible grid system for review displays
**Adaptive table layout for different screen sizes
**Maintainable component structure for future extensions
**Consistent padding and margin systems

=== Design ===
Core Architecture

*The system follows a component-based architecture with five key components:
**TeammateReview (Root)**: Main container component managing application state and user roles
**CompositeScore**: Handles score aggregation and display
**ReviewToggle**: Controls view switching between given/received reviews
**TeammateHeatmap**: Visualizes review data in a color-coded matrix
**ShowReviews**: Displays detailed review information

Design Decisions

*State Management
**Redux for global authentication state
**React hooks for local component state
**Local storage for persistent user preferences

*Role-Based Access
**Distinct views for instructors, and students
**Feature toggling based on user roles
**Anonymous review mode option

UML Design

*Instructor: Has full access to manage and view all team reviews, including the ability to view all students' reviews and control students' access permissions to view reviews.
*Student: Can view their own received teammate reviews only if granted permission by the instructor, with no access to other students' review information.
[[File:Teammate view uml.jpg|800px]]

=== Control Flow to access the concerned screens ===
From the student's perspective, they can see the comments he made to his teammates and there is a button available to choose to hide information or view details.

[[File:Teammate view student off.jpg|800px]]

When the student presses the button.

[[File:Teammate view student on.jpg|800px]]

When the instructor grants students permission to view teammate reviews, students can see score and comments from their teammates.

[[File:Teammate view student recevied.jpg|800px]]

In the instructor view, the instructor can choose to enable teammate review visibility permissions.

[[File:Teammate instructor view.jpg|800px]]

== Testing Overview ==
Our testing suite utilizes **React Testing Library (RTL)** with **Jest** as the test runner, focusing on component-level testing that prioritizes user interaction patterns over implementation details. The testing stack includes:
* *React Testing Library* for DOM manipulation and assertions
* *Jest* as the testing framework and runner
* *Redux Mock Store* for simulating Redux state in tests
* *@testing-library/react* for React-specific testing utilities

=== Test Coverage ===
Our test suite covers several key areas:

==== Component Rendering ====
* Verification of component mounting and proper display of UI elements
* Testing of conditional rendering based on props
* Validation of anonymous vs. identified user displays

==== User Interactions ====
* Toggle functionality between different view modes
* Button click handlers and state changes
* Form interactions and user input handling

==== State Management ====
* Redux store integration testing
* State changes based on user roles (Student vs. Instructor)
* Component state management for features like anonymous mode

==== Edge Cases ====
* Empty data handling
* Extreme score values
* Permission-based rendering differences
* Anonymous mode functionality
* Missing or incomplete data scenarios

The tests follow RTL's best practices by focusing on user-centric behavior rather than implementation details, ensuring our components remain maintainable and resilient to refactoring while maintaining their expected functionality from an end-user perspective.

== Test Files Overview ==

=== TeammateHeatmap.test.tsx ===
Tests the heatmap visualization component that displays peer review scores. This component is responsible for showing a matrix of review scores with optional anonymization.

* Renders review scores in a heatmap format
* Handles anonymous mode by masking reviewer names
* Manages empty data states
* Displays question text when enabled
* Shows column averages correctly

[[File:cap1.png]]

=== CompositeScore.test.tsx ===
Tests the component that calculates and displays aggregate scores for both given and received reviews.

* Renders all score sections (given, received, overall)
* Handles empty review sets appropriately
* Correctly calculates scores for extreme cases (0 and 5)
* Displays formatted scores with proper decimal places
* Maintains correct score calculations across different review types

[[File:cap2.png]]

=== ReviewToggle.test.tsx ===
Tests the toggle mechanism that switches between "Reviews Given" and "Reviews Received" views.

* Renders appropriate buttons based on user permissions
* Handles toggle state changes correctly
* Shows/hides received reviews based on permissions
* Special handling for instructor views
* Maintains correct active states for buttons

[[File:cap3.png]]

=== TeammateReview.test.tsx ===
Tests the main container component that orchestrates the entire teammate review feature.

* Renders the main interface elements
* Toggles between review views (given/received)
* Controls question list visibility
* Manages anonymous mode
* Handles different user roles (student/instructor)
* Shows/hides review sections
* Integrates with Redux store

[[File:cap4.png]]

=== ShowReviews.test.tsx ===
Tests the component responsible for displaying individual review entries with comments and scores.

* Renders review content correctly
* Handles anonymous mode for reviewer names
* Manages empty review states
* Displays comments and scores appropriately
* Integrates with Redux for user authentication

== Common Testing Patterns ==
All files share several common testing patterns:
* Use of `beforeEach` for test setup
* Mock data initialization
* Edge case handling
* Role-based permission testing
* Integration with Redux store where needed
* Consistent use of RTL's query methods
* Focus on user-centric behavior testing

These tests ensure robust functionality across the teammate review system while maintaining good testing practices and comprehensive coverage of both happy paths and edge cases.

== Team ==
===Mentor===
* Sahil Sawant

=== Members ===
* Arlee Shelby (ashelby@ncsu.edu)
* Aryan Tapkire (atapkir@ncsu.edu)
* Haojie Zhou (hzhou33@ncsu.edu)

==Links ==
*Github Repository: https://github.com/arlee-shelby/expertiza
*Pull Request: https://github.com/expertiza/reimplementation-front-end/pull/82

==References==
[1]https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page

[2]https://github.com/expertiza/reimplementation-front-end

[3]https://github.com/expertiza/reimplementation-back-end

CSC/ECE 517 Fall 2024 - E2494. UI for Teammate Review View

2024-12-04T14:31:42Z

Atapkir:

== Overview ==
After the previous design document submission, we changed projects, with the suggestion and approval of our mentor and Dr. Gehringer, to a reimplementation of the UI for Teammate Review view, which has a larger scope than our previous project. The previous implementation of this UI proposed changes to not only the view files, but the controller and model files as well. This was beyond the scope of the project and complicated the integration of the UI to the existing Expertiza. Thus, our current project will focus on reimplementing the Teammate Review view isolated from other components of the current Expertiza application. Additionally, we focus on implementing a clear and user-friendly UI for both students and instructors. Following the current review display, our main display will show the numerical scores with an associated color as a heat-map.

== Previous Design ==
=== Specifications ===
*Display teammate reviews as a colormap corresponding to the numerical scores
*Students should be able to view reviews they have given to their teammates and the reviews their teammates have given them
**There should be a clear indication in the view which reviews the student is viewing (i.e. those they have given or those they have received)
*Instructors should also be able to view a student's reviews from their teammates and the reviews a student has given for their teammates
*The instructor should be able to chose whether teammate reviews are visible to the student or not by a checkbox
*An average score should be shown, for all the relevant reviews, in a clear and useful way
*There should be an anonymized view option where the names of the reviewer should not be shown

=== Design ===
The previous implementation focussed on a few main improvements to the view.
*Displaying the average score for instructors based on:
**A student's average received teammate score
**A student's average score given to teammates
*Improving the functionality of the automized view for students when selected by the instructor
**Use case diagram for the anonymized view:
[[File:uml_1.PNG|500px|UML for Anonymized]]

=== Testing ===
Main components to the testing plan included:
*Verifying the different displays for students vs. instructors
*Verifying login credentials
*Improvement in unit tests
*Addition of tests for calculating the average score
*Manual testing of the main display with the correct functionality

== Proposed Design ==

=== Specifications ===
Following the previous project specifications, our project will focus on further development of the user experience and testing, with particular emphasis on team collaboration features.

*Review Interface Layout
**Clean tabbed interface separating "Reviews given" and "Reviews received"
**Toggle controls for showing/hiding review details
**Comprehensive data grid with:
***Question numbers for easy reference
***Question text column
***Individual reviewer columns
***Average score column
***Color-coded scoring cells for visual feedback

*Interactive Elements
**Toggle switches for feature controls
**Hide/Show functionality for review details
**Anonymous mode toggle with visual indicator
**Click-through navigation between different review states

*Visual Hierarchy
**Clear section headers and subheaders
**Consistent spacing and alignment
**Data-dense yet readable table design
**Score highlighting using appropriate color coding:
***Green for high scores
***Orange for medium scores
***Red for attention areas

*Responsive Components
**Flexible grid system for review displays
**Adaptive table layout for different screen sizes
**Maintainable component structure for future extensions
**Consistent padding and margin systems

=== Design ===
Core Architecture

*The system follows a component-based architecture with five key components:
**TeammateReview (Root)**: Main container component managing application state and user roles
**CompositeScore**: Handles score aggregation and display
**ReviewToggle**: Controls view switching between given/received reviews
**TeammateHeatmap**: Visualizes review data in a color-coded matrix
**ShowReviews**: Displays detailed review information

Design Decisions

*State Management
**Redux for global authentication state
**React hooks for local component state
**Local storage for persistent user preferences

*Role-Based Access
**Distinct views for instructors, and students
**Feature toggling based on user roles
**Anonymous review mode option

UML Design

*Instructor: Has full access to manage and view all team reviews, including the ability to view all students' reviews and control students' access permissions to view reviews.
*Student: Can view their own received teammate reviews only if granted permission by the instructor, with no access to other students' review information.
[[File:Teammate view uml.jpg|800px]]

=== Control Flow to access the concerned screens ===
From the student's perspective, they can see the comments he made to his teammates and there is a button available to choose to hide information or view details.

[[File:Teammate view student off.jpg|800px]]

When the student presses the button.

[[File:Teammate view student on.jpg|800px]]

When the instructor grants students permission to view teammate reviews, students can see score and comments from their teammates.

[[File:Teammate view student recevied.jpg|800px]]

In the instructor view, the instructor can choose to enable teammate review visibility permissions.

[[File:Teammate instructor view.jpg|800px]]

== Testing Overview ==
Our testing suite utilizes **React Testing Library (RTL)** with **Jest** as the test runner, focusing on component-level testing that prioritizes user interaction patterns over implementation details. The testing stack includes:
* **React Testing Library** for DOM manipulation and assertions
* **Jest** as the testing framework and runner
* **Redux Mock Store** for simulating Redux state in tests
* **@testing-library/react** for React-specific testing utilities

=== Test Coverage ===
Our test suite covers several key areas:

==== Component Rendering ====
* Verification of component mounting and proper display of UI elements
* Testing of conditional rendering based on props
* Validation of anonymous vs. identified user displays

==== User Interactions ====
* Toggle functionality between different view modes
* Button click handlers and state changes
* Form interactions and user input handling

==== State Management ====
* Redux store integration testing
* State changes based on user roles (Student vs. Instructor)
* Component state management for features like anonymous mode

==== Edge Cases ====
* Empty data handling
* Extreme score values
* Permission-based rendering differences
* Anonymous mode functionality
* Missing or incomplete data scenarios

The tests follow RTL's best practices by focusing on user-centric behavior rather than implementation details, ensuring our components remain maintainable and resilient to refactoring while maintaining their expected functionality from an end-user perspective.

== Test Files Overview ==

=== TeammateHeatmap.test.tsx ===
Tests the heatmap visualization component that displays peer review scores. This component is responsible for showing a matrix of review scores with optional anonymization.

* Renders review scores in a heatmap format
* Handles anonymous mode by masking reviewer names
* Manages empty data states
* Displays question text when enabled
* Shows column averages correctly

[[File:cap1.png]]

=== CompositeScore.test.tsx ===
Tests the component that calculates and displays aggregate scores for both given and received reviews.

* Renders all score sections (given, received, overall)
* Handles empty review sets appropriately
* Correctly calculates scores for extreme cases (0 and 5)
* Displays formatted scores with proper decimal places
* Maintains correct score calculations across different review types

[[File:cap2.png]]

=== ReviewToggle.test.tsx ===
Tests the toggle mechanism that switches between "Reviews Given" and "Reviews Received" views.

* Renders appropriate buttons based on user permissions
* Handles toggle state changes correctly
* Shows/hides received reviews based on permissions
* Special handling for instructor views
* Maintains correct active states for buttons

[[File:cap3.png]]

=== TeammateReview.test.tsx ===
Tests the main container component that orchestrates the entire teammate review feature.

* Renders the main interface elements
* Toggles between review views (given/received)
* Controls question list visibility
* Manages anonymous mode
* Handles different user roles (student/instructor)
* Shows/hides review sections
* Integrates with Redux store

[[File:cap4.png]]

=== ShowReviews.test.tsx ===
Tests the component responsible for displaying individual review entries with comments and scores.

* Renders review content correctly
* Handles anonymous mode for reviewer names
* Manages empty review states
* Displays comments and scores appropriately
* Integrates with Redux for user authentication

== Common Testing Patterns ==
All files share several common testing patterns:
* Use of `beforeEach` for test setup
* Mock data initialization
* Edge case handling
* Role-based permission testing
* Integration with Redux store where needed
* Consistent use of RTL's query methods
* Focus on user-centric behavior testing

These tests ensure robust functionality across the teammate review system while maintaining good testing practices and comprehensive coverage of both happy paths and edge cases.

== Team ==
===Mentor===
* Sahil Sawant

=== Members ===
* Arlee Shelby (ashelby@ncsu.edu)
* Aryan Tapkire (atapkir@ncsu.edu)
* Haojie Zhou (hzhou33@ncsu.edu)

==Links ==
*Github Repository: https://github.com/arlee-shelby/expertiza
*Pull Request: https://github.com/expertiza/reimplementation-front-end/pull/82

==References==
[1]https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page

[2]https://github.com/expertiza/reimplementation-front-end

[3]https://github.com/expertiza/reimplementation-back-end

CSC/ECE 517 Fall 2024

2024-12-04T06:33:30Z

Atapkir:

* [[CSC/ECE 517 Fall 2024 - E2450. Refactor assignments_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2451. Reimplement feedback_response_map.rb]]
* [[CSC/ECE 517 Fall 2024 - E2452. Refactor review_mapping_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2453. Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Fall 2024 - E2454. Refactor student_task.rb]]
* [[CSC/ECE 517 Fall 2024 - E2455. Refactor sign_up_sheet_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2456. Refactor teams_user.rb]]
* [[CSC/ECE 517 Fall 2024 - E2456. Refactor teams_user.rb (Phase 2 - Design Document)]]
* [[CSC/ECE 517 Fall 2024 - E2457. GitHub metrics integration]]
* [[CSC/ECE 517 Fall 2024 - E2458. User management and users table]]
* [[CSC/ECE 517 Fall 2024 - E2459. View for results of bidding]]
* [[CSC/ECE 517 Fall 2024 - E2460 Mentor-Meeting Management]]
* [[CSC/ECE 517 Fall 2024 - E2461. UI for Courses]]
* [[CSC/ECE 517 Fall 2024 - E2461. UI and Backend for Courses]]
* [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2024_-_E2462._UI_for_Questionnaires CSC/ECE 517 Fall 2024 - E2462. UI for Questionnaire.rb]
* [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2024_-_E2463_Implement_Front_End_for_Student_Task_List CSC/ECE 517 Fall 2024 - E2463. UI for Student Task List]
* [[CSC/ECE 517 Fall 2024 - E2464 UI for Project Topics (was: Sign_up_Topics)]]
* [[CSC/ECE 517 Fall 2024 - E2465. UI for Institutions and Notification]]
* [[CSC/ECE 517 Fall 2024 - E2466. UI for Impersonate User]]
* [[CSC/ECE 517 Fall 2024 - E2467. UI for View Submissions]]
* [[CSC/ECE 517 Fall 2024 - E2468. Reimplement due_date]]
* [[CSC/ECE 517 Fall 2024 - E2469. Reimplement grades/view_team]]
* [[CSC/ECE 517 Fall 2024 - E2470. Reimplement grades_controller]]
* [[CSC/ECE 517 Fall 2024 - E2471. Reimplement logger]]
* [[CSC/ECE 517 Fall 2024 - E2472. Reimplement responses_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2473. Reimplement sign up topic.rb as project topic.rb]]
* [[CSC/ECE 517 Fall 2024 - E2474. Reimplement student_quizzes_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2475. Reimplement student_task view]]
* [[CSC/ECE 517 Fall 2024 - E2476. Reimplement student_teams_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2477. Reimplement suggestion_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2478. Reimplement the Question hierarchy as Item hierarchy]]
* [[CSC/ECE 517 Fall 2024 - E2479. Reimplement teams_users_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2480. Implement testing for new Bookmarks Controller]]
* [[CSC/ECE 517 Fall 2024 - E2481 Reimplement response_map.rb]]
* [[CSC/ECE 517 Fall 2024 - E2482. Reimplement heatgrid for reviews]]
* [[CSC/ECE 517 Fall 2024 - E2483. Reimplement Notification Controller and Model]]
* [[CSC/ECE 517 Fall 2024 - E2484. Reimplement participants_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2485. Allow reviewers to bid on what to review]]
* [[CSC/ECE 517 Fall 2024 - E2486.Reimplement deadline_rights and deadline_types]]
* [[CSC/ECE 517 Fall 2024 - E2487. Reimplement authorization_helper.rb]]
* [[CSC/ECE 517 Fall 2024 - E2488 Reimplementation of Add TA to course]]
* [[CSC/ECE 517 Fall 2024 - E2489. Create a UI for Assignment Edit page "Etc" tab in ReactJS]]
* [[CSC/ECE 517 Fall 2024 - E2490.1 Improving Assignment Participants Management UI in Expertiza]]
* [[CSC/ECE 517 Fall 2024 - E2491.UI for View assignments in Courses view]]
* [[CSC/ECE 517 Fall 2024 - E2492. UI for View submissions/assign grades (except heatgrid)]]
* [[CSC/ECE 517 Fall 2024 - E2493. UI for Assign Reviewers]]
* [[CSC/ECE 517 Fall 2024 - E2494. UI for Teammate Review View]]
* [[CSC/ECE 517 Fall 2024 - G2401 Refactor Graphql API endpoint for contribution metrics]]
* [[CSC/ECE 517 Fall 2024 - G2402 Refactor Graphql API endpoint for repositories]]

CSC/ECE 517 Fall 2024 - E2494. UI for Teammate Review View

2024-12-04T05:11:42Z

Atapkir:

== Overview ==
After the previous design document submission, we changed projects, with the suggestion and approval of our mentor and Dr. Gehringer, to a reimplementation of the UI for Teammate Review view, which has a larger scope than our previous project. The previous implementation of this UI proposed changes to not only the view files, but the controller and model files as well. This was beyond the scope of the project and complicated the integration of the UI to the existing Expertiza. Thus, our current project will focus on reimplementing the Teammate Review view isolated from other components of the current Expertiza application. Additionally, we focus on implementing a clear and user-friendly UI for both students and instructors. Following the current review display, our main display will show the numerical scores with an associated color as a heat-map.

== Previous Design ==
=== Specifications ===
*Display teammate reviews as a colormap corresponding to the numerical scores
*Students should be able to view reviews they have given to their teammates and the reviews their teammates have given them
**There should be a clear indication in the view which reviews the student is viewing (i.e. those they have given or those they have received)
*Instructors should also be able to view a student's reviews from their teammates and the reviews a student has given for their teammates
*The instructor should be able to chose whether teammate reviews are visible to the student or not by a checkbox
*An average score should be shown, for all the relevant reviews, in a clear and useful way
*There should be an anonymized view option where the names of the reviewer should not be shown

=== Design ===
The previous implementation focussed on a few main improvements to the view.
*Displaying the average score for instructors based on:
**A student's average received teammate score
**A student's average score given to teammates
*Improving the functionality of the automized view for students when selected by the instructor
**Use case diagram for the anonymized view:
[[File:uml_1.PNG|500px|UML for Anonymized]]

=== Testing ===
Main components to the testing plan included:
*Verifying the different displays for students vs. instructors
*Verifying login credentials
*Improvement in unit tests
*Addition of tests for calculating the average score
*Manual testing of the main display with the correct functionality

== Proposed Design ==

=== Specifications ===
Following the previous project specifications, our project will focus on further development of the user experience and testing, with particular emphasis on team collaboration features.

*Review Interface Layout
**Clean tabbed interface separating "Reviews given" and "Reviews received"
**Toggle controls for showing/hiding review details
**Comprehensive data grid with:
***Question numbers for easy reference
***Question text column
***Individual reviewer columns
***Average score column
***Color-coded scoring cells for visual feedback

*Interactive Elements
**Toggle switches for feature controls
**Hide/Show functionality for review details
**Anonymous mode toggle with visual indicator
**Click-through navigation between different review states

*Visual Hierarchy
**Clear section headers and subheaders
**Consistent spacing and alignment
**Data-dense yet readable table design
**Score highlighting using appropriate color coding:
***Green for high scores
***Orange for medium scores
***Red for attention areas

*Responsive Components
**Flexible grid system for review displays
**Adaptive table layout for different screen sizes
**Maintainable component structure for future extensions
**Consistent padding and margin systems

=== Design ===
Core Architecture

*The system follows a component-based architecture with five key components:
**TeammateReview (Root)**: Main container component managing application state and user roles
**CompositeScore**: Handles score aggregation and display
**ReviewToggle**: Controls view switching between given/received reviews
**TeammateHeatmap**: Visualizes review data in a color-coded matrix
**ShowReviews**: Displays detailed review information

Design Decisions

*State Management
**Redux for global authentication state
**React hooks for local component state
**Local storage for persistent user preferences

*Role-Based Access
**Distinct views for instructors, and students
**Feature toggling based on user roles
**Anonymous review mode option

UML Design

*Instructor: Has full access to manage and view all team reviews, including the ability to view all students' reviews and control students' access permissions to view reviews.
*Student: Can view their own received teammate reviews only if granted permission by the instructor, with no access to other students' review information.
[[File:Teammate view uml.jpg|800px]]

=== Control Flow to access the concerned screens ===
From the student's perspective, they can see the comments he made to his teammates and there is a button available to choose to hide information or view details.

[[File:Teammate view student off.jpg|800px]]

When the student presses the button.

[[File:Teammate view student on.jpg|800px]]

When the instructor grants students permission to view teammate reviews, students can see score and comments from their teammates.

[[File:Teammate view student recevied.jpg|800px]]

In the instructor view, the instructor can choose to enable teammate review visibility permissions.

[[File:Teammate instructor view.jpg|800px]]

== Testing Overview ==
Our testing suite utilizes **React Testing Library (RTL)** with **Jest** as the test runner, focusing on component-level testing that prioritizes user interaction patterns over implementation details. The testing stack includes:
* **React Testing Library** for DOM manipulation and assertions
* **Jest** as the testing framework and runner
* **Redux Mock Store** for simulating Redux state in tests
* **@testing-library/react** for React-specific testing utilities

=== Test Coverage ===
Our test suite covers several key areas:

==== Component Rendering ====
* Verification of component mounting and proper display of UI elements
* Testing of conditional rendering based on props
* Validation of anonymous vs. identified user displays

==== User Interactions ====
* Toggle functionality between different view modes
* Button click handlers and state changes
* Form interactions and user input handling

==== State Management ====
* Redux store integration testing
* State changes based on user roles (Student vs. Instructor)
* Component state management for features like anonymous mode

==== Edge Cases ====
* Empty data handling
* Extreme score values
* Permission-based rendering differences
* Anonymous mode functionality
* Missing or incomplete data scenarios

The tests follow RTL's best practices by focusing on user-centric behavior rather than implementation details, ensuring our components remain maintainable and resilient to refactoring while maintaining their expected functionality from an end-user perspective.

== Test Files Overview ==

=== TeammateHeatmap.test.tsx ===
Tests the heatmap visualization component that displays peer review scores. This component is responsible for showing a matrix of review scores with optional anonymization.

* Renders review scores in a heatmap format
* Handles anonymous mode by masking reviewer names
* Manages empty data states
* Displays question text when enabled
* Shows column averages correctly

[[File:cap1.png]]

=== CompositeScore.test.tsx ===
Tests the component that calculates and displays aggregate scores for both given and received reviews.

* Renders all score sections (given, received, overall)
* Handles empty review sets appropriately
* Correctly calculates scores for extreme cases (0 and 5)
* Displays formatted scores with proper decimal places
* Maintains correct score calculations across different review types

[[File:cap2.png]]

=== ReviewToggle.test.tsx ===
Tests the toggle mechanism that switches between "Reviews Given" and "Reviews Received" views.

* Renders appropriate buttons based on user permissions
* Handles toggle state changes correctly
* Shows/hides received reviews based on permissions
* Special handling for instructor views
* Maintains correct active states for buttons

[[File:cap3.png]]

=== TeammateReview.test.tsx ===
Tests the main container component that orchestrates the entire teammate review feature.

* Renders the main interface elements
* Toggles between review views (given/received)
* Controls question list visibility
* Manages anonymous mode
* Handles different user roles (student/instructor)
* Shows/hides review sections
* Integrates with Redux store

[[File:cap4.png]]

=== ShowReviews.test.tsx ===
Tests the component responsible for displaying individual review entries with comments and scores.

* Renders review content correctly
* Handles anonymous mode for reviewer names
* Manages empty review states
* Displays comments and scores appropriately
* Integrates with Redux for user authentication

== Common Testing Patterns ==
All files share several common testing patterns:
* Use of `beforeEach` for test setup
* Mock data initialization
* Edge case handling
* Role-based permission testing
* Integration with Redux store where needed
* Consistent use of RTL's query methods
* Focus on user-centric behavior testing

These tests ensure robust functionality across the teammate review system while maintaining good testing practices and comprehensive coverage of both happy paths and edge cases.

== Team ==
===Mentor===
* Sahil Sawant

=== Members ===
* Arlee Shelby (ashelby@ncsu.edu)
* Aryan Tapkire (atapkir@ncsu.edu)
* Haojie Zhou (hzhou33@ncsu.edu)

==Links ==
*Github Repository: https://github.com/arlee-shelby/expertiza
*Pull Request:

==References==
[1]https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page

[2]https://github.com/expertiza/reimplementation-front-end

[3]https://github.com/expertiza/reimplementation-back-end

File:Cap4.png

2024-12-04T05:09:51Z

Atapkir:

File:Cap3.png

2024-12-04T05:09:41Z

Atapkir:

File:Cap2.png

2024-12-04T05:09:32Z

Atapkir:

File:Cap1.png

2024-12-04T05:09:12Z

Atapkir:

CSC/ECE 517 Fall 2024 - E2494. UI for Teammate Review View

2024-12-04T04:59:57Z

Atapkir:

== Overview ==
After the previous design document submission, we changed projects, with the suggestion and approval of our mentor and Dr. Gehringer, to a reimplementation of the UI for Teammate Review view, which has a larger scope than our previous project. The previous implementation of this UI proposed changes to not only the view files, but the controller and model files as well. This was beyond the scope of the project and complicated the integration of the UI to the existing Expertiza. Thus, our current project will focus on reimplementing the Teammate Review view isolated from other components of the current Expertiza application. Additionally, we focus on implementing a clear and user-friendly UI for both students and instructors. Following the current review display, our main display will show the numerical scores with an associated color as a heat-map.

== Previous Design ==
=== Specifications ===
*Display teammate reviews as a colormap corresponding to the numerical scores
*Students should be able to view reviews they have given to their teammates and the reviews their teammates have given them
**There should be a clear indication in the view which reviews the student is viewing (i.e. those they have given or those they have received)
*Instructors should also be able to view a student's reviews from their teammates and the reviews a student has given for their teammates
*The instructor should be able to chose whether teammate reviews are visible to the student or not by a checkbox
*An average score should be shown, for all the relevant reviews, in a clear and useful way
*There should be an anonymized view option where the names of the reviewer should not be shown

=== Design ===
The previous implementation focussed on a few main improvements to the view.
*Displaying the average score for instructors based on:
**A student's average received teammate score
**A student's average score given to teammates
*Improving the functionality of the automized view for students when selected by the instructor
**Use case diagram for the anonymized view:
[[File:uml_1.PNG|500px|UML for Anonymized]]

=== Testing ===
Main components to the testing plan included:
*Verifying the different displays for students vs. instructors
*Verifying login credentials
*Improvement in unit tests
*Addition of tests for calculating the average score
*Manual testing of the main display with the correct functionality

== Proposed Design ==

=== Specifications ===
Following the previous project specifications, our project will focus on further development of the user experience and testing, with particular emphasis on team collaboration features.

*Review Interface Layout
**Clean tabbed interface separating "Reviews given" and "Reviews received"
**Toggle controls for showing/hiding review details
**Comprehensive data grid with:
***Question numbers for easy reference
***Question text column
***Individual reviewer columns
***Average score column
***Color-coded scoring cells for visual feedback

*Interactive Elements
**Toggle switches for feature controls
**Hide/Show functionality for review details
**Anonymous mode toggle with visual indicator
**Click-through navigation between different review states

*Visual Hierarchy
**Clear section headers and subheaders
**Consistent spacing and alignment
**Data-dense yet readable table design
**Score highlighting using appropriate color coding:
***Green for high scores
***Orange for medium scores
***Red for attention areas

*Responsive Components
**Flexible grid system for review displays
**Adaptive table layout for different screen sizes
**Maintainable component structure for future extensions
**Consistent padding and margin systems

=== Design ===
Core Architecture

*The system follows a component-based architecture with five key components:
**TeammateReview (Root)**: Main container component managing application state and user roles
**CompositeScore**: Handles score aggregation and display
**ReviewToggle**: Controls view switching between given/received reviews
**TeammateHeatmap**: Visualizes review data in a color-coded matrix
**ShowReviews**: Displays detailed review information

Design Decisions

*State Management
**Redux for global authentication state
**React hooks for local component state
**Local storage for persistent user preferences

*Role-Based Access
**Distinct views for instructors, and students
**Feature toggling based on user roles
**Anonymous review mode option

UML Design

*Instructor: Has full access to manage and view all team reviews, including the ability to view all students' reviews and control students' access permissions to view reviews.
*Student: Can view their own received teammate reviews only if granted permission by the instructor, with no access to other students' review information.
[[File:Teammate view uml.jpg|800px]]

=== Control Flow to access the concerned screens ===
From the student's perspective, they can see the comments he made to his teammates and there is a button available to choose to hide information or view details.

[[File:Teammate view student off.jpg|800px]]

When the student presses the button.

[[File:Teammate view student on.jpg|800px]]

When the instructor grants students permission to view teammate reviews, students can see score and comments from their teammates.

[[File:Teammate view student recevied.jpg|800px]]

In the instructor view, the instructor can choose to enable teammate review visibility permissions.

[[File:Teammate instructor view.jpg|800px]]

== Testing Overview ==
Our testing suite utilizes **React Testing Library (RTL)** with **Jest** as the test runner, focusing on component-level testing that prioritizes user interaction patterns over implementation details. The testing stack includes:
* **React Testing Library** for DOM manipulation and assertions
* **Jest** as the testing framework and runner
* **Redux Mock Store** for simulating Redux state in tests
* **@testing-library/react** for React-specific testing utilities

=== Test Coverage ===
Our test suite covers several key areas:

==== Component Rendering ====
* Verification of component mounting and proper display of UI elements
* Testing of conditional rendering based on props
* Validation of anonymous vs. identified user displays

==== User Interactions ====
* Toggle functionality between different view modes
* Button click handlers and state changes
* Form interactions and user input handling

==== State Management ====
* Redux store integration testing
* State changes based on user roles (Student vs. Instructor)
* Component state management for features like anonymous mode

==== Edge Cases ====
* Empty data handling
* Extreme score values
* Permission-based rendering differences
* Anonymous mode functionality
* Missing or incomplete data scenarios

The tests follow RTL's best practices by focusing on user-centric behavior rather than implementation details, ensuring our components remain maintainable and resilient to refactoring while maintaining their expected functionality from an end-user perspective.

== Test Files Overview ==

=== TeammateHeatmap.test.tsx ===
Tests the heatmap visualization component that displays peer review scores. This component is responsible for showing a matrix of review scores with optional anonymization.

* Renders review scores in a heatmap format
* Handles anonymous mode by masking reviewer names
* Manages empty data states
* Displays question text when enabled
* Shows column averages correctly

=== CompositeScore.test.tsx ===
Tests the component that calculates and displays aggregate scores for both given and received reviews.

* Renders all score sections (given, received, overall)
* Handles empty review sets appropriately
* Correctly calculates scores for extreme cases (0 and 5)
* Displays formatted scores with proper decimal places
* Maintains correct score calculations across different review types

=== ReviewToggle.test.tsx ===
Tests the toggle mechanism that switches between "Reviews Given" and "Reviews Received" views.

* Renders appropriate buttons based on user permissions
* Handles toggle state changes correctly
* Shows/hides received reviews based on permissions
* Special handling for instructor views
* Maintains correct active states for buttons

=== TeammateReview.test.tsx ===
Tests the main container component that orchestrates the entire teammate review feature.

* Renders the main interface elements
* Toggles between review views (given/received)
* Controls question list visibility
* Manages anonymous mode
* Handles different user roles (student/instructor)
* Shows/hides review sections
* Integrates with Redux store

=== ShowReviews.test.tsx ===
Tests the component responsible for displaying individual review entries with comments and scores.

* Renders review content correctly
* Handles anonymous mode for reviewer names
* Manages empty review states
* Displays comments and scores appropriately
* Integrates with Redux for user authentication

== Common Testing Patterns ==
All files share several common testing patterns:
* Use of `beforeEach` for test setup
* Mock data initialization
* Edge case handling
* Role-based permission testing
* Integration with Redux store where needed
* Consistent use of RTL's query methods
* Focus on user-centric behavior testing

These tests ensure robust functionality across the teammate review system while maintaining good testing practices and comprehensive coverage of both happy paths and edge cases.

== Team ==
===Mentor===
* Sahil Sawant

=== Members ===
* Arlee Shelby (ashelby@ncsu.edu)
* Aryan Tapkire (atapkir@ncsu.edu)
* Haojie Zhou (hzhou33@ncsu.edu)

==Links ==
*Github Repository: https://github.com/arlee-shelby/expertiza
*Pull Request:

==References==
[1]https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page

[2]https://github.com/expertiza/reimplementation-front-end

[3]https://github.com/expertiza/reimplementation-back-end

CSC/ECE 517 Fall 2024 - E2494. UI for Teammate Review View

2024-12-02T21:10:53Z

Atapkir:

CSC/ECE 517 Fall 2024 - E2494. UI for Teammate Review View

2024-12-02T20:57:15Z

Atapkir:

CSC/ECE 517 Fall 2024 - E2494. UI for Report Review for Assignment

2024-11-14T18:59:23Z

Atapkir:

=== Overview ===
This project will create a modern, responsive TypeScript and ReactJS interface for the Report Review page within Expertiza. It aims to present instructors with a summary of student reviews for each assignment. The design will prioritize simplicity and usability, providing instructors with a clear and effective way to review student feedback.

== 1. Objective and Goals ==
Develop a TypeScript and React-based UI for the Report Review page, accessible only to instructors, which will be responsive, intuitive, and efficient.

Key Goals:
1. Deliver an organized and clean display of student review summaries.
2. Create a responsive design adaptable to various screen sizes and devices.
3. Implement robust error handling for reliable data display and ensure usability across the application.

== 2. Scope ==
Report Review Summary: Display individual review summaries per student for instructors, incorporating filtering and search functionalities to facilitate navigation.
Role-Based Access Control (RBAC): Limit access to this page strictly to instructors, ensuring students cannot view the review summary.

== 3. System Architecture ==
The system architecture will use ReactJS with a focus on component reusability, TypeScript for type safety, and enhanced role-based access control. Components will communicate with the backend through RESTful APIs.

[[File:UIforReviewReport.jpeg]]

== 4. Technical Specifications and Design Patterns ==

=== 4.1 Component Design and Structure ===
The Report Review UI will include modular components for scalability, reusability, and role-based access control.

Core Components for Report Review UI:
ReviewSummaryList: Displays a summary list of student reviews for a specific assignment.
ReviewDetail: Shows detailed information for each review, accessible upon selecting a summary.
ErrorBoundary: Wraps components to catch and display errors related to data fetching and rendering.

=== 4.2 Enhanced Role Management System ===
Role management will ensure only instructors can access the Report Review page. Key elements include:
Role Enumeration (ROLE Enum): Define roles like `INSTRUCTOR` to control access to the Report Review UI.
Centralized Authentication Context (AuthContext): Store and provide role information globally. This enables easy role checks, such as `AuthContext.hasPermission('view_reviews')`, to control access based on user roles.
Conditional Rendering: Use `AuthContext` to ensure only users with the `INSTRUCTOR` role can view the `ReviewSummaryList`.

=== 4.3 Application of Design Patterns ===
Container-Presenter Pattern:
Purpose: Separate data-fetching logic from display logic for easier maintenance.
Application: A container component (e.g., `ReviewSummaryPageContainer`) will handle data fetching and pass the data to presentational components like `ReviewSummaryList`.
Benefits: Clear separation of concerns makes components more readable and easier to test.

Error Handling Pattern with Error Boundaries:
Purpose: Capture and manage errors for smoother user experience and reliability.
Application: Use an `ErrorBoundary` component to handle errors within the `ReviewSummaryList` and `ReviewDetail` components.
Benefits: Improves reliability by ensuring unexpected errors do not disrupt the entire page.

=== 4.4 TypeScript for Static Typing ===
TypeScript will be used throughout to enforce strict typing, reduce errors, and improve code readability. Custom types/interfaces, such as `ReviewSummary`, will define expected data structures for better integration with the backend API.

=== 4.5 Testing Strategy ===
Unit Tests:
Components like `ReviewDetail` and `ErrorBoundary` will have unit tests to ensure error handling and data display work as expected.

Integration Tests:
Verify that data flows correctly between components, especially between `ReviewSummaryList` and `ReviewDetail`.

End-to-End Tests:
Simulate instructor interactions to ensure only authorized users can access the review data, validating user flows from review list to detailed view.

== 5. Implementation Plan ==

=== 5.1 Development Environment Setup ===
Install React and TypeScript: Initialize a TypeScript and React setup, configuring linting and testing tools.
Configure API Integration: Define REST API endpoints for backend interaction, with TypeScript enforcing the response structure.

=== 5.2 Component Development Process ===
Step-by-Step Development for Core Components:
1. Notification Management Page Components:
NotificationList:
Data Fetching: Use a container to call the backend API, retrieving notifications based on user permissions.
Display: Render a list with notification summaries and active/inactive states. Notifications include a toggle to activate/deactivate, implemented by `NotificationToggle`.
NotificationForm:
Role Validation: Only accessible to TAs or higher, as verified through `AuthContext`.
Form Fields: Include title, message, and course selection with validation.
Submission: On submission, the form creates or updates a notification and refreshes `NotificationList`.

2. Institution Management Page Components:
InstitutionList:
Data Loading: The container fetches institutions for authorized users (e.g., `INSTRUCTOR` or `ADMIN`).
Rendering: Display institution names, associated courses, and additional information, with pagination and search for easy navigation.
InstitutionForm:
Authorization Check: Only `INSTRUCTOR` or `ADMIN` roles can access this form.
Form Fields: Fields include institution name, address, and details, with backend validation.
Save and Update: Submission calls the backend to create or update institution data.

=== 5.3 State Management ===
Global State with Context API: The `AuthContext` and `NotificationContext` manage global states, including user roles and notification status.
Local State: Component-level states manage form data, loading status, and error messages, scoped to each component to prevent unnecessary re-renders.

=== 5.4 Testing Strategy ===
Unit Tests:
Components like `NotificationToggle` and `InstitutionForm` will be individually tested with Jest and React Testing Library for expected behavior.
Integration Tests:
Objective: Verify interactions between components.
Process: Complete page testing to confirm permissions, data flows, and interactions work together. Example: Verifying that `NotificationList` updates when a new notification is
created.
End-to-End Tests:
Objective: Validate complete user flows and role-based access.
Process: Use Cypress to simulate real user actions, ensuring each role sees authorized components only.

=== 5.5 API Integration ===
RESTful API Design: API interactions are defined using REST conventions, with TypeScript enforcing response structure integrity.
Error Handling: Components handle API errors, guiding users with relevant messages.

== Team ==
===Mentor===
* Sahil Sawant

=== Members ===
* Arlee Shelby (ashelby@ncsu.edu)
* Aryan Tapkire (atapkir@ncsu.edu)
* Haojie Zhou (hzhou33@ncsu.edu)

==Links ==
*Github Repository:
*Pull Request:

==References==
[1]https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page

[2]https://github.com/expertiza/reimplementation-front-end

[3]https://github.com/expertiza/reimplementation-back-end

CSC/ECE 517 Fall 2024 - E2494. UI for Report Review for Assignment

2024-11-14T17:20:13Z

Atapkir:

=== Overview ===
This project will create a modern, responsive TypeScript and ReactJS interface for the Report Review page within Expertiza. It aims to present instructors with a summary of student reviews for each assignment. The design will prioritize simplicity and usability, providing instructors with a clear and effective way to review student feedback.

== 1. Objective and Goals ==
Develop a TypeScript and React-based UI for the Report Review page, accessible only to instructors, which will be responsive, intuitive, and efficient.

'''Key Goals''':
1. Deliver an organized and clean display of student review summaries.
2. Create a responsive design adaptable to various screen sizes and devices.
3. Implement robust error handling for reliable data display and ensure usability across the application.

== 2. Scope ==
* Report Review Summary: Display individual review summaries per student for instructors, incorporating filtering and search functionalities to facilitate navigation.
* Role-Based Access Control (RBAC): Limit access to this page strictly to instructors, ensuring students cannot view the review summary.

== 3. System Architecture ==
The system architecture will use ReactJS with a focus on component reusability, TypeScript for type safety, and enhanced role-based access control. Components will communicate with the backend through RESTful APIs.

[[File:UIforReviewReport.jpeg]]

== 4. Technical Specifications and Design Patterns ==

=== 4.1 Component Design and Structure ===
The Report Review UI will include modular components for scalability, reusability, and role-based access control.

'''Core Components for Report Review UI''':
* ReviewSummaryList: Displays a summary list of student reviews for a specific assignment.
* ReviewDetail: Shows detailed information for each review, accessible upon selecting a summary.
* ErrorBoundary: Wraps components to catch and display errors related to data fetching and rendering.

=== 4.2 Enhanced Role Management System ===
Role management will ensure only instructors can access the Report Review page. Key elements include:
* Role Enumeration (ROLE Enum): Define roles like `INSTRUCTOR` to control access to the Report Review UI.
* Centralized Authentication Context (AuthContext): Store and provide role information globally. This enables easy role checks, such as `AuthContext.hasPermission('view_reviews')`, to control access based on user roles.
* Conditional Rendering: Use `AuthContext` to ensure only users with the `INSTRUCTOR` role can view the `ReviewSummaryList`.

=== 4.3 Application of Design Patterns ===
* Container-Presenter Pattern:
Purpose: Separate data-fetching logic from display logic for easier maintenance.
Application: A container component (e.g., `ReviewSummaryPageContainer`) will handle data fetching and pass the data to presentational components like `ReviewSummaryList`.
Benefits: Clear separation of concerns makes components more readable and easier to test.

* Error Handling Pattern with Error Boundaries:
Purpose: Capture and manage errors for smoother user experience and reliability.
Application: Use an `ErrorBoundary` component to handle errors within the `ReviewSummaryList` and `ReviewDetail` components.
Benefits: Improves reliability by ensuring unexpected errors do not disrupt the entire page.

=== 4.4 TypeScript for Static Typing ===
TypeScript will be used throughout to enforce strict typing, reduce errors, and improve code readability. Custom types/interfaces, such as `ReviewSummary`, will define expected data structures for better integration with the backend API.

=== 4.5 Testing Strategy ===
* Unit Tests:
Components like `ReviewDetail` and `ErrorBoundary` will have unit tests to ensure error handling and data display work as expected.

* Integration Tests:
Verify that data flows correctly between components, especially between `ReviewSummaryList` and `ReviewDetail`.

* End-to-End Tests:
Simulate instructor interactions to ensure only authorized users can access the review data, validating user flows from review list to detailed view.

== 5. Implementation Plan ==

=== 5.1 Development Environment Setup ===
* Install React and TypeScript: Initialize a TypeScript and React setup, configuring linting and testing tools.
* Configure API Integration: Define REST API endpoints for backend interaction, with TypeScript enforcing the response structure.

=== 5.2 Component Development Process ===
* Step-by-Step Development for Core Components:
1. **Notification Management Page Components**:
NotificationList:
Data Fetching: Use a container to call the backend API, retrieving notifications based on user permissions.
Display: Render a list with notification summaries and active/inactive states. Notifications include a toggle to activate/deactivate, implemented by `NotificationToggle`.
NotificationForm:
Role Validation: Only accessible to TAs or higher, as verified through `AuthContext`.
Form Fields: Include title, message, and course selection with validation.
Submission: On submission, the form creates or updates a notification and refreshes `NotificationList`.

2. **Institution Management Page Components**:
InstitutionList:
Data Loading: The container fetches institutions for authorized users (e.g., `INSTRUCTOR` or `ADMIN`).
Rendering: Display institution names, associated courses, and additional information, with pagination and search for easy navigation.
InstitutionForm''':
Authorization Check: Only `INSTRUCTOR` or `ADMIN` roles can access this form.
Form Fields: Fields include institution name, address, and details, with backend validation.
Save and Update: Submission calls the backend to create or update institution data.

=== 5.3 State Management ===
* **Global State with Context API**: The `AuthContext` and `NotificationContext` manage global states, including user roles and notification status.
* **Local State**: Component-level states manage form data, loading status, and error messages, scoped to each component to prevent unnecessary re-renders.

=== 5.4 Testing Strategy ===
* Unit Tests:
Components like `NotificationToggle` and `InstitutionForm` will be individually tested with Jest and React Testing Library for expected behavior.
* Integration Tests:
Objective: Verify interactions between components.
Process: Complete page testing to confirm permissions, data flows, and interactions work together. Example: Verifying that `NotificationList` updates when a new notification is created.
* End-to-End Tests:
Objective: Validate complete user flows and role-based access.
Process: Use Cypress to simulate real user actions, ensuring each role sees authorized components only.

=== 5.5 API Integration ===
* RESTful API Design: API interactions are defined using REST conventions, with TypeScript enforcing response structure integrity.
* Error Handling: Components handle API errors, guiding users with relevant messages.

== Team ==
===Mentor===
* Sahil Sawant

=== Members ===
* Arlee Shelby (ashelby@ncsu.edu)
* Aryan Tapkire (atapkir@ncsu.edu)
* Haojie Zhou (hzhou33@ncsu.edu)

==Links ==
*Github Repository:
*Pull Request:

==References==
[1]https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page

[2]https://github.com/expertiza/reimplementation-front-end

[3]https://github.com/expertiza/reimplementation-back-end

CSC/ECE 517 Fall 2024 - E2494. UI for Report Review for Assignment

2024-11-14T17:11:00Z

Atapkir:

=== Overview ===
This project will create a modern, responsive TypeScript and ReactJS interface for the Report Review page within Expertiza. It aims to present instructors with a summary of student reviews for each assignment. The design will prioritize simplicity and usability, providing instructors with a clear and effective way to review student feedback.

== 1. Objective and Goals ==
Develop a TypeScript and React-based UI for the Report Review page, accessible only to instructors, which will be responsive, intuitive, and efficient.

'''Key Goals''':
1. Deliver an organized and clean display of student review summaries.
2. Create a responsive design adaptable to various screen sizes and devices.
3. Implement robust error handling for reliable data display and ensure usability across the application.

== 2. Scope ==
* Report Review Summary: Display individual review summaries per student for instructors, incorporating filtering and search functionalities to facilitate navigation.
* Role-Based Access Control (RBAC): Limit access to this page strictly to instructors, ensuring students cannot view the review summary.

== 3. System Architecture ==
The system architecture will use ReactJS with a focus on component reusability, TypeScript for type safety, and enhanced role-based access control. Components will communicate with the backend through RESTful APIs.

[[File:UIforReviewReport.jpeg]]

== 4. Technical Specifications and Design Patterns ==

=== 4.1 Component Design and Structure ===
The Report Review UI will include modular components for scalability, reusability, and role-based access control.

'''Core Components for Report Review UI''':
* ReviewSummaryList: Displays a summary list of student reviews for a specific assignment.
* ReviewDetail: Shows detailed information for each review, accessible upon selecting a summary.
* ErrorBoundary: Wraps components to catch and display errors related to data fetching and rendering.

=== 4.2 Enhanced Role Management System ===
Role management will ensure only instructors can access the Report Review page. Key elements include:
* Role Enumeration (ROLE Enum): Define roles like `INSTRUCTOR` to control access to the Report Review UI.
* Centralized Authentication Context (AuthContext): Store and provide role information globally. This enables easy role checks, such as `AuthContext.hasPermission('view_reviews')`, to control access based on user roles.
* Conditional Rendering: Use `AuthContext` to ensure only users with the `INSTRUCTOR` role can view the `ReviewSummaryList`.

=== 4.3 Application of Design Patterns ===
* Container-Presenter Pattern:
'''Purpose''': Separate data-fetching logic from display logic for easier maintenance.
'''Application''': A container component (e.g., `ReviewSummaryPageContainer`) will handle data fetching and pass the data to presentational components like `ReviewSummaryList`.
'''Benefits''': Clear separation of concerns makes components more readable and easier to test.

* Error Handling Pattern with Error Boundaries:
'''Purpose''': Capture and manage errors for smoother user experience and reliability.
'''Application''': Use an `ErrorBoundary` component to handle errors within the `ReviewSummaryList` and `ReviewDetail` components.
'''Benefits''': Improves reliability by ensuring unexpected errors do not disrupt the entire page.

=== 4.4 TypeScript for Static Typing ===
TypeScript will be used throughout to enforce strict typing, reduce errors, and improve code readability. Custom types/interfaces, such as `ReviewSummary`, will define expected data structures for better integration with the backend API.

=== 4.5 Testing Strategy ===
* Unit Tests:
Components like `ReviewDetail` and `ErrorBoundary` will have unit tests to ensure error handling and data display work as expected.

* Integration Tests:
Verify that data flows correctly between components, especially between `ReviewSummaryList` and `ReviewDetail`.

* End-to-End Tests:
Simulate instructor interactions to ensure only authorized users can access the review data, validating user flows from review list to detailed view.

== 5. Implementation Plan ==

=== 5.1 Development Environment Setup ===
* '''Install React and TypeScript''': Initialize a TypeScript and React setup, configuring linting and testing tools.
* '''Configure API Integration''': Define REST API endpoints for backend interaction, with TypeScript enforcing the response structure.

=== 5.2 Component Development Process ===
* '''Step-by-Step Development for Core Components''':
1. **Notification Management Page Components**:
'''NotificationList''':
'''Data Fetching''': Use a container to call the backend API, retrieving notifications based on user permissions.
'''Display''': Render a list with notification summaries and active/inactive states. Notifications include a toggle to activate/deactivate, implemented by `NotificationToggle`.
'''NotificationForm''':
'''Role Validation''': Only accessible to TAs or higher, as verified through `AuthContext`.
'''Form Fields''': Include title, message, and course selection with validation.
'''Submission''': On submission, the form creates or updates a notification and refreshes `NotificationList`.

2. **Institution Management Page Components**:
'''InstitutionList''':
'''Data Loading''': The container fetches institutions for authorized users (e.g., `INSTRUCTOR` or `ADMIN`).
'''Rendering''': Display institution names, associated courses, and additional information, with pagination and search for easy navigation.
'''InstitutionForm''':
'''Authorization Check''': Only `INSTRUCTOR` or `ADMIN` roles can access this form.
'''Form Fields''': Fields include institution name, address, and details, with backend validation.
'''Save and Update''': Submission calls the backend to create or update institution data.

=== 5.3 State Management ===
* **Global State with Context API**: The `AuthContext` and `NotificationContext` manage global states, including user roles and notification status.
* **Local State**: Component-level states manage form data, loading status, and error messages, scoped to each component to prevent unnecessary re-renders.

=== 5.4 Testing Strategy ===
* Unit Tests:
Components like `NotificationToggle` and `InstitutionForm` will be individually tested with Jest and React Testing Library for expected behavior.
* Integration Tests:
'''Objective''': Verify interactions between components.
'''Process''': Complete page testing to confirm permissions, data flows, and interactions work together. Example: Verifying that `NotificationList` updates when a new notification is created.
* End-to-End Tests:
'''Objective''': Validate complete user flows and role-based access.
'''Process''': Use Cypress to simulate real user actions, ensuring each role sees authorized components only.

=== 5.5 API Integration ===
* RESTful API Design: API interactions are defined using REST conventions, with TypeScript enforcing response structure integrity.
* Error Handling: Components handle API errors, guiding users with relevant messages.

== Team ==
===Mentor===
* Sahil Sawant

=== Members ===
* Arlee Shelby (ashelby@ncsu.edu)
* Aryan Tapkire (atapkir@ncsu.edu)
* Haojie Zhou (hzhou33@ncsu.edu)

==Links ==
*Github Repository:
*Pull Request:

==References==
[1]https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page

[2]https://github.com/expertiza/reimplementation-front-end

[3]https://github.com/expertiza/reimplementation-back-end

File:UIforReviewReport.jpeg

2024-11-14T17:09:57Z

Atapkir:

CSC/ECE 517 Fall 2024 - E2494. UI for Report Review for Assignment

2024-11-14T17:08:21Z

Atapkir:

=== Overview ===
This project will create a modern, responsive TypeScript and ReactJS interface for the Report Review page within Expertiza. It aims to present instructors with a summary of student reviews for each assignment. The design will prioritize simplicity and usability, providing instructors with a clear and effective way to review student feedback.

== 1. Objective and Goals ==
Develop a TypeScript and React-based UI for the Report Review page, accessible only to instructors, which will be responsive, intuitive, and efficient.

'''Key Goals''':
1. Deliver an organized and clean display of student review summaries.
2. Create a responsive design adaptable to various screen sizes and devices.
3. Implement robust error handling for reliable data display and ensure usability across the application.

== 2. Scope ==
* Report Review Summary: Display individual review summaries per student for instructors, incorporating filtering and search functionalities to facilitate navigation.
* Role-Based Access Control (RBAC): Limit access to this page strictly to instructors, ensuring students cannot view the review summary.

== 3. System Architecture ==
The system architecture will use ReactJS with a focus on component reusability, TypeScript for type safety, and enhanced role-based access control. Components will communicate with the backend through RESTful APIs.

== 4. Technical Specifications and Design Patterns ==

=== 4.1 Component Design and Structure ===
The Report Review UI will include modular components for scalability, reusability, and role-based access control.

'''Core Components for Report Review UI''':
* ReviewSummaryList: Displays a summary list of student reviews for a specific assignment.
* ReviewDetail: Shows detailed information for each review, accessible upon selecting a summary.
* ErrorBoundary: Wraps components to catch and display errors related to data fetching and rendering.

=== 4.2 Enhanced Role Management System ===
Role management will ensure only instructors can access the Report Review page. Key elements include:
* Role Enumeration (ROLE Enum): Define roles like `INSTRUCTOR` to control access to the Report Review UI.
* Centralized Authentication Context (AuthContext): Store and provide role information globally. This enables easy role checks, such as `AuthContext.hasPermission('view_reviews')`, to control access based on user roles.
* Conditional Rendering: Use `AuthContext` to ensure only users with the `INSTRUCTOR` role can view the `ReviewSummaryList`.

=== 4.3 Application of Design Patterns ===
* Container-Presenter Pattern:
'''Purpose''': Separate data-fetching logic from display logic for easier maintenance.
'''Application''': A container component (e.g., `ReviewSummaryPageContainer`) will handle data fetching and pass the data to presentational components like `ReviewSummaryList`.
'''Benefits''': Clear separation of concerns makes components more readable and easier to test.

* Error Handling Pattern with Error Boundaries:
'''Purpose''': Capture and manage errors for smoother user experience and reliability.
'''Application''': Use an `ErrorBoundary` component to handle errors within the `ReviewSummaryList` and `ReviewDetail` components.
'''Benefits''': Improves reliability by ensuring unexpected errors do not disrupt the entire page.

=== 4.4 TypeScript for Static Typing ===
TypeScript will be used throughout to enforce strict typing, reduce errors, and improve code readability. Custom types/interfaces, such as `ReviewSummary`, will define expected data structures for better integration with the backend API.

=== 4.5 Testing Strategy ===
* Unit Tests:
Components like `ReviewDetail` and `ErrorBoundary` will have unit tests to ensure error handling and data display work as expected.

* Integration Tests:
Verify that data flows correctly between components, especially between `ReviewSummaryList` and `ReviewDetail`.

* End-to-End Tests:
Simulate instructor interactions to ensure only authorized users can access the review data, validating user flows from review list to detailed view.

== 5. Implementation Plan ==

=== 5.1 Development Environment Setup ===
* '''Install React and TypeScript''': Initialize a TypeScript and React setup, configuring linting and testing tools.
* '''Configure API Integration''': Define REST API endpoints for backend interaction, with TypeScript enforcing the response structure.

=== 5.2 Component Development Process ===
* '''Step-by-Step Development for Core Components''':
1. **Notification Management Page Components**:
'''NotificationList''':
'''Data Fetching''': Use a container to call the backend API, retrieving notifications based on user permissions.
'''Display''': Render a list with notification summaries and active/inactive states. Notifications include a toggle to activate/deactivate, implemented by `NotificationToggle`.
'''NotificationForm''':
'''Role Validation''': Only accessible to TAs or higher, as verified through `AuthContext`.
'''Form Fields''': Include title, message, and course selection with validation.
'''Submission''': On submission, the form creates or updates a notification and refreshes `NotificationList`.

2. **Institution Management Page Components**:
'''InstitutionList''':
'''Data Loading''': The container fetches institutions for authorized users (e.g., `INSTRUCTOR` or `ADMIN`).
'''Rendering''': Display institution names, associated courses, and additional information, with pagination and search for easy navigation.
'''InstitutionForm''':
'''Authorization Check''': Only `INSTRUCTOR` or `ADMIN` roles can access this form.
'''Form Fields''': Fields include institution name, address, and details, with backend validation.
'''Save and Update''': Submission calls the backend to create or update institution data.

=== 5.3 State Management ===
* **Global State with Context API**: The `AuthContext` and `NotificationContext` manage global states, including user roles and notification status.
* **Local State**: Component-level states manage form data, loading status, and error messages, scoped to each component to prevent unnecessary re-renders.

=== 5.4 Testing Strategy ===
* Unit Tests:
Components like `NotificationToggle` and `InstitutionForm` will be individually tested with Jest and React Testing Library for expected behavior.
* Integration Tests:
'''Objective''': Verify interactions between components.
'''Process''': Complete page testing to confirm permissions, data flows, and interactions work together. Example: Verifying that `NotificationList` updates when a new notification is created.
* End-to-End Tests:
'''Objective''': Validate complete user flows and role-based access.
'''Process''': Use Cypress to simulate real user actions, ensuring each role sees authorized components only.

=== 5.5 API Integration ===
* RESTful API Design: API interactions are defined using REST conventions, with TypeScript enforcing response structure integrity.
* Error Handling: Components handle API errors, guiding users with relevant messages.

== Team ==
===Mentor===
* Sahil Sawant

=== Members ===
* Arlee Shelby (ashelby@ncsu.edu)
* Aryan Tapkire (atapkir@ncsu.edu)
* Haojie Zhou (hzhou33@ncsu.edu)

==Links ==
*Github Repository:
*Pull Request:

==References==
[1]https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page

[2]https://github.com/expertiza/reimplementation-front-end

[3]https://github.com/expertiza/reimplementation-back-end

CSC/ECE 517 Fall 2024 - E2494. UI for Report Review for Assignment

2024-11-14T04:34:05Z

Atapkir:

=== Overview ===
This project will create a modern, responsive TypeScript and ReactJS interface for the Report Review page within Expertiza. It aims to present instructors with a summary of student reviews for each assignment. The design will prioritize simplicity and usability, providing instructors with a clear and effective way to review student feedback.

== 1. Objective and Goals ==
Develop a TypeScript and React-based UI for the Report Review page, accessible only to instructors, which will be responsive, intuitive, and efficient.

'''Key Goals''':
1. Deliver an organized and clean display of student review summaries.
2. Create a responsive design adaptable to various screen sizes and devices.
3. Implement robust error handling for reliable data display and ensure usability across the application.

== 2. Scope ==
* **Report Review Summary**: Display individual review summaries per student for instructors, incorporating filtering and search functionalities to facilitate navigation.
* **Role-Based Access Control (RBAC)**: Limit access to this page strictly to instructors, ensuring students cannot view the review summary.

== 3. System Architecture ==
The system architecture will use ReactJS with a focus on component reusability, TypeScript for type safety, and enhanced role-based access control. Components will communicate with the backend through RESTful APIs.

== 4. Technical Specifications and Design Patterns ==

=== 4.1 Component Design and Structure ===
The Report Review UI will include modular components for scalability, reusability, and role-based access control.

'''Core Components for Report Review UI''':
* **ReviewSummaryList**: Displays a summary list of student reviews for a specific assignment.
* **ReviewDetail**: Shows detailed information for each review, accessible upon selecting a summary.
* **ErrorBoundary**: Wraps components to catch and display errors related to data fetching and rendering.

=== 4.2 Enhanced Role Management System ===
Role management will ensure only instructors can access the Report Review page. Key elements include:
* **Role Enumeration (ROLE Enum)**: Define roles like `INSTRUCTOR` to control access to the Report Review UI.
* **Centralized Authentication Context (AuthContext)**: Store and provide role information globally. This enables easy role checks, such as `AuthContext.hasPermission('view_reviews')`, to control access based on user roles.
* **Conditional Rendering**: Use `AuthContext` to ensure only users with the `INSTRUCTOR` role can view the `ReviewSummaryList`.

=== 4.3 Application of Design Patterns ===
* **Container-Presenter Pattern**:
* '''Purpose''': Separate data-fetching logic from display logic for easier maintenance.
* '''Application''': A container component (e.g., `ReviewSummaryPageContainer`) will handle data fetching and pass the data to presentational components like `ReviewSummaryList`.
* '''Benefits''': Clear separation of concerns makes components more readable and easier to test.

* **Error Handling Pattern with Error Boundaries**:
* '''Purpose''': Capture and manage errors for smoother user experience and reliability.
* '''Application''': Use an `ErrorBoundary` component to handle errors within the `ReviewSummaryList` and `ReviewDetail` components.
* '''Benefits''': Improves reliability by ensuring unexpected errors do not disrupt the entire page.

=== 4.4 TypeScript for Static Typing ===
TypeScript will be used throughout to enforce strict typing, reduce errors, and improve code readability. Custom types/interfaces, such as `ReviewSummary`, will define expected data structures for better integration with the backend API.

=== 4.5 Testing Strategy ===
* **Unit Tests**:
Components like `ReviewDetail` and `ErrorBoundary` will have unit tests to ensure error handling and data display work as expected.

* **Integration Tests**:
Verify that data flows correctly between components, especially between `ReviewSummaryList` and `ReviewDetail`.

* **End-to-End Tests**:
Simulate instructor interactions to ensure only authorized users can access the review data, validating user flows from review list to detailed view.

== 5. Implementation Plan ==

=== 5.1 Development Environment Setup ===
* '''Install React and TypeScript''': Initialize a TypeScript and React setup, configuring linting and testing tools.
* '''Configure API Integration''': Define REST API endpoints for backend interaction, with TypeScript enforcing the response structure.

=== 5.2 Component Development Process ===
* '''Step-by-Step Development for Core Components''':
1. **Notification Management Page Components**:
* '''NotificationList''':
* '''Data Fetching''': Use a container to call the backend API, retrieving notifications based on user permissions.
* '''Display''': Render a list with notification summaries and active/inactive states. Notifications include a toggle to activate/deactivate, implemented by `NotificationToggle`.
* '''NotificationForm''':
* '''Role Validation''': Only accessible to TAs or higher, as verified through `AuthContext`.
* '''Form Fields''': Include title, message, and course selection with validation.
* '''Submission''': On submission, the form creates or updates a notification and refreshes `NotificationList`.

2. **Institution Management Page Components**:
* '''InstitutionList''':
* '''Data Loading''': The container fetches institutions for authorized users (e.g., `INSTRUCTOR` or `ADMIN`).
* '''Rendering''': Display institution names, associated courses, and additional information, with pagination and search for easy navigation.
* '''InstitutionForm''':
* '''Authorization Check''': Only `INSTRUCTOR` or `ADMIN` roles can access this form.
* '''Form Fields''': Fields include institution name, address, and details, with backend validation.
* '''Save and Update''': Submission calls the backend to create or update institution data.

=== 5.3 State Management ===
* **Global State with Context API**: The `AuthContext` and `NotificationContext` manage global states, including user roles and notification status.
* **Local State**: Component-level states manage form data, loading status, and error messages, scoped to each component to prevent unnecessary re-renders.

=== 5.4 Testing Strategy ===
* **Unit Tests**:
Components like `NotificationToggle` and `InstitutionForm` will be individually tested with Jest and React Testing Library for expected behavior.
* **Integration Tests**:
* '''Objective''': Verify interactions between components.
* '''Process''': Complete page testing to confirm permissions, data flows, and interactions work together. Example: Verifying that `NotificationList` updates when a new notification is created.
* **End-to-End Tests**:
* '''Objective''': Validate complete user flows and role-based access.
* '''Process''': Use Cypress to simulate real user actions, ensuring each role sees authorized components only.

=== 5.5 API Integration ===
* **RESTful API Design**: API interactions are defined using REST conventions, with TypeScript enforcing response structure integrity.
* **Error Handling**: Components handle API errors, guiding users with relevant messages.

== Team ==
===Mentor===
* Sahil Sawant

=== Members ===
* Arlee Shelby (ashelby@ncsu.edu)
* Aryan Tapkire (atapkir@ncsu.edu)
* Haojie Zhou (hzhou33@ncsu.edu)

==Links ==
*Github Repository:
*Pull Request:

==References==
[1]https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page

[2]https://github.com/expertiza/reimplementation-front-end

[3]https://github.com/expertiza/reimplementation-back-end

CSC/ECE 517 Fall 2024 - E2494. UI for Report Review for Assignment

2024-11-14T04:32:10Z

Atapkir:

===Overview===
This project will create a modern, responsive TypeScript and ReactJS interface for the Report Review page within Expertiza. It aims to present instructors with a summary of student reviews for each assignment. The design will prioritize simplicity and usability, providing instructors with a clear and effective way to review student feedback.

==1. Objective and Goals==
Develop a TypeScript and React-based UI for the Report Review page, accessible only to instructors, which will be responsive, intuitive, and efficient.

Key Goals:
1.Deliver an organized and clean display of student review summaries.
2.Create a responsive design adaptable to various screen sizes and devices.
3.Implement robust error handling for reliable data display and ensure usability across the application.

==2. Scope==
- Report Review Summary: Display individual review summaries per student for instructors, incorporating filtering and search functionalities to facilitate navigation.

- Role-Based Access Control (RBAC): Limit access to this page strictly to instructors, ensuring students cannot view the review summary.

==3. System Architecture==
The system architecture will use ReactJS with a focus on component reusability, TypeScript for type safety, and enhanced role-based access control. Components will communicate with the backend through RESTful APIs.

==4. Technical Specifications and Design Patterns==
4.1 Component Design and Structure
The Report Review UI will include modular components for scalability, reusability, and role-based access control.

Core Components for Report Review UI:

ReviewSummaryList: Displays a summary list of student reviews for a specific assignment.
ReviewDetail: Shows detailed information for each review, accessible upon selecting a summary.
ErrorBoundary: Wraps components to catch and display errors related to data fetching and rendering.

4.2 Enhanced Role Management System
Role management will ensure only instructors can access the Report Review page. Key elements include:

Role Enumeration (ROLE Enum): Define roles like INSTRUCTOR to control access to the Report Review UI.
Centralized Authentication Context (AuthContext): Store and provide role information globally. This enables easy role checks, such as
AuthContext.hasPermission('view_reviews'), to control access based on user roles.
Conditional Rendering: Use AuthContext to ensure only users with the INSTRUCTOR role can view the ReviewSummaryList.

4.3 Application of Design Patterns
Container-Presenter Pattern:

Purpose: Separate data-fetching logic from display logic for easier maintenance.
Application: A container component (e.g., ReviewSummaryPageContainer) will handle data fetching and pass the data to presentational components like ReviewSummaryList.
Benefits: Clear separation of concerns makes components more readable and easier to test.

Error Handling Pattern with Error Boundaries:

Purpose: Capture and manage errors for smoother user experience and reliability.
Application: Use an ErrorBoundary component to handle errors within the ReviewSummaryList and ReviewDetail components.
Benefits: Improves reliability by ensuring unexpected errors do not disrupt the entire page.

4.4 TypeScript for Static Typing
TypeScript will be used throughout to enforce strict typing, reduce errors, and improve code readability. Custom types/interfaces, such as ReviewSummary, will define expected
data structures for better integration with the backend API.

4.5 Testing Strategy
Unit Tests:

Components like ReviewDetail and ErrorBoundary will have unit tests to ensure error handling and data display work as expected.

Integration Tests:

Verify that data flows correctly between components, especially between ReviewSummaryList and ReviewDetail.

End-to-End Tests:

Simulate instructor interactions to ensure only authorized users can access the review data, validating user flows from review list to detailed view.

== 5. Implementation Plan ==

=== 5.1 Development Environment Setup ===
* '''Install React and TypeScript''': Initialize a TypeScript and React setup, configuring linting and testing tools.
* '''Configure API Integration''': Define REST API endpoints for backend interaction, with TypeScript enforcing the response structure.

=== 5.2 Component Development Process ===
* '''Step-by-Step Development for Core Components''':
1. **Notification Management Page Components**:
* '''NotificationList''':
* '''Data Fetching''': Use a container to call the backend API, retrieving notifications based on user permissions.
* '''Display''': Render a list with notification summaries and active/inactive states. Notifications include a toggle to activate/deactivate, implemented by `NotificationToggle`.
* '''NotificationForm''':
* '''Role Validation''': Only accessible to TAs or higher, as verified through `AuthContext`.
* '''Form Fields''': Include title, message, and course selection with validation.
* '''Submission''': On submission, the form creates or updates a notification and refreshes `NotificationList`.

2. **Institution Management Page Components**:
* '''InstitutionList''':
* '''Data Loading''': The container fetches institutions for authorized users (e.g., `INSTRUCTOR` or `ADMIN`).
* '''Rendering''': Display institution names, associated courses, and additional information, with pagination and search for easy navigation.
* '''InstitutionForm''':
* '''Authorization Check''': Only `INSTRUCTOR` or `ADMIN` roles can access this form.
* '''Form Fields''': Fields include institution name, address, and details, with backend validation.
* '''Save and Update''': Submission calls the backend to create or update institution data.

=== 5.3 State Management ===
* **Global State with Context API**: The `AuthContext` and `NotificationContext` manage global states, including user roles and notification status.
* **Local State**: Component-level states manage form data, loading status, and error messages, scoped to each component to prevent unnecessary re-renders.

=== 5.4 Testing Strategy ===
* **Unit Tests**:
Components like `NotificationToggle` and `InstitutionForm` will be individually tested with Jest and React Testing Library for expected behavior.
* **Integration Tests**:
* '''Objective''': Verify interactions between components.
* '''Process''': Complete page testing to confirm permissions, data flows, and interactions work together. Example: Verifying that `NotificationList` updates when a new notification is created.
* **End-to-End Tests**:
* '''Objective''': Validate complete user flows and role-based access.
* '''Process''': Use Cypress to simulate real user actions, ensuring each role sees authorized components only.

=== 5.5 API Integration ===
* **RESTful API Design**: API interactions are defined using REST conventions, with TypeScript enforcing response structure integrity.
* **Error Handling**: Components handle API errors, guiding users with relevant messages.

== Team ==
===Mentor===
* Sahil Sawant

=== Members ===
* Arlee Shelby (ashelby@ncsu.edu)
* Aryan Tapkire (atapkir@ncsu.edu)
* Haojie Zhou (hzhou33@ncsu.edu)

==Links ==
*Github Repository:
*Pull Request:

==References==
[1]https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page

[2]https://github.com/expertiza/reimplementation-front-end

[3]https://github.com/expertiza/reimplementation-back-end

CSC/ECE 517 Fall 2024 - E2494. UI for Report Review for Assignment

2024-11-14T04:28:37Z

Atapkir:

===Overview===
This project will create a modern, responsive TypeScript and ReactJS interface for the Report Review page within Expertiza. It aims to present instructors with a summary of student reviews for each assignment. The design will prioritize simplicity and usability, providing instructors with a clear and effective way to review student feedback.

==1. Objective and Goals==
Develop a TypeScript and React-based UI for the Report Review page, accessible only to instructors, which will be responsive, intuitive, and efficient.

Key Goals:
1.Deliver an organized and clean display of student review summaries.
2.Create a responsive design adaptable to various screen sizes and devices.
3.Implement robust error handling for reliable data display and ensure usability across the application.

==2. Scope==
- Report Review Summary: Display individual review summaries per student for instructors, incorporating filtering and search functionalities to facilitate navigation.

- Role-Based Access Control (RBAC): Limit access to this page strictly to instructors, ensuring students cannot view the review summary.

==3. System Architecture==
The system architecture will use ReactJS with a focus on component reusability, TypeScript for type safety, and enhanced role-based access control. Components will communicate with the backend through RESTful APIs.

==4. Technical Specifications and Design Patterns==
4.1 Component Design and Structure
The Report Review UI will include modular components for scalability, reusability, and role-based access control.

Core Components for Report Review UI:

ReviewSummaryList: Displays a summary list of student reviews for a specific assignment.
ReviewDetail: Shows detailed information for each review, accessible upon selecting a summary.
ErrorBoundary: Wraps components to catch and display errors related to data fetching and rendering.

4.2 Enhanced Role Management System
Role management will ensure only instructors can access the Report Review page. Key elements include:

Role Enumeration (ROLE Enum): Define roles like INSTRUCTOR to control access to the Report Review UI.
Centralized Authentication Context (AuthContext): Store and provide role information globally. This enables easy role checks, such as
AuthContext.hasPermission('view_reviews'), to control access based on user roles.
Conditional Rendering: Use AuthContext to ensure only users with the INSTRUCTOR role can view the ReviewSummaryList.

4.3 Application of Design Patterns
Container-Presenter Pattern:

Purpose: Separate data-fetching logic from display logic for easier maintenance.
Application: A container component (e.g., ReviewSummaryPageContainer) will handle data fetching and pass the data to presentational components like ReviewSummaryList.
Benefits: Clear separation of concerns makes components more readable and easier to test.

Error Handling Pattern with Error Boundaries:

Purpose: Capture and manage errors for smoother user experience and reliability.
Application: Use an ErrorBoundary component to handle errors within the ReviewSummaryList and ReviewDetail components.
Benefits: Improves reliability by ensuring unexpected errors do not disrupt the entire page.

4.4 TypeScript for Static Typing
TypeScript will be used throughout to enforce strict typing, reduce errors, and improve code readability. Custom types/interfaces, such as ReviewSummary, will define expected
data structures for better integration with the backend API.

4.5 Testing Strategy
Unit Tests:

Components like ReviewDetail and ErrorBoundary will have unit tests to ensure error handling and data display work as expected.

Integration Tests:

Verify that data flows correctly between components, especially between ReviewSummaryList and ReviewDetail.

End-to-End Tests:

Simulate instructor interactions to ensure only authorized users can access the review data, validating user flows from review list to detailed view.

==5. Implementation Plan==

5.1 Development Environment Setup
Install React and TypeScript: Initialize a TypeScript and React setup, configuring linting and testing tools.
Configure API Integration: Define REST API endpoints for backend interaction, with TypeScript enforcing the response structure.

5.2 Component Development Process
Step-by-Step Development for Core Components:
1. Notification Management Page Components:
NotificationList:
Data Fetching: Use a container to call the backend API, retrieving notifications based on user permissions.
Display: Render a list with notification summaries and active/inactive states. Notifications include a toggle to activate/deactivate, implemented by `NotificationToggle`.
NotificationForm:
Role Validation: Only accessible to TAs or higher, as verified through `AuthContext`.
Form Fields: Include title, message, and course selection with validation.
Submission: On submission, the form creates or updates a notification and refreshes `NotificationList`.
2. Institution Management Page Components:
InstitutionList:
Data Loading: The container fetches institutions for authorized users (e.g., `INSTRUCTOR` or `ADMIN`).
Rendering: Display institution names, associated courses, and additional information, with pagination and search for easy navigation.
InstitutionForm:
Authorization Check: Only `INSTRUCTOR` or `ADMIN` roles can access this form.
Form Fields: Fields include institution name, address, and details, with backend validation.
Save and Update: Submission calls the backend to create or update institution data.

5.3 State Management
1. Global State with Context API: The `AuthContext` and `NotificationContext` manage global states, including user roles and notification status.
2. Local State: Component-level states manage form data, loading status, and error messages, scoped to each component to prevent unnecessary re-renders.

5.4 Testing Strategy
1. Unit Tests:
Components like `NotificationToggle` and `InstitutionForm` will be individually tested with Jest and React Testing Library for expected behavior.
2. Integration Tests:
Objective: Verify interactions between components.
Process: Complete-page testing to confirm permissions, data flows, and interactions work together. Example: Verifying that `NotificationList` updates when a new
notification is created.
3. End-to-End Tests:
Objective: Validate complete user flows and role-based access.
Process: Use Cypress to simulate real user actions, ensuring each role sees authorized components only.

5.5 API Integration
RESTful API Design: API interactions are defined using REST conventions, with TypeScript enforcing response structure integrity.
Error Handling: Components handle API errors, guiding users with relevant messages.

== Team ==
===Mentor===
* Sahil Sawant

=== Members ===
* Arlee Shelby (ashelby@ncsu.edu)
* Aryan Tapkire (atapkir@ncsu.edu)
* Haojie Zhou (hzhou33@ncsu.edu)

==Links ==
*Github Repository:
*Pull Request:

==References==
[1]https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page

[2]https://github.com/expertiza/reimplementation-front-end

[3]https://github.com/expertiza/reimplementation-back-end

CSC/ECE 517 Fall 2024 - E2494. UI for Report Review for Assignment

2024-11-14T04:04:04Z

Atapkir:

===Overview===
This project will create a modern, responsive TypeScript and ReactJS interface for the Report Review page within Expertiza. It aims to present instructors with a summary of student reviews for each assignment. The design will prioritize simplicity and usability, providing instructors with a clear and effective way to review student feedback.

==1. Objective and Goals==
Develop a TypeScript and React-based UI for the Report Review page, accessible only to instructors, which will be responsive, intuitive, and efficient.

Key Goals:
1.Deliver an organized and clean display of student review summaries.
2.Create a responsive design adaptable to various screen sizes and devices.
3.Implement robust error handling for reliable data display and ensure usability across the application.

==2. Scope==
- Report Review Summary: Display individual review summaries per student for instructors, incorporating filtering and search functionalities to facilitate navigation.

- Role-Based Access Control (RBAC): Limit access to this page strictly to instructors, ensuring students cannot view the review summary.

==3. System Architecture==
The system architecture will use ReactJS with a focus on component reusability, TypeScript for type safety, and enhanced role-based access control. Components will communicate with the backend through RESTful APIs.

==4. Technical Specifications and Design Patterns==
4.1 Component Design and Structure
The Report Review UI will include modular components for scalability, reusability, and role-based access control.

Core Components for Report Review UI:

ReviewSummaryList: Displays a summary list of student reviews for a specific assignment.
ReviewDetail: Shows detailed information for each review, accessible upon selecting a summary.
ErrorBoundary: Wraps components to catch and display errors related to data fetching and rendering.

4.2 Enhanced Role Management System
Role management will ensure only instructors can access the Report Review page. Key elements include:

Role Enumeration (ROLE Enum): Define roles like INSTRUCTOR to control access to the Report Review UI.
Centralized Authentication Context (AuthContext): Store and provide role information globally. This enables easy role checks, such as
AuthContext.hasPermission('view_reviews'), to control access based on user roles.
Conditional Rendering: Use AuthContext to ensure only users with the INSTRUCTOR role can view the ReviewSummaryList.

4.3 Application of Design Patterns
Container-Presenter Pattern:

Purpose: Separate data-fetching logic from display logic for easier maintenance.
Application: A container component (e.g., ReviewSummaryPageContainer) will handle data fetching and pass the data to presentational components like ReviewSummaryList.
Benefits: Clear separation of concerns makes components more readable and easier to test.

Error Handling Pattern with Error Boundaries:

Purpose: Capture and manage errors for smoother user experience and reliability.
Application: Use an ErrorBoundary component to handle errors within the ReviewSummaryList and ReviewDetail components.
Benefits: Improves reliability by ensuring unexpected errors do not disrupt the entire page.

4.4 TypeScript for Static Typing
TypeScript will be used throughout to enforce strict typing, reduce errors, and improve code readability. Custom types/interfaces, such as ReviewSummary, will define expected
data structures for better integration with the backend API.

4.5 Testing Strategy
Unit Tests:

Components like ReviewDetail and ErrorBoundary will have unit tests to ensure error handling and data display work as expected.

Integration Tests:

Verify that data flows correctly between components, especially between ReviewSummaryList and ReviewDetail.

End-to-End Tests:

Simulate instructor interactions to ensure only authorized users can access the review data, validating user flows from review list to detailed view.

==5. Implementation Plan==

5.1 Development Environment Setup
- Install React and TypeScript: Initialize a TypeScript and React setup, configuring linting and testing tools.
- Configure API Integration: Define REST API endpoints for backend interaction, with TypeScript enforcing the response structure.

5.2 Component Development Process
Step-by-Step Development for Core Components:
1. Notification Management Page Components:
- NotificationList:
- Data Fetching: Use a container to call the backend API, retrieving notifications based on user permissions.
- Display: Render a list with notification summaries and active/inactive states. Notifications include a toggle to activate/deactivate, implemented by `NotificationToggle`.
- NotificationForm:
- Role Validation: Only accessible to TAs or higher, as verified through `AuthContext`.
- Form Fields: Include title, message, and course selection with validation.
- Submission: On submission, the form creates or updates a notification and refreshes `NotificationList`.
2. Institution Management Page Components:
- InstitutionList:
- Data Loading: The container fetches institutions for authorized users (e.g., `INSTRUCTOR` or `ADMIN`).
- Rendering: Display institution names, associated courses, and additional information, with pagination and search for easy navigation.
- InstitutionForm:
- Authorization Check: Only `INSTRUCTOR` or `ADMIN` roles can access this form.
- Form Fields: Fields include institution name, address, and details, with backend validation.
- Save and Update: Submission calls the backend to create or update institution data.

5.3 State Management
1. Global State with Context API: The `AuthContext` and `NotificationContext` manage global states, including user roles and notification status.
2. Local State: Component-level states manage form data, loading status, and error messages, scoped to each component to prevent unnecessary re-renders.

5.4 Testing Strategy
1. Unit Tests:
- Components like `NotificationToggle` and `InstitutionForm` will be individually tested with Jest and React Testing Library for expected behavior.
2. Integration Tests:
- Objective: Verify interactions between components.
- Process: Complete-page testing to confirm permissions, data flows, and interactions work together. Example: Verifying that `NotificationList` updates when a new notification is created.
3. End-to-End Tests:
- Objective: Validate complete user flows and role-based access.
- Process: Use Cypress to simulate real user actions, ensuring each role sees authorized components only.

5.5 API Integration
- RESTful API Design: API interactions are defined using REST conventions, with TypeScript enforcing response structure integrity.
- Error Handling: Components handle API errors, guiding users with relevant messages.

== Team ==
===Mentor===
* Sahil Sawant

=== Members ===
* Arlee Shelby (ashelby@ncsu.edu)
* Aryan Tapkire (atapkir@ncsu.edu)
* Haojie Zhou (hzhou33@ncsu.edu)

==Links ==
*Github Repository:
*Pull Request:

==References==
[1]https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page

[2]https://github.com/expertiza/reimplementation-front-end

[3]https://github.com/expertiza/reimplementation-back-end

CSC/ECE 517 Fall 2024 - E2494. UI for Report Review for Assignment

2024-11-14T03:51:44Z

Atapkir:

CSC/ECE 517 Fall 2024 - E2494. UI for Report Review for Assignment

2024-11-14T03:50:50Z

Atapkir:

CSC/ECE 517 Fall 2024 - E2494. UI for Report Review for Assignment

2024-11-13T05:11:11Z

Atapkir:

==Background==
Expertiza is an open-source course management web application, built with Ruby on Rails, that is maintained by students and teaching staff across NC State and other universities. Additionally, Expertiza is used as a platform to help students learn how to work collaboratively and contribute to large applications concurrent with best practices and object oriented design and development.

This project involves building the UI for report review, using React to create a responsive and intuitive experience. The page displays the review summary for each student for individual assignments. This view is only accessible to the instructor and not the students. The goal of this project is to create the user interface in a way to keep the visual simple and efficient.

If you would like to learn more about Expertiza, please check the Expertiza wiki[1], or the GitHub pages [2],[3].

===Overview===
This project will replace the current Ruby on Rails frontend for Expertiza’s Institution and Notification UIs with a modern, maintainable TypeScript and ReactJS solution. The goals are to enhance user experience, secure role-based access, and facilitate better communication and course management.

==1. Objective and Goals==
Objective: Re-implement the frontend in TypeScript and ReactJS to improve maintainability, performance, and user experience, adhering to role-based access control and supporting effective notification and institution management.

==2. Scope==
Objective: Re-implement the frontend in TypeScript and ReactJS to improve maintainability, performance, and user experience, adhering to role-based access control and supporting effective notification and institution management.

==3. System Architecture==
Objective: Re-implement the frontend in TypeScript and ReactJS to improve maintainability, performance, and user experience, adhering to role-based access control and supporting effective notification and institution management.

==4. Technical Specifications and Design Patterns==
Objective: Re-implement the frontend in TypeScript and ReactJS to improve maintainability, performance, and user experience, adhering to role-based access control and supporting effective notification and institution management.

== Team ==
===Mentor===
* Sahil Sawant

=== Members ===
* Arlee Shelby (ashelby@ncsu.edu)
* Aryan Tapkire (atapkir@ncsu.edu)
* Haojie Zhou (hzhou33@ncsu.edu)

==Links ==
*Github Repository:
*Pull Request:

==References==
[1]https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page

[2]https://github.com/expertiza/reimplementation-front-end

[3]https://github.com/expertiza/reimplementation-back-end

[4]https://wiki.expertiza.ncsu.edu/index.php?title=Sign_up_topics

CSC/ECE 517 Fall 2024 - E2494. UI for Report Review for Assignment

2024-11-13T05:07:03Z

Atapkir:

CSC/ECE 517 Fall 2024 - E2494. UI for Report Review for Assignment

2024-11-13T05:03:39Z

Atapkir:

==Background==
Expertiza is an open-source course management web application, built with Ruby on Rails, that is maintained by students and teaching staff across NC State and other universities. Additionally, Expertiza is used as a platform to help students learn how to work collaboratively and contribute to large applications concurrent with best practices and object oriented design and development.

This project involves building the UI for report review, using React to create a responsive and intuitive experience. The page displays the review summary for each student for individual assignments. This view is only accessible to the instructor and not the students. The goal of this project is to create the user interface in a way to keep the visual simple and efficient.

What needs to be done:

1. Intuitive Design: Create a user-friendly interface that is easy to navigate and has enough spacing to ensure all the fetched information is being displayed in an orderly and clean fashion.
2. Responsive Design: The UI should be able to hold its design across multiple devices (mobile, laptop, tablet) and screen sizes (fullscreen, windowed).
3. Error Handling: Consider all possible data errors (invalid data, missing data) while displaying the fetched information.
4. Testing: Ensure that all the aspects of the component are functioning as intended, and make sure that the error handling is being taken care of. The reliability of the UI is
maintained.
If you would like to learn more about Expertiza, please check the Expertiza wiki[1], or the GitHub pages [2],[3].

===Overview===
This project will replace the current Ruby on Rails frontend for Expertiza’s Institution and Notification UIs with a modern, maintainable TypeScript and ReactJS solution. The goals are to enhance user experience, secure role-based access, and facilitate better communication and course management.
====Files Changed====
To provide access to our new Project Topics page, we added a new route and header to the following files, as well as updated the README.md file with instructions to add a user. We use the added user to view and test the student view. The current Expertiza application already has an admin user implemented which we used to test the admin/instructor display.
*src/App.tsx
*src/layout/Header.tsx
*README.md

== Team ==
===Mentor===
* Sahil Sawant

=== Members ===
* Arlee Shelby (ashelby@ncsu.edu)
* Aryan Tapkire (atapkir@ncsu.edu)
* Haojie Zhou (hzhou33@ncsu.edu)

==Links ==
*Github Repository:
*Pull Request:

==References==
[1]https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page

[2]https://github.com/expertiza/reimplementation-front-end

[3]https://github.com/expertiza/reimplementation-back-end

[4]https://wiki.expertiza.ncsu.edu/index.php?title=Sign_up_topics

CSC/ECE 517 Fall 2024 - E2494. UI for Report Review for Assignment

2024-11-13T05:02:20Z

Atapkir: Created page with "==Background== Expertiza is an open-source course management web application, built with Ruby on Rails, that is maintained by students and teaching staff across NC State and other universities. Additionally, Expertiza is used as a platform to help students learn how to work collaboratively and contribute to large applications concurrent with best practices and object oriented design and development. This project involves building the UI for report review, using React..."

==Background==
Expertiza is an open-source course management web application, built with Ruby on Rails, that is maintained by students and teaching staff across NC State and other universities. Additionally, Expertiza is used as a platform to help students learn how to work collaboratively and contribute to large applications concurrent with best practices and object oriented design and development.

This project involves building the UI for report review, using React to create a responsive and intuitive experience. The page displays the review summary for each student for individual assignments. This view is only accessible to the instructor and not the students. The goal of this project is to create the user interface in a way to keep the visual simple and efficient.

What needs to be done:

1. Intuitive Design: Create a user-friendly interface that is easy to navigate and has enough spacing to ensure all the fetched information is being displayed in an orderly and
clean fashion.
2. Responsive Design: The UI should be able to hold its design across multiple devices (mobile, laptop, tablet) and screen sizes (fullscreen, windowed).
3. Error Handling: Consider all possible data errors (invalid data, missing data) while displaying the fetched information.
4. Testing: Ensure that all the aspects of the component are functioning as intended, and make sure that the error handling is being taken care of. The reliability of the UI is
maintained.
If you would like to learn more about Expertiza, please check the Expertiza wiki[1], or the GitHub pages [2],[3].

===Overview===
This project will replace the current Ruby on Rails frontend for Expertiza’s Institution and Notification UIs with a modern, maintainable TypeScript and ReactJS solution. The goals are to enhance user experience, secure role-based access, and facilitate better communication and course management.
====Files Changed====
To provide access to our new Project Topics page, we added a new route and header to the following files, as well as updated the README.md file with instructions to add a user. We use the added user to view and test the student view. The current Expertiza application already has an admin user implemented which we used to test the admin/instructor display.
*src/App.tsx
*src/layout/Header.tsx
*README.md

== Team ==
===Mentor===
* Sahil Sawant

=== Members ===
* Arlee Shelby (ashelby@ncsu.edu)
* Aryan Tapkire (atapkir@ncsu.edu)
* Haojie Zhou (hzhou33@ncsu.edu)

==Links ==
*Github Repository:
*Pull Request:

==References==
[1]https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page

[2]https://github.com/expertiza/reimplementation-front-end

[3]https://github.com/expertiza/reimplementation-back-end

[4]https://wiki.expertiza.ncsu.edu/index.php?title=Sign_up_topics

CSC/ECE 517 Fall 2024

2024-11-13T04:54:12Z

Atapkir:

* [[CSC/ECE 517 Fall 2024 - E2450. Refactor assignments_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2451. Reimplement feedback_response_map.rb]]
* [[CSC/ECE 517 Fall 2024 - E2452. Refactor review_mapping_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2453. Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Fall 2024 - E2454. Refactor student_task.rb]]
* [[CSC/ECE 517 Fall 2024 - E2455. Refactor sign_up_sheet_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2456. Refactor teams_user.rb]]
* [[CSC/ECE 517 Fall 2024 - E2456. Refactor teams_user.rb (Phase 2 - Design Document)]]
* [[CSC/ECE 517 Fall 2024 - E2457. GitHub metrics integration]]
* [[CSC/ECE 517 Fall 2024 - E2458. User management and users table]]
* [[CSC/ECE 517 Fall 2024 - E2459. View for results of bidding]]
* [[CSC/ECE 517 Fall 2024 - E2460 Mentor-Meeting Management]]
* [[CSC/ECE 517 Fall 2024 - E2461. UI for Courses]]
* [[CSC/ECE 517 Fall 2024 - E2461. UI and Backend for Courses]]
* [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2024_-_E2462._UI_for_Questionnaires CSC/ECE 517 Fall 2024 - E2462. UI for Questionnaire.rb]
* [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2024_-_E2463_Implement_Front_End_for_Student_Task_List CSC/ECE 517 Fall 2024 - E2463. UI for Student Task List]
* [[CSC/ECE 517 Fall 2024 - E2464 UI for Project Topics (was: Sign_up_Topics)]]
* [[CSC/ECE 517 Fall 2024 - E2465. UI for Institutions and Notification]]
* [[CSC/ECE 517 Fall 2024 - E2466. UI for Impersonate User]]
* [[CSC/ECE 517 Fall 2024 - E2467. UI for View Submissions]]
* [[CSC/ECE 517 Fall 2024 - E2468. Reimplement due_date]]
* [[CSC/ECE 517 Fall 2024 - E2469. Reimplement grades/view_team]]
* [[CSC/ECE 517 Fall 2024 - E2470. Reimplement grades_controller]]
* [[CSC/ECE 517 Fall 2024 - E2471. Reimplement logger]]
* [[CSC/ECE 517 Fall 2024 - E2472. Reimplement responses_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2473. Reimplement sign up topic.rb as project topic.rb]]
* [[CSC/ECE 517 Fall 2024 - E2474. Reimplement student_quizzes_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2475. Reimplement student_task view]]
* [[CSC/ECE 517 Fall 2024 - E2476. Reimplement student_teams_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2477. Reimplement suggestion_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2478. Reimplement the Question hierarchy as Item hierarchy]]
* [[CSC/ECE 517 Fall 2024 - E2479. Reimplement teams_users_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2480. Implement testing for new Bookmarks Controller]]
* [[CSC/ECE 517 Fall 2024 - E2481 Reimplement response_map.rb]]
* [[CSC/ECE 517 Fall 2024 - E2482. Reimplement heatgrid for reviews]]
* [[CSC/ECE 517 Fall 2024 - E2483. Reimplement Notification Controller and Model]]
* [[CSC/ECE 517 Fall 2024 - E2484. Reimplement participants_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2485. Allow reviewers to bid on what to review]]
* [[CSC/ECE 517 Fall 2024 - E2487. Reimplement authorization_helper.rb]]
* [[CSC/ECE 517 Fall 2024 - E2488 Reimplementation of Add TA to course]]
* [[CSC/ECE 517 Fall 2024 - E2489. Create a UI for Assignment Edit page "Etc" tab in ReactJS]]
* [[CSC/ECE 517 Fall 2024 - E2491.UI for View assignments in Courses view]]
* [[CSC/ECE 517 Fall 2024 - E2492. UI for View submissions/assign grades (except heatgrid)]]
* [[CSC/ECE 517 Fall 2024 - E2493. UI for Assign Reviewers]]
* [[CSC/ECE 517 Fall 2024 - E2494. UI for Report Review for Assignment]]
* [[CSC/ECE 517 Fall 2024 - G2401 Refactor Graphql API endpoint for contribution metrics]]
* [[CSC/ECE 517 Fall 2024 - G2402 Refactor Graphql API endpoint for repositories]]

CSC/ECE 517 Fall 2024 - E2464 UI for Project Topics (was: Sign up Topics)

2024-10-29T04:53:58Z

Atapkir:

== Relevant Links ==
*Github Repository: https://github.com/arlee-shelby/reimplementation-front-end

==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 and extending the user interface for the Expertiza Project Topics page where students and teams choose and sign up for project topics.

== Team ==
===Mentor===
* Sahil Sawant

=== Members ===
* Arlee Shelby (ashelby@ncsu.edu)
* Aryan Tapkire (atapkir@ncsu.edu)
* Haojie Zhou (hzhou33@ncsu.edu)

CSC/ECE 517 Fall 2024 - E2464 UI for Project Topics (was: Sign up Topics)

2024-10-29T04:50:29Z

Atapkir: Created page with "== Relevant Links == *Github Repository: https://github.com/arlee-shelby/reimplementation-front-end == Team == ===Mentor=== * Sahil Sawant === Members === * Arlee Shelby (ashelby@ncsu.edu) * Aryan Tapkire (atapkir@ncsu.edu) * Haojie Zhou (hzhou33@ncsu.edu)"

== Relevant Links ==
*Github Repository: https://github.com/arlee-shelby/reimplementation-front-end

== Team ==
===Mentor===
* Sahil Sawant

=== Members ===
* Arlee Shelby (ashelby@ncsu.edu)
* Aryan Tapkire (atapkir@ncsu.edu)
* Haojie Zhou (hzhou33@ncsu.edu)

CSC/ECE 517 Fall 2024

2024-10-29T04:20:49Z

Atapkir:

* [[CSC/ECE 517 Fall 2024 - E2454. Refactor student_task.rb]]
* [[CSC/ECE 517 Fall 2024 - E2456. Refactor teams_user.rb]]
* [[CSC/ECE 517 Fall 2024 - E2455. Refactor sign_up_sheet_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2459. View for results of bidding]]
* [[CSC/ECE 517 Fall 2024 - E2461. UI for Courses]]
* [[CSC/ECE 517 Fall 2024 - E2465. UI for Institutions and Notification]]
* [[CSC/ECE 517 Fall 2024 - E2466. UI for Impersonate User]]
* [[CSC/ECE 517 Fall 2024 - E2467. UI for View Submissions]]
* [[CSC/ECE 517 Fall 2024 - E2469. Reimplement grades/view_team]]
* [[CSC/ECE 517 Fall 2024 - E2470. Reimplement grades_controller]]
* [[CSC/ECE 517 Fall 2024 - E2478. Reimplement the Question hierarchy as Item hierarchy]]
* [[CSC/ECE 517 Fall 2024 - E2480. Implement testing for new Bookmarks Controller]]
* [[CSC/ECE 517 Fall 2024 - E2482. Reimplement heatgrid for reviews]]
* [[CSC/ECE 517 Fall 2024 - E2460 Mentor-Meeting Management]]
* [[CSC/ECE 517 Fall 2024 - G2401 Refactor Graphql API endpoint for contribution metrics]]
* [[CSC/ECE 517 Fall 2024 - E2452. Refactor review_mapping_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2464 UI for Project Topics (was: Sign_up_Topics)]]