Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2025 - E2536. Improve assessment360 controller

2025-04-23T02:08:33Z

Psamant2: /* Current View (after code changes) */

== Problem Overview ==
The '''Assessment360 Controller''' within the Expertiza platform serves as a key tool for instructors, providing a holistic view of student performance across multiple assessment perspectives. The controller aggregates and displays data from various evaluation components, including teammate reviews, meta-reviews, instructor grades, peer review scores, and assignment submissions. The term <code>Assessment360</code> reflects its purpose of offering a comprehensive, 360-degree evaluation of a student's performance.

Currently, the system relies on two separate views — <code>all_students_all_reviews</code> and <code>course_student_grade_summary</code> — to display different aspects of student performance. These views present:
* Project-level data: The projects a student has worked on and the corresponding grades.
* Peer review data: The scores students receive from their teammates through the teammate review process.

While these views serve important functions, their separation results in a fragmented user experience, as instructors must switch between the views to see a complete set of student performance data. Additionally, the user interface (UI) is not optimized for an intuitive, seamless experience. There are limitations regarding
* The ability to interact with or customize the data display (e.g., column visibility, sorting, and reordering).
* The lack of visual clarity in data presentation (e.g., inconsistent formatting and absence of visual grade indicators).
* Inadequate responsiveness for different device types.

== Objective ==
The primary goal is to enhance the UI/UX and code quality of the <code>assessment360</code> controller. This involves:
* Merging the two existing views (<code>all_students_all_reviews</code> and <code>course_student_grade_summary</code>) into a single unified view.
* Improving the presentation and clarity of data (student grades, peer reviews).
* Refactoring logic for better separation of concerns and maintainability.
* Implementing feedback from the previous team.

== Current Implementation ==

=== Controller Structure ===
The <code>Assessment360Controller</code> is the central controller handling the logic for both the <code>all_students_all_reviews</code> and <code>course_student_grade_summary</code> views. It interacts with various models and services to fetch, process, and deliver the necessary data to the views. The current structure is as follows:
* The controller is responsible for gathering and processing assessment data such as grades, peer reviews, and meta-reviews for each student.
* It includes logic for handling class averages, calculating final grades, and determining peer review averages.
* The current implementation uses direct logic for grade calculations, and all calculations are executed within the controller itself, which could lead to bloated code and reduced maintainability.
* The views are rendered with minimal controller-side logic, relying on the controller to pass the necessary data to the front-end.

=== Current Views ===
The current implementation provides two main views that instructors can use to assess the performance of students. These views are defined in separate HTML ERB files.

==== <code>all_students_all_reviews.html.erb</code> ====
This view displays detailed student performance data in a table format. Key features include:
* Student Information Table: Displays each student’s name, ID, and relevant information.
* Teammate and Meta-Review Scores: For each student, the table shows the scores received from teammates and meta-reviews, which help in assessing peer evaluations.
* Class Averages: For each assignment and review type, class averages are calculated and displayed for instructors to analyze the overall performance of the class.
* Separate Columns for Review Types: Each type of review (<code>teammate</code>, <code>meta-review</code>, etc.) is shown in a separate column, making it easy to compare different assessment categories side by side.

==== <code>course_student_grade_summary.html.erb</code> ====
This view focuses on summarizing the project grades and peer review scores for each student. It includes:
* Student Grades and Peer Review Scores**: Displays the individual project grades and the peer review scores that a student has received.
* Assignment Topics: Lists the assignment topics associated with each project, along with the grades and peer review scores for those specific topics.
* Final Grades and Peer Review Averages: The final grade for each student is calculated by considering both the project grade and peer review scores, and the average peer review score is displayed alongside the final grade.
* Sortable Table Structure: The table in this view is designed to be sortable, allowing instructors to order students by project grades, peer review scores, or any other criterion available in the table. This adds flexibility in how data is analyzed.

== Use Case Diagram ==
For this project our job is to unify the view of the two files, i.e. all_students_all_reviews and course_student_grade_summary, which were created in the previous implementation to one. This would result in a single view which would help in evaluating performances by combining a lot of different perspectives. In our case, if we merge the two files and create a new view, the user should be able to view all the information that is there to be seen in one page. This includes:
* Viewing a Unified Dashboard
* Viewing all the Project Grades
* Viewing Peer Evaluation Scores
* Selecting and Deselecting Columns

Using this information we have created the following Use Case Diagram:

<center>[[File:E2536_Spring_2025.png|600x600px|Improve assessment360]]</center>

== Design Pattern Usage in Assessment360Controller ==

The '''Assessment360Controller''' implements multiple design patterns that improve clarity, modularity, and maintainability of the code.

=== 1. Facade Pattern ===
The controller acts as a facade, hiding complex interactions between various models (''Course'', ''Assignment'', ''Participant'', ''Team'', etc.) and exposing a simplified interface for the view. It aggregates data like grades, reviews, and penalties and prepares it in a structured format, simplifying the presentation layer.

=== 2. Strategy Pattern ===
The use of helper modules such as:
* '''GradesHelper'''
* '''AuthorizationHelper'''
* '''Scoring'''
* '''PenaltyHelper'''

follows the Strategy Pattern. Each module encapsulates a specific piece of functionality, and the controller delegates responsibility to these interchangeable strategies, promoting clean separation of concerns and easier testing.

=== 3. Template Method Pattern ===
The method '''action_allowed?''' is a hook method that overrides a predefined template method in ''ApplicationController''. This allows customized access control behavior while maintaining a consistent interface across all controllers — an example of the Template Method Pattern in action.

=== 4. Separation of Concerns ===
Responsibility is split between:
* '''Controller''': Orchestrates data flow
* '''Models''': Store and retrieve business data
* '''Helpers''': Encapsulate computation and utility logic
* '''Views''': Render formatted output

This adheres to the '''Separation of Concerns''' principle and keeps each layer clean and testable.

These design patterns contribute to the robustness and scalability of the 360-degree assessment feature, allowing future teams to maintain and extend it with ease.

== Planned Enhancements ==

=== Functional Changes ===
{| class="wikitable"
! Feature !! Description
|-
| Unified View || Combine both views into a single HTML page that includes both project grades and review scores.
|-
| Column Selection || Allow users to toggle visible columns using checkboxes.
|-
| Exclude Unreviewed Assignments || Retain the functionality to exclude unreviewed assignments from averages.
|-
| Averages Precision || Limit decimal precision to 2 points for clarity.
|-
| Wider Name Column || Adjust layout to prioritize readability (e.g., wider name column than username).
|}

=== Code Refactor ===
{| class="wikitable"
! Task !! Reason
|-
| Move averaging logic to mixins or model concerns || Improve separation of concerns and reusability.
|-
| Commenting || Add meaningful comments for helper methods and business logic.
|}

== UI/UX Design ==
The new unified view will feature:
* A tabular layout showing all relevant data.
* Sectioned headers for each student.
* Collapsible panels (if needed) for clarity.
* Visual cues for peer review vs. project grades.
* Responsive design for usability across devices.

== Implementation ==

=== Previous View ===

Previously, the Assessment360 Controllers view relied on two separate views i.e. all_students_all_reviews and course_student_grade_summary, to display different aspects of student performance. This is how they looked like before.

1. all_students_all_reviews.html.erb

[[File:old_all_students_all_reviews.png|750px]]

2. course_student_grade_summary.html.erb

[[File:old_course_student_grade_summary.png|750px]]

=== Current View (after code changes) ===

The main objective of this project was to enhance the UI/UX and code quality of the assessment360 controller. This involved merging the two existing views (all_students_all_reviews and course_student_grade_summary) into a single unified view.

1. assessment360_controller.rb

[[File:Assessment360_1.png|750px]]

[[File:assessment360_2.png|750px]]

[[File:assessment360_3.png|750px]]

2. all_students_all_reviews.html.erb and course_student_grade_summary.html.erb removed

[[File:Delete_2.png|750px]]

3. course_summary.html.erb added which contains the combined view

[[File:course_summary.png|750px]]

2. tree_display.jsx

[[File:tree_display.png|750px]]

3. routes.rb

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

== Testing Strategy ==

{| class="wikitable"
|-
! Type !! Description !! Tests
|-
| ''' Unit Tests''' || Test individual controller methods || - Test grade calculations - Test data formatting
|-
| ''' Integration Tests''' || Test interactions between components || - Test view rendering - Test database queries - Test caching functionality
|-
| ''' Manual Testing''' || Test UI functionality, performance, and error handling || - Test UI functionality - Test performance with large datasets - Test error scenarios
|}

=== Testing Results ===

[[File:testing.png|750px]]

== Success Criteria ==

The success of this feature implementation will be evaluated based on the following criteria:

{| class="wikitable"
|-
! Criterion !! Description
|-
| '''UI Enhancements Implemented and Working''' || All proposed UI enhancements, including the unified view, column management features, and data presentation improvements, must be fully implemented and functioning as expected. The UI should be intuitive, responsive, and meet the design goals outlined in the document.
|-
| '''Performance Improvements Measurable''' || The feature should demonstrate a measurable improvement in performance, particularly in terms of load times and responsiveness when rendering large datasets or performing grade calculations. Performance benchmarking should indicate a noticeable reduction in latency.
|-
| '''Test Coverage ''' || Comprehensive unit and integration tests must cover more than 80% of the new code and critical paths in the controller. This ensures that the feature is reliable, and potential issues are identified early in the development cycle. Test results should be stable, with no significant failures.
|-
| '''Code Documentation Complete''' || All new and modified code must be thoroughly documented. This includes clear inline comments, explanations for complex logic, and appropriate documentation for new functions, classes, and components. This ensures that future developers can understand and maintain the code efficiently.
|-
| '''No Regression Bugs''' || After implementing the new feature, no existing functionality in the Assessment360 controller should break or behave unexpectedly. Regression testing should show that previously working parts of the system continue to function without issues.
|-
| '''Positive User Feedback''' || End-users (instructors and administrators) must provide positive feedback about the usability and effectiveness of the feature. Feedback should indicate that the feature adds value, improves user experience, and meets the goals outlined in the design document.
|}

== Implementation Video ==

Video Link: https://drive.google.com/file/d/1aAzGuSc-qwed4sGMIsWrIgelTTqd_OJ0/view

Youtube Link: https://youtu.be/I3f4sVR_NWg

== Team Information ==
'''Mentor:''' Mitesh Anil Agarwal

'''Team:'''
* Jap Ashokbhai Purohit - jpurohi@ncsu.edu
* Sharmeen Momin - smomin@ncsu.edu
* Prithish Samanta - psamant2@ncsu.edu

== References ==
* [https://github.com/expertiza/expertiza Expertiza Codebase]
* [https://guides.rubyonrails.org/action_view_overview.html Rails View Helpers]
* [https://github.com/flyerhzm/bullet Bullet Gem Documentation]

CSC/ECE 517 Spring 2025 - E2536. Improve assessment360 controller

2025-04-23T02:08:10Z

Psamant2: /* Current View (after code changes) */

== Problem Overview ==
The '''Assessment360 Controller''' within the Expertiza platform serves as a key tool for instructors, providing a holistic view of student performance across multiple assessment perspectives. The controller aggregates and displays data from various evaluation components, including teammate reviews, meta-reviews, instructor grades, peer review scores, and assignment submissions. The term <code>Assessment360</code> reflects its purpose of offering a comprehensive, 360-degree evaluation of a student's performance.

Currently, the system relies on two separate views — <code>all_students_all_reviews</code> and <code>course_student_grade_summary</code> — to display different aspects of student performance. These views present:
* Project-level data: The projects a student has worked on and the corresponding grades.
* Peer review data: The scores students receive from their teammates through the teammate review process.

While these views serve important functions, their separation results in a fragmented user experience, as instructors must switch between the views to see a complete set of student performance data. Additionally, the user interface (UI) is not optimized for an intuitive, seamless experience. There are limitations regarding
* The ability to interact with or customize the data display (e.g., column visibility, sorting, and reordering).
* The lack of visual clarity in data presentation (e.g., inconsistent formatting and absence of visual grade indicators).
* Inadequate responsiveness for different device types.

== Objective ==
The primary goal is to enhance the UI/UX and code quality of the <code>assessment360</code> controller. This involves:
* Merging the two existing views (<code>all_students_all_reviews</code> and <code>course_student_grade_summary</code>) into a single unified view.
* Improving the presentation and clarity of data (student grades, peer reviews).
* Refactoring logic for better separation of concerns and maintainability.
* Implementing feedback from the previous team.

== Current Implementation ==

=== Controller Structure ===
The <code>Assessment360Controller</code> is the central controller handling the logic for both the <code>all_students_all_reviews</code> and <code>course_student_grade_summary</code> views. It interacts with various models and services to fetch, process, and deliver the necessary data to the views. The current structure is as follows:
* The controller is responsible for gathering and processing assessment data such as grades, peer reviews, and meta-reviews for each student.
* It includes logic for handling class averages, calculating final grades, and determining peer review averages.
* The current implementation uses direct logic for grade calculations, and all calculations are executed within the controller itself, which could lead to bloated code and reduced maintainability.
* The views are rendered with minimal controller-side logic, relying on the controller to pass the necessary data to the front-end.

=== Current Views ===
The current implementation provides two main views that instructors can use to assess the performance of students. These views are defined in separate HTML ERB files.

==== <code>all_students_all_reviews.html.erb</code> ====
This view displays detailed student performance data in a table format. Key features include:
* Student Information Table: Displays each student’s name, ID, and relevant information.
* Teammate and Meta-Review Scores: For each student, the table shows the scores received from teammates and meta-reviews, which help in assessing peer evaluations.
* Class Averages: For each assignment and review type, class averages are calculated and displayed for instructors to analyze the overall performance of the class.
* Separate Columns for Review Types: Each type of review (<code>teammate</code>, <code>meta-review</code>, etc.) is shown in a separate column, making it easy to compare different assessment categories side by side.

==== <code>course_student_grade_summary.html.erb</code> ====
This view focuses on summarizing the project grades and peer review scores for each student. It includes:
* Student Grades and Peer Review Scores**: Displays the individual project grades and the peer review scores that a student has received.
* Assignment Topics: Lists the assignment topics associated with each project, along with the grades and peer review scores for those specific topics.
* Final Grades and Peer Review Averages: The final grade for each student is calculated by considering both the project grade and peer review scores, and the average peer review score is displayed alongside the final grade.
* Sortable Table Structure: The table in this view is designed to be sortable, allowing instructors to order students by project grades, peer review scores, or any other criterion available in the table. This adds flexibility in how data is analyzed.

== Use Case Diagram ==
For this project our job is to unify the view of the two files, i.e. all_students_all_reviews and course_student_grade_summary, which were created in the previous implementation to one. This would result in a single view which would help in evaluating performances by combining a lot of different perspectives. In our case, if we merge the two files and create a new view, the user should be able to view all the information that is there to be seen in one page. This includes:
* Viewing a Unified Dashboard
* Viewing all the Project Grades
* Viewing Peer Evaluation Scores
* Selecting and Deselecting Columns

Using this information we have created the following Use Case Diagram:

<center>[[File:E2536_Spring_2025.png|600x600px|Improve assessment360]]</center>

== Design Pattern Usage in Assessment360Controller ==

The '''Assessment360Controller''' implements multiple design patterns that improve clarity, modularity, and maintainability of the code.

=== 1. Facade Pattern ===
The controller acts as a facade, hiding complex interactions between various models (''Course'', ''Assignment'', ''Participant'', ''Team'', etc.) and exposing a simplified interface for the view. It aggregates data like grades, reviews, and penalties and prepares it in a structured format, simplifying the presentation layer.

=== 2. Strategy Pattern ===
The use of helper modules such as:
* '''GradesHelper'''
* '''AuthorizationHelper'''
* '''Scoring'''
* '''PenaltyHelper'''

follows the Strategy Pattern. Each module encapsulates a specific piece of functionality, and the controller delegates responsibility to these interchangeable strategies, promoting clean separation of concerns and easier testing.

=== 3. Template Method Pattern ===
The method '''action_allowed?''' is a hook method that overrides a predefined template method in ''ApplicationController''. This allows customized access control behavior while maintaining a consistent interface across all controllers — an example of the Template Method Pattern in action.

=== 4. Separation of Concerns ===
Responsibility is split between:
* '''Controller''': Orchestrates data flow
* '''Models''': Store and retrieve business data
* '''Helpers''': Encapsulate computation and utility logic
* '''Views''': Render formatted output

This adheres to the '''Separation of Concerns''' principle and keeps each layer clean and testable.

These design patterns contribute to the robustness and scalability of the 360-degree assessment feature, allowing future teams to maintain and extend it with ease.

== Planned Enhancements ==

=== Functional Changes ===
{| class="wikitable"
! Feature !! Description
|-
| Unified View || Combine both views into a single HTML page that includes both project grades and review scores.
|-
| Column Selection || Allow users to toggle visible columns using checkboxes.
|-
| Exclude Unreviewed Assignments || Retain the functionality to exclude unreviewed assignments from averages.
|-
| Averages Precision || Limit decimal precision to 2 points for clarity.
|-
| Wider Name Column || Adjust layout to prioritize readability (e.g., wider name column than username).
|}

=== Code Refactor ===
{| class="wikitable"
! Task !! Reason
|-
| Move averaging logic to mixins or model concerns || Improve separation of concerns and reusability.
|-
| Commenting || Add meaningful comments for helper methods and business logic.
|}

== UI/UX Design ==
The new unified view will feature:
* A tabular layout showing all relevant data.
* Sectioned headers for each student.
* Collapsible panels (if needed) for clarity.
* Visual cues for peer review vs. project grades.
* Responsive design for usability across devices.

== Implementation ==

=== Previous View ===

Previously, the Assessment360 Controllers view relied on two separate views i.e. all_students_all_reviews and course_student_grade_summary, to display different aspects of student performance. This is how they looked like before.

1. all_students_all_reviews.html.erb

[[File:old_all_students_all_reviews.png|750px]]

2. course_student_grade_summary.html.erb

[[File:old_course_student_grade_summary.png|750px]]

=== Current View (after code changes) ===

The main objective of this project was to enhance the UI/UX and code quality of the assessment360 controller. This involved merging the two existing views (all_students_all_reviews and course_student_grade_summary) into a single unified view.

1. assessment360_controller.rb

[[File:Assessment360_1.png.png|750px]]

[[File:assessment360_2.png.png|750px]]

[[File:assessment360_3.png.png|750px]]

2. all_students_all_reviews.html.erb and course_student_grade_summary.html.erb removed

[[File:Delete_2.png|750px]]

3. course_summary.html.erb added which contains the combined view

[[File:course_summary.png|750px]]

2. tree_display.jsx

[[File:tree_display.png|750px]]

3. routes.rb

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

== Testing Strategy ==

{| class="wikitable"
|-
! Type !! Description !! Tests
|-
| ''' Unit Tests''' || Test individual controller methods || - Test grade calculations - Test data formatting
|-
| ''' Integration Tests''' || Test interactions between components || - Test view rendering - Test database queries - Test caching functionality
|-
| ''' Manual Testing''' || Test UI functionality, performance, and error handling || - Test UI functionality - Test performance with large datasets - Test error scenarios
|}

=== Testing Results ===

[[File:testing.png|750px]]

== Success Criteria ==

The success of this feature implementation will be evaluated based on the following criteria:

{| class="wikitable"
|-
! Criterion !! Description
|-
| '''UI Enhancements Implemented and Working''' || All proposed UI enhancements, including the unified view, column management features, and data presentation improvements, must be fully implemented and functioning as expected. The UI should be intuitive, responsive, and meet the design goals outlined in the document.
|-
| '''Performance Improvements Measurable''' || The feature should demonstrate a measurable improvement in performance, particularly in terms of load times and responsiveness when rendering large datasets or performing grade calculations. Performance benchmarking should indicate a noticeable reduction in latency.
|-
| '''Test Coverage ''' || Comprehensive unit and integration tests must cover more than 80% of the new code and critical paths in the controller. This ensures that the feature is reliable, and potential issues are identified early in the development cycle. Test results should be stable, with no significant failures.
|-
| '''Code Documentation Complete''' || All new and modified code must be thoroughly documented. This includes clear inline comments, explanations for complex logic, and appropriate documentation for new functions, classes, and components. This ensures that future developers can understand and maintain the code efficiently.
|-
| '''No Regression Bugs''' || After implementing the new feature, no existing functionality in the Assessment360 controller should break or behave unexpectedly. Regression testing should show that previously working parts of the system continue to function without issues.
|-
| '''Positive User Feedback''' || End-users (instructors and administrators) must provide positive feedback about the usability and effectiveness of the feature. Feedback should indicate that the feature adds value, improves user experience, and meets the goals outlined in the design document.
|}

== Implementation Video ==

Video Link: https://drive.google.com/file/d/1aAzGuSc-qwed4sGMIsWrIgelTTqd_OJ0/view

Youtube Link: https://youtu.be/I3f4sVR_NWg

== Team Information ==
'''Mentor:''' Mitesh Anil Agarwal

'''Team:'''
* Jap Ashokbhai Purohit - jpurohi@ncsu.edu
* Sharmeen Momin - smomin@ncsu.edu
* Prithish Samanta - psamant2@ncsu.edu

== References ==
* [https://github.com/expertiza/expertiza Expertiza Codebase]
* [https://guides.rubyonrails.org/action_view_overview.html Rails View Helpers]
* [https://github.com/flyerhzm/bullet Bullet Gem Documentation]

CSC/ECE 517 Spring 2025 - E2536. Improve assessment360 controller

2025-04-23T02:07:46Z

Psamant2: /* Current View (after code changes) */

== Problem Overview ==
The '''Assessment360 Controller''' within the Expertiza platform serves as a key tool for instructors, providing a holistic view of student performance across multiple assessment perspectives. The controller aggregates and displays data from various evaluation components, including teammate reviews, meta-reviews, instructor grades, peer review scores, and assignment submissions. The term <code>Assessment360</code> reflects its purpose of offering a comprehensive, 360-degree evaluation of a student's performance.

Currently, the system relies on two separate views — <code>all_students_all_reviews</code> and <code>course_student_grade_summary</code> — to display different aspects of student performance. These views present:
* Project-level data: The projects a student has worked on and the corresponding grades.
* Peer review data: The scores students receive from their teammates through the teammate review process.

While these views serve important functions, their separation results in a fragmented user experience, as instructors must switch between the views to see a complete set of student performance data. Additionally, the user interface (UI) is not optimized for an intuitive, seamless experience. There are limitations regarding
* The ability to interact with or customize the data display (e.g., column visibility, sorting, and reordering).
* The lack of visual clarity in data presentation (e.g., inconsistent formatting and absence of visual grade indicators).
* Inadequate responsiveness for different device types.

== Objective ==
The primary goal is to enhance the UI/UX and code quality of the <code>assessment360</code> controller. This involves:
* Merging the two existing views (<code>all_students_all_reviews</code> and <code>course_student_grade_summary</code>) into a single unified view.
* Improving the presentation and clarity of data (student grades, peer reviews).
* Refactoring logic for better separation of concerns and maintainability.
* Implementing feedback from the previous team.

== Current Implementation ==

=== Controller Structure ===
The <code>Assessment360Controller</code> is the central controller handling the logic for both the <code>all_students_all_reviews</code> and <code>course_student_grade_summary</code> views. It interacts with various models and services to fetch, process, and deliver the necessary data to the views. The current structure is as follows:
* The controller is responsible for gathering and processing assessment data such as grades, peer reviews, and meta-reviews for each student.
* It includes logic for handling class averages, calculating final grades, and determining peer review averages.
* The current implementation uses direct logic for grade calculations, and all calculations are executed within the controller itself, which could lead to bloated code and reduced maintainability.
* The views are rendered with minimal controller-side logic, relying on the controller to pass the necessary data to the front-end.

=== Current Views ===
The current implementation provides two main views that instructors can use to assess the performance of students. These views are defined in separate HTML ERB files.

==== <code>all_students_all_reviews.html.erb</code> ====
This view displays detailed student performance data in a table format. Key features include:
* Student Information Table: Displays each student’s name, ID, and relevant information.
* Teammate and Meta-Review Scores: For each student, the table shows the scores received from teammates and meta-reviews, which help in assessing peer evaluations.
* Class Averages: For each assignment and review type, class averages are calculated and displayed for instructors to analyze the overall performance of the class.
* Separate Columns for Review Types: Each type of review (<code>teammate</code>, <code>meta-review</code>, etc.) is shown in a separate column, making it easy to compare different assessment categories side by side.

==== <code>course_student_grade_summary.html.erb</code> ====
This view focuses on summarizing the project grades and peer review scores for each student. It includes:
* Student Grades and Peer Review Scores**: Displays the individual project grades and the peer review scores that a student has received.
* Assignment Topics: Lists the assignment topics associated with each project, along with the grades and peer review scores for those specific topics.
* Final Grades and Peer Review Averages: The final grade for each student is calculated by considering both the project grade and peer review scores, and the average peer review score is displayed alongside the final grade.
* Sortable Table Structure: The table in this view is designed to be sortable, allowing instructors to order students by project grades, peer review scores, or any other criterion available in the table. This adds flexibility in how data is analyzed.

== Use Case Diagram ==
For this project our job is to unify the view of the two files, i.e. all_students_all_reviews and course_student_grade_summary, which were created in the previous implementation to one. This would result in a single view which would help in evaluating performances by combining a lot of different perspectives. In our case, if we merge the two files and create a new view, the user should be able to view all the information that is there to be seen in one page. This includes:
* Viewing a Unified Dashboard
* Viewing all the Project Grades
* Viewing Peer Evaluation Scores
* Selecting and Deselecting Columns

Using this information we have created the following Use Case Diagram:

<center>[[File:E2536_Spring_2025.png|600x600px|Improve assessment360]]</center>

== Design Pattern Usage in Assessment360Controller ==

The '''Assessment360Controller''' implements multiple design patterns that improve clarity, modularity, and maintainability of the code.

=== 1. Facade Pattern ===
The controller acts as a facade, hiding complex interactions between various models (''Course'', ''Assignment'', ''Participant'', ''Team'', etc.) and exposing a simplified interface for the view. It aggregates data like grades, reviews, and penalties and prepares it in a structured format, simplifying the presentation layer.

=== 2. Strategy Pattern ===
The use of helper modules such as:
* '''GradesHelper'''
* '''AuthorizationHelper'''
* '''Scoring'''
* '''PenaltyHelper'''

follows the Strategy Pattern. Each module encapsulates a specific piece of functionality, and the controller delegates responsibility to these interchangeable strategies, promoting clean separation of concerns and easier testing.

=== 3. Template Method Pattern ===
The method '''action_allowed?''' is a hook method that overrides a predefined template method in ''ApplicationController''. This allows customized access control behavior while maintaining a consistent interface across all controllers — an example of the Template Method Pattern in action.

=== 4. Separation of Concerns ===
Responsibility is split between:
* '''Controller''': Orchestrates data flow
* '''Models''': Store and retrieve business data
* '''Helpers''': Encapsulate computation and utility logic
* '''Views''': Render formatted output

This adheres to the '''Separation of Concerns''' principle and keeps each layer clean and testable.

These design patterns contribute to the robustness and scalability of the 360-degree assessment feature, allowing future teams to maintain and extend it with ease.

== Planned Enhancements ==

=== Functional Changes ===
{| class="wikitable"
! Feature !! Description
|-
| Unified View || Combine both views into a single HTML page that includes both project grades and review scores.
|-
| Column Selection || Allow users to toggle visible columns using checkboxes.
|-
| Exclude Unreviewed Assignments || Retain the functionality to exclude unreviewed assignments from averages.
|-
| Averages Precision || Limit decimal precision to 2 points for clarity.
|-
| Wider Name Column || Adjust layout to prioritize readability (e.g., wider name column than username).
|}

=== Code Refactor ===
{| class="wikitable"
! Task !! Reason
|-
| Move averaging logic to mixins or model concerns || Improve separation of concerns and reusability.
|-
| Commenting || Add meaningful comments for helper methods and business logic.
|}

== UI/UX Design ==
The new unified view will feature:
* A tabular layout showing all relevant data.
* Sectioned headers for each student.
* Collapsible panels (if needed) for clarity.
* Visual cues for peer review vs. project grades.
* Responsive design for usability across devices.

== Implementation ==

=== Previous View ===

Previously, the Assessment360 Controllers view relied on two separate views i.e. all_students_all_reviews and course_student_grade_summary, to display different aspects of student performance. This is how they looked like before.

1. all_students_all_reviews.html.erb

[[File:old_all_students_all_reviews.png|750px]]

2. course_student_grade_summary.html.erb

[[File:old_course_student_grade_summary.png|750px]]

=== Current View (after code changes) ===

The main objective of this project was to enhance the UI/UX and code quality of the assessment360 controller. This involved merging the two existing views (all_students_all_reviews and course_student_grade_summary) into a single unified view.

1. assessment360_controller.rb

[[File:assessment360_1.png.png|750px]]

[[File:assessment360_2.png.png|750px]]

[[File:assessment360_3.png.png|750px]]

2. all_students_all_reviews.html.erb and course_student_grade_summary.html.erb removed

[[File:Delete_2.png|750px]]

3. course_summary.html.erb added which contains the combined view

[[File:course_summary.png|750px]]

2. tree_display.jsx

[[File:tree_display.png|750px]]

3. routes.rb

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

== Testing Strategy ==

{| class="wikitable"
|-
! Type !! Description !! Tests
|-
| ''' Unit Tests''' || Test individual controller methods || - Test grade calculations - Test data formatting
|-
| ''' Integration Tests''' || Test interactions between components || - Test view rendering - Test database queries - Test caching functionality
|-
| ''' Manual Testing''' || Test UI functionality, performance, and error handling || - Test UI functionality - Test performance with large datasets - Test error scenarios
|}

=== Testing Results ===

[[File:testing.png|750px]]

== Success Criteria ==

The success of this feature implementation will be evaluated based on the following criteria:

{| class="wikitable"
|-
! Criterion !! Description
|-
| '''UI Enhancements Implemented and Working''' || All proposed UI enhancements, including the unified view, column management features, and data presentation improvements, must be fully implemented and functioning as expected. The UI should be intuitive, responsive, and meet the design goals outlined in the document.
|-
| '''Performance Improvements Measurable''' || The feature should demonstrate a measurable improvement in performance, particularly in terms of load times and responsiveness when rendering large datasets or performing grade calculations. Performance benchmarking should indicate a noticeable reduction in latency.
|-
| '''Test Coverage ''' || Comprehensive unit and integration tests must cover more than 80% of the new code and critical paths in the controller. This ensures that the feature is reliable, and potential issues are identified early in the development cycle. Test results should be stable, with no significant failures.
|-
| '''Code Documentation Complete''' || All new and modified code must be thoroughly documented. This includes clear inline comments, explanations for complex logic, and appropriate documentation for new functions, classes, and components. This ensures that future developers can understand and maintain the code efficiently.
|-
| '''No Regression Bugs''' || After implementing the new feature, no existing functionality in the Assessment360 controller should break or behave unexpectedly. Regression testing should show that previously working parts of the system continue to function without issues.
|-
| '''Positive User Feedback''' || End-users (instructors and administrators) must provide positive feedback about the usability and effectiveness of the feature. Feedback should indicate that the feature adds value, improves user experience, and meets the goals outlined in the design document.
|}

== Implementation Video ==

Video Link: https://drive.google.com/file/d/1aAzGuSc-qwed4sGMIsWrIgelTTqd_OJ0/view

Youtube Link: https://youtu.be/I3f4sVR_NWg

== Team Information ==
'''Mentor:''' Mitesh Anil Agarwal

'''Team:'''
* Jap Ashokbhai Purohit - jpurohi@ncsu.edu
* Sharmeen Momin - smomin@ncsu.edu
* Prithish Samanta - psamant2@ncsu.edu

== References ==
* [https://github.com/expertiza/expertiza Expertiza Codebase]
* [https://guides.rubyonrails.org/action_view_overview.html Rails View Helpers]
* [https://github.com/flyerhzm/bullet Bullet Gem Documentation]

File:Delete 2.png

2025-04-23T02:07:22Z

Psamant2:

File:Course summary.png

2025-04-23T02:06:53Z

Psamant2:

File:Tree display.png

2025-04-23T02:04:50Z

Psamant2:

File:Routes.png

2025-04-23T02:03:45Z

Psamant2:

File:Assessment360 3.png

2025-04-23T01:59:48Z

Psamant2:

File:Assessment360 2.png

2025-04-23T01:59:39Z

Psamant2:

File:Assessment360 1.png

2025-04-23T01:59:29Z

Psamant2:

CSC/ECE 517 Spring 2025 - E2536. Improve assessment360 controller

2025-04-23T01:54:53Z

Psamant2: /* Implementation */

== Problem Overview ==
The '''Assessment360 Controller''' within the Expertiza platform serves as a key tool for instructors, providing a holistic view of student performance across multiple assessment perspectives. The controller aggregates and displays data from various evaluation components, including teammate reviews, meta-reviews, instructor grades, peer review scores, and assignment submissions. The term <code>Assessment360</code> reflects its purpose of offering a comprehensive, 360-degree evaluation of a student's performance.

Currently, the system relies on two separate views — <code>all_students_all_reviews</code> and <code>course_student_grade_summary</code> — to display different aspects of student performance. These views present:
* Project-level data: The projects a student has worked on and the corresponding grades.
* Peer review data: The scores students receive from their teammates through the teammate review process.

While these views serve important functions, their separation results in a fragmented user experience, as instructors must switch between the views to see a complete set of student performance data. Additionally, the user interface (UI) is not optimized for an intuitive, seamless experience. There are limitations regarding
* The ability to interact with or customize the data display (e.g., column visibility, sorting, and reordering).
* The lack of visual clarity in data presentation (e.g., inconsistent formatting and absence of visual grade indicators).
* Inadequate responsiveness for different device types.

== Objective ==
The primary goal is to enhance the UI/UX and code quality of the <code>assessment360</code> controller. This involves:
* Merging the two existing views (<code>all_students_all_reviews</code> and <code>course_student_grade_summary</code>) into a single unified view.
* Improving the presentation and clarity of data (student grades, peer reviews).
* Refactoring logic for better separation of concerns and maintainability.
* Implementing feedback from the previous team.

== Current Implementation ==

=== Controller Structure ===
The <code>Assessment360Controller</code> is the central controller handling the logic for both the <code>all_students_all_reviews</code> and <code>course_student_grade_summary</code> views. It interacts with various models and services to fetch, process, and deliver the necessary data to the views. The current structure is as follows:
* The controller is responsible for gathering and processing assessment data such as grades, peer reviews, and meta-reviews for each student.
* It includes logic for handling class averages, calculating final grades, and determining peer review averages.
* The current implementation uses direct logic for grade calculations, and all calculations are executed within the controller itself, which could lead to bloated code and reduced maintainability.
* The views are rendered with minimal controller-side logic, relying on the controller to pass the necessary data to the front-end.

=== Current Views ===
The current implementation provides two main views that instructors can use to assess the performance of students. These views are defined in separate HTML ERB files.

==== <code>all_students_all_reviews.html.erb</code> ====
This view displays detailed student performance data in a table format. Key features include:
* Student Information Table: Displays each student’s name, ID, and relevant information.
* Teammate and Meta-Review Scores: For each student, the table shows the scores received from teammates and meta-reviews, which help in assessing peer evaluations.
* Class Averages: For each assignment and review type, class averages are calculated and displayed for instructors to analyze the overall performance of the class.
* Separate Columns for Review Types: Each type of review (<code>teammate</code>, <code>meta-review</code>, etc.) is shown in a separate column, making it easy to compare different assessment categories side by side.

==== <code>course_student_grade_summary.html.erb</code> ====
This view focuses on summarizing the project grades and peer review scores for each student. It includes:
* Student Grades and Peer Review Scores**: Displays the individual project grades and the peer review scores that a student has received.
* Assignment Topics: Lists the assignment topics associated with each project, along with the grades and peer review scores for those specific topics.
* Final Grades and Peer Review Averages: The final grade for each student is calculated by considering both the project grade and peer review scores, and the average peer review score is displayed alongside the final grade.
* Sortable Table Structure: The table in this view is designed to be sortable, allowing instructors to order students by project grades, peer review scores, or any other criterion available in the table. This adds flexibility in how data is analyzed.

== Use Case Diagram ==
For this project our job is to unify the view of the two files, i.e. all_students_all_reviews and course_student_grade_summary, which were created in the previous implementation to one. This would result in a single view which would help in evaluating performances by combining a lot of different perspectives. In our case, if we merge the two files and create a new view, the user should be able to view all the information that is there to be seen in one page. This includes:
* Viewing a Unified Dashboard
* Viewing all the Project Grades
* Viewing Peer Evaluation Scores
* Selecting and Deselecting Columns

Using this information we have created the following Use Case Diagram:

<center>[[File:E2536_Spring_2025.png|600x600px|Improve assessment360]]</center>

== Design Pattern Usage in Assessment360Controller ==

The '''Assessment360Controller''' implements multiple design patterns that improve clarity, modularity, and maintainability of the code.

=== 1. Facade Pattern ===
The controller acts as a facade, hiding complex interactions between various models (''Course'', ''Assignment'', ''Participant'', ''Team'', etc.) and exposing a simplified interface for the view. It aggregates data like grades, reviews, and penalties and prepares it in a structured format, simplifying the presentation layer.

=== 2. Strategy Pattern ===
The use of helper modules such as:
* '''GradesHelper'''
* '''AuthorizationHelper'''
* '''Scoring'''
* '''PenaltyHelper'''

follows the Strategy Pattern. Each module encapsulates a specific piece of functionality, and the controller delegates responsibility to these interchangeable strategies, promoting clean separation of concerns and easier testing.

=== 3. Template Method Pattern ===
The method '''action_allowed?''' is a hook method that overrides a predefined template method in ''ApplicationController''. This allows customized access control behavior while maintaining a consistent interface across all controllers — an example of the Template Method Pattern in action.

=== 4. Separation of Concerns ===
Responsibility is split between:
* '''Controller''': Orchestrates data flow
* '''Models''': Store and retrieve business data
* '''Helpers''': Encapsulate computation and utility logic
* '''Views''': Render formatted output

This adheres to the '''Separation of Concerns''' principle and keeps each layer clean and testable.

These design patterns contribute to the robustness and scalability of the 360-degree assessment feature, allowing future teams to maintain and extend it with ease.

== Planned Enhancements ==

=== Functional Changes ===
{| class="wikitable"
! Feature !! Description
|-
| Unified View || Combine both views into a single HTML page that includes both project grades and review scores.
|-
| Column Selection || Allow users to toggle visible columns using checkboxes.
|-
| Exclude Unreviewed Assignments || Retain the functionality to exclude unreviewed assignments from averages.
|-
| Averages Precision || Limit decimal precision to 2 points for clarity.
|-
| Wider Name Column || Adjust layout to prioritize readability (e.g., wider name column than username).
|}

=== Code Refactor ===
{| class="wikitable"
! Task !! Reason
|-
| Move averaging logic to mixins or model concerns || Improve separation of concerns and reusability.
|-
| Commenting || Add meaningful comments for helper methods and business logic.
|}

== UI/UX Design ==
The new unified view will feature:
* A tabular layout showing all relevant data.
* Sectioned headers for each student.
* Collapsible panels (if needed) for clarity.
* Visual cues for peer review vs. project grades.
* Responsive design for usability across devices.

== Implementation ==

=== Previous View ===

Previously, the Assessment360 Controllers view relied on two separate views i.e. all_students_all_reviews and course_student_grade_summary, to display different aspects of student performance. This is how they looked like before.

1. all_students_all_reviews.html.erb

[[File:old_all_students_all_reviews.png|750px]]

2. course_student_grade_summary.html.erb

[[File:old_course_student_grade_summary.png|750px]]

=== Current View (after code changes) ===

The main objective of this project was to enhance the UI/UX and code quality of the assessment360 controller. This involved merging the two existing views (all_students_all_reviews and course_student_grade_summary) into a single unified view.

1. assessment360_controller.rb

[[File:old_all_students_all_reviews.png|750px]]

2. all_students_all_reviews.html.erb and course_student_grade_summary.html.erb removed

[[File:old_course_student_grade_summary.png|750px]]

3. course_summary.html.erb added which contains the combined view

[[File:old_course_student_grade_summary.png|750px]]

2. tree_display.jsx

[[File:old_course_student_grade_summary.png|750px]]

3. routes.rb

[[File:old_course_student_grade_summary.png|750px]]

== Testing Strategy ==

{| class="wikitable"
|-
! Type !! Description !! Tests
|-
| ''' Unit Tests''' || Test individual controller methods || - Test grade calculations - Test data formatting
|-
| ''' Integration Tests''' || Test interactions between components || - Test view rendering - Test database queries - Test caching functionality
|-
| ''' Manual Testing''' || Test UI functionality, performance, and error handling || - Test UI functionality - Test performance with large datasets - Test error scenarios
|}

=== Testing Results ===

[[File:testing.png|750px]]

== Success Criteria ==

The success of this feature implementation will be evaluated based on the following criteria:

{| class="wikitable"
|-
! Criterion !! Description
|-
| '''UI Enhancements Implemented and Working''' || All proposed UI enhancements, including the unified view, column management features, and data presentation improvements, must be fully implemented and functioning as expected. The UI should be intuitive, responsive, and meet the design goals outlined in the document.
|-
| '''Performance Improvements Measurable''' || The feature should demonstrate a measurable improvement in performance, particularly in terms of load times and responsiveness when rendering large datasets or performing grade calculations. Performance benchmarking should indicate a noticeable reduction in latency.
|-
| '''Test Coverage ''' || Comprehensive unit and integration tests must cover more than 80% of the new code and critical paths in the controller. This ensures that the feature is reliable, and potential issues are identified early in the development cycle. Test results should be stable, with no significant failures.
|-
| '''Code Documentation Complete''' || All new and modified code must be thoroughly documented. This includes clear inline comments, explanations for complex logic, and appropriate documentation for new functions, classes, and components. This ensures that future developers can understand and maintain the code efficiently.
|-
| '''No Regression Bugs''' || After implementing the new feature, no existing functionality in the Assessment360 controller should break or behave unexpectedly. Regression testing should show that previously working parts of the system continue to function without issues.
|-
| '''Positive User Feedback''' || End-users (instructors and administrators) must provide positive feedback about the usability and effectiveness of the feature. Feedback should indicate that the feature adds value, improves user experience, and meets the goals outlined in the design document.
|}

== Implementation Video ==

Video Link: https://drive.google.com/file/d/1aAzGuSc-qwed4sGMIsWrIgelTTqd_OJ0/view

Youtube Link: https://youtu.be/I3f4sVR_NWg

== Team Information ==
'''Mentor:''' Mitesh Anil Agarwal

'''Team:'''
* Jap Ashokbhai Purohit - jpurohi@ncsu.edu
* Sharmeen Momin - smomin@ncsu.edu
* Prithish Samanta - psamant2@ncsu.edu

== References ==
* [https://github.com/expertiza/expertiza Expertiza Codebase]
* [https://guides.rubyonrails.org/action_view_overview.html Rails View Helpers]
* [https://github.com/flyerhzm/bullet Bullet Gem Documentation]

CSC/ECE 517 Spring 2025 - E2536. Improve assessment360 controller

2025-04-23T01:38:36Z

Psamant2: /* Testing Strategy */

== Problem Overview ==
The '''Assessment360 Controller''' within the Expertiza platform serves as a key tool for instructors, providing a holistic view of student performance across multiple assessment perspectives. The controller aggregates and displays data from various evaluation components, including teammate reviews, meta-reviews, instructor grades, peer review scores, and assignment submissions. The term <code>Assessment360</code> reflects its purpose of offering a comprehensive, 360-degree evaluation of a student's performance.

Currently, the system relies on two separate views — <code>all_students_all_reviews</code> and <code>course_student_grade_summary</code> — to display different aspects of student performance. These views present:
* Project-level data: The projects a student has worked on and the corresponding grades.
* Peer review data: The scores students receive from their teammates through the teammate review process.

While these views serve important functions, their separation results in a fragmented user experience, as instructors must switch between the views to see a complete set of student performance data. Additionally, the user interface (UI) is not optimized for an intuitive, seamless experience. There are limitations regarding
* The ability to interact with or customize the data display (e.g., column visibility, sorting, and reordering).
* The lack of visual clarity in data presentation (e.g., inconsistent formatting and absence of visual grade indicators).
* Inadequate responsiveness for different device types.

== Objective ==
The primary goal is to enhance the UI/UX and code quality of the <code>assessment360</code> controller. This involves:
* Merging the two existing views (<code>all_students_all_reviews</code> and <code>course_student_grade_summary</code>) into a single unified view.
* Improving the presentation and clarity of data (student grades, peer reviews).
* Refactoring logic for better separation of concerns and maintainability.
* Implementing feedback from the previous team.

== Current Implementation ==

=== Controller Structure ===
The <code>Assessment360Controller</code> is the central controller handling the logic for both the <code>all_students_all_reviews</code> and <code>course_student_grade_summary</code> views. It interacts with various models and services to fetch, process, and deliver the necessary data to the views. The current structure is as follows:
* The controller is responsible for gathering and processing assessment data such as grades, peer reviews, and meta-reviews for each student.
* It includes logic for handling class averages, calculating final grades, and determining peer review averages.
* The current implementation uses direct logic for grade calculations, and all calculations are executed within the controller itself, which could lead to bloated code and reduced maintainability.
* The views are rendered with minimal controller-side logic, relying on the controller to pass the necessary data to the front-end.

=== Current Views ===
The current implementation provides two main views that instructors can use to assess the performance of students. These views are defined in separate HTML ERB files.

==== <code>all_students_all_reviews.html.erb</code> ====
This view displays detailed student performance data in a table format. Key features include:
* Student Information Table: Displays each student’s name, ID, and relevant information.
* Teammate and Meta-Review Scores: For each student, the table shows the scores received from teammates and meta-reviews, which help in assessing peer evaluations.
* Class Averages: For each assignment and review type, class averages are calculated and displayed for instructors to analyze the overall performance of the class.
* Separate Columns for Review Types: Each type of review (<code>teammate</code>, <code>meta-review</code>, etc.) is shown in a separate column, making it easy to compare different assessment categories side by side.

==== <code>course_student_grade_summary.html.erb</code> ====
This view focuses on summarizing the project grades and peer review scores for each student. It includes:
* Student Grades and Peer Review Scores**: Displays the individual project grades and the peer review scores that a student has received.
* Assignment Topics: Lists the assignment topics associated with each project, along with the grades and peer review scores for those specific topics.
* Final Grades and Peer Review Averages: The final grade for each student is calculated by considering both the project grade and peer review scores, and the average peer review score is displayed alongside the final grade.
* Sortable Table Structure: The table in this view is designed to be sortable, allowing instructors to order students by project grades, peer review scores, or any other criterion available in the table. This adds flexibility in how data is analyzed.

== Use Case Diagram ==
For this project our job is to unify the view of the two files, i.e. all_students_all_reviews and course_student_grade_summary, which were created in the previous implementation to one. This would result in a single view which would help in evaluating performances by combining a lot of different perspectives. In our case, if we merge the two files and create a new view, the user should be able to view all the information that is there to be seen in one page. This includes:
* Viewing a Unified Dashboard
* Viewing all the Project Grades
* Viewing Peer Evaluation Scores
* Selecting and Deselecting Columns

Using this information we have created the following Use Case Diagram:

<center>[[File:E2536_Spring_2025.png|600x600px|Improve assessment360]]</center>

== Design Pattern Usage in Assessment360Controller ==

The '''Assessment360Controller''' implements multiple design patterns that improve clarity, modularity, and maintainability of the code.

=== 1. Facade Pattern ===
The controller acts as a facade, hiding complex interactions between various models (''Course'', ''Assignment'', ''Participant'', ''Team'', etc.) and exposing a simplified interface for the view. It aggregates data like grades, reviews, and penalties and prepares it in a structured format, simplifying the presentation layer.

=== 2. Strategy Pattern ===
The use of helper modules such as:
* '''GradesHelper'''
* '''AuthorizationHelper'''
* '''Scoring'''
* '''PenaltyHelper'''

follows the Strategy Pattern. Each module encapsulates a specific piece of functionality, and the controller delegates responsibility to these interchangeable strategies, promoting clean separation of concerns and easier testing.

=== 3. Template Method Pattern ===
The method '''action_allowed?''' is a hook method that overrides a predefined template method in ''ApplicationController''. This allows customized access control behavior while maintaining a consistent interface across all controllers — an example of the Template Method Pattern in action.

=== 4. Separation of Concerns ===
Responsibility is split between:
* '''Controller''': Orchestrates data flow
* '''Models''': Store and retrieve business data
* '''Helpers''': Encapsulate computation and utility logic
* '''Views''': Render formatted output

This adheres to the '''Separation of Concerns''' principle and keeps each layer clean and testable.

These design patterns contribute to the robustness and scalability of the 360-degree assessment feature, allowing future teams to maintain and extend it with ease.

== Planned Enhancements ==

=== Functional Changes ===
{| class="wikitable"
! Feature !! Description
|-
| Unified View || Combine both views into a single HTML page that includes both project grades and review scores.
|-
| Column Selection || Allow users to toggle visible columns using checkboxes.
|-
| Exclude Unreviewed Assignments || Retain the functionality to exclude unreviewed assignments from averages.
|-
| Averages Precision || Limit decimal precision to 2 points for clarity.
|-
| Wider Name Column || Adjust layout to prioritize readability (e.g., wider name column than username).
|}

=== Code Refactor ===
{| class="wikitable"
! Task !! Reason
|-
| Move averaging logic to mixins or model concerns || Improve separation of concerns and reusability.
|-
| Commenting || Add meaningful comments for helper methods and business logic.
|}

== UI/UX Design ==
The new unified view will feature:
* A tabular layout showing all relevant data.
* Sectioned headers for each student.
* Collapsible panels (if needed) for clarity.
* Visual cues for peer review vs. project grades.
* Responsive design for usability across devices.

== Implementation ==

=== Previous View ===

Previously, the Assessment360 Controllers view relied on two separate views i.e. all_students_all_reviews and course_student_grade_summary, to display different aspects of student performance. This is how they looked like before.

1. all_students_all_reviews.html.erb

[[File:old_all_students_all_reviews.png|750px]]

2. course_student_grade_summary.html.erb

[[File:old_course_student_grade_summary.png|750px]]

=== Current View (after code changes) ===

The main objective of this project was to enhance the UI/UX and code quality of the assessment360 controller. This involved merging the two existing views (all_students_all_reviews and course_student_grade_summary) into a single unified view.

== Testing Strategy ==

{| class="wikitable"
|-
! Type !! Description !! Tests
|-
| ''' Unit Tests''' || Test individual controller methods || - Test grade calculations - Test data formatting
|-
| ''' Integration Tests''' || Test interactions between components || - Test view rendering - Test database queries - Test caching functionality
|-
| ''' Manual Testing''' || Test UI functionality, performance, and error handling || - Test UI functionality - Test performance with large datasets - Test error scenarios
|}

=== Testing Results ===

[[File:testing.png|750px]]

== Success Criteria ==

The success of this feature implementation will be evaluated based on the following criteria:

{| class="wikitable"
|-
! Criterion !! Description
|-
| '''UI Enhancements Implemented and Working''' || All proposed UI enhancements, including the unified view, column management features, and data presentation improvements, must be fully implemented and functioning as expected. The UI should be intuitive, responsive, and meet the design goals outlined in the document.
|-
| '''Performance Improvements Measurable''' || The feature should demonstrate a measurable improvement in performance, particularly in terms of load times and responsiveness when rendering large datasets or performing grade calculations. Performance benchmarking should indicate a noticeable reduction in latency.
|-
| '''Test Coverage ''' || Comprehensive unit and integration tests must cover more than 80% of the new code and critical paths in the controller. This ensures that the feature is reliable, and potential issues are identified early in the development cycle. Test results should be stable, with no significant failures.
|-
| '''Code Documentation Complete''' || All new and modified code must be thoroughly documented. This includes clear inline comments, explanations for complex logic, and appropriate documentation for new functions, classes, and components. This ensures that future developers can understand and maintain the code efficiently.
|-
| '''No Regression Bugs''' || After implementing the new feature, no existing functionality in the Assessment360 controller should break or behave unexpectedly. Regression testing should show that previously working parts of the system continue to function without issues.
|-
| '''Positive User Feedback''' || End-users (instructors and administrators) must provide positive feedback about the usability and effectiveness of the feature. Feedback should indicate that the feature adds value, improves user experience, and meets the goals outlined in the design document.
|}

== Implementation Video ==

Video Link: https://drive.google.com/file/d/1aAzGuSc-qwed4sGMIsWrIgelTTqd_OJ0/view

Youtube Link: https://youtu.be/I3f4sVR_NWg

== Team Information ==
'''Mentor:''' Mitesh Anil Agarwal

'''Team:'''
* Jap Ashokbhai Purohit - jpurohi@ncsu.edu
* Sharmeen Momin - smomin@ncsu.edu
* Prithish Samanta - psamant2@ncsu.edu

== References ==
* [https://github.com/expertiza/expertiza Expertiza Codebase]
* [https://guides.rubyonrails.org/action_view_overview.html Rails View Helpers]
* [https://github.com/flyerhzm/bullet Bullet Gem Documentation]

CSC/ECE 517 Spring 2025 - E2536. Improve assessment360 controller

2025-04-23T01:37:24Z

Psamant2: /* Testing Strategy */

== Problem Overview ==
The '''Assessment360 Controller''' within the Expertiza platform serves as a key tool for instructors, providing a holistic view of student performance across multiple assessment perspectives. The controller aggregates and displays data from various evaluation components, including teammate reviews, meta-reviews, instructor grades, peer review scores, and assignment submissions. The term <code>Assessment360</code> reflects its purpose of offering a comprehensive, 360-degree evaluation of a student's performance.

Currently, the system relies on two separate views — <code>all_students_all_reviews</code> and <code>course_student_grade_summary</code> — to display different aspects of student performance. These views present:
* Project-level data: The projects a student has worked on and the corresponding grades.
* Peer review data: The scores students receive from their teammates through the teammate review process.

While these views serve important functions, their separation results in a fragmented user experience, as instructors must switch between the views to see a complete set of student performance data. Additionally, the user interface (UI) is not optimized for an intuitive, seamless experience. There are limitations regarding
* The ability to interact with or customize the data display (e.g., column visibility, sorting, and reordering).
* The lack of visual clarity in data presentation (e.g., inconsistent formatting and absence of visual grade indicators).
* Inadequate responsiveness for different device types.

== Objective ==
The primary goal is to enhance the UI/UX and code quality of the <code>assessment360</code> controller. This involves:
* Merging the two existing views (<code>all_students_all_reviews</code> and <code>course_student_grade_summary</code>) into a single unified view.
* Improving the presentation and clarity of data (student grades, peer reviews).
* Refactoring logic for better separation of concerns and maintainability.
* Implementing feedback from the previous team.

== Current Implementation ==

=== Controller Structure ===
The <code>Assessment360Controller</code> is the central controller handling the logic for both the <code>all_students_all_reviews</code> and <code>course_student_grade_summary</code> views. It interacts with various models and services to fetch, process, and deliver the necessary data to the views. The current structure is as follows:
* The controller is responsible for gathering and processing assessment data such as grades, peer reviews, and meta-reviews for each student.
* It includes logic for handling class averages, calculating final grades, and determining peer review averages.
* The current implementation uses direct logic for grade calculations, and all calculations are executed within the controller itself, which could lead to bloated code and reduced maintainability.
* The views are rendered with minimal controller-side logic, relying on the controller to pass the necessary data to the front-end.

=== Current Views ===
The current implementation provides two main views that instructors can use to assess the performance of students. These views are defined in separate HTML ERB files.

==== <code>all_students_all_reviews.html.erb</code> ====
This view displays detailed student performance data in a table format. Key features include:
* Student Information Table: Displays each student’s name, ID, and relevant information.
* Teammate and Meta-Review Scores: For each student, the table shows the scores received from teammates and meta-reviews, which help in assessing peer evaluations.
* Class Averages: For each assignment and review type, class averages are calculated and displayed for instructors to analyze the overall performance of the class.
* Separate Columns for Review Types: Each type of review (<code>teammate</code>, <code>meta-review</code>, etc.) is shown in a separate column, making it easy to compare different assessment categories side by side.

==== <code>course_student_grade_summary.html.erb</code> ====
This view focuses on summarizing the project grades and peer review scores for each student. It includes:
* Student Grades and Peer Review Scores**: Displays the individual project grades and the peer review scores that a student has received.
* Assignment Topics: Lists the assignment topics associated with each project, along with the grades and peer review scores for those specific topics.
* Final Grades and Peer Review Averages: The final grade for each student is calculated by considering both the project grade and peer review scores, and the average peer review score is displayed alongside the final grade.
* Sortable Table Structure: The table in this view is designed to be sortable, allowing instructors to order students by project grades, peer review scores, or any other criterion available in the table. This adds flexibility in how data is analyzed.

== Use Case Diagram ==
For this project our job is to unify the view of the two files, i.e. all_students_all_reviews and course_student_grade_summary, which were created in the previous implementation to one. This would result in a single view which would help in evaluating performances by combining a lot of different perspectives. In our case, if we merge the two files and create a new view, the user should be able to view all the information that is there to be seen in one page. This includes:
* Viewing a Unified Dashboard
* Viewing all the Project Grades
* Viewing Peer Evaluation Scores
* Selecting and Deselecting Columns

Using this information we have created the following Use Case Diagram:

<center>[[File:E2536_Spring_2025.png|600x600px|Improve assessment360]]</center>

== Design Pattern Usage in Assessment360Controller ==

The '''Assessment360Controller''' implements multiple design patterns that improve clarity, modularity, and maintainability of the code.

=== 1. Facade Pattern ===
The controller acts as a facade, hiding complex interactions between various models (''Course'', ''Assignment'', ''Participant'', ''Team'', etc.) and exposing a simplified interface for the view. It aggregates data like grades, reviews, and penalties and prepares it in a structured format, simplifying the presentation layer.

=== 2. Strategy Pattern ===
The use of helper modules such as:
* '''GradesHelper'''
* '''AuthorizationHelper'''
* '''Scoring'''
* '''PenaltyHelper'''

follows the Strategy Pattern. Each module encapsulates a specific piece of functionality, and the controller delegates responsibility to these interchangeable strategies, promoting clean separation of concerns and easier testing.

=== 3. Template Method Pattern ===
The method '''action_allowed?''' is a hook method that overrides a predefined template method in ''ApplicationController''. This allows customized access control behavior while maintaining a consistent interface across all controllers — an example of the Template Method Pattern in action.

=== 4. Separation of Concerns ===
Responsibility is split between:
* '''Controller''': Orchestrates data flow
* '''Models''': Store and retrieve business data
* '''Helpers''': Encapsulate computation and utility logic
* '''Views''': Render formatted output

This adheres to the '''Separation of Concerns''' principle and keeps each layer clean and testable.

These design patterns contribute to the robustness and scalability of the 360-degree assessment feature, allowing future teams to maintain and extend it with ease.

== Planned Enhancements ==

=== Functional Changes ===
{| class="wikitable"
! Feature !! Description
|-
| Unified View || Combine both views into a single HTML page that includes both project grades and review scores.
|-
| Column Selection || Allow users to toggle visible columns using checkboxes.
|-
| Exclude Unreviewed Assignments || Retain the functionality to exclude unreviewed assignments from averages.
|-
| Averages Precision || Limit decimal precision to 2 points for clarity.
|-
| Wider Name Column || Adjust layout to prioritize readability (e.g., wider name column than username).
|}

=== Code Refactor ===
{| class="wikitable"
! Task !! Reason
|-
| Move averaging logic to mixins or model concerns || Improve separation of concerns and reusability.
|-
| Commenting || Add meaningful comments for helper methods and business logic.
|}

== UI/UX Design ==
The new unified view will feature:
* A tabular layout showing all relevant data.
* Sectioned headers for each student.
* Collapsible panels (if needed) for clarity.
* Visual cues for peer review vs. project grades.
* Responsive design for usability across devices.

== Implementation ==

=== Previous View ===

Previously, the Assessment360 Controllers view relied on two separate views i.e. all_students_all_reviews and course_student_grade_summary, to display different aspects of student performance. This is how they looked like before.

1. all_students_all_reviews.html.erb

[[File:old_all_students_all_reviews.png|750px]]

2. course_student_grade_summary.html.erb

[[File:old_course_student_grade_summary.png|750px]]

=== Current View (after code changes) ===

The main objective of this project was to enhance the UI/UX and code quality of the assessment360 controller. This involved merging the two existing views (all_students_all_reviews and course_student_grade_summary) into a single unified view.

== Testing Strategy ==

{| class="wikitable"
|-
! Type !! Description !! Tests
|-
| ''' Unit Tests''' || Test individual controller methods || - Test grade calculations - Test data formatting
|-
| ''' Integration Tests''' || Test interactions between components || - Test view rendering - Test database queries - Test caching functionality
|-
| ''' Manual Testing''' || Test UI functionality, performance, and error handling || - Test UI functionality - Test performance with large datasets - Test error scenarios
|}

[[File:testing.png|750px]]

== Success Criteria ==

The success of this feature implementation will be evaluated based on the following criteria:

{| class="wikitable"
|-
! Criterion !! Description
|-
| '''UI Enhancements Implemented and Working''' || All proposed UI enhancements, including the unified view, column management features, and data presentation improvements, must be fully implemented and functioning as expected. The UI should be intuitive, responsive, and meet the design goals outlined in the document.
|-
| '''Performance Improvements Measurable''' || The feature should demonstrate a measurable improvement in performance, particularly in terms of load times and responsiveness when rendering large datasets or performing grade calculations. Performance benchmarking should indicate a noticeable reduction in latency.
|-
| '''Test Coverage ''' || Comprehensive unit and integration tests must cover more than 80% of the new code and critical paths in the controller. This ensures that the feature is reliable, and potential issues are identified early in the development cycle. Test results should be stable, with no significant failures.
|-
| '''Code Documentation Complete''' || All new and modified code must be thoroughly documented. This includes clear inline comments, explanations for complex logic, and appropriate documentation for new functions, classes, and components. This ensures that future developers can understand and maintain the code efficiently.
|-
| '''No Regression Bugs''' || After implementing the new feature, no existing functionality in the Assessment360 controller should break or behave unexpectedly. Regression testing should show that previously working parts of the system continue to function without issues.
|-
| '''Positive User Feedback''' || End-users (instructors and administrators) must provide positive feedback about the usability and effectiveness of the feature. Feedback should indicate that the feature adds value, improves user experience, and meets the goals outlined in the design document.
|}

== Implementation Video ==

Video Link: https://drive.google.com/file/d/1aAzGuSc-qwed4sGMIsWrIgelTTqd_OJ0/view

Youtube Link: https://youtu.be/I3f4sVR_NWg

== Team Information ==
'''Mentor:''' Mitesh Anil Agarwal

'''Team:'''
* Jap Ashokbhai Purohit - jpurohi@ncsu.edu
* Sharmeen Momin - smomin@ncsu.edu
* Prithish Samanta - psamant2@ncsu.edu

== References ==
* [https://github.com/expertiza/expertiza Expertiza Codebase]
* [https://guides.rubyonrails.org/action_view_overview.html Rails View Helpers]
* [https://github.com/flyerhzm/bullet Bullet Gem Documentation]

File:Testing.png

2025-04-23T01:31:42Z

Psamant2: Psamant2 uploaded a new version of File:Testing.png

CSC/ECE 517 Spring 2025 - E2536. Improve assessment360 controller

2025-04-23T01:27:34Z

Psamant2: /* Implementation Video */

== Problem Overview ==
The '''Assessment360 Controller''' within the Expertiza platform serves as a key tool for instructors, providing a holistic view of student performance across multiple assessment perspectives. The controller aggregates and displays data from various evaluation components, including teammate reviews, meta-reviews, instructor grades, peer review scores, and assignment submissions. The term <code>Assessment360</code> reflects its purpose of offering a comprehensive, 360-degree evaluation of a student's performance.

Currently, the system relies on two separate views — <code>all_students_all_reviews</code> and <code>course_student_grade_summary</code> — to display different aspects of student performance. These views present:
* Project-level data: The projects a student has worked on and the corresponding grades.
* Peer review data: The scores students receive from their teammates through the teammate review process.

While these views serve important functions, their separation results in a fragmented user experience, as instructors must switch between the views to see a complete set of student performance data. Additionally, the user interface (UI) is not optimized for an intuitive, seamless experience. There are limitations regarding
* The ability to interact with or customize the data display (e.g., column visibility, sorting, and reordering).
* The lack of visual clarity in data presentation (e.g., inconsistent formatting and absence of visual grade indicators).
* Inadequate responsiveness for different device types.

== Objective ==
The primary goal is to enhance the UI/UX and code quality of the <code>assessment360</code> controller. This involves:
* Merging the two existing views (<code>all_students_all_reviews</code> and <code>course_student_grade_summary</code>) into a single unified view.
* Improving the presentation and clarity of data (student grades, peer reviews).
* Refactoring logic for better separation of concerns and maintainability.
* Implementing feedback from the previous team.

== Current Implementation ==

=== Controller Structure ===
The <code>Assessment360Controller</code> is the central controller handling the logic for both the <code>all_students_all_reviews</code> and <code>course_student_grade_summary</code> views. It interacts with various models and services to fetch, process, and deliver the necessary data to the views. The current structure is as follows:
* The controller is responsible for gathering and processing assessment data such as grades, peer reviews, and meta-reviews for each student.
* It includes logic for handling class averages, calculating final grades, and determining peer review averages.
* The current implementation uses direct logic for grade calculations, and all calculations are executed within the controller itself, which could lead to bloated code and reduced maintainability.
* The views are rendered with minimal controller-side logic, relying on the controller to pass the necessary data to the front-end.

=== Current Views ===
The current implementation provides two main views that instructors can use to assess the performance of students. These views are defined in separate HTML ERB files.

==== <code>all_students_all_reviews.html.erb</code> ====
This view displays detailed student performance data in a table format. Key features include:
* Student Information Table: Displays each student’s name, ID, and relevant information.
* Teammate and Meta-Review Scores: For each student, the table shows the scores received from teammates and meta-reviews, which help in assessing peer evaluations.
* Class Averages: For each assignment and review type, class averages are calculated and displayed for instructors to analyze the overall performance of the class.
* Separate Columns for Review Types: Each type of review (<code>teammate</code>, <code>meta-review</code>, etc.) is shown in a separate column, making it easy to compare different assessment categories side by side.

==== <code>course_student_grade_summary.html.erb</code> ====
This view focuses on summarizing the project grades and peer review scores for each student. It includes:
* Student Grades and Peer Review Scores**: Displays the individual project grades and the peer review scores that a student has received.
* Assignment Topics: Lists the assignment topics associated with each project, along with the grades and peer review scores for those specific topics.
* Final Grades and Peer Review Averages: The final grade for each student is calculated by considering both the project grade and peer review scores, and the average peer review score is displayed alongside the final grade.
* Sortable Table Structure: The table in this view is designed to be sortable, allowing instructors to order students by project grades, peer review scores, or any other criterion available in the table. This adds flexibility in how data is analyzed.

== Use Case Diagram ==
For this project our job is to unify the view of the two files, i.e. all_students_all_reviews and course_student_grade_summary, which were created in the previous implementation to one. This would result in a single view which would help in evaluating performances by combining a lot of different perspectives. In our case, if we merge the two files and create a new view, the user should be able to view all the information that is there to be seen in one page. This includes:
* Viewing a Unified Dashboard
* Viewing all the Project Grades
* Viewing Peer Evaluation Scores
* Selecting and Deselecting Columns

Using this information we have created the following Use Case Diagram:

<center>[[File:E2536_Spring_2025.png|600x600px|Improve assessment360]]</center>

== Design Pattern Usage in Assessment360Controller ==

The '''Assessment360Controller''' implements multiple design patterns that improve clarity, modularity, and maintainability of the code.

=== 1. Facade Pattern ===
The controller acts as a facade, hiding complex interactions between various models (''Course'', ''Assignment'', ''Participant'', ''Team'', etc.) and exposing a simplified interface for the view. It aggregates data like grades, reviews, and penalties and prepares it in a structured format, simplifying the presentation layer.

=== 2. Strategy Pattern ===
The use of helper modules such as:
* '''GradesHelper'''
* '''AuthorizationHelper'''
* '''Scoring'''
* '''PenaltyHelper'''

follows the Strategy Pattern. Each module encapsulates a specific piece of functionality, and the controller delegates responsibility to these interchangeable strategies, promoting clean separation of concerns and easier testing.

=== 3. Template Method Pattern ===
The method '''action_allowed?''' is a hook method that overrides a predefined template method in ''ApplicationController''. This allows customized access control behavior while maintaining a consistent interface across all controllers — an example of the Template Method Pattern in action.

=== 4. Separation of Concerns ===
Responsibility is split between:
* '''Controller''': Orchestrates data flow
* '''Models''': Store and retrieve business data
* '''Helpers''': Encapsulate computation and utility logic
* '''Views''': Render formatted output

This adheres to the '''Separation of Concerns''' principle and keeps each layer clean and testable.

These design patterns contribute to the robustness and scalability of the 360-degree assessment feature, allowing future teams to maintain and extend it with ease.

== Planned Enhancements ==

=== Functional Changes ===
{| class="wikitable"
! Feature !! Description
|-
| Unified View || Combine both views into a single HTML page that includes both project grades and review scores.
|-
| Column Selection || Allow users to toggle visible columns using checkboxes.
|-
| Exclude Unreviewed Assignments || Retain the functionality to exclude unreviewed assignments from averages.
|-
| Averages Precision || Limit decimal precision to 2 points for clarity.
|-
| Wider Name Column || Adjust layout to prioritize readability (e.g., wider name column than username).
|}

=== Code Refactor ===
{| class="wikitable"
! Task !! Reason
|-
| Move averaging logic to mixins or model concerns || Improve separation of concerns and reusability.
|-
| Commenting || Add meaningful comments for helper methods and business logic.
|}

== UI/UX Design ==
The new unified view will feature:
* A tabular layout showing all relevant data.
* Sectioned headers for each student.
* Collapsible panels (if needed) for clarity.
* Visual cues for peer review vs. project grades.
* Responsive design for usability across devices.

== Implementation ==

=== Previous View ===

Previously, the Assessment360 Controllers view relied on two separate views i.e. all_students_all_reviews and course_student_grade_summary, to display different aspects of student performance. This is how they looked like before.

1. all_students_all_reviews.html.erb

[[File:old_all_students_all_reviews.png|750px]]

2. course_student_grade_summary.html.erb

[[File:old_course_student_grade_summary.png|750px]]

=== Current View (after code changes) ===

The main objective of this project was to enhance the UI/UX and code quality of the assessment360 controller. This involved merging the two existing views (all_students_all_reviews and course_student_grade_summary) into a single unified view.

== Testing Strategy ==

{| class="wikitable"
|-
! Type !! Description !! Tests
|-
| ''' Unit Tests''' || Test individual controller methods || - Test grade calculations - Test data formatting
|-
| ''' Integration Tests''' || Test interactions between components || - Test view rendering - Test database queries - Test caching functionality
|-
| ''' Manual Testing''' || Test UI functionality, performance, and error handling || - Test UI functionality - Test performance with large datasets - Test error scenarios
|}

== Success Criteria ==

The success of this feature implementation will be evaluated based on the following criteria:

{| class="wikitable"
|-
! Criterion !! Description
|-
| '''UI Enhancements Implemented and Working''' || All proposed UI enhancements, including the unified view, column management features, and data presentation improvements, must be fully implemented and functioning as expected. The UI should be intuitive, responsive, and meet the design goals outlined in the document.
|-
| '''Performance Improvements Measurable''' || The feature should demonstrate a measurable improvement in performance, particularly in terms of load times and responsiveness when rendering large datasets or performing grade calculations. Performance benchmarking should indicate a noticeable reduction in latency.
|-
| '''Test Coverage ''' || Comprehensive unit and integration tests must cover more than 80% of the new code and critical paths in the controller. This ensures that the feature is reliable, and potential issues are identified early in the development cycle. Test results should be stable, with no significant failures.
|-
| '''Code Documentation Complete''' || All new and modified code must be thoroughly documented. This includes clear inline comments, explanations for complex logic, and appropriate documentation for new functions, classes, and components. This ensures that future developers can understand and maintain the code efficiently.
|-
| '''No Regression Bugs''' || After implementing the new feature, no existing functionality in the Assessment360 controller should break or behave unexpectedly. Regression testing should show that previously working parts of the system continue to function without issues.
|-
| '''Positive User Feedback''' || End-users (instructors and administrators) must provide positive feedback about the usability and effectiveness of the feature. Feedback should indicate that the feature adds value, improves user experience, and meets the goals outlined in the design document.
|}

== Implementation Video ==

Video Link: https://drive.google.com/file/d/1aAzGuSc-qwed4sGMIsWrIgelTTqd_OJ0/view

Youtube Link: https://youtu.be/I3f4sVR_NWg

== Team Information ==
'''Mentor:''' Mitesh Anil Agarwal

'''Team:'''
* Jap Ashokbhai Purohit - jpurohi@ncsu.edu
* Sharmeen Momin - smomin@ncsu.edu
* Prithish Samanta - psamant2@ncsu.edu

== References ==
* [https://github.com/expertiza/expertiza Expertiza Codebase]
* [https://guides.rubyonrails.org/action_view_overview.html Rails View Helpers]
* [https://github.com/flyerhzm/bullet Bullet Gem Documentation]

CSC/ECE 517 Spring 2025 - E2536. Improve assessment360 controller

2025-04-23T01:16:35Z

Psamant2: /* Team Information */

== Problem Overview ==
The '''Assessment360 Controller''' within the Expertiza platform serves as a key tool for instructors, providing a holistic view of student performance across multiple assessment perspectives. The controller aggregates and displays data from various evaluation components, including teammate reviews, meta-reviews, instructor grades, peer review scores, and assignment submissions. The term <code>Assessment360</code> reflects its purpose of offering a comprehensive, 360-degree evaluation of a student's performance.

Currently, the system relies on two separate views — <code>all_students_all_reviews</code> and <code>course_student_grade_summary</code> — to display different aspects of student performance. These views present:
* Project-level data: The projects a student has worked on and the corresponding grades.
* Peer review data: The scores students receive from their teammates through the teammate review process.

While these views serve important functions, their separation results in a fragmented user experience, as instructors must switch between the views to see a complete set of student performance data. Additionally, the user interface (UI) is not optimized for an intuitive, seamless experience. There are limitations regarding
* The ability to interact with or customize the data display (e.g., column visibility, sorting, and reordering).
* The lack of visual clarity in data presentation (e.g., inconsistent formatting and absence of visual grade indicators).
* Inadequate responsiveness for different device types.

== Objective ==
The primary goal is to enhance the UI/UX and code quality of the <code>assessment360</code> controller. This involves:
* Merging the two existing views (<code>all_students_all_reviews</code> and <code>course_student_grade_summary</code>) into a single unified view.
* Improving the presentation and clarity of data (student grades, peer reviews).
* Refactoring logic for better separation of concerns and maintainability.
* Implementing feedback from the previous team.

== Current Implementation ==

=== Controller Structure ===
The <code>Assessment360Controller</code> is the central controller handling the logic for both the <code>all_students_all_reviews</code> and <code>course_student_grade_summary</code> views. It interacts with various models and services to fetch, process, and deliver the necessary data to the views. The current structure is as follows:
* The controller is responsible for gathering and processing assessment data such as grades, peer reviews, and meta-reviews for each student.
* It includes logic for handling class averages, calculating final grades, and determining peer review averages.
* The current implementation uses direct logic for grade calculations, and all calculations are executed within the controller itself, which could lead to bloated code and reduced maintainability.
* The views are rendered with minimal controller-side logic, relying on the controller to pass the necessary data to the front-end.

=== Current Views ===
The current implementation provides two main views that instructors can use to assess the performance of students. These views are defined in separate HTML ERB files.

==== <code>all_students_all_reviews.html.erb</code> ====
This view displays detailed student performance data in a table format. Key features include:
* Student Information Table: Displays each student’s name, ID, and relevant information.
* Teammate and Meta-Review Scores: For each student, the table shows the scores received from teammates and meta-reviews, which help in assessing peer evaluations.
* Class Averages: For each assignment and review type, class averages are calculated and displayed for instructors to analyze the overall performance of the class.
* Separate Columns for Review Types: Each type of review (<code>teammate</code>, <code>meta-review</code>, etc.) is shown in a separate column, making it easy to compare different assessment categories side by side.

==== <code>course_student_grade_summary.html.erb</code> ====
This view focuses on summarizing the project grades and peer review scores for each student. It includes:
* Student Grades and Peer Review Scores**: Displays the individual project grades and the peer review scores that a student has received.
* Assignment Topics: Lists the assignment topics associated with each project, along with the grades and peer review scores for those specific topics.
* Final Grades and Peer Review Averages: The final grade for each student is calculated by considering both the project grade and peer review scores, and the average peer review score is displayed alongside the final grade.
* Sortable Table Structure: The table in this view is designed to be sortable, allowing instructors to order students by project grades, peer review scores, or any other criterion available in the table. This adds flexibility in how data is analyzed.

== Use Case Diagram ==
For this project our job is to unify the view of the two files, i.e. all_students_all_reviews and course_student_grade_summary, which were created in the previous implementation to one. This would result in a single view which would help in evaluating performances by combining a lot of different perspectives. In our case, if we merge the two files and create a new view, the user should be able to view all the information that is there to be seen in one page. This includes:
* Viewing a Unified Dashboard
* Viewing all the Project Grades
* Viewing Peer Evaluation Scores
* Selecting and Deselecting Columns

Using this information we have created the following Use Case Diagram:

<center>[[File:E2536_Spring_2025.png|600x600px|Improve assessment360]]</center>

== Design Pattern Usage in Assessment360Controller ==

The '''Assessment360Controller''' implements multiple design patterns that improve clarity, modularity, and maintainability of the code.

=== 1. Facade Pattern ===
The controller acts as a facade, hiding complex interactions between various models (''Course'', ''Assignment'', ''Participant'', ''Team'', etc.) and exposing a simplified interface for the view. It aggregates data like grades, reviews, and penalties and prepares it in a structured format, simplifying the presentation layer.

=== 2. Strategy Pattern ===
The use of helper modules such as:
* '''GradesHelper'''
* '''AuthorizationHelper'''
* '''Scoring'''
* '''PenaltyHelper'''

follows the Strategy Pattern. Each module encapsulates a specific piece of functionality, and the controller delegates responsibility to these interchangeable strategies, promoting clean separation of concerns and easier testing.

=== 3. Template Method Pattern ===
The method '''action_allowed?''' is a hook method that overrides a predefined template method in ''ApplicationController''. This allows customized access control behavior while maintaining a consistent interface across all controllers — an example of the Template Method Pattern in action.

=== 4. Separation of Concerns ===
Responsibility is split between:
* '''Controller''': Orchestrates data flow
* '''Models''': Store and retrieve business data
* '''Helpers''': Encapsulate computation and utility logic
* '''Views''': Render formatted output

This adheres to the '''Separation of Concerns''' principle and keeps each layer clean and testable.

These design patterns contribute to the robustness and scalability of the 360-degree assessment feature, allowing future teams to maintain and extend it with ease.

== Planned Enhancements ==

=== Functional Changes ===
{| class="wikitable"
! Feature !! Description
|-
| Unified View || Combine both views into a single HTML page that includes both project grades and review scores.
|-
| Column Selection || Allow users to toggle visible columns using checkboxes.
|-
| Exclude Unreviewed Assignments || Retain the functionality to exclude unreviewed assignments from averages.
|-
| Averages Precision || Limit decimal precision to 2 points for clarity.
|-
| Wider Name Column || Adjust layout to prioritize readability (e.g., wider name column than username).
|}

=== Code Refactor ===
{| class="wikitable"
! Task !! Reason
|-
| Move averaging logic to mixins or model concerns || Improve separation of concerns and reusability.
|-
| Commenting || Add meaningful comments for helper methods and business logic.
|}

== UI/UX Design ==
The new unified view will feature:
* A tabular layout showing all relevant data.
* Sectioned headers for each student.
* Collapsible panels (if needed) for clarity.
* Visual cues for peer review vs. project grades.
* Responsive design for usability across devices.

== Implementation ==

=== Previous View ===

Previously, the Assessment360 Controllers view relied on two separate views i.e. all_students_all_reviews and course_student_grade_summary, to display different aspects of student performance. This is how they looked like before.

1. all_students_all_reviews.html.erb

[[File:old_all_students_all_reviews.png|750px]]

2. course_student_grade_summary.html.erb

[[File:old_course_student_grade_summary.png|750px]]

=== Current View (after code changes) ===

The main objective of this project was to enhance the UI/UX and code quality of the assessment360 controller. This involved merging the two existing views (all_students_all_reviews and course_student_grade_summary) into a single unified view.

== Testing Strategy ==

{| class="wikitable"
|-
! Type !! Description !! Tests
|-
| ''' Unit Tests''' || Test individual controller methods || - Test grade calculations - Test data formatting
|-
| ''' Integration Tests''' || Test interactions between components || - Test view rendering - Test database queries - Test caching functionality
|-
| ''' Manual Testing''' || Test UI functionality, performance, and error handling || - Test UI functionality - Test performance with large datasets - Test error scenarios
|}

== Success Criteria ==

The success of this feature implementation will be evaluated based on the following criteria:

{| class="wikitable"
|-
! Criterion !! Description
|-
| '''UI Enhancements Implemented and Working''' || All proposed UI enhancements, including the unified view, column management features, and data presentation improvements, must be fully implemented and functioning as expected. The UI should be intuitive, responsive, and meet the design goals outlined in the document.
|-
| '''Performance Improvements Measurable''' || The feature should demonstrate a measurable improvement in performance, particularly in terms of load times and responsiveness when rendering large datasets or performing grade calculations. Performance benchmarking should indicate a noticeable reduction in latency.
|-
| '''Test Coverage ''' || Comprehensive unit and integration tests must cover more than 80% of the new code and critical paths in the controller. This ensures that the feature is reliable, and potential issues are identified early in the development cycle. Test results should be stable, with no significant failures.
|-
| '''Code Documentation Complete''' || All new and modified code must be thoroughly documented. This includes clear inline comments, explanations for complex logic, and appropriate documentation for new functions, classes, and components. This ensures that future developers can understand and maintain the code efficiently.
|-
| '''No Regression Bugs''' || After implementing the new feature, no existing functionality in the Assessment360 controller should break or behave unexpectedly. Regression testing should show that previously working parts of the system continue to function without issues.
|-
| '''Positive User Feedback''' || End-users (instructors and administrators) must provide positive feedback about the usability and effectiveness of the feature. Feedback should indicate that the feature adds value, improves user experience, and meets the goals outlined in the design document.
|}

== Implementation Video ==

Video Link: https://drive.google.com/file/d/1aAzGuSc-qwed4sGMIsWrIgelTTqd_OJ0/view

== Team Information ==
'''Mentor:''' Mitesh Anil Agarwal

'''Team:'''
* Jap Ashokbhai Purohit - jpurohi@ncsu.edu
* Sharmeen Momin - smomin@ncsu.edu
* Prithish Samanta - psamant2@ncsu.edu

== References ==
* [https://github.com/expertiza/expertiza Expertiza Codebase]
* [https://guides.rubyonrails.org/action_view_overview.html Rails View Helpers]
* [https://github.com/flyerhzm/bullet Bullet Gem Documentation]

CSC/ECE 517 Spring 2025 - E2536. Improve assessment360 controller

2025-04-23T01:02:35Z

Psamant2: /* Implementation */

== Problem Overview ==
The '''Assessment360 Controller''' within the Expertiza platform serves as a key tool for instructors, providing a holistic view of student performance across multiple assessment perspectives. The controller aggregates and displays data from various evaluation components, including teammate reviews, meta-reviews, instructor grades, peer review scores, and assignment submissions. The term <code>Assessment360</code> reflects its purpose of offering a comprehensive, 360-degree evaluation of a student's performance.

Currently, the system relies on two separate views — <code>all_students_all_reviews</code> and <code>course_student_grade_summary</code> — to display different aspects of student performance. These views present:
* Project-level data: The projects a student has worked on and the corresponding grades.
* Peer review data: The scores students receive from their teammates through the teammate review process.

While these views serve important functions, their separation results in a fragmented user experience, as instructors must switch between the views to see a complete set of student performance data. Additionally, the user interface (UI) is not optimized for an intuitive, seamless experience. There are limitations regarding
* The ability to interact with or customize the data display (e.g., column visibility, sorting, and reordering).
* The lack of visual clarity in data presentation (e.g., inconsistent formatting and absence of visual grade indicators).
* Inadequate responsiveness for different device types.

== Objective ==
The primary goal is to enhance the UI/UX and code quality of the <code>assessment360</code> controller. This involves:
* Merging the two existing views (<code>all_students_all_reviews</code> and <code>course_student_grade_summary</code>) into a single unified view.
* Improving the presentation and clarity of data (student grades, peer reviews).
* Refactoring logic for better separation of concerns and maintainability.
* Implementing feedback from the previous team.

== Current Implementation ==

=== Controller Structure ===
The <code>Assessment360Controller</code> is the central controller handling the logic for both the <code>all_students_all_reviews</code> and <code>course_student_grade_summary</code> views. It interacts with various models and services to fetch, process, and deliver the necessary data to the views. The current structure is as follows:
* The controller is responsible for gathering and processing assessment data such as grades, peer reviews, and meta-reviews for each student.
* It includes logic for handling class averages, calculating final grades, and determining peer review averages.
* The current implementation uses direct logic for grade calculations, and all calculations are executed within the controller itself, which could lead to bloated code and reduced maintainability.
* The views are rendered with minimal controller-side logic, relying on the controller to pass the necessary data to the front-end.

=== Current Views ===
The current implementation provides two main views that instructors can use to assess the performance of students. These views are defined in separate HTML ERB files.

==== <code>all_students_all_reviews.html.erb</code> ====
This view displays detailed student performance data in a table format. Key features include:
* Student Information Table: Displays each student’s name, ID, and relevant information.
* Teammate and Meta-Review Scores: For each student, the table shows the scores received from teammates and meta-reviews, which help in assessing peer evaluations.
* Class Averages: For each assignment and review type, class averages are calculated and displayed for instructors to analyze the overall performance of the class.
* Separate Columns for Review Types: Each type of review (<code>teammate</code>, <code>meta-review</code>, etc.) is shown in a separate column, making it easy to compare different assessment categories side by side.

==== <code>course_student_grade_summary.html.erb</code> ====
This view focuses on summarizing the project grades and peer review scores for each student. It includes:
* Student Grades and Peer Review Scores**: Displays the individual project grades and the peer review scores that a student has received.
* Assignment Topics: Lists the assignment topics associated with each project, along with the grades and peer review scores for those specific topics.
* Final Grades and Peer Review Averages: The final grade for each student is calculated by considering both the project grade and peer review scores, and the average peer review score is displayed alongside the final grade.
* Sortable Table Structure: The table in this view is designed to be sortable, allowing instructors to order students by project grades, peer review scores, or any other criterion available in the table. This adds flexibility in how data is analyzed.

== Use Case Diagram ==
For this project our job is to unify the view of the two files, i.e. all_students_all_reviews and course_student_grade_summary, which were created in the previous implementation to one. This would result in a single view which would help in evaluating performances by combining a lot of different perspectives. In our case, if we merge the two files and create a new view, the user should be able to view all the information that is there to be seen in one page. This includes:
* Viewing a Unified Dashboard
* Viewing all the Project Grades
* Viewing Peer Evaluation Scores
* Selecting and Deselecting Columns

Using this information we have created the following Use Case Diagram:

<center>[[File:E2536_Spring_2025.png|600x600px|Improve assessment360]]</center>

== Design Pattern Usage in Assessment360Controller ==

The '''Assessment360Controller''' implements multiple design patterns that improve clarity, modularity, and maintainability of the code.

=== 1. Facade Pattern ===
The controller acts as a facade, hiding complex interactions between various models (''Course'', ''Assignment'', ''Participant'', ''Team'', etc.) and exposing a simplified interface for the view. It aggregates data like grades, reviews, and penalties and prepares it in a structured format, simplifying the presentation layer.

=== 2. Strategy Pattern ===
The use of helper modules such as:
* '''GradesHelper'''
* '''AuthorizationHelper'''
* '''Scoring'''
* '''PenaltyHelper'''

follows the Strategy Pattern. Each module encapsulates a specific piece of functionality, and the controller delegates responsibility to these interchangeable strategies, promoting clean separation of concerns and easier testing.

=== 3. Template Method Pattern ===
The method '''action_allowed?''' is a hook method that overrides a predefined template method in ''ApplicationController''. This allows customized access control behavior while maintaining a consistent interface across all controllers — an example of the Template Method Pattern in action.

=== 4. Separation of Concerns ===
Responsibility is split between:
* '''Controller''': Orchestrates data flow
* '''Models''': Store and retrieve business data
* '''Helpers''': Encapsulate computation and utility logic
* '''Views''': Render formatted output

This adheres to the '''Separation of Concerns''' principle and keeps each layer clean and testable.

These design patterns contribute to the robustness and scalability of the 360-degree assessment feature, allowing future teams to maintain and extend it with ease.

== Planned Enhancements ==

=== Functional Changes ===
{| class="wikitable"
! Feature !! Description
|-
| Unified View || Combine both views into a single HTML page that includes both project grades and review scores.
|-
| Column Selection || Allow users to toggle visible columns using checkboxes.
|-
| Exclude Unreviewed Assignments || Retain the functionality to exclude unreviewed assignments from averages.
|-
| Averages Precision || Limit decimal precision to 2 points for clarity.
|-
| Wider Name Column || Adjust layout to prioritize readability (e.g., wider name column than username).
|}

=== Code Refactor ===
{| class="wikitable"
! Task !! Reason
|-
| Move averaging logic to mixins or model concerns || Improve separation of concerns and reusability.
|-
| Commenting || Add meaningful comments for helper methods and business logic.
|}

== UI/UX Design ==
The new unified view will feature:
* A tabular layout showing all relevant data.
* Sectioned headers for each student.
* Collapsible panels (if needed) for clarity.
* Visual cues for peer review vs. project grades.
* Responsive design for usability across devices.

== Implementation ==

=== Previous View ===

Previously, the Assessment360 Controllers view relied on two separate views i.e. all_students_all_reviews and course_student_grade_summary, to display different aspects of student performance. This is how they looked like before.

1. all_students_all_reviews.html.erb

[[File:old_all_students_all_reviews.png|750px]]

2. course_student_grade_summary.html.erb

[[File:old_course_student_grade_summary.png|750px]]

=== Current View (after code changes) ===

The main objective of this project was to enhance the UI/UX and code quality of the assessment360 controller. This involved merging the two existing views (all_students_all_reviews and course_student_grade_summary) into a single unified view.

== Testing Strategy ==

{| class="wikitable"
|-
! Type !! Description !! Tests
|-
| ''' Unit Tests''' || Test individual controller methods || - Test grade calculations - Test data formatting
|-
| ''' Integration Tests''' || Test interactions between components || - Test view rendering - Test database queries - Test caching functionality
|-
| ''' Manual Testing''' || Test UI functionality, performance, and error handling || - Test UI functionality - Test performance with large datasets - Test error scenarios
|}

== Success Criteria ==

The success of this feature implementation will be evaluated based on the following criteria:

{| class="wikitable"
|-
! Criterion !! Description
|-
| '''UI Enhancements Implemented and Working''' || All proposed UI enhancements, including the unified view, column management features, and data presentation improvements, must be fully implemented and functioning as expected. The UI should be intuitive, responsive, and meet the design goals outlined in the document.
|-
| '''Performance Improvements Measurable''' || The feature should demonstrate a measurable improvement in performance, particularly in terms of load times and responsiveness when rendering large datasets or performing grade calculations. Performance benchmarking should indicate a noticeable reduction in latency.
|-
| '''Test Coverage ''' || Comprehensive unit and integration tests must cover more than 80% of the new code and critical paths in the controller. This ensures that the feature is reliable, and potential issues are identified early in the development cycle. Test results should be stable, with no significant failures.
|-
| '''Code Documentation Complete''' || All new and modified code must be thoroughly documented. This includes clear inline comments, explanations for complex logic, and appropriate documentation for new functions, classes, and components. This ensures that future developers can understand and maintain the code efficiently.
|-
| '''No Regression Bugs''' || After implementing the new feature, no existing functionality in the Assessment360 controller should break or behave unexpectedly. Regression testing should show that previously working parts of the system continue to function without issues.
|-
| '''Positive User Feedback''' || End-users (instructors and administrators) must provide positive feedback about the usability and effectiveness of the feature. Feedback should indicate that the feature adds value, improves user experience, and meets the goals outlined in the design document.
|}

== Team Information ==
'''Mentor:''' Mitesh Anil Agarwal

'''Team:'''
* Jap Ashokbhai Purohit - jpurohi@ncsu.edu
* Sharmeen Momin - smomin@ncsu.edu
* Prithish Samanta - psamant2@ncsu.edu

== References ==
* [https://github.com/expertiza/expertiza Expertiza Codebase]
* [https://guides.rubyonrails.org/action_view_overview.html Rails View Helpers]
* [https://github.com/flyerhzm/bullet Bullet Gem Documentation]

CSC/ECE 517 Spring 2025 - E2536. Improve assessment360 controller

2025-04-23T01:02:24Z

Psamant2: /* Previous View */

== Problem Overview ==
The '''Assessment360 Controller''' within the Expertiza platform serves as a key tool for instructors, providing a holistic view of student performance across multiple assessment perspectives. The controller aggregates and displays data from various evaluation components, including teammate reviews, meta-reviews, instructor grades, peer review scores, and assignment submissions. The term <code>Assessment360</code> reflects its purpose of offering a comprehensive, 360-degree evaluation of a student's performance.

Currently, the system relies on two separate views — <code>all_students_all_reviews</code> and <code>course_student_grade_summary</code> — to display different aspects of student performance. These views present:
* Project-level data: The projects a student has worked on and the corresponding grades.
* Peer review data: The scores students receive from their teammates through the teammate review process.

While these views serve important functions, their separation results in a fragmented user experience, as instructors must switch between the views to see a complete set of student performance data. Additionally, the user interface (UI) is not optimized for an intuitive, seamless experience. There are limitations regarding
* The ability to interact with or customize the data display (e.g., column visibility, sorting, and reordering).
* The lack of visual clarity in data presentation (e.g., inconsistent formatting and absence of visual grade indicators).
* Inadequate responsiveness for different device types.

== Objective ==
The primary goal is to enhance the UI/UX and code quality of the <code>assessment360</code> controller. This involves:
* Merging the two existing views (<code>all_students_all_reviews</code> and <code>course_student_grade_summary</code>) into a single unified view.
* Improving the presentation and clarity of data (student grades, peer reviews).
* Refactoring logic for better separation of concerns and maintainability.
* Implementing feedback from the previous team.

== Current Implementation ==

=== Controller Structure ===
The <code>Assessment360Controller</code> is the central controller handling the logic for both the <code>all_students_all_reviews</code> and <code>course_student_grade_summary</code> views. It interacts with various models and services to fetch, process, and deliver the necessary data to the views. The current structure is as follows:
* The controller is responsible for gathering and processing assessment data such as grades, peer reviews, and meta-reviews for each student.
* It includes logic for handling class averages, calculating final grades, and determining peer review averages.
* The current implementation uses direct logic for grade calculations, and all calculations are executed within the controller itself, which could lead to bloated code and reduced maintainability.
* The views are rendered with minimal controller-side logic, relying on the controller to pass the necessary data to the front-end.

=== Current Views ===
The current implementation provides two main views that instructors can use to assess the performance of students. These views are defined in separate HTML ERB files.

==== <code>all_students_all_reviews.html.erb</code> ====
This view displays detailed student performance data in a table format. Key features include:
* Student Information Table: Displays each student’s name, ID, and relevant information.
* Teammate and Meta-Review Scores: For each student, the table shows the scores received from teammates and meta-reviews, which help in assessing peer evaluations.
* Class Averages: For each assignment and review type, class averages are calculated and displayed for instructors to analyze the overall performance of the class.
* Separate Columns for Review Types: Each type of review (<code>teammate</code>, <code>meta-review</code>, etc.) is shown in a separate column, making it easy to compare different assessment categories side by side.

==== <code>course_student_grade_summary.html.erb</code> ====
This view focuses on summarizing the project grades and peer review scores for each student. It includes:
* Student Grades and Peer Review Scores**: Displays the individual project grades and the peer review scores that a student has received.
* Assignment Topics: Lists the assignment topics associated with each project, along with the grades and peer review scores for those specific topics.
* Final Grades and Peer Review Averages: The final grade for each student is calculated by considering both the project grade and peer review scores, and the average peer review score is displayed alongside the final grade.
* Sortable Table Structure: The table in this view is designed to be sortable, allowing instructors to order students by project grades, peer review scores, or any other criterion available in the table. This adds flexibility in how data is analyzed.

== Use Case Diagram ==
For this project our job is to unify the view of the two files, i.e. all_students_all_reviews and course_student_grade_summary, which were created in the previous implementation to one. This would result in a single view which would help in evaluating performances by combining a lot of different perspectives. In our case, if we merge the two files and create a new view, the user should be able to view all the information that is there to be seen in one page. This includes:
* Viewing a Unified Dashboard
* Viewing all the Project Grades
* Viewing Peer Evaluation Scores
* Selecting and Deselecting Columns

Using this information we have created the following Use Case Diagram:

<center>[[File:E2536_Spring_2025.png|600x600px|Improve assessment360]]</center>

== Design Pattern Usage in Assessment360Controller ==

The '''Assessment360Controller''' implements multiple design patterns that improve clarity, modularity, and maintainability of the code.

=== 1. Facade Pattern ===
The controller acts as a facade, hiding complex interactions between various models (''Course'', ''Assignment'', ''Participant'', ''Team'', etc.) and exposing a simplified interface for the view. It aggregates data like grades, reviews, and penalties and prepares it in a structured format, simplifying the presentation layer.

=== 2. Strategy Pattern ===
The use of helper modules such as:
* '''GradesHelper'''
* '''AuthorizationHelper'''
* '''Scoring'''
* '''PenaltyHelper'''

follows the Strategy Pattern. Each module encapsulates a specific piece of functionality, and the controller delegates responsibility to these interchangeable strategies, promoting clean separation of concerns and easier testing.

=== 3. Template Method Pattern ===
The method '''action_allowed?''' is a hook method that overrides a predefined template method in ''ApplicationController''. This allows customized access control behavior while maintaining a consistent interface across all controllers — an example of the Template Method Pattern in action.

=== 4. Separation of Concerns ===
Responsibility is split between:
* '''Controller''': Orchestrates data flow
* '''Models''': Store and retrieve business data
* '''Helpers''': Encapsulate computation and utility logic
* '''Views''': Render formatted output

This adheres to the '''Separation of Concerns''' principle and keeps each layer clean and testable.

These design patterns contribute to the robustness and scalability of the 360-degree assessment feature, allowing future teams to maintain and extend it with ease.

== Planned Enhancements ==

=== Functional Changes ===
{| class="wikitable"
! Feature !! Description
|-
| Unified View || Combine both views into a single HTML page that includes both project grades and review scores.
|-
| Column Selection || Allow users to toggle visible columns using checkboxes.
|-
| Exclude Unreviewed Assignments || Retain the functionality to exclude unreviewed assignments from averages.
|-
| Averages Precision || Limit decimal precision to 2 points for clarity.
|-
| Wider Name Column || Adjust layout to prioritize readability (e.g., wider name column than username).
|}

=== Code Refactor ===
{| class="wikitable"
! Task !! Reason
|-
| Move averaging logic to mixins or model concerns || Improve separation of concerns and reusability.
|-
| Commenting || Add meaningful comments for helper methods and business logic.
|}

== UI/UX Design ==
The new unified view will feature:
* A tabular layout showing all relevant data.
* Sectioned headers for each student.
* Collapsible panels (if needed) for clarity.
* Visual cues for peer review vs. project grades.
* Responsive design for usability across devices.

== Implementation ==

=== Previous View ===

Previously, the Assessment360 Controllers view relied on two separate views i.e. all_students_all_reviews and course_student_grade_summary, to display different aspects of student performance. This is how they looked like before.

1. all_students_all_reviews.html.erb
[[File:old_all_students_all_reviews.png|750px]]

2. course_student_grade_summary.html.erb
[[File:old_course_student_grade_summary.png|750px]]

=== Current View (after code changes) ===

The main objective of this project was to enhance the UI/UX and code quality of the assessment360 controller. This involved merging the two existing views (all_students_all_reviews and course_student_grade_summary) into a single unified view.

== Testing Strategy ==

{| class="wikitable"
|-
! Type !! Description !! Tests
|-
| ''' Unit Tests''' || Test individual controller methods || - Test grade calculations - Test data formatting
|-
| ''' Integration Tests''' || Test interactions between components || - Test view rendering - Test database queries - Test caching functionality
|-
| ''' Manual Testing''' || Test UI functionality, performance, and error handling || - Test UI functionality - Test performance with large datasets - Test error scenarios
|}

== Success Criteria ==

The success of this feature implementation will be evaluated based on the following criteria:

{| class="wikitable"
|-
! Criterion !! Description
|-
| '''UI Enhancements Implemented and Working''' || All proposed UI enhancements, including the unified view, column management features, and data presentation improvements, must be fully implemented and functioning as expected. The UI should be intuitive, responsive, and meet the design goals outlined in the document.
|-
| '''Performance Improvements Measurable''' || The feature should demonstrate a measurable improvement in performance, particularly in terms of load times and responsiveness when rendering large datasets or performing grade calculations. Performance benchmarking should indicate a noticeable reduction in latency.
|-
| '''Test Coverage ''' || Comprehensive unit and integration tests must cover more than 80% of the new code and critical paths in the controller. This ensures that the feature is reliable, and potential issues are identified early in the development cycle. Test results should be stable, with no significant failures.
|-
| '''Code Documentation Complete''' || All new and modified code must be thoroughly documented. This includes clear inline comments, explanations for complex logic, and appropriate documentation for new functions, classes, and components. This ensures that future developers can understand and maintain the code efficiently.
|-
| '''No Regression Bugs''' || After implementing the new feature, no existing functionality in the Assessment360 controller should break or behave unexpectedly. Regression testing should show that previously working parts of the system continue to function without issues.
|-
| '''Positive User Feedback''' || End-users (instructors and administrators) must provide positive feedback about the usability and effectiveness of the feature. Feedback should indicate that the feature adds value, improves user experience, and meets the goals outlined in the design document.
|}

== Team Information ==
'''Mentor:''' Mitesh Anil Agarwal

'''Team:'''
* Jap Ashokbhai Purohit - jpurohi@ncsu.edu
* Sharmeen Momin - smomin@ncsu.edu
* Prithish Samanta - psamant2@ncsu.edu

== References ==
* [https://github.com/expertiza/expertiza Expertiza Codebase]
* [https://guides.rubyonrails.org/action_view_overview.html Rails View Helpers]
* [https://github.com/flyerhzm/bullet Bullet Gem Documentation]

CSC/ECE 517 Spring 2025 - E2536. Improve assessment360 controller

2025-04-23T01:01:20Z

Psamant2: /* Previous View */

== Problem Overview ==
The '''Assessment360 Controller''' within the Expertiza platform serves as a key tool for instructors, providing a holistic view of student performance across multiple assessment perspectives. The controller aggregates and displays data from various evaluation components, including teammate reviews, meta-reviews, instructor grades, peer review scores, and assignment submissions. The term <code>Assessment360</code> reflects its purpose of offering a comprehensive, 360-degree evaluation of a student's performance.

Currently, the system relies on two separate views — <code>all_students_all_reviews</code> and <code>course_student_grade_summary</code> — to display different aspects of student performance. These views present:
* Project-level data: The projects a student has worked on and the corresponding grades.
* Peer review data: The scores students receive from their teammates through the teammate review process.

While these views serve important functions, their separation results in a fragmented user experience, as instructors must switch between the views to see a complete set of student performance data. Additionally, the user interface (UI) is not optimized for an intuitive, seamless experience. There are limitations regarding
* The ability to interact with or customize the data display (e.g., column visibility, sorting, and reordering).
* The lack of visual clarity in data presentation (e.g., inconsistent formatting and absence of visual grade indicators).
* Inadequate responsiveness for different device types.

== Objective ==
The primary goal is to enhance the UI/UX and code quality of the <code>assessment360</code> controller. This involves:
* Merging the two existing views (<code>all_students_all_reviews</code> and <code>course_student_grade_summary</code>) into a single unified view.
* Improving the presentation and clarity of data (student grades, peer reviews).
* Refactoring logic for better separation of concerns and maintainability.
* Implementing feedback from the previous team.

== Current Implementation ==

=== Controller Structure ===
The <code>Assessment360Controller</code> is the central controller handling the logic for both the <code>all_students_all_reviews</code> and <code>course_student_grade_summary</code> views. It interacts with various models and services to fetch, process, and deliver the necessary data to the views. The current structure is as follows:
* The controller is responsible for gathering and processing assessment data such as grades, peer reviews, and meta-reviews for each student.
* It includes logic for handling class averages, calculating final grades, and determining peer review averages.
* The current implementation uses direct logic for grade calculations, and all calculations are executed within the controller itself, which could lead to bloated code and reduced maintainability.
* The views are rendered with minimal controller-side logic, relying on the controller to pass the necessary data to the front-end.

=== Current Views ===
The current implementation provides two main views that instructors can use to assess the performance of students. These views are defined in separate HTML ERB files.

==== <code>all_students_all_reviews.html.erb</code> ====
This view displays detailed student performance data in a table format. Key features include:
* Student Information Table: Displays each student’s name, ID, and relevant information.
* Teammate and Meta-Review Scores: For each student, the table shows the scores received from teammates and meta-reviews, which help in assessing peer evaluations.
* Class Averages: For each assignment and review type, class averages are calculated and displayed for instructors to analyze the overall performance of the class.
* Separate Columns for Review Types: Each type of review (<code>teammate</code>, <code>meta-review</code>, etc.) is shown in a separate column, making it easy to compare different assessment categories side by side.

==== <code>course_student_grade_summary.html.erb</code> ====
This view focuses on summarizing the project grades and peer review scores for each student. It includes:
* Student Grades and Peer Review Scores**: Displays the individual project grades and the peer review scores that a student has received.
* Assignment Topics: Lists the assignment topics associated with each project, along with the grades and peer review scores for those specific topics.
* Final Grades and Peer Review Averages: The final grade for each student is calculated by considering both the project grade and peer review scores, and the average peer review score is displayed alongside the final grade.
* Sortable Table Structure: The table in this view is designed to be sortable, allowing instructors to order students by project grades, peer review scores, or any other criterion available in the table. This adds flexibility in how data is analyzed.

== Use Case Diagram ==
For this project our job is to unify the view of the two files, i.e. all_students_all_reviews and course_student_grade_summary, which were created in the previous implementation to one. This would result in a single view which would help in evaluating performances by combining a lot of different perspectives. In our case, if we merge the two files and create a new view, the user should be able to view all the information that is there to be seen in one page. This includes:
* Viewing a Unified Dashboard
* Viewing all the Project Grades
* Viewing Peer Evaluation Scores
* Selecting and Deselecting Columns

Using this information we have created the following Use Case Diagram:

<center>[[File:E2536_Spring_2025.png|600x600px|Improve assessment360]]</center>

== Design Pattern Usage in Assessment360Controller ==

The '''Assessment360Controller''' implements multiple design patterns that improve clarity, modularity, and maintainability of the code.

=== 1. Facade Pattern ===
The controller acts as a facade, hiding complex interactions between various models (''Course'', ''Assignment'', ''Participant'', ''Team'', etc.) and exposing a simplified interface for the view. It aggregates data like grades, reviews, and penalties and prepares it in a structured format, simplifying the presentation layer.

=== 2. Strategy Pattern ===
The use of helper modules such as:
* '''GradesHelper'''
* '''AuthorizationHelper'''
* '''Scoring'''
* '''PenaltyHelper'''

follows the Strategy Pattern. Each module encapsulates a specific piece of functionality, and the controller delegates responsibility to these interchangeable strategies, promoting clean separation of concerns and easier testing.

=== 3. Template Method Pattern ===
The method '''action_allowed?''' is a hook method that overrides a predefined template method in ''ApplicationController''. This allows customized access control behavior while maintaining a consistent interface across all controllers — an example of the Template Method Pattern in action.

=== 4. Separation of Concerns ===
Responsibility is split between:
* '''Controller''': Orchestrates data flow
* '''Models''': Store and retrieve business data
* '''Helpers''': Encapsulate computation and utility logic
* '''Views''': Render formatted output

This adheres to the '''Separation of Concerns''' principle and keeps each layer clean and testable.

These design patterns contribute to the robustness and scalability of the 360-degree assessment feature, allowing future teams to maintain and extend it with ease.

== Planned Enhancements ==

=== Functional Changes ===
{| class="wikitable"
! Feature !! Description
|-
| Unified View || Combine both views into a single HTML page that includes both project grades and review scores.
|-
| Column Selection || Allow users to toggle visible columns using checkboxes.
|-
| Exclude Unreviewed Assignments || Retain the functionality to exclude unreviewed assignments from averages.
|-
| Averages Precision || Limit decimal precision to 2 points for clarity.
|-
| Wider Name Column || Adjust layout to prioritize readability (e.g., wider name column than username).
|}

=== Code Refactor ===
{| class="wikitable"
! Task !! Reason
|-
| Move averaging logic to mixins or model concerns || Improve separation of concerns and reusability.
|-
| Commenting || Add meaningful comments for helper methods and business logic.
|}

== UI/UX Design ==
The new unified view will feature:
* A tabular layout showing all relevant data.
* Sectioned headers for each student.
* Collapsible panels (if needed) for clarity.
* Visual cues for peer review vs. project grades.
* Responsive design for usability across devices.

== Implementation ==

=== Previous View ===

Previously, the Assessment360 Controllers view relied on two separate views i.e. all_students_all_reviews and course_student_grade_summary, to display different aspects of student performance. This is how they looked like before.

[[File:old_all_students_all_reviews.png|750px]]
[[File:old_course_student_grade_summary.png|750px]]

=== Current View (after code changes) ===

The main objective of this project was to enhance the UI/UX and code quality of the assessment360 controller. This involved merging the two existing views (all_students_all_reviews and course_student_grade_summary) into a single unified view.

== Testing Strategy ==

{| class="wikitable"
|-
! Type !! Description !! Tests
|-
| ''' Unit Tests''' || Test individual controller methods || - Test grade calculations - Test data formatting
|-
| ''' Integration Tests''' || Test interactions between components || - Test view rendering - Test database queries - Test caching functionality
|-
| ''' Manual Testing''' || Test UI functionality, performance, and error handling || - Test UI functionality - Test performance with large datasets - Test error scenarios
|}

== Success Criteria ==

The success of this feature implementation will be evaluated based on the following criteria:

{| class="wikitable"
|-
! Criterion !! Description
|-
| '''UI Enhancements Implemented and Working''' || All proposed UI enhancements, including the unified view, column management features, and data presentation improvements, must be fully implemented and functioning as expected. The UI should be intuitive, responsive, and meet the design goals outlined in the document.
|-
| '''Performance Improvements Measurable''' || The feature should demonstrate a measurable improvement in performance, particularly in terms of load times and responsiveness when rendering large datasets or performing grade calculations. Performance benchmarking should indicate a noticeable reduction in latency.
|-
| '''Test Coverage ''' || Comprehensive unit and integration tests must cover more than 80% of the new code and critical paths in the controller. This ensures that the feature is reliable, and potential issues are identified early in the development cycle. Test results should be stable, with no significant failures.
|-
| '''Code Documentation Complete''' || All new and modified code must be thoroughly documented. This includes clear inline comments, explanations for complex logic, and appropriate documentation for new functions, classes, and components. This ensures that future developers can understand and maintain the code efficiently.
|-
| '''No Regression Bugs''' || After implementing the new feature, no existing functionality in the Assessment360 controller should break or behave unexpectedly. Regression testing should show that previously working parts of the system continue to function without issues.
|-
| '''Positive User Feedback''' || End-users (instructors and administrators) must provide positive feedback about the usability and effectiveness of the feature. Feedback should indicate that the feature adds value, improves user experience, and meets the goals outlined in the design document.
|}

== Team Information ==
'''Mentor:''' Mitesh Anil Agarwal

'''Team:'''
* Jap Ashokbhai Purohit - jpurohi@ncsu.edu
* Sharmeen Momin - smomin@ncsu.edu
* Prithish Samanta - psamant2@ncsu.edu

== References ==
* [https://github.com/expertiza/expertiza Expertiza Codebase]
* [https://guides.rubyonrails.org/action_view_overview.html Rails View Helpers]
* [https://github.com/flyerhzm/bullet Bullet Gem Documentation]

File:Old course student grade summary.png

2025-04-23T01:00:50Z

Psamant2:

File:Old all students all reviews.png

2025-04-23T01:00:05Z

Psamant2:

CSC/ECE 517 Spring 2025 - E2536. Improve assessment360 controller

2025-04-23T00:17:51Z

Psamant2: /* Current View (after code changes) */

== Problem Overview ==
The '''Assessment360 Controller''' within the Expertiza platform serves as a key tool for instructors, providing a holistic view of student performance across multiple assessment perspectives. The controller aggregates and displays data from various evaluation components, including teammate reviews, meta-reviews, instructor grades, peer review scores, and assignment submissions. The term <code>Assessment360</code> reflects its purpose of offering a comprehensive, 360-degree evaluation of a student's performance.

Currently, the system relies on two separate views — <code>all_students_all_reviews</code> and <code>course_student_grade_summary</code> — to display different aspects of student performance. These views present:
* Project-level data: The projects a student has worked on and the corresponding grades.
* Peer review data: The scores students receive from their teammates through the teammate review process.

While these views serve important functions, their separation results in a fragmented user experience, as instructors must switch between the views to see a complete set of student performance data. Additionally, the user interface (UI) is not optimized for an intuitive, seamless experience. There are limitations regarding
* The ability to interact with or customize the data display (e.g., column visibility, sorting, and reordering).
* The lack of visual clarity in data presentation (e.g., inconsistent formatting and absence of visual grade indicators).
* Inadequate responsiveness for different device types.

== Objective ==
The primary goal is to enhance the UI/UX and code quality of the <code>assessment360</code> controller. This involves:
* Merging the two existing views (<code>all_students_all_reviews</code> and <code>course_student_grade_summary</code>) into a single unified view.
* Improving the presentation and clarity of data (student grades, peer reviews).
* Refactoring logic for better separation of concerns and maintainability.
* Implementing feedback from the previous team.

== Current Implementation ==

=== Controller Structure ===
The <code>Assessment360Controller</code> is the central controller handling the logic for both the <code>all_students_all_reviews</code> and <code>course_student_grade_summary</code> views. It interacts with various models and services to fetch, process, and deliver the necessary data to the views. The current structure is as follows:
* The controller is responsible for gathering and processing assessment data such as grades, peer reviews, and meta-reviews for each student.
* It includes logic for handling class averages, calculating final grades, and determining peer review averages.
* The current implementation uses direct logic for grade calculations, and all calculations are executed within the controller itself, which could lead to bloated code and reduced maintainability.
* The views are rendered with minimal controller-side logic, relying on the controller to pass the necessary data to the front-end.

=== Current Views ===
The current implementation provides two main views that instructors can use to assess the performance of students. These views are defined in separate HTML ERB files.

==== <code>all_students_all_reviews.html.erb</code> ====
This view displays detailed student performance data in a table format. Key features include:
* Student Information Table: Displays each student’s name, ID, and relevant information.
* Teammate and Meta-Review Scores: For each student, the table shows the scores received from teammates and meta-reviews, which help in assessing peer evaluations.
* Class Averages: For each assignment and review type, class averages are calculated and displayed for instructors to analyze the overall performance of the class.
* Separate Columns for Review Types: Each type of review (<code>teammate</code>, <code>meta-review</code>, etc.) is shown in a separate column, making it easy to compare different assessment categories side by side.

==== <code>course_student_grade_summary.html.erb</code> ====
This view focuses on summarizing the project grades and peer review scores for each student. It includes:
* Student Grades and Peer Review Scores**: Displays the individual project grades and the peer review scores that a student has received.
* Assignment Topics: Lists the assignment topics associated with each project, along with the grades and peer review scores for those specific topics.
* Final Grades and Peer Review Averages: The final grade for each student is calculated by considering both the project grade and peer review scores, and the average peer review score is displayed alongside the final grade.
* Sortable Table Structure: The table in this view is designed to be sortable, allowing instructors to order students by project grades, peer review scores, or any other criterion available in the table. This adds flexibility in how data is analyzed.

== Use Case Diagram ==
For this project our job is to unify the view of the two files, i.e. all_students_all_reviews and course_student_grade_summary, which were created in the previous implementation to one. This would result in a single view which would help in evaluating performances by combining a lot of different perspectives. In our case, if we merge the two files and create a new view, the user should be able to view all the information that is there to be seen in one page. This includes:
* Viewing a Unified Dashboard
* Viewing all the Project Grades
* Viewing Peer Evaluation Scores
* Selecting and Deselecting Columns

Using this information we have created the following Use Case Diagram:

<center>[[File:E2536_Spring_2025.png|600x600px|Improve assessment360]]</center>

== Design Pattern Usage in Assessment360Controller ==

The '''Assessment360Controller''' implements multiple design patterns that improve clarity, modularity, and maintainability of the code.

=== 1. Facade Pattern ===
The controller acts as a facade, hiding complex interactions between various models (''Course'', ''Assignment'', ''Participant'', ''Team'', etc.) and exposing a simplified interface for the view. It aggregates data like grades, reviews, and penalties and prepares it in a structured format, simplifying the presentation layer.

=== 2. Strategy Pattern ===
The use of helper modules such as:
* '''GradesHelper'''
* '''AuthorizationHelper'''
* '''Scoring'''
* '''PenaltyHelper'''

follows the Strategy Pattern. Each module encapsulates a specific piece of functionality, and the controller delegates responsibility to these interchangeable strategies, promoting clean separation of concerns and easier testing.

=== 3. Template Method Pattern ===
The method '''action_allowed?''' is a hook method that overrides a predefined template method in ''ApplicationController''. This allows customized access control behavior while maintaining a consistent interface across all controllers — an example of the Template Method Pattern in action.

=== 4. Separation of Concerns ===
Responsibility is split between:
* '''Controller''': Orchestrates data flow
* '''Models''': Store and retrieve business data
* '''Helpers''': Encapsulate computation and utility logic
* '''Views''': Render formatted output

This adheres to the '''Separation of Concerns''' principle and keeps each layer clean and testable.

These design patterns contribute to the robustness and scalability of the 360-degree assessment feature, allowing future teams to maintain and extend it with ease.

== Planned Enhancements ==

=== Functional Changes ===
{| class="wikitable"
! Feature !! Description
|-
| Unified View || Combine both views into a single HTML page that includes both project grades and review scores.
|-
| Column Selection || Allow users to toggle visible columns using checkboxes.
|-
| Exclude Unreviewed Assignments || Retain the functionality to exclude unreviewed assignments from averages.
|-
| Averages Precision || Limit decimal precision to 2 points for clarity.
|-
| Wider Name Column || Adjust layout to prioritize readability (e.g., wider name column than username).
|}

=== Code Refactor ===
{| class="wikitable"
! Task !! Reason
|-
| Move averaging logic to mixins or model concerns || Improve separation of concerns and reusability.
|-
| Commenting || Add meaningful comments for helper methods and business logic.
|}

== UI/UX Design ==
The new unified view will feature:
* A tabular layout showing all relevant data.
* Sectioned headers for each student.
* Collapsible panels (if needed) for clarity.
* Visual cues for peer review vs. project grades.
* Responsive design for usability across devices.

== Implementation ==

=== Previous View ===

Previously, the Assessment360 Controllers view relied on two separate views i.e. all_students_all_reviews and course_student_grade_summary, to display different aspects of student performance. This is how they looked like before.

[[File:All_students_all_reviews.png|750px]]
[[File:course_student_grade_summary.png|750px]]

=== Current View (after code changes) ===

The main objective of this project was to enhance the UI/UX and code quality of the assessment360 controller. This involved merging the two existing views (all_students_all_reviews and course_student_grade_summary) into a single unified view.

== Testing Strategy ==

{| class="wikitable"
|-
! Type !! Description !! Tests
|-
| ''' Unit Tests''' || Test individual controller methods || - Test grade calculations - Test data formatting
|-
| ''' Integration Tests''' || Test interactions between components || - Test view rendering - Test database queries - Test caching functionality
|-
| ''' Manual Testing''' || Test UI functionality, performance, and error handling || - Test UI functionality - Test performance with large datasets - Test error scenarios
|}

== Success Criteria ==

The success of this feature implementation will be evaluated based on the following criteria:

{| class="wikitable"
|-
! Criterion !! Description
|-
| '''UI Enhancements Implemented and Working''' || All proposed UI enhancements, including the unified view, column management features, and data presentation improvements, must be fully implemented and functioning as expected. The UI should be intuitive, responsive, and meet the design goals outlined in the document.
|-
| '''Performance Improvements Measurable''' || The feature should demonstrate a measurable improvement in performance, particularly in terms of load times and responsiveness when rendering large datasets or performing grade calculations. Performance benchmarking should indicate a noticeable reduction in latency.
|-
| '''Test Coverage ''' || Comprehensive unit and integration tests must cover more than 80% of the new code and critical paths in the controller. This ensures that the feature is reliable, and potential issues are identified early in the development cycle. Test results should be stable, with no significant failures.
|-
| '''Code Documentation Complete''' || All new and modified code must be thoroughly documented. This includes clear inline comments, explanations for complex logic, and appropriate documentation for new functions, classes, and components. This ensures that future developers can understand and maintain the code efficiently.
|-
| '''No Regression Bugs''' || After implementing the new feature, no existing functionality in the Assessment360 controller should break or behave unexpectedly. Regression testing should show that previously working parts of the system continue to function without issues.
|-
| '''Positive User Feedback''' || End-users (instructors and administrators) must provide positive feedback about the usability and effectiveness of the feature. Feedback should indicate that the feature adds value, improves user experience, and meets the goals outlined in the design document.
|}

== Team Information ==
'''Mentor:''' Mitesh Anil Agarwal

'''Team:'''
* Jap Ashokbhai Purohit - jpurohi@ncsu.edu
* Sharmeen Momin - smomin@ncsu.edu
* Prithish Samanta - psamant2@ncsu.edu

== References ==
* [https://github.com/expertiza/expertiza Expertiza Codebase]
* [https://guides.rubyonrails.org/action_view_overview.html Rails View Helpers]
* [https://github.com/flyerhzm/bullet Bullet Gem Documentation]

CSC/ECE 517 Spring 2025 - E2536. Improve assessment360 controller

2025-04-23T00:15:59Z

Psamant2: /* Previous View */

== Problem Overview ==
The '''Assessment360 Controller''' within the Expertiza platform serves as a key tool for instructors, providing a holistic view of student performance across multiple assessment perspectives. The controller aggregates and displays data from various evaluation components, including teammate reviews, meta-reviews, instructor grades, peer review scores, and assignment submissions. The term <code>Assessment360</code> reflects its purpose of offering a comprehensive, 360-degree evaluation of a student's performance.

Currently, the system relies on two separate views — <code>all_students_all_reviews</code> and <code>course_student_grade_summary</code> — to display different aspects of student performance. These views present:
* Project-level data: The projects a student has worked on and the corresponding grades.
* Peer review data: The scores students receive from their teammates through the teammate review process.

While these views serve important functions, their separation results in a fragmented user experience, as instructors must switch between the views to see a complete set of student performance data. Additionally, the user interface (UI) is not optimized for an intuitive, seamless experience. There are limitations regarding
* The ability to interact with or customize the data display (e.g., column visibility, sorting, and reordering).
* The lack of visual clarity in data presentation (e.g., inconsistent formatting and absence of visual grade indicators).
* Inadequate responsiveness for different device types.

== Objective ==
The primary goal is to enhance the UI/UX and code quality of the <code>assessment360</code> controller. This involves:
* Merging the two existing views (<code>all_students_all_reviews</code> and <code>course_student_grade_summary</code>) into a single unified view.
* Improving the presentation and clarity of data (student grades, peer reviews).
* Refactoring logic for better separation of concerns and maintainability.
* Implementing feedback from the previous team.

== Current Implementation ==

=== Controller Structure ===
The <code>Assessment360Controller</code> is the central controller handling the logic for both the <code>all_students_all_reviews</code> and <code>course_student_grade_summary</code> views. It interacts with various models and services to fetch, process, and deliver the necessary data to the views. The current structure is as follows:
* The controller is responsible for gathering and processing assessment data such as grades, peer reviews, and meta-reviews for each student.
* It includes logic for handling class averages, calculating final grades, and determining peer review averages.
* The current implementation uses direct logic for grade calculations, and all calculations are executed within the controller itself, which could lead to bloated code and reduced maintainability.
* The views are rendered with minimal controller-side logic, relying on the controller to pass the necessary data to the front-end.

=== Current Views ===
The current implementation provides two main views that instructors can use to assess the performance of students. These views are defined in separate HTML ERB files.

==== <code>all_students_all_reviews.html.erb</code> ====
This view displays detailed student performance data in a table format. Key features include:
* Student Information Table: Displays each student’s name, ID, and relevant information.
* Teammate and Meta-Review Scores: For each student, the table shows the scores received from teammates and meta-reviews, which help in assessing peer evaluations.
* Class Averages: For each assignment and review type, class averages are calculated and displayed for instructors to analyze the overall performance of the class.
* Separate Columns for Review Types: Each type of review (<code>teammate</code>, <code>meta-review</code>, etc.) is shown in a separate column, making it easy to compare different assessment categories side by side.

==== <code>course_student_grade_summary.html.erb</code> ====
This view focuses on summarizing the project grades and peer review scores for each student. It includes:
* Student Grades and Peer Review Scores**: Displays the individual project grades and the peer review scores that a student has received.
* Assignment Topics: Lists the assignment topics associated with each project, along with the grades and peer review scores for those specific topics.
* Final Grades and Peer Review Averages: The final grade for each student is calculated by considering both the project grade and peer review scores, and the average peer review score is displayed alongside the final grade.
* Sortable Table Structure: The table in this view is designed to be sortable, allowing instructors to order students by project grades, peer review scores, or any other criterion available in the table. This adds flexibility in how data is analyzed.

== Use Case Diagram ==
For this project our job is to unify the view of the two files, i.e. all_students_all_reviews and course_student_grade_summary, which were created in the previous implementation to one. This would result in a single view which would help in evaluating performances by combining a lot of different perspectives. In our case, if we merge the two files and create a new view, the user should be able to view all the information that is there to be seen in one page. This includes:
* Viewing a Unified Dashboard
* Viewing all the Project Grades
* Viewing Peer Evaluation Scores
* Selecting and Deselecting Columns

Using this information we have created the following Use Case Diagram:

<center>[[File:E2536_Spring_2025.png|600x600px|Improve assessment360]]</center>

== Design Pattern Usage in Assessment360Controller ==

The '''Assessment360Controller''' implements multiple design patterns that improve clarity, modularity, and maintainability of the code.

=== 1. Facade Pattern ===
The controller acts as a facade, hiding complex interactions between various models (''Course'', ''Assignment'', ''Participant'', ''Team'', etc.) and exposing a simplified interface for the view. It aggregates data like grades, reviews, and penalties and prepares it in a structured format, simplifying the presentation layer.

=== 2. Strategy Pattern ===
The use of helper modules such as:
* '''GradesHelper'''
* '''AuthorizationHelper'''
* '''Scoring'''
* '''PenaltyHelper'''

follows the Strategy Pattern. Each module encapsulates a specific piece of functionality, and the controller delegates responsibility to these interchangeable strategies, promoting clean separation of concerns and easier testing.

=== 3. Template Method Pattern ===
The method '''action_allowed?''' is a hook method that overrides a predefined template method in ''ApplicationController''. This allows customized access control behavior while maintaining a consistent interface across all controllers — an example of the Template Method Pattern in action.

=== 4. Separation of Concerns ===
Responsibility is split between:
* '''Controller''': Orchestrates data flow
* '''Models''': Store and retrieve business data
* '''Helpers''': Encapsulate computation and utility logic
* '''Views''': Render formatted output

This adheres to the '''Separation of Concerns''' principle and keeps each layer clean and testable.

These design patterns contribute to the robustness and scalability of the 360-degree assessment feature, allowing future teams to maintain and extend it with ease.

== Planned Enhancements ==

=== Functional Changes ===
{| class="wikitable"
! Feature !! Description
|-
| Unified View || Combine both views into a single HTML page that includes both project grades and review scores.
|-
| Column Selection || Allow users to toggle visible columns using checkboxes.
|-
| Exclude Unreviewed Assignments || Retain the functionality to exclude unreviewed assignments from averages.
|-
| Averages Precision || Limit decimal precision to 2 points for clarity.
|-
| Wider Name Column || Adjust layout to prioritize readability (e.g., wider name column than username).
|}

=== Code Refactor ===
{| class="wikitable"
! Task !! Reason
|-
| Move averaging logic to mixins or model concerns || Improve separation of concerns and reusability.
|-
| Commenting || Add meaningful comments for helper methods and business logic.
|}

== UI/UX Design ==
The new unified view will feature:
* A tabular layout showing all relevant data.
* Sectioned headers for each student.
* Collapsible panels (if needed) for clarity.
* Visual cues for peer review vs. project grades.
* Responsive design for usability across devices.

== Implementation ==

=== Previous View ===

Previously, the Assessment360 Controllers view relied on two separate views i.e. all_students_all_reviews and course_student_grade_summary, to display different aspects of student performance. This is how they looked like before.

[[File:All_students_all_reviews.png|750px]]
[[File:course_student_grade_summary.png|750px]]

=== Current View (after code changes) ===

== Testing Strategy ==

{| class="wikitable"
|-
! Type !! Description !! Tests
|-
| ''' Unit Tests''' || Test individual controller methods || - Test grade calculations - Test data formatting
|-
| ''' Integration Tests''' || Test interactions between components || - Test view rendering - Test database queries - Test caching functionality
|-
| ''' Manual Testing''' || Test UI functionality, performance, and error handling || - Test UI functionality - Test performance with large datasets - Test error scenarios
|}

== Success Criteria ==

The success of this feature implementation will be evaluated based on the following criteria:

{| class="wikitable"
|-
! Criterion !! Description
|-
| '''UI Enhancements Implemented and Working''' || All proposed UI enhancements, including the unified view, column management features, and data presentation improvements, must be fully implemented and functioning as expected. The UI should be intuitive, responsive, and meet the design goals outlined in the document.
|-
| '''Performance Improvements Measurable''' || The feature should demonstrate a measurable improvement in performance, particularly in terms of load times and responsiveness when rendering large datasets or performing grade calculations. Performance benchmarking should indicate a noticeable reduction in latency.
|-
| '''Test Coverage ''' || Comprehensive unit and integration tests must cover more than 80% of the new code and critical paths in the controller. This ensures that the feature is reliable, and potential issues are identified early in the development cycle. Test results should be stable, with no significant failures.
|-
| '''Code Documentation Complete''' || All new and modified code must be thoroughly documented. This includes clear inline comments, explanations for complex logic, and appropriate documentation for new functions, classes, and components. This ensures that future developers can understand and maintain the code efficiently.
|-
| '''No Regression Bugs''' || After implementing the new feature, no existing functionality in the Assessment360 controller should break or behave unexpectedly. Regression testing should show that previously working parts of the system continue to function without issues.
|-
| '''Positive User Feedback''' || End-users (instructors and administrators) must provide positive feedback about the usability and effectiveness of the feature. Feedback should indicate that the feature adds value, improves user experience, and meets the goals outlined in the design document.
|}

== Team Information ==
'''Mentor:''' Mitesh Anil Agarwal

'''Team:'''
* Jap Ashokbhai Purohit - jpurohi@ncsu.edu
* Sharmeen Momin - smomin@ncsu.edu
* Prithish Samanta - psamant2@ncsu.edu

== References ==
* [https://github.com/expertiza/expertiza Expertiza Codebase]
* [https://guides.rubyonrails.org/action_view_overview.html Rails View Helpers]
* [https://github.com/flyerhzm/bullet Bullet Gem Documentation]

CSC/ECE 517 Spring 2025 - E2536. Improve assessment360 controller

2025-04-23T00:11:46Z

Psamant2: /* Previous View */

== Problem Overview ==
The '''Assessment360 Controller''' within the Expertiza platform serves as a key tool for instructors, providing a holistic view of student performance across multiple assessment perspectives. The controller aggregates and displays data from various evaluation components, including teammate reviews, meta-reviews, instructor grades, peer review scores, and assignment submissions. The term <code>Assessment360</code> reflects its purpose of offering a comprehensive, 360-degree evaluation of a student's performance.

Currently, the system relies on two separate views — <code>all_students_all_reviews</code> and <code>course_student_grade_summary</code> — to display different aspects of student performance. These views present:
* Project-level data: The projects a student has worked on and the corresponding grades.
* Peer review data: The scores students receive from their teammates through the teammate review process.

While these views serve important functions, their separation results in a fragmented user experience, as instructors must switch between the views to see a complete set of student performance data. Additionally, the user interface (UI) is not optimized for an intuitive, seamless experience. There are limitations regarding
* The ability to interact with or customize the data display (e.g., column visibility, sorting, and reordering).
* The lack of visual clarity in data presentation (e.g., inconsistent formatting and absence of visual grade indicators).
* Inadequate responsiveness for different device types.

== Objective ==
The primary goal is to enhance the UI/UX and code quality of the <code>assessment360</code> controller. This involves:
* Merging the two existing views (<code>all_students_all_reviews</code> and <code>course_student_grade_summary</code>) into a single unified view.
* Improving the presentation and clarity of data (student grades, peer reviews).
* Refactoring logic for better separation of concerns and maintainability.
* Implementing feedback from the previous team.

== Current Implementation ==

=== Controller Structure ===
The <code>Assessment360Controller</code> is the central controller handling the logic for both the <code>all_students_all_reviews</code> and <code>course_student_grade_summary</code> views. It interacts with various models and services to fetch, process, and deliver the necessary data to the views. The current structure is as follows:
* The controller is responsible for gathering and processing assessment data such as grades, peer reviews, and meta-reviews for each student.
* It includes logic for handling class averages, calculating final grades, and determining peer review averages.
* The current implementation uses direct logic for grade calculations, and all calculations are executed within the controller itself, which could lead to bloated code and reduced maintainability.
* The views are rendered with minimal controller-side logic, relying on the controller to pass the necessary data to the front-end.

=== Current Views ===
The current implementation provides two main views that instructors can use to assess the performance of students. These views are defined in separate HTML ERB files.

==== <code>all_students_all_reviews.html.erb</code> ====
This view displays detailed student performance data in a table format. Key features include:
* Student Information Table: Displays each student’s name, ID, and relevant information.
* Teammate and Meta-Review Scores: For each student, the table shows the scores received from teammates and meta-reviews, which help in assessing peer evaluations.
* Class Averages: For each assignment and review type, class averages are calculated and displayed for instructors to analyze the overall performance of the class.
* Separate Columns for Review Types: Each type of review (<code>teammate</code>, <code>meta-review</code>, etc.) is shown in a separate column, making it easy to compare different assessment categories side by side.

==== <code>course_student_grade_summary.html.erb</code> ====
This view focuses on summarizing the project grades and peer review scores for each student. It includes:
* Student Grades and Peer Review Scores**: Displays the individual project grades and the peer review scores that a student has received.
* Assignment Topics: Lists the assignment topics associated with each project, along with the grades and peer review scores for those specific topics.
* Final Grades and Peer Review Averages: The final grade for each student is calculated by considering both the project grade and peer review scores, and the average peer review score is displayed alongside the final grade.
* Sortable Table Structure: The table in this view is designed to be sortable, allowing instructors to order students by project grades, peer review scores, or any other criterion available in the table. This adds flexibility in how data is analyzed.

== Use Case Diagram ==
For this project our job is to unify the view of the two files, i.e. all_students_all_reviews and course_student_grade_summary, which were created in the previous implementation to one. This would result in a single view which would help in evaluating performances by combining a lot of different perspectives. In our case, if we merge the two files and create a new view, the user should be able to view all the information that is there to be seen in one page. This includes:
* Viewing a Unified Dashboard
* Viewing all the Project Grades
* Viewing Peer Evaluation Scores
* Selecting and Deselecting Columns

Using this information we have created the following Use Case Diagram:

<center>[[File:E2536_Spring_2025.png|600x600px|Improve assessment360]]</center>

== Design Pattern Usage in Assessment360Controller ==

The '''Assessment360Controller''' implements multiple design patterns that improve clarity, modularity, and maintainability of the code.

=== 1. Facade Pattern ===
The controller acts as a facade, hiding complex interactions between various models (''Course'', ''Assignment'', ''Participant'', ''Team'', etc.) and exposing a simplified interface for the view. It aggregates data like grades, reviews, and penalties and prepares it in a structured format, simplifying the presentation layer.

=== 2. Strategy Pattern ===
The use of helper modules such as:
* '''GradesHelper'''
* '''AuthorizationHelper'''
* '''Scoring'''
* '''PenaltyHelper'''

follows the Strategy Pattern. Each module encapsulates a specific piece of functionality, and the controller delegates responsibility to these interchangeable strategies, promoting clean separation of concerns and easier testing.

=== 3. Template Method Pattern ===
The method '''action_allowed?''' is a hook method that overrides a predefined template method in ''ApplicationController''. This allows customized access control behavior while maintaining a consistent interface across all controllers — an example of the Template Method Pattern in action.

=== 4. Separation of Concerns ===
Responsibility is split between:
* '''Controller''': Orchestrates data flow
* '''Models''': Store and retrieve business data
* '''Helpers''': Encapsulate computation and utility logic
* '''Views''': Render formatted output

This adheres to the '''Separation of Concerns''' principle and keeps each layer clean and testable.

These design patterns contribute to the robustness and scalability of the 360-degree assessment feature, allowing future teams to maintain and extend it with ease.

== Planned Enhancements ==

=== Functional Changes ===
{| class="wikitable"
! Feature !! Description
|-
| Unified View || Combine both views into a single HTML page that includes both project grades and review scores.
|-
| Column Selection || Allow users to toggle visible columns using checkboxes.
|-
| Exclude Unreviewed Assignments || Retain the functionality to exclude unreviewed assignments from averages.
|-
| Averages Precision || Limit decimal precision to 2 points for clarity.
|-
| Wider Name Column || Adjust layout to prioritize readability (e.g., wider name column than username).
|}

=== Code Refactor ===
{| class="wikitable"
! Task !! Reason
|-
| Move averaging logic to mixins or model concerns || Improve separation of concerns and reusability.
|-
| Commenting || Add meaningful comments for helper methods and business logic.
|}

== UI/UX Design ==
The new unified view will feature:
* A tabular layout showing all relevant data.
* Sectioned headers for each student.
* Collapsible panels (if needed) for clarity.
* Visual cues for peer review vs. project grades.
* Responsive design for usability across devices.

== Implementation ==

=== Previous View ===

[[File:All_students_all_reviews.png|750px]]
[[File:course_student_grade_summary.png|750px]]

=== Current View (after code changes) ===

== Testing Strategy ==

{| class="wikitable"
|-
! Type !! Description !! Tests
|-
| ''' Unit Tests''' || Test individual controller methods || - Test grade calculations - Test data formatting
|-
| ''' Integration Tests''' || Test interactions between components || - Test view rendering - Test database queries - Test caching functionality
|-
| ''' Manual Testing''' || Test UI functionality, performance, and error handling || - Test UI functionality - Test performance with large datasets - Test error scenarios
|}

== Success Criteria ==

The success of this feature implementation will be evaluated based on the following criteria:

{| class="wikitable"
|-
! Criterion !! Description
|-
| '''UI Enhancements Implemented and Working''' || All proposed UI enhancements, including the unified view, column management features, and data presentation improvements, must be fully implemented and functioning as expected. The UI should be intuitive, responsive, and meet the design goals outlined in the document.
|-
| '''Performance Improvements Measurable''' || The feature should demonstrate a measurable improvement in performance, particularly in terms of load times and responsiveness when rendering large datasets or performing grade calculations. Performance benchmarking should indicate a noticeable reduction in latency.
|-
| '''Test Coverage ''' || Comprehensive unit and integration tests must cover more than 80% of the new code and critical paths in the controller. This ensures that the feature is reliable, and potential issues are identified early in the development cycle. Test results should be stable, with no significant failures.
|-
| '''Code Documentation Complete''' || All new and modified code must be thoroughly documented. This includes clear inline comments, explanations for complex logic, and appropriate documentation for new functions, classes, and components. This ensures that future developers can understand and maintain the code efficiently.
|-
| '''No Regression Bugs''' || After implementing the new feature, no existing functionality in the Assessment360 controller should break or behave unexpectedly. Regression testing should show that previously working parts of the system continue to function without issues.
|-
| '''Positive User Feedback''' || End-users (instructors and administrators) must provide positive feedback about the usability and effectiveness of the feature. Feedback should indicate that the feature adds value, improves user experience, and meets the goals outlined in the design document.
|}

== Team Information ==
'''Mentor:''' Mitesh Anil Agarwal

'''Team:'''
* Jap Ashokbhai Purohit - jpurohi@ncsu.edu
* Sharmeen Momin - smomin@ncsu.edu
* Prithish Samanta - psamant2@ncsu.edu

== References ==
* [https://github.com/expertiza/expertiza Expertiza Codebase]
* [https://guides.rubyonrails.org/action_view_overview.html Rails View Helpers]
* [https://github.com/flyerhzm/bullet Bullet Gem Documentation]

CSC/ECE 517 Spring 2025 - E2536. Improve assessment360 controller

2025-04-23T00:11:25Z

Psamant2: /* Previous View */

== Problem Overview ==
The '''Assessment360 Controller''' within the Expertiza platform serves as a key tool for instructors, providing a holistic view of student performance across multiple assessment perspectives. The controller aggregates and displays data from various evaluation components, including teammate reviews, meta-reviews, instructor grades, peer review scores, and assignment submissions. The term <code>Assessment360</code> reflects its purpose of offering a comprehensive, 360-degree evaluation of a student's performance.

Currently, the system relies on two separate views — <code>all_students_all_reviews</code> and <code>course_student_grade_summary</code> — to display different aspects of student performance. These views present:
* Project-level data: The projects a student has worked on and the corresponding grades.
* Peer review data: The scores students receive from their teammates through the teammate review process.

While these views serve important functions, their separation results in a fragmented user experience, as instructors must switch between the views to see a complete set of student performance data. Additionally, the user interface (UI) is not optimized for an intuitive, seamless experience. There are limitations regarding
* The ability to interact with or customize the data display (e.g., column visibility, sorting, and reordering).
* The lack of visual clarity in data presentation (e.g., inconsistent formatting and absence of visual grade indicators).
* Inadequate responsiveness for different device types.

== Objective ==
The primary goal is to enhance the UI/UX and code quality of the <code>assessment360</code> controller. This involves:
* Merging the two existing views (<code>all_students_all_reviews</code> and <code>course_student_grade_summary</code>) into a single unified view.
* Improving the presentation and clarity of data (student grades, peer reviews).
* Refactoring logic for better separation of concerns and maintainability.
* Implementing feedback from the previous team.

== Current Implementation ==

=== Controller Structure ===
The <code>Assessment360Controller</code> is the central controller handling the logic for both the <code>all_students_all_reviews</code> and <code>course_student_grade_summary</code> views. It interacts with various models and services to fetch, process, and deliver the necessary data to the views. The current structure is as follows:
* The controller is responsible for gathering and processing assessment data such as grades, peer reviews, and meta-reviews for each student.
* It includes logic for handling class averages, calculating final grades, and determining peer review averages.
* The current implementation uses direct logic for grade calculations, and all calculations are executed within the controller itself, which could lead to bloated code and reduced maintainability.
* The views are rendered with minimal controller-side logic, relying on the controller to pass the necessary data to the front-end.

=== Current Views ===
The current implementation provides two main views that instructors can use to assess the performance of students. These views are defined in separate HTML ERB files.

==== <code>all_students_all_reviews.html.erb</code> ====
This view displays detailed student performance data in a table format. Key features include:
* Student Information Table: Displays each student’s name, ID, and relevant information.
* Teammate and Meta-Review Scores: For each student, the table shows the scores received from teammates and meta-reviews, which help in assessing peer evaluations.
* Class Averages: For each assignment and review type, class averages are calculated and displayed for instructors to analyze the overall performance of the class.
* Separate Columns for Review Types: Each type of review (<code>teammate</code>, <code>meta-review</code>, etc.) is shown in a separate column, making it easy to compare different assessment categories side by side.

==== <code>course_student_grade_summary.html.erb</code> ====
This view focuses on summarizing the project grades and peer review scores for each student. It includes:
* Student Grades and Peer Review Scores**: Displays the individual project grades and the peer review scores that a student has received.
* Assignment Topics: Lists the assignment topics associated with each project, along with the grades and peer review scores for those specific topics.
* Final Grades and Peer Review Averages: The final grade for each student is calculated by considering both the project grade and peer review scores, and the average peer review score is displayed alongside the final grade.
* Sortable Table Structure: The table in this view is designed to be sortable, allowing instructors to order students by project grades, peer review scores, or any other criterion available in the table. This adds flexibility in how data is analyzed.

== Use Case Diagram ==
For this project our job is to unify the view of the two files, i.e. all_students_all_reviews and course_student_grade_summary, which were created in the previous implementation to one. This would result in a single view which would help in evaluating performances by combining a lot of different perspectives. In our case, if we merge the two files and create a new view, the user should be able to view all the information that is there to be seen in one page. This includes:
* Viewing a Unified Dashboard
* Viewing all the Project Grades
* Viewing Peer Evaluation Scores
* Selecting and Deselecting Columns

Using this information we have created the following Use Case Diagram:

<center>[[File:E2536_Spring_2025.png|600x600px|Improve assessment360]]</center>

== Design Pattern Usage in Assessment360Controller ==

The '''Assessment360Controller''' implements multiple design patterns that improve clarity, modularity, and maintainability of the code.

=== 1. Facade Pattern ===
The controller acts as a facade, hiding complex interactions between various models (''Course'', ''Assignment'', ''Participant'', ''Team'', etc.) and exposing a simplified interface for the view. It aggregates data like grades, reviews, and penalties and prepares it in a structured format, simplifying the presentation layer.

=== 2. Strategy Pattern ===
The use of helper modules such as:
* '''GradesHelper'''
* '''AuthorizationHelper'''
* '''Scoring'''
* '''PenaltyHelper'''

follows the Strategy Pattern. Each module encapsulates a specific piece of functionality, and the controller delegates responsibility to these interchangeable strategies, promoting clean separation of concerns and easier testing.

=== 3. Template Method Pattern ===
The method '''action_allowed?''' is a hook method that overrides a predefined template method in ''ApplicationController''. This allows customized access control behavior while maintaining a consistent interface across all controllers — an example of the Template Method Pattern in action.

=== 4. Separation of Concerns ===
Responsibility is split between:
* '''Controller''': Orchestrates data flow
* '''Models''': Store and retrieve business data
* '''Helpers''': Encapsulate computation and utility logic
* '''Views''': Render formatted output

This adheres to the '''Separation of Concerns''' principle and keeps each layer clean and testable.

These design patterns contribute to the robustness and scalability of the 360-degree assessment feature, allowing future teams to maintain and extend it with ease.

== Planned Enhancements ==

=== Functional Changes ===
{| class="wikitable"
! Feature !! Description
|-
| Unified View || Combine both views into a single HTML page that includes both project grades and review scores.
|-
| Column Selection || Allow users to toggle visible columns using checkboxes.
|-
| Exclude Unreviewed Assignments || Retain the functionality to exclude unreviewed assignments from averages.
|-
| Averages Precision || Limit decimal precision to 2 points for clarity.
|-
| Wider Name Column || Adjust layout to prioritize readability (e.g., wider name column than username).
|}

=== Code Refactor ===
{| class="wikitable"
! Task !! Reason
|-
| Move averaging logic to mixins or model concerns || Improve separation of concerns and reusability.
|-
| Commenting || Add meaningful comments for helper methods and business logic.
|}

== UI/UX Design ==
The new unified view will feature:
* A tabular layout showing all relevant data.
* Sectioned headers for each student.
* Collapsible panels (if needed) for clarity.
* Visual cues for peer review vs. project grades.
* Responsive design for usability across devices.

== Implementation ==

=== Previous View ===

[[File:All_students_all_reviews.png|650px]]
[[File:course_student_grade_summary.png|650px]]

=== Current View (after code changes) ===

== Testing Strategy ==

{| class="wikitable"
|-
! Type !! Description !! Tests
|-
| ''' Unit Tests''' || Test individual controller methods || - Test grade calculations - Test data formatting
|-
| ''' Integration Tests''' || Test interactions between components || - Test view rendering - Test database queries - Test caching functionality
|-
| ''' Manual Testing''' || Test UI functionality, performance, and error handling || - Test UI functionality - Test performance with large datasets - Test error scenarios
|}

== Success Criteria ==

The success of this feature implementation will be evaluated based on the following criteria:

{| class="wikitable"
|-
! Criterion !! Description
|-
| '''UI Enhancements Implemented and Working''' || All proposed UI enhancements, including the unified view, column management features, and data presentation improvements, must be fully implemented and functioning as expected. The UI should be intuitive, responsive, and meet the design goals outlined in the document.
|-
| '''Performance Improvements Measurable''' || The feature should demonstrate a measurable improvement in performance, particularly in terms of load times and responsiveness when rendering large datasets or performing grade calculations. Performance benchmarking should indicate a noticeable reduction in latency.
|-
| '''Test Coverage ''' || Comprehensive unit and integration tests must cover more than 80% of the new code and critical paths in the controller. This ensures that the feature is reliable, and potential issues are identified early in the development cycle. Test results should be stable, with no significant failures.
|-
| '''Code Documentation Complete''' || All new and modified code must be thoroughly documented. This includes clear inline comments, explanations for complex logic, and appropriate documentation for new functions, classes, and components. This ensures that future developers can understand and maintain the code efficiently.
|-
| '''No Regression Bugs''' || After implementing the new feature, no existing functionality in the Assessment360 controller should break or behave unexpectedly. Regression testing should show that previously working parts of the system continue to function without issues.
|-
| '''Positive User Feedback''' || End-users (instructors and administrators) must provide positive feedback about the usability and effectiveness of the feature. Feedback should indicate that the feature adds value, improves user experience, and meets the goals outlined in the design document.
|}

== Team Information ==
'''Mentor:''' Mitesh Anil Agarwal

'''Team:'''
* Jap Ashokbhai Purohit - jpurohi@ncsu.edu
* Sharmeen Momin - smomin@ncsu.edu
* Prithish Samanta - psamant2@ncsu.edu

== References ==
* [https://github.com/expertiza/expertiza Expertiza Codebase]
* [https://guides.rubyonrails.org/action_view_overview.html Rails View Helpers]
* [https://github.com/flyerhzm/bullet Bullet Gem Documentation]

File:Course student grade summary.png

2025-04-23T00:10:45Z

Psamant2:

CSC/ECE 517 Spring 2025 - E2536. Improve assessment360 controller

2025-04-23T00:10:01Z

Psamant2: /* Previous View */

== Problem Overview ==
The '''Assessment360 Controller''' within the Expertiza platform serves as a key tool for instructors, providing a holistic view of student performance across multiple assessment perspectives. The controller aggregates and displays data from various evaluation components, including teammate reviews, meta-reviews, instructor grades, peer review scores, and assignment submissions. The term <code>Assessment360</code> reflects its purpose of offering a comprehensive, 360-degree evaluation of a student's performance.

Currently, the system relies on two separate views — <code>all_students_all_reviews</code> and <code>course_student_grade_summary</code> — to display different aspects of student performance. These views present:
* Project-level data: The projects a student has worked on and the corresponding grades.
* Peer review data: The scores students receive from their teammates through the teammate review process.

While these views serve important functions, their separation results in a fragmented user experience, as instructors must switch between the views to see a complete set of student performance data. Additionally, the user interface (UI) is not optimized for an intuitive, seamless experience. There are limitations regarding
* The ability to interact with or customize the data display (e.g., column visibility, sorting, and reordering).
* The lack of visual clarity in data presentation (e.g., inconsistent formatting and absence of visual grade indicators).
* Inadequate responsiveness for different device types.

== Objective ==
The primary goal is to enhance the UI/UX and code quality of the <code>assessment360</code> controller. This involves:
* Merging the two existing views (<code>all_students_all_reviews</code> and <code>course_student_grade_summary</code>) into a single unified view.
* Improving the presentation and clarity of data (student grades, peer reviews).
* Refactoring logic for better separation of concerns and maintainability.
* Implementing feedback from the previous team.

== Current Implementation ==

=== Controller Structure ===
The <code>Assessment360Controller</code> is the central controller handling the logic for both the <code>all_students_all_reviews</code> and <code>course_student_grade_summary</code> views. It interacts with various models and services to fetch, process, and deliver the necessary data to the views. The current structure is as follows:
* The controller is responsible for gathering and processing assessment data such as grades, peer reviews, and meta-reviews for each student.
* It includes logic for handling class averages, calculating final grades, and determining peer review averages.
* The current implementation uses direct logic for grade calculations, and all calculations are executed within the controller itself, which could lead to bloated code and reduced maintainability.
* The views are rendered with minimal controller-side logic, relying on the controller to pass the necessary data to the front-end.

=== Current Views ===
The current implementation provides two main views that instructors can use to assess the performance of students. These views are defined in separate HTML ERB files.

==== <code>all_students_all_reviews.html.erb</code> ====
This view displays detailed student performance data in a table format. Key features include:
* Student Information Table: Displays each student’s name, ID, and relevant information.
* Teammate and Meta-Review Scores: For each student, the table shows the scores received from teammates and meta-reviews, which help in assessing peer evaluations.
* Class Averages: For each assignment and review type, class averages are calculated and displayed for instructors to analyze the overall performance of the class.
* Separate Columns for Review Types: Each type of review (<code>teammate</code>, <code>meta-review</code>, etc.) is shown in a separate column, making it easy to compare different assessment categories side by side.

==== <code>course_student_grade_summary.html.erb</code> ====
This view focuses on summarizing the project grades and peer review scores for each student. It includes:
* Student Grades and Peer Review Scores**: Displays the individual project grades and the peer review scores that a student has received.
* Assignment Topics: Lists the assignment topics associated with each project, along with the grades and peer review scores for those specific topics.
* Final Grades and Peer Review Averages: The final grade for each student is calculated by considering both the project grade and peer review scores, and the average peer review score is displayed alongside the final grade.
* Sortable Table Structure: The table in this view is designed to be sortable, allowing instructors to order students by project grades, peer review scores, or any other criterion available in the table. This adds flexibility in how data is analyzed.

== Use Case Diagram ==
For this project our job is to unify the view of the two files, i.e. all_students_all_reviews and course_student_grade_summary, which were created in the previous implementation to one. This would result in a single view which would help in evaluating performances by combining a lot of different perspectives. In our case, if we merge the two files and create a new view, the user should be able to view all the information that is there to be seen in one page. This includes:
* Viewing a Unified Dashboard
* Viewing all the Project Grades
* Viewing Peer Evaluation Scores
* Selecting and Deselecting Columns

Using this information we have created the following Use Case Diagram:

<center>[[File:E2536_Spring_2025.png|600x600px|Improve assessment360]]</center>

== Design Pattern Usage in Assessment360Controller ==

The '''Assessment360Controller''' implements multiple design patterns that improve clarity, modularity, and maintainability of the code.

=== 1. Facade Pattern ===
The controller acts as a facade, hiding complex interactions between various models (''Course'', ''Assignment'', ''Participant'', ''Team'', etc.) and exposing a simplified interface for the view. It aggregates data like grades, reviews, and penalties and prepares it in a structured format, simplifying the presentation layer.

=== 2. Strategy Pattern ===
The use of helper modules such as:
* '''GradesHelper'''
* '''AuthorizationHelper'''
* '''Scoring'''
* '''PenaltyHelper'''

follows the Strategy Pattern. Each module encapsulates a specific piece of functionality, and the controller delegates responsibility to these interchangeable strategies, promoting clean separation of concerns and easier testing.

=== 3. Template Method Pattern ===
The method '''action_allowed?''' is a hook method that overrides a predefined template method in ''ApplicationController''. This allows customized access control behavior while maintaining a consistent interface across all controllers — an example of the Template Method Pattern in action.

=== 4. Separation of Concerns ===
Responsibility is split between:
* '''Controller''': Orchestrates data flow
* '''Models''': Store and retrieve business data
* '''Helpers''': Encapsulate computation and utility logic
* '''Views''': Render formatted output

This adheres to the '''Separation of Concerns''' principle and keeps each layer clean and testable.

These design patterns contribute to the robustness and scalability of the 360-degree assessment feature, allowing future teams to maintain and extend it with ease.

== Planned Enhancements ==

=== Functional Changes ===
{| class="wikitable"
! Feature !! Description
|-
| Unified View || Combine both views into a single HTML page that includes both project grades and review scores.
|-
| Column Selection || Allow users to toggle visible columns using checkboxes.
|-
| Exclude Unreviewed Assignments || Retain the functionality to exclude unreviewed assignments from averages.
|-
| Averages Precision || Limit decimal precision to 2 points for clarity.
|-
| Wider Name Column || Adjust layout to prioritize readability (e.g., wider name column than username).
|}

=== Code Refactor ===
{| class="wikitable"
! Task !! Reason
|-
| Move averaging logic to mixins or model concerns || Improve separation of concerns and reusability.
|-
| Commenting || Add meaningful comments for helper methods and business logic.
|}

== UI/UX Design ==
The new unified view will feature:
* A tabular layout showing all relevant data.
* Sectioned headers for each student.
* Collapsible panels (if needed) for clarity.
* Visual cues for peer review vs. project grades.
* Responsive design for usability across devices.

== Implementation ==

=== Previous View ===

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

=== Current View (after code changes) ===

== Testing Strategy ==

{| class="wikitable"
|-
! Type !! Description !! Tests
|-
| ''' Unit Tests''' || Test individual controller methods || - Test grade calculations - Test data formatting
|-
| ''' Integration Tests''' || Test interactions between components || - Test view rendering - Test database queries - Test caching functionality
|-
| ''' Manual Testing''' || Test UI functionality, performance, and error handling || - Test UI functionality - Test performance with large datasets - Test error scenarios
|}

== Success Criteria ==

The success of this feature implementation will be evaluated based on the following criteria:

{| class="wikitable"
|-
! Criterion !! Description
|-
| '''UI Enhancements Implemented and Working''' || All proposed UI enhancements, including the unified view, column management features, and data presentation improvements, must be fully implemented and functioning as expected. The UI should be intuitive, responsive, and meet the design goals outlined in the document.
|-
| '''Performance Improvements Measurable''' || The feature should demonstrate a measurable improvement in performance, particularly in terms of load times and responsiveness when rendering large datasets or performing grade calculations. Performance benchmarking should indicate a noticeable reduction in latency.
|-
| '''Test Coverage ''' || Comprehensive unit and integration tests must cover more than 80% of the new code and critical paths in the controller. This ensures that the feature is reliable, and potential issues are identified early in the development cycle. Test results should be stable, with no significant failures.
|-
| '''Code Documentation Complete''' || All new and modified code must be thoroughly documented. This includes clear inline comments, explanations for complex logic, and appropriate documentation for new functions, classes, and components. This ensures that future developers can understand and maintain the code efficiently.
|-
| '''No Regression Bugs''' || After implementing the new feature, no existing functionality in the Assessment360 controller should break or behave unexpectedly. Regression testing should show that previously working parts of the system continue to function without issues.
|-
| '''Positive User Feedback''' || End-users (instructors and administrators) must provide positive feedback about the usability and effectiveness of the feature. Feedback should indicate that the feature adds value, improves user experience, and meets the goals outlined in the design document.
|}

== Team Information ==
'''Mentor:''' Mitesh Anil Agarwal

'''Team:'''
* Jap Ashokbhai Purohit - jpurohi@ncsu.edu
* Sharmeen Momin - smomin@ncsu.edu
* Prithish Samanta - psamant2@ncsu.edu

== References ==
* [https://github.com/expertiza/expertiza Expertiza Codebase]
* [https://guides.rubyonrails.org/action_view_overview.html Rails View Helpers]
* [https://github.com/flyerhzm/bullet Bullet Gem Documentation]

CSC/ECE 517 Spring 2025 - E2536. Improve assessment360 controller

2025-04-23T00:09:40Z

Psamant2: /* Previous View */

== Problem Overview ==
The '''Assessment360 Controller''' within the Expertiza platform serves as a key tool for instructors, providing a holistic view of student performance across multiple assessment perspectives. The controller aggregates and displays data from various evaluation components, including teammate reviews, meta-reviews, instructor grades, peer review scores, and assignment submissions. The term <code>Assessment360</code> reflects its purpose of offering a comprehensive, 360-degree evaluation of a student's performance.

Currently, the system relies on two separate views — <code>all_students_all_reviews</code> and <code>course_student_grade_summary</code> — to display different aspects of student performance. These views present:
* Project-level data: The projects a student has worked on and the corresponding grades.
* Peer review data: The scores students receive from their teammates through the teammate review process.

While these views serve important functions, their separation results in a fragmented user experience, as instructors must switch between the views to see a complete set of student performance data. Additionally, the user interface (UI) is not optimized for an intuitive, seamless experience. There are limitations regarding
* The ability to interact with or customize the data display (e.g., column visibility, sorting, and reordering).
* The lack of visual clarity in data presentation (e.g., inconsistent formatting and absence of visual grade indicators).
* Inadequate responsiveness for different device types.

== Objective ==
The primary goal is to enhance the UI/UX and code quality of the <code>assessment360</code> controller. This involves:
* Merging the two existing views (<code>all_students_all_reviews</code> and <code>course_student_grade_summary</code>) into a single unified view.
* Improving the presentation and clarity of data (student grades, peer reviews).
* Refactoring logic for better separation of concerns and maintainability.
* Implementing feedback from the previous team.

== Current Implementation ==

=== Controller Structure ===
The <code>Assessment360Controller</code> is the central controller handling the logic for both the <code>all_students_all_reviews</code> and <code>course_student_grade_summary</code> views. It interacts with various models and services to fetch, process, and deliver the necessary data to the views. The current structure is as follows:
* The controller is responsible for gathering and processing assessment data such as grades, peer reviews, and meta-reviews for each student.
* It includes logic for handling class averages, calculating final grades, and determining peer review averages.
* The current implementation uses direct logic for grade calculations, and all calculations are executed within the controller itself, which could lead to bloated code and reduced maintainability.
* The views are rendered with minimal controller-side logic, relying on the controller to pass the necessary data to the front-end.

=== Current Views ===
The current implementation provides two main views that instructors can use to assess the performance of students. These views are defined in separate HTML ERB files.

==== <code>all_students_all_reviews.html.erb</code> ====
This view displays detailed student performance data in a table format. Key features include:
* Student Information Table: Displays each student’s name, ID, and relevant information.
* Teammate and Meta-Review Scores: For each student, the table shows the scores received from teammates and meta-reviews, which help in assessing peer evaluations.
* Class Averages: For each assignment and review type, class averages are calculated and displayed for instructors to analyze the overall performance of the class.
* Separate Columns for Review Types: Each type of review (<code>teammate</code>, <code>meta-review</code>, etc.) is shown in a separate column, making it easy to compare different assessment categories side by side.

==== <code>course_student_grade_summary.html.erb</code> ====
This view focuses on summarizing the project grades and peer review scores for each student. It includes:
* Student Grades and Peer Review Scores**: Displays the individual project grades and the peer review scores that a student has received.
* Assignment Topics: Lists the assignment topics associated with each project, along with the grades and peer review scores for those specific topics.
* Final Grades and Peer Review Averages: The final grade for each student is calculated by considering both the project grade and peer review scores, and the average peer review score is displayed alongside the final grade.
* Sortable Table Structure: The table in this view is designed to be sortable, allowing instructors to order students by project grades, peer review scores, or any other criterion available in the table. This adds flexibility in how data is analyzed.

== Use Case Diagram ==
For this project our job is to unify the view of the two files, i.e. all_students_all_reviews and course_student_grade_summary, which were created in the previous implementation to one. This would result in a single view which would help in evaluating performances by combining a lot of different perspectives. In our case, if we merge the two files and create a new view, the user should be able to view all the information that is there to be seen in one page. This includes:
* Viewing a Unified Dashboard
* Viewing all the Project Grades
* Viewing Peer Evaluation Scores
* Selecting and Deselecting Columns

Using this information we have created the following Use Case Diagram:

<center>[[File:E2536_Spring_2025.png|600x600px|Improve assessment360]]</center>

== Design Pattern Usage in Assessment360Controller ==

The '''Assessment360Controller''' implements multiple design patterns that improve clarity, modularity, and maintainability of the code.

=== 1. Facade Pattern ===
The controller acts as a facade, hiding complex interactions between various models (''Course'', ''Assignment'', ''Participant'', ''Team'', etc.) and exposing a simplified interface for the view. It aggregates data like grades, reviews, and penalties and prepares it in a structured format, simplifying the presentation layer.

=== 2. Strategy Pattern ===
The use of helper modules such as:
* '''GradesHelper'''
* '''AuthorizationHelper'''
* '''Scoring'''
* '''PenaltyHelper'''

follows the Strategy Pattern. Each module encapsulates a specific piece of functionality, and the controller delegates responsibility to these interchangeable strategies, promoting clean separation of concerns and easier testing.

=== 3. Template Method Pattern ===
The method '''action_allowed?''' is a hook method that overrides a predefined template method in ''ApplicationController''. This allows customized access control behavior while maintaining a consistent interface across all controllers — an example of the Template Method Pattern in action.

=== 4. Separation of Concerns ===
Responsibility is split between:
* '''Controller''': Orchestrates data flow
* '''Models''': Store and retrieve business data
* '''Helpers''': Encapsulate computation and utility logic
* '''Views''': Render formatted output

This adheres to the '''Separation of Concerns''' principle and keeps each layer clean and testable.

These design patterns contribute to the robustness and scalability of the 360-degree assessment feature, allowing future teams to maintain and extend it with ease.

== Planned Enhancements ==

=== Functional Changes ===
{| class="wikitable"
! Feature !! Description
|-
| Unified View || Combine both views into a single HTML page that includes both project grades and review scores.
|-
| Column Selection || Allow users to toggle visible columns using checkboxes.
|-
| Exclude Unreviewed Assignments || Retain the functionality to exclude unreviewed assignments from averages.
|-
| Averages Precision || Limit decimal precision to 2 points for clarity.
|-
| Wider Name Column || Adjust layout to prioritize readability (e.g., wider name column than username).
|}

=== Code Refactor ===
{| class="wikitable"
! Task !! Reason
|-
| Move averaging logic to mixins or model concerns || Improve separation of concerns and reusability.
|-
| Commenting || Add meaningful comments for helper methods and business logic.
|}

== UI/UX Design ==
The new unified view will feature:
* A tabular layout showing all relevant data.
* Sectioned headers for each student.
* Collapsible panels (if needed) for clarity.
* Visual cues for peer review vs. project grades.
* Responsive design for usability across devices.

== Implementation ==

=== Previous View ===

[[File:All_students_all_reviews.png|200px|thumb|left|Caption]]

=== Current View (after code changes) ===

== Testing Strategy ==

{| class="wikitable"
|-
! Type !! Description !! Tests
|-
| ''' Unit Tests''' || Test individual controller methods || - Test grade calculations - Test data formatting
|-
| ''' Integration Tests''' || Test interactions between components || - Test view rendering - Test database queries - Test caching functionality
|-
| ''' Manual Testing''' || Test UI functionality, performance, and error handling || - Test UI functionality - Test performance with large datasets - Test error scenarios
|}

== Success Criteria ==

The success of this feature implementation will be evaluated based on the following criteria:

{| class="wikitable"
|-
! Criterion !! Description
|-
| '''UI Enhancements Implemented and Working''' || All proposed UI enhancements, including the unified view, column management features, and data presentation improvements, must be fully implemented and functioning as expected. The UI should be intuitive, responsive, and meet the design goals outlined in the document.
|-
| '''Performance Improvements Measurable''' || The feature should demonstrate a measurable improvement in performance, particularly in terms of load times and responsiveness when rendering large datasets or performing grade calculations. Performance benchmarking should indicate a noticeable reduction in latency.
|-
| '''Test Coverage ''' || Comprehensive unit and integration tests must cover more than 80% of the new code and critical paths in the controller. This ensures that the feature is reliable, and potential issues are identified early in the development cycle. Test results should be stable, with no significant failures.
|-
| '''Code Documentation Complete''' || All new and modified code must be thoroughly documented. This includes clear inline comments, explanations for complex logic, and appropriate documentation for new functions, classes, and components. This ensures that future developers can understand and maintain the code efficiently.
|-
| '''No Regression Bugs''' || After implementing the new feature, no existing functionality in the Assessment360 controller should break or behave unexpectedly. Regression testing should show that previously working parts of the system continue to function without issues.
|-
| '''Positive User Feedback''' || End-users (instructors and administrators) must provide positive feedback about the usability and effectiveness of the feature. Feedback should indicate that the feature adds value, improves user experience, and meets the goals outlined in the design document.
|}

== Team Information ==
'''Mentor:''' Mitesh Anil Agarwal

'''Team:'''
* Jap Ashokbhai Purohit - jpurohi@ncsu.edu
* Sharmeen Momin - smomin@ncsu.edu
* Prithish Samanta - psamant2@ncsu.edu

== References ==
* [https://github.com/expertiza/expertiza Expertiza Codebase]
* [https://guides.rubyonrails.org/action_view_overview.html Rails View Helpers]
* [https://github.com/flyerhzm/bullet Bullet Gem Documentation]

CSC/ECE 517 Spring 2025 - E2536. Improve assessment360 controller

2025-04-23T00:09:02Z

Psamant2: /* Previous View */

== Problem Overview ==
The '''Assessment360 Controller''' within the Expertiza platform serves as a key tool for instructors, providing a holistic view of student performance across multiple assessment perspectives. The controller aggregates and displays data from various evaluation components, including teammate reviews, meta-reviews, instructor grades, peer review scores, and assignment submissions. The term <code>Assessment360</code> reflects its purpose of offering a comprehensive, 360-degree evaluation of a student's performance.

Currently, the system relies on two separate views — <code>all_students_all_reviews</code> and <code>course_student_grade_summary</code> — to display different aspects of student performance. These views present:
* Project-level data: The projects a student has worked on and the corresponding grades.
* Peer review data: The scores students receive from their teammates through the teammate review process.

While these views serve important functions, their separation results in a fragmented user experience, as instructors must switch between the views to see a complete set of student performance data. Additionally, the user interface (UI) is not optimized for an intuitive, seamless experience. There are limitations regarding
* The ability to interact with or customize the data display (e.g., column visibility, sorting, and reordering).
* The lack of visual clarity in data presentation (e.g., inconsistent formatting and absence of visual grade indicators).
* Inadequate responsiveness for different device types.

== Objective ==
The primary goal is to enhance the UI/UX and code quality of the <code>assessment360</code> controller. This involves:
* Merging the two existing views (<code>all_students_all_reviews</code> and <code>course_student_grade_summary</code>) into a single unified view.
* Improving the presentation and clarity of data (student grades, peer reviews).
* Refactoring logic for better separation of concerns and maintainability.
* Implementing feedback from the previous team.

== Current Implementation ==

=== Controller Structure ===
The <code>Assessment360Controller</code> is the central controller handling the logic for both the <code>all_students_all_reviews</code> and <code>course_student_grade_summary</code> views. It interacts with various models and services to fetch, process, and deliver the necessary data to the views. The current structure is as follows:
* The controller is responsible for gathering and processing assessment data such as grades, peer reviews, and meta-reviews for each student.
* It includes logic for handling class averages, calculating final grades, and determining peer review averages.
* The current implementation uses direct logic for grade calculations, and all calculations are executed within the controller itself, which could lead to bloated code and reduced maintainability.
* The views are rendered with minimal controller-side logic, relying on the controller to pass the necessary data to the front-end.

=== Current Views ===
The current implementation provides two main views that instructors can use to assess the performance of students. These views are defined in separate HTML ERB files.

==== <code>all_students_all_reviews.html.erb</code> ====
This view displays detailed student performance data in a table format. Key features include:
* Student Information Table: Displays each student’s name, ID, and relevant information.
* Teammate and Meta-Review Scores: For each student, the table shows the scores received from teammates and meta-reviews, which help in assessing peer evaluations.
* Class Averages: For each assignment and review type, class averages are calculated and displayed for instructors to analyze the overall performance of the class.
* Separate Columns for Review Types: Each type of review (<code>teammate</code>, <code>meta-review</code>, etc.) is shown in a separate column, making it easy to compare different assessment categories side by side.

==== <code>course_student_grade_summary.html.erb</code> ====
This view focuses on summarizing the project grades and peer review scores for each student. It includes:
* Student Grades and Peer Review Scores**: Displays the individual project grades and the peer review scores that a student has received.
* Assignment Topics: Lists the assignment topics associated with each project, along with the grades and peer review scores for those specific topics.
* Final Grades and Peer Review Averages: The final grade for each student is calculated by considering both the project grade and peer review scores, and the average peer review score is displayed alongside the final grade.
* Sortable Table Structure: The table in this view is designed to be sortable, allowing instructors to order students by project grades, peer review scores, or any other criterion available in the table. This adds flexibility in how data is analyzed.

== Use Case Diagram ==
For this project our job is to unify the view of the two files, i.e. all_students_all_reviews and course_student_grade_summary, which were created in the previous implementation to one. This would result in a single view which would help in evaluating performances by combining a lot of different perspectives. In our case, if we merge the two files and create a new view, the user should be able to view all the information that is there to be seen in one page. This includes:
* Viewing a Unified Dashboard
* Viewing all the Project Grades
* Viewing Peer Evaluation Scores
* Selecting and Deselecting Columns

Using this information we have created the following Use Case Diagram:

<center>[[File:E2536_Spring_2025.png|600x600px|Improve assessment360]]</center>

== Design Pattern Usage in Assessment360Controller ==

The '''Assessment360Controller''' implements multiple design patterns that improve clarity, modularity, and maintainability of the code.

=== 1. Facade Pattern ===
The controller acts as a facade, hiding complex interactions between various models (''Course'', ''Assignment'', ''Participant'', ''Team'', etc.) and exposing a simplified interface for the view. It aggregates data like grades, reviews, and penalties and prepares it in a structured format, simplifying the presentation layer.

=== 2. Strategy Pattern ===
The use of helper modules such as:
* '''GradesHelper'''
* '''AuthorizationHelper'''
* '''Scoring'''
* '''PenaltyHelper'''

follows the Strategy Pattern. Each module encapsulates a specific piece of functionality, and the controller delegates responsibility to these interchangeable strategies, promoting clean separation of concerns and easier testing.

=== 3. Template Method Pattern ===
The method '''action_allowed?''' is a hook method that overrides a predefined template method in ''ApplicationController''. This allows customized access control behavior while maintaining a consistent interface across all controllers — an example of the Template Method Pattern in action.

=== 4. Separation of Concerns ===
Responsibility is split between:
* '''Controller''': Orchestrates data flow
* '''Models''': Store and retrieve business data
* '''Helpers''': Encapsulate computation and utility logic
* '''Views''': Render formatted output

This adheres to the '''Separation of Concerns''' principle and keeps each layer clean and testable.

These design patterns contribute to the robustness and scalability of the 360-degree assessment feature, allowing future teams to maintain and extend it with ease.

== Planned Enhancements ==

=== Functional Changes ===
{| class="wikitable"
! Feature !! Description
|-
| Unified View || Combine both views into a single HTML page that includes both project grades and review scores.
|-
| Column Selection || Allow users to toggle visible columns using checkboxes.
|-
| Exclude Unreviewed Assignments || Retain the functionality to exclude unreviewed assignments from averages.
|-
| Averages Precision || Limit decimal precision to 2 points for clarity.
|-
| Wider Name Column || Adjust layout to prioritize readability (e.g., wider name column than username).
|}

=== Code Refactor ===
{| class="wikitable"
! Task !! Reason
|-
| Move averaging logic to mixins or model concerns || Improve separation of concerns and reusability.
|-
| Commenting || Add meaningful comments for helper methods and business logic.
|}

== UI/UX Design ==
The new unified view will feature:
* A tabular layout showing all relevant data.
* Sectioned headers for each student.
* Collapsible panels (if needed) for clarity.
* Visual cues for peer review vs. project grades.
* Responsive design for usability across devices.

== Implementation ==

=== Previous View ===

[[File:All_students_all_reviews.png]]

=== Current View (after code changes) ===

== Testing Strategy ==

{| class="wikitable"
|-
! Type !! Description !! Tests
|-
| ''' Unit Tests''' || Test individual controller methods || - Test grade calculations - Test data formatting
|-
| ''' Integration Tests''' || Test interactions between components || - Test view rendering - Test database queries - Test caching functionality
|-
| ''' Manual Testing''' || Test UI functionality, performance, and error handling || - Test UI functionality - Test performance with large datasets - Test error scenarios
|}

== Success Criteria ==

The success of this feature implementation will be evaluated based on the following criteria:

{| class="wikitable"
|-
! Criterion !! Description
|-
| '''UI Enhancements Implemented and Working''' || All proposed UI enhancements, including the unified view, column management features, and data presentation improvements, must be fully implemented and functioning as expected. The UI should be intuitive, responsive, and meet the design goals outlined in the document.
|-
| '''Performance Improvements Measurable''' || The feature should demonstrate a measurable improvement in performance, particularly in terms of load times and responsiveness when rendering large datasets or performing grade calculations. Performance benchmarking should indicate a noticeable reduction in latency.
|-
| '''Test Coverage ''' || Comprehensive unit and integration tests must cover more than 80% of the new code and critical paths in the controller. This ensures that the feature is reliable, and potential issues are identified early in the development cycle. Test results should be stable, with no significant failures.
|-
| '''Code Documentation Complete''' || All new and modified code must be thoroughly documented. This includes clear inline comments, explanations for complex logic, and appropriate documentation for new functions, classes, and components. This ensures that future developers can understand and maintain the code efficiently.
|-
| '''No Regression Bugs''' || After implementing the new feature, no existing functionality in the Assessment360 controller should break or behave unexpectedly. Regression testing should show that previously working parts of the system continue to function without issues.
|-
| '''Positive User Feedback''' || End-users (instructors and administrators) must provide positive feedback about the usability and effectiveness of the feature. Feedback should indicate that the feature adds value, improves user experience, and meets the goals outlined in the design document.
|}

== Team Information ==
'''Mentor:''' Mitesh Anil Agarwal

'''Team:'''
* Jap Ashokbhai Purohit - jpurohi@ncsu.edu
* Sharmeen Momin - smomin@ncsu.edu
* Prithish Samanta - psamant2@ncsu.edu

== References ==
* [https://github.com/expertiza/expertiza Expertiza Codebase]
* [https://guides.rubyonrails.org/action_view_overview.html Rails View Helpers]
* [https://github.com/flyerhzm/bullet Bullet Gem Documentation]

File:All students all reviews.png

2025-04-23T00:07:58Z

Psamant2:

CSC/ECE 517 Spring 2025 - E2536. Improve assessment360 controller

2025-04-22T23:57:48Z

Psamant2: /* Implementation */

== Problem Overview ==
The '''Assessment360 Controller''' within the Expertiza platform serves as a key tool for instructors, providing a holistic view of student performance across multiple assessment perspectives. The controller aggregates and displays data from various evaluation components, including teammate reviews, meta-reviews, instructor grades, peer review scores, and assignment submissions. The term <code>Assessment360</code> reflects its purpose of offering a comprehensive, 360-degree evaluation of a student's performance.

Currently, the system relies on two separate views — <code>all_students_all_reviews</code> and <code>course_student_grade_summary</code> — to display different aspects of student performance. These views present:
* Project-level data: The projects a student has worked on and the corresponding grades.
* Peer review data: The scores students receive from their teammates through the teammate review process.

While these views serve important functions, their separation results in a fragmented user experience, as instructors must switch between the views to see a complete set of student performance data. Additionally, the user interface (UI) is not optimized for an intuitive, seamless experience. There are limitations regarding
* The ability to interact with or customize the data display (e.g., column visibility, sorting, and reordering).
* The lack of visual clarity in data presentation (e.g., inconsistent formatting and absence of visual grade indicators).
* Inadequate responsiveness for different device types.

== Objective ==
The primary goal is to enhance the UI/UX and code quality of the <code>assessment360</code> controller. This involves:
* Merging the two existing views (<code>all_students_all_reviews</code> and <code>course_student_grade_summary</code>) into a single unified view.
* Improving the presentation and clarity of data (student grades, peer reviews).
* Refactoring logic for better separation of concerns and maintainability.
* Implementing feedback from the previous team.

== Current Implementation ==

=== Controller Structure ===
The <code>Assessment360Controller</code> is the central controller handling the logic for both the <code>all_students_all_reviews</code> and <code>course_student_grade_summary</code> views. It interacts with various models and services to fetch, process, and deliver the necessary data to the views. The current structure is as follows:
* The controller is responsible for gathering and processing assessment data such as grades, peer reviews, and meta-reviews for each student.
* It includes logic for handling class averages, calculating final grades, and determining peer review averages.
* The current implementation uses direct logic for grade calculations, and all calculations are executed within the controller itself, which could lead to bloated code and reduced maintainability.
* The views are rendered with minimal controller-side logic, relying on the controller to pass the necessary data to the front-end.

=== Current Views ===
The current implementation provides two main views that instructors can use to assess the performance of students. These views are defined in separate HTML ERB files.

==== <code>all_students_all_reviews.html.erb</code> ====
This view displays detailed student performance data in a table format. Key features include:
* Student Information Table: Displays each student’s name, ID, and relevant information.
* Teammate and Meta-Review Scores: For each student, the table shows the scores received from teammates and meta-reviews, which help in assessing peer evaluations.
* Class Averages: For each assignment and review type, class averages are calculated and displayed for instructors to analyze the overall performance of the class.
* Separate Columns for Review Types: Each type of review (<code>teammate</code>, <code>meta-review</code>, etc.) is shown in a separate column, making it easy to compare different assessment categories side by side.

==== <code>course_student_grade_summary.html.erb</code> ====
This view focuses on summarizing the project grades and peer review scores for each student. It includes:
* Student Grades and Peer Review Scores**: Displays the individual project grades and the peer review scores that a student has received.
* Assignment Topics: Lists the assignment topics associated with each project, along with the grades and peer review scores for those specific topics.
* Final Grades and Peer Review Averages: The final grade for each student is calculated by considering both the project grade and peer review scores, and the average peer review score is displayed alongside the final grade.
* Sortable Table Structure: The table in this view is designed to be sortable, allowing instructors to order students by project grades, peer review scores, or any other criterion available in the table. This adds flexibility in how data is analyzed.

== Use Case Diagram ==
For this project our job is to unify the view of the two files, i.e. all_students_all_reviews and course_student_grade_summary, which were created in the previous implementation to one. This would result in a single view which would help in evaluating performances by combining a lot of different perspectives. In our case, if we merge the two files and create a new view, the user should be able to view all the information that is there to be seen in one page. This includes:
* Viewing a Unified Dashboard
* Viewing all the Project Grades
* Viewing Peer Evaluation Scores
* Selecting and Deselecting Columns

Using this information we have created the following Use Case Diagram:

<center>[[File:E2536_Spring_2025.png|600x600px|Improve assessment360]]</center>

== Design Pattern Usage in Assessment360Controller ==

The '''Assessment360Controller''' implements multiple design patterns that improve clarity, modularity, and maintainability of the code.

=== 1. Facade Pattern ===
The controller acts as a facade, hiding complex interactions between various models (''Course'', ''Assignment'', ''Participant'', ''Team'', etc.) and exposing a simplified interface for the view. It aggregates data like grades, reviews, and penalties and prepares it in a structured format, simplifying the presentation layer.

=== 2. Strategy Pattern ===
The use of helper modules such as:
* '''GradesHelper'''
* '''AuthorizationHelper'''
* '''Scoring'''
* '''PenaltyHelper'''

follows the Strategy Pattern. Each module encapsulates a specific piece of functionality, and the controller delegates responsibility to these interchangeable strategies, promoting clean separation of concerns and easier testing.

=== 3. Template Method Pattern ===
The method '''action_allowed?''' is a hook method that overrides a predefined template method in ''ApplicationController''. This allows customized access control behavior while maintaining a consistent interface across all controllers — an example of the Template Method Pattern in action.

=== 4. Separation of Concerns ===
Responsibility is split between:
* '''Controller''': Orchestrates data flow
* '''Models''': Store and retrieve business data
* '''Helpers''': Encapsulate computation and utility logic
* '''Views''': Render formatted output

This adheres to the '''Separation of Concerns''' principle and keeps each layer clean and testable.

These design patterns contribute to the robustness and scalability of the 360-degree assessment feature, allowing future teams to maintain and extend it with ease.

== Planned Enhancements ==

=== Functional Changes ===
{| class="wikitable"
! Feature !! Description
|-
| Unified View || Combine both views into a single HTML page that includes both project grades and review scores.
|-
| Column Selection || Allow users to toggle visible columns using checkboxes.
|-
| Exclude Unreviewed Assignments || Retain the functionality to exclude unreviewed assignments from averages.
|-
| Averages Precision || Limit decimal precision to 2 points for clarity.
|-
| Wider Name Column || Adjust layout to prioritize readability (e.g., wider name column than username).
|}

=== Code Refactor ===
{| class="wikitable"
! Task !! Reason
|-
| Move averaging logic to mixins or model concerns || Improve separation of concerns and reusability.
|-
| Commenting || Add meaningful comments for helper methods and business logic.
|}

== UI/UX Design ==
The new unified view will feature:
* A tabular layout showing all relevant data.
* Sectioned headers for each student.
* Collapsible panels (if needed) for clarity.
* Visual cues for peer review vs. project grades.
* Responsive design for usability across devices.

== Implementation ==

=== Previous View ===

=== Current View (after code changes) ===

== Testing Strategy ==

{| class="wikitable"
|-
! Type !! Description !! Tests
|-
| ''' Unit Tests''' || Test individual controller methods || - Test grade calculations - Test data formatting
|-
| ''' Integration Tests''' || Test interactions between components || - Test view rendering - Test database queries - Test caching functionality
|-
| ''' Manual Testing''' || Test UI functionality, performance, and error handling || - Test UI functionality - Test performance with large datasets - Test error scenarios
|}

== Success Criteria ==

The success of this feature implementation will be evaluated based on the following criteria:

{| class="wikitable"
|-
! Criterion !! Description
|-
| '''UI Enhancements Implemented and Working''' || All proposed UI enhancements, including the unified view, column management features, and data presentation improvements, must be fully implemented and functioning as expected. The UI should be intuitive, responsive, and meet the design goals outlined in the document.
|-
| '''Performance Improvements Measurable''' || The feature should demonstrate a measurable improvement in performance, particularly in terms of load times and responsiveness when rendering large datasets or performing grade calculations. Performance benchmarking should indicate a noticeable reduction in latency.
|-
| '''Test Coverage ''' || Comprehensive unit and integration tests must cover more than 80% of the new code and critical paths in the controller. This ensures that the feature is reliable, and potential issues are identified early in the development cycle. Test results should be stable, with no significant failures.
|-
| '''Code Documentation Complete''' || All new and modified code must be thoroughly documented. This includes clear inline comments, explanations for complex logic, and appropriate documentation for new functions, classes, and components. This ensures that future developers can understand and maintain the code efficiently.
|-
| '''No Regression Bugs''' || After implementing the new feature, no existing functionality in the Assessment360 controller should break or behave unexpectedly. Regression testing should show that previously working parts of the system continue to function without issues.
|-
| '''Positive User Feedback''' || End-users (instructors and administrators) must provide positive feedback about the usability and effectiveness of the feature. Feedback should indicate that the feature adds value, improves user experience, and meets the goals outlined in the design document.
|}

== Team Information ==
'''Mentor:''' Mitesh Anil Agarwal

'''Team:'''
* Jap Ashokbhai Purohit - jpurohi@ncsu.edu
* Sharmeen Momin - smomin@ncsu.edu
* Prithish Samanta - psamant2@ncsu.edu

== References ==
* [https://github.com/expertiza/expertiza Expertiza Codebase]
* [https://guides.rubyonrails.org/action_view_overview.html Rails View Helpers]
* [https://github.com/flyerhzm/bullet Bullet Gem Documentation]

CSC/ECE 517 Spring 2025 - E2536. Improve assessment360 controller

2025-04-22T23:56:47Z

Psamant2: /* Implementation */

== Problem Overview ==
The '''Assessment360 Controller''' within the Expertiza platform serves as a key tool for instructors, providing a holistic view of student performance across multiple assessment perspectives. The controller aggregates and displays data from various evaluation components, including teammate reviews, meta-reviews, instructor grades, peer review scores, and assignment submissions. The term <code>Assessment360</code> reflects its purpose of offering a comprehensive, 360-degree evaluation of a student's performance.

Currently, the system relies on two separate views — <code>all_students_all_reviews</code> and <code>course_student_grade_summary</code> — to display different aspects of student performance. These views present:
* Project-level data: The projects a student has worked on and the corresponding grades.
* Peer review data: The scores students receive from their teammates through the teammate review process.

While these views serve important functions, their separation results in a fragmented user experience, as instructors must switch between the views to see a complete set of student performance data. Additionally, the user interface (UI) is not optimized for an intuitive, seamless experience. There are limitations regarding
* The ability to interact with or customize the data display (e.g., column visibility, sorting, and reordering).
* The lack of visual clarity in data presentation (e.g., inconsistent formatting and absence of visual grade indicators).
* Inadequate responsiveness for different device types.

== Objective ==
The primary goal is to enhance the UI/UX and code quality of the <code>assessment360</code> controller. This involves:
* Merging the two existing views (<code>all_students_all_reviews</code> and <code>course_student_grade_summary</code>) into a single unified view.
* Improving the presentation and clarity of data (student grades, peer reviews).
* Refactoring logic for better separation of concerns and maintainability.
* Implementing feedback from the previous team.

== Current Implementation ==

=== Controller Structure ===
The <code>Assessment360Controller</code> is the central controller handling the logic for both the <code>all_students_all_reviews</code> and <code>course_student_grade_summary</code> views. It interacts with various models and services to fetch, process, and deliver the necessary data to the views. The current structure is as follows:
* The controller is responsible for gathering and processing assessment data such as grades, peer reviews, and meta-reviews for each student.
* It includes logic for handling class averages, calculating final grades, and determining peer review averages.
* The current implementation uses direct logic for grade calculations, and all calculations are executed within the controller itself, which could lead to bloated code and reduced maintainability.
* The views are rendered with minimal controller-side logic, relying on the controller to pass the necessary data to the front-end.

=== Current Views ===
The current implementation provides two main views that instructors can use to assess the performance of students. These views are defined in separate HTML ERB files.

==== <code>all_students_all_reviews.html.erb</code> ====
This view displays detailed student performance data in a table format. Key features include:
* Student Information Table: Displays each student’s name, ID, and relevant information.
* Teammate and Meta-Review Scores: For each student, the table shows the scores received from teammates and meta-reviews, which help in assessing peer evaluations.
* Class Averages: For each assignment and review type, class averages are calculated and displayed for instructors to analyze the overall performance of the class.
* Separate Columns for Review Types: Each type of review (<code>teammate</code>, <code>meta-review</code>, etc.) is shown in a separate column, making it easy to compare different assessment categories side by side.

==== <code>course_student_grade_summary.html.erb</code> ====
This view focuses on summarizing the project grades and peer review scores for each student. It includes:
* Student Grades and Peer Review Scores**: Displays the individual project grades and the peer review scores that a student has received.
* Assignment Topics: Lists the assignment topics associated with each project, along with the grades and peer review scores for those specific topics.
* Final Grades and Peer Review Averages: The final grade for each student is calculated by considering both the project grade and peer review scores, and the average peer review score is displayed alongside the final grade.
* Sortable Table Structure: The table in this view is designed to be sortable, allowing instructors to order students by project grades, peer review scores, or any other criterion available in the table. This adds flexibility in how data is analyzed.

== Use Case Diagram ==
For this project our job is to unify the view of the two files, i.e. all_students_all_reviews and course_student_grade_summary, which were created in the previous implementation to one. This would result in a single view which would help in evaluating performances by combining a lot of different perspectives. In our case, if we merge the two files and create a new view, the user should be able to view all the information that is there to be seen in one page. This includes:
* Viewing a Unified Dashboard
* Viewing all the Project Grades
* Viewing Peer Evaluation Scores
* Selecting and Deselecting Columns

Using this information we have created the following Use Case Diagram:

<center>[[File:E2536_Spring_2025.png|600x600px|Improve assessment360]]</center>

== Design Pattern Usage in Assessment360Controller ==

The '''Assessment360Controller''' implements multiple design patterns that improve clarity, modularity, and maintainability of the code.

=== 1. Facade Pattern ===
The controller acts as a facade, hiding complex interactions between various models (''Course'', ''Assignment'', ''Participant'', ''Team'', etc.) and exposing a simplified interface for the view. It aggregates data like grades, reviews, and penalties and prepares it in a structured format, simplifying the presentation layer.

=== 2. Strategy Pattern ===
The use of helper modules such as:
* '''GradesHelper'''
* '''AuthorizationHelper'''
* '''Scoring'''
* '''PenaltyHelper'''

follows the Strategy Pattern. Each module encapsulates a specific piece of functionality, and the controller delegates responsibility to these interchangeable strategies, promoting clean separation of concerns and easier testing.

=== 3. Template Method Pattern ===
The method '''action_allowed?''' is a hook method that overrides a predefined template method in ''ApplicationController''. This allows customized access control behavior while maintaining a consistent interface across all controllers — an example of the Template Method Pattern in action.

=== 4. Separation of Concerns ===
Responsibility is split between:
* '''Controller''': Orchestrates data flow
* '''Models''': Store and retrieve business data
* '''Helpers''': Encapsulate computation and utility logic
* '''Views''': Render formatted output

This adheres to the '''Separation of Concerns''' principle and keeps each layer clean and testable.

These design patterns contribute to the robustness and scalability of the 360-degree assessment feature, allowing future teams to maintain and extend it with ease.

== Planned Enhancements ==

=== Functional Changes ===
{| class="wikitable"
! Feature !! Description
|-
| Unified View || Combine both views into a single HTML page that includes both project grades and review scores.
|-
| Column Selection || Allow users to toggle visible columns using checkboxes.
|-
| Exclude Unreviewed Assignments || Retain the functionality to exclude unreviewed assignments from averages.
|-
| Averages Precision || Limit decimal precision to 2 points for clarity.
|-
| Wider Name Column || Adjust layout to prioritize readability (e.g., wider name column than username).
|}

=== Code Refactor ===
{| class="wikitable"
! Task !! Reason
|-
| Move averaging logic to mixins or model concerns || Improve separation of concerns and reusability.
|-
| Commenting || Add meaningful comments for helper methods and business logic.
|}

== UI/UX Design ==
The new unified view will feature:
* A tabular layout showing all relevant data.
* Sectioned headers for each student.
* Collapsible panels (if needed) for clarity.
* Visual cues for peer review vs. project grades.
* Responsive design for usability across devices.

== Implementation ==
=== Functional Changes ===
{| class="wikitable"
! Feature !! Description
|-
| Unified View || Combine both views into a single HTML page that includes both project grades and review scores.
|-
| Column Selection || Allow users to toggle visible columns using checkboxes.
|-
| Exclude Unreviewed Assignments || Retain the functionality to exclude unreviewed assignments from averages.
|-
| Averages Precision || Limit decimal precision to 2 points for clarity.
|-
| Wider Name Column || Adjust layout to prioritize readability (e.g., wider name column than username).
|}

=== Code Refactor ===
{| class="wikitable"
! Task !! Reason
|-
| Move averaging logic to mixins or model concerns || Improve separation of concerns and reusability.
|-
| Commenting || Add meaningful comments for helper methods and business logic.
|}

== Testing Strategy ==

{| class="wikitable"
|-
! Type !! Description !! Tests
|-
| ''' Unit Tests''' || Test individual controller methods || - Test grade calculations - Test data formatting
|-
| ''' Integration Tests''' || Test interactions between components || - Test view rendering - Test database queries - Test caching functionality
|-
| ''' Manual Testing''' || Test UI functionality, performance, and error handling || - Test UI functionality - Test performance with large datasets - Test error scenarios
|}

== Success Criteria ==

The success of this feature implementation will be evaluated based on the following criteria:

{| class="wikitable"
|-
! Criterion !! Description
|-
| '''UI Enhancements Implemented and Working''' || All proposed UI enhancements, including the unified view, column management features, and data presentation improvements, must be fully implemented and functioning as expected. The UI should be intuitive, responsive, and meet the design goals outlined in the document.
|-
| '''Performance Improvements Measurable''' || The feature should demonstrate a measurable improvement in performance, particularly in terms of load times and responsiveness when rendering large datasets or performing grade calculations. Performance benchmarking should indicate a noticeable reduction in latency.
|-
| '''Test Coverage ''' || Comprehensive unit and integration tests must cover more than 80% of the new code and critical paths in the controller. This ensures that the feature is reliable, and potential issues are identified early in the development cycle. Test results should be stable, with no significant failures.
|-
| '''Code Documentation Complete''' || All new and modified code must be thoroughly documented. This includes clear inline comments, explanations for complex logic, and appropriate documentation for new functions, classes, and components. This ensures that future developers can understand and maintain the code efficiently.
|-
| '''No Regression Bugs''' || After implementing the new feature, no existing functionality in the Assessment360 controller should break or behave unexpectedly. Regression testing should show that previously working parts of the system continue to function without issues.
|-
| '''Positive User Feedback''' || End-users (instructors and administrators) must provide positive feedback about the usability and effectiveness of the feature. Feedback should indicate that the feature adds value, improves user experience, and meets the goals outlined in the design document.
|}

== Team Information ==
'''Mentor:''' Mitesh Anil Agarwal

'''Team:'''
* Jap Ashokbhai Purohit - jpurohi@ncsu.edu
* Sharmeen Momin - smomin@ncsu.edu
* Prithish Samanta - psamant2@ncsu.edu

== References ==
* [https://github.com/expertiza/expertiza Expertiza Codebase]
* [https://guides.rubyonrails.org/action_view_overview.html Rails View Helpers]
* [https://github.com/flyerhzm/bullet Bullet Gem Documentation]

CSC/ECE 517 Spring 2025 - E2536. Improve assessment360 controller

2025-04-22T23:56:22Z

Psamant2: /* UI/UX Design */

== Problem Overview ==
The '''Assessment360 Controller''' within the Expertiza platform serves as a key tool for instructors, providing a holistic view of student performance across multiple assessment perspectives. The controller aggregates and displays data from various evaluation components, including teammate reviews, meta-reviews, instructor grades, peer review scores, and assignment submissions. The term <code>Assessment360</code> reflects its purpose of offering a comprehensive, 360-degree evaluation of a student's performance.

Currently, the system relies on two separate views — <code>all_students_all_reviews</code> and <code>course_student_grade_summary</code> — to display different aspects of student performance. These views present:
* Project-level data: The projects a student has worked on and the corresponding grades.
* Peer review data: The scores students receive from their teammates through the teammate review process.

While these views serve important functions, their separation results in a fragmented user experience, as instructors must switch between the views to see a complete set of student performance data. Additionally, the user interface (UI) is not optimized for an intuitive, seamless experience. There are limitations regarding
* The ability to interact with or customize the data display (e.g., column visibility, sorting, and reordering).
* The lack of visual clarity in data presentation (e.g., inconsistent formatting and absence of visual grade indicators).
* Inadequate responsiveness for different device types.

== Objective ==
The primary goal is to enhance the UI/UX and code quality of the <code>assessment360</code> controller. This involves:
* Merging the two existing views (<code>all_students_all_reviews</code> and <code>course_student_grade_summary</code>) into a single unified view.
* Improving the presentation and clarity of data (student grades, peer reviews).
* Refactoring logic for better separation of concerns and maintainability.
* Implementing feedback from the previous team.

== Current Implementation ==

=== Controller Structure ===
The <code>Assessment360Controller</code> is the central controller handling the logic for both the <code>all_students_all_reviews</code> and <code>course_student_grade_summary</code> views. It interacts with various models and services to fetch, process, and deliver the necessary data to the views. The current structure is as follows:
* The controller is responsible for gathering and processing assessment data such as grades, peer reviews, and meta-reviews for each student.
* It includes logic for handling class averages, calculating final grades, and determining peer review averages.
* The current implementation uses direct logic for grade calculations, and all calculations are executed within the controller itself, which could lead to bloated code and reduced maintainability.
* The views are rendered with minimal controller-side logic, relying on the controller to pass the necessary data to the front-end.

=== Current Views ===
The current implementation provides two main views that instructors can use to assess the performance of students. These views are defined in separate HTML ERB files.

==== <code>all_students_all_reviews.html.erb</code> ====
This view displays detailed student performance data in a table format. Key features include:
* Student Information Table: Displays each student’s name, ID, and relevant information.
* Teammate and Meta-Review Scores: For each student, the table shows the scores received from teammates and meta-reviews, which help in assessing peer evaluations.
* Class Averages: For each assignment and review type, class averages are calculated and displayed for instructors to analyze the overall performance of the class.
* Separate Columns for Review Types: Each type of review (<code>teammate</code>, <code>meta-review</code>, etc.) is shown in a separate column, making it easy to compare different assessment categories side by side.

==== <code>course_student_grade_summary.html.erb</code> ====
This view focuses on summarizing the project grades and peer review scores for each student. It includes:
* Student Grades and Peer Review Scores**: Displays the individual project grades and the peer review scores that a student has received.
* Assignment Topics: Lists the assignment topics associated with each project, along with the grades and peer review scores for those specific topics.
* Final Grades and Peer Review Averages: The final grade for each student is calculated by considering both the project grade and peer review scores, and the average peer review score is displayed alongside the final grade.
* Sortable Table Structure: The table in this view is designed to be sortable, allowing instructors to order students by project grades, peer review scores, or any other criterion available in the table. This adds flexibility in how data is analyzed.

== Use Case Diagram ==
For this project our job is to unify the view of the two files, i.e. all_students_all_reviews and course_student_grade_summary, which were created in the previous implementation to one. This would result in a single view which would help in evaluating performances by combining a lot of different perspectives. In our case, if we merge the two files and create a new view, the user should be able to view all the information that is there to be seen in one page. This includes:
* Viewing a Unified Dashboard
* Viewing all the Project Grades
* Viewing Peer Evaluation Scores
* Selecting and Deselecting Columns

Using this information we have created the following Use Case Diagram:

<center>[[File:E2536_Spring_2025.png|600x600px|Improve assessment360]]</center>

== Design Pattern Usage in Assessment360Controller ==

The '''Assessment360Controller''' implements multiple design patterns that improve clarity, modularity, and maintainability of the code.

=== 1. Facade Pattern ===
The controller acts as a facade, hiding complex interactions between various models (''Course'', ''Assignment'', ''Participant'', ''Team'', etc.) and exposing a simplified interface for the view. It aggregates data like grades, reviews, and penalties and prepares it in a structured format, simplifying the presentation layer.

=== 2. Strategy Pattern ===
The use of helper modules such as:
* '''GradesHelper'''
* '''AuthorizationHelper'''
* '''Scoring'''
* '''PenaltyHelper'''

follows the Strategy Pattern. Each module encapsulates a specific piece of functionality, and the controller delegates responsibility to these interchangeable strategies, promoting clean separation of concerns and easier testing.

=== 3. Template Method Pattern ===
The method '''action_allowed?''' is a hook method that overrides a predefined template method in ''ApplicationController''. This allows customized access control behavior while maintaining a consistent interface across all controllers — an example of the Template Method Pattern in action.

=== 4. Separation of Concerns ===
Responsibility is split between:
* '''Controller''': Orchestrates data flow
* '''Models''': Store and retrieve business data
* '''Helpers''': Encapsulate computation and utility logic
* '''Views''': Render formatted output

This adheres to the '''Separation of Concerns''' principle and keeps each layer clean and testable.

These design patterns contribute to the robustness and scalability of the 360-degree assessment feature, allowing future teams to maintain and extend it with ease.

== Planned Enhancements ==

=== Functional Changes ===
{| class="wikitable"
! Feature !! Description
|-
| Unified View || Combine both views into a single HTML page that includes both project grades and review scores.
|-
| Column Selection || Allow users to toggle visible columns using checkboxes.
|-
| Exclude Unreviewed Assignments || Retain the functionality to exclude unreviewed assignments from averages.
|-
| Averages Precision || Limit decimal precision to 2 points for clarity.
|-
| Wider Name Column || Adjust layout to prioritize readability (e.g., wider name column than username).
|}

=== Code Refactor ===
{| class="wikitable"
! Task !! Reason
|-
| Move averaging logic to mixins or model concerns || Improve separation of concerns and reusability.
|-
| Commenting || Add meaningful comments for helper methods and business logic.
|}

== UI/UX Design ==
The new unified view will feature:
* A tabular layout showing all relevant data.
* Sectioned headers for each student.
* Collapsible panels (if needed) for clarity.
* Visual cues for peer review vs. project grades.
* Responsive design for usability across devices.

== Implementation ==

-- Previous View

-- Current View After Changes

== Testing Strategy ==

{| class="wikitable"
|-
! Type !! Description !! Tests
|-
| ''' Unit Tests''' || Test individual controller methods || - Test grade calculations - Test data formatting
|-
| ''' Integration Tests''' || Test interactions between components || - Test view rendering - Test database queries - Test caching functionality
|-
| ''' Manual Testing''' || Test UI functionality, performance, and error handling || - Test UI functionality - Test performance with large datasets - Test error scenarios
|}

== Success Criteria ==

The success of this feature implementation will be evaluated based on the following criteria:

{| class="wikitable"
|-
! Criterion !! Description
|-
| '''UI Enhancements Implemented and Working''' || All proposed UI enhancements, including the unified view, column management features, and data presentation improvements, must be fully implemented and functioning as expected. The UI should be intuitive, responsive, and meet the design goals outlined in the document.
|-
| '''Performance Improvements Measurable''' || The feature should demonstrate a measurable improvement in performance, particularly in terms of load times and responsiveness when rendering large datasets or performing grade calculations. Performance benchmarking should indicate a noticeable reduction in latency.
|-
| '''Test Coverage ''' || Comprehensive unit and integration tests must cover more than 80% of the new code and critical paths in the controller. This ensures that the feature is reliable, and potential issues are identified early in the development cycle. Test results should be stable, with no significant failures.
|-
| '''Code Documentation Complete''' || All new and modified code must be thoroughly documented. This includes clear inline comments, explanations for complex logic, and appropriate documentation for new functions, classes, and components. This ensures that future developers can understand and maintain the code efficiently.
|-
| '''No Regression Bugs''' || After implementing the new feature, no existing functionality in the Assessment360 controller should break or behave unexpectedly. Regression testing should show that previously working parts of the system continue to function without issues.
|-
| '''Positive User Feedback''' || End-users (instructors and administrators) must provide positive feedback about the usability and effectiveness of the feature. Feedback should indicate that the feature adds value, improves user experience, and meets the goals outlined in the design document.
|}

== Team Information ==
'''Mentor:''' Mitesh Anil Agarwal

'''Team:'''
* Jap Ashokbhai Purohit - jpurohi@ncsu.edu
* Sharmeen Momin - smomin@ncsu.edu
* Prithish Samanta - psamant2@ncsu.edu

== References ==
* [https://github.com/expertiza/expertiza Expertiza Codebase]
* [https://guides.rubyonrails.org/action_view_overview.html Rails View Helpers]
* [https://github.com/flyerhzm/bullet Bullet Gem Documentation]

CSC/ECE 517 Spring 2025 - E2536. Improve assessment360 controller

2025-04-08T02:05:01Z

Psamant2: /* Use Case Diagram */

== Project Overview ==
'''Project Title: Improve assessment360 Controller'''

== Objective ==
The primary goal is to enhance the UI/UX and code quality of the <code>assessment360</code> controller. This involves:
* Merging the two existing views (<code>all_students_all_reviews</code> and <code>course_student_grade_summary</code>) into a single unified view.
* Improving the presentation and clarity of data (student grades, peer reviews).
* Refactoring logic for better separation of concerns and maintainability.
* Implementing feedback from the previous team.

== Current Implementation Summary ==
The <code>assessment360</code> controller exposes two main methods:
* <code>all_students_all_reviews</code>: Displays peer review scores per student.
* <code>course_student_grade_summary</code>: Displays projects and grades for each student.

'''Limitations noted in previous feedback:'''
* Separate views instead of a unified dashboard.
* Excessive decimal precision in grade averages.
* Some layout/design issues (e.g., narrow name column).
* Business logic within controllers (should be moved to mixins).
* Sparse code comments.

== Use Case Diagram ==
For this project our job is to unify the view of the two files, i.e. all_students_all_reviews and course_student_grade_summary, which were created in the previous implementation to one. This would result in a single view which would help in evaluating performances by combining a lot of different perspectives. In our case, if we merge the two files and create a new view, the user should be able to view all the information that is there to be seen in one page. This includes:
* Viewing a Unified Dashboard
* Viewing all the Project Grades
* Viewing Peer Evaluation Scores
* Selecting and Deselecting Columns

Using this information we have created the following Use Case Diagram:

[[File:UseCaseDiagram.png|UseCaseDiagram]]

== Design Pattern Usage in Assessment360Controller ==

The '''Assessment360Controller''' implements multiple design patterns that improve clarity, modularity, and maintainability of the code.

=== 1. Facade Pattern ===
The controller acts as a facade, hiding complex interactions between various models (''Course'', ''Assignment'', ''Participant'', ''Team'', etc.) and exposing a simplified interface for the view. It aggregates data like grades, reviews, and penalties and prepares it in a structured format, simplifying the presentation layer.

=== 2. Strategy Pattern ===
The use of helper modules such as:
* '''GradesHelper'''
* '''AuthorizationHelper'''
* '''Scoring'''
* '''PenaltyHelper'''

follows the Strategy Pattern. Each module encapsulates a specific piece of functionality, and the controller delegates responsibility to these interchangeable strategies, promoting clean separation of concerns and easier testing.

=== 3. Template Method Pattern ===
The method '''action_allowed?''' is a hook method that overrides a predefined template method in ''ApplicationController''. This allows customized access control behavior while maintaining a consistent interface across all controllers — an example of the Template Method Pattern in action.

=== 4. Separation of Concerns ===
Responsibility is split between:
* '''Controller''': Orchestrates data flow
* '''Models''': Store and retrieve business data
* '''Helpers''': Encapsulate computation and utility logic
* '''Views''': Render formatted output

This adheres to the '''Separation of Concerns''' principle and keeps each layer clean and testable.

These design patterns contribute to the robustness and scalability of the 360-degree assessment feature, allowing future teams to maintain and extend it with ease.

== Planned Enhancements ==

=== Functional Changes ===
{| class="wikitable"
! Feature !! Description
|-
| Unified View || Combine both views into a single HTML page that includes both project grades and review scores.
|-
| Column Selection || Allow users to toggle visible columns using checkboxes.
|-
| Exclude Unreviewed Assignments || Retain the functionality to exclude unreviewed assignments from averages.
|-
| Averages Precision || Limit decimal precision to 2 points for clarity.
|-
| Wider Name Column || Adjust layout to prioritize readability (e.g., wider name column than username).
|}

=== Code Refactor ===
{| class="wikitable"
! Task !! Reason
|-
| Move averaging logic to mixins or model concerns || Improve separation of concerns and reusability.
|-
| Commenting || Add meaningful comments for helper methods and business logic.
|-
| Query Optimization || Utilize the <code>bullet</code> gem to prevent N+1 queries where applicable.
|}

== UI/UX Design ==
The new unified view will feature:
* A tabular layout showing all relevant data.
* Sectioned headers for each student.
* Collapsible panels (if needed) for clarity.
* Visual cues for peer review vs. project grades.
* Responsive design for usability across devices.

== Testing Plan ==
{| class="wikitable"
! Test Type !! Details
|-
| Unit Tests || For mixin methods and average calculations.
|-
| Functional Tests || Using RSpec + Capybara to validate UI behavior.
|-
| Manual Testing || Validate layout, toggle functionality, and performance.
|}

== Metrics for Success ==
* Unified view is fully integrated and intuitive.
* UI loads efficiently and scales with data.
* Code coverage is maintained or improved.
* Previous feedback points are addressed.
* PR receives clean review with minimal rework.

== Team Information ==
'''Mentor:''' Mitesh Anil Agarwal

'''Team:'''
* Jap Ashokbhai Purohit - jpurohi@ncsu.edu
* Sharmeen Momin - smomin@ncsu.edu
* Prithish Samanta - psamant2@ncsu.edu

== References ==
* [https://github.com/expertiza/expertiza Expertiza Codebase]
* [https://guides.rubyonrails.org/action_view_overview.html Rails View Helpers]
* [https://github.com/flyerhzm/bullet Bullet Gem Documentation]

CSC/ECE 517 Spring 2025 - E2536. Improve assessment360 controller

2025-04-08T02:03:14Z

Psamant2: /* Current Implementation Summary */

== Project Overview ==
'''Project Title: Improve assessment360 Controller'''

== Objective ==
The primary goal is to enhance the UI/UX and code quality of the <code>assessment360</code> controller. This involves:
* Merging the two existing views (<code>all_students_all_reviews</code> and <code>course_student_grade_summary</code>) into a single unified view.
* Improving the presentation and clarity of data (student grades, peer reviews).
* Refactoring logic for better separation of concerns and maintainability.
* Implementing feedback from the previous team.

== Current Implementation Summary ==
The <code>assessment360</code> controller exposes two main methods:
* <code>all_students_all_reviews</code>: Displays peer review scores per student.
* <code>course_student_grade_summary</code>: Displays projects and grades for each student.

'''Limitations noted in previous feedback:'''
* Separate views instead of a unified dashboard.
* Excessive decimal precision in grade averages.
* Some layout/design issues (e.g., narrow name column).
* Business logic within controllers (should be moved to mixins).
* Sparse code comments.

== Use Case Diagram ==
For this project our job is to unify the view of the two files, i.e. all_students_all_reviews and course_student_grade_summary, which were created in the previous implementation to one. This would result in a single view which would help in evaluating performances by combining a lot of different perspectives. In our case, if we merge the two files and create a new view, the user should be able to view all the information that is there to be seen in one page. This includes:
* Viewing a Unified Dashboard
* Viewing all the Project Grades
* Viewing Peer Evaluation Scores
* Selecting and Deselecting Columns

Using this information we have created the following Use Case Diagram:

== Design Pattern Usage in Assessment360Controller ==

The '''Assessment360Controller''' implements multiple design patterns that improve clarity, modularity, and maintainability of the code.

=== 1. Facade Pattern ===
The controller acts as a facade, hiding complex interactions between various models (''Course'', ''Assignment'', ''Participant'', ''Team'', etc.) and exposing a simplified interface for the view. It aggregates data like grades, reviews, and penalties and prepares it in a structured format, simplifying the presentation layer.

=== 2. Strategy Pattern ===
The use of helper modules such as:
* '''GradesHelper'''
* '''AuthorizationHelper'''
* '''Scoring'''
* '''PenaltyHelper'''

follows the Strategy Pattern. Each module encapsulates a specific piece of functionality, and the controller delegates responsibility to these interchangeable strategies, promoting clean separation of concerns and easier testing.

=== 3. Template Method Pattern ===
The method '''action_allowed?''' is a hook method that overrides a predefined template method in ''ApplicationController''. This allows customized access control behavior while maintaining a consistent interface across all controllers — an example of the Template Method Pattern in action.

=== 4. Separation of Concerns ===
Responsibility is split between:
* '''Controller''': Orchestrates data flow
* '''Models''': Store and retrieve business data
* '''Helpers''': Encapsulate computation and utility logic
* '''Views''': Render formatted output

This adheres to the '''Separation of Concerns''' principle and keeps each layer clean and testable.

These design patterns contribute to the robustness and scalability of the 360-degree assessment feature, allowing future teams to maintain and extend it with ease.

== Planned Enhancements ==

=== Functional Changes ===
{| class="wikitable"
! Feature !! Description
|-
| Unified View || Combine both views into a single HTML page that includes both project grades and review scores.
|-
| Column Selection || Allow users to toggle visible columns using checkboxes.
|-
| Exclude Unreviewed Assignments || Retain the functionality to exclude unreviewed assignments from averages.
|-
| Averages Precision || Limit decimal precision to 2 points for clarity.
|-
| Wider Name Column || Adjust layout to prioritize readability (e.g., wider name column than username).
|}

=== Code Refactor ===
{| class="wikitable"
! Task !! Reason
|-
| Move averaging logic to mixins or model concerns || Improve separation of concerns and reusability.
|-
| Commenting || Add meaningful comments for helper methods and business logic.
|-
| Query Optimization || Utilize the <code>bullet</code> gem to prevent N+1 queries where applicable.
|}

== UI/UX Design ==
The new unified view will feature:
* A tabular layout showing all relevant data.
* Sectioned headers for each student.
* Collapsible panels (if needed) for clarity.
* Visual cues for peer review vs. project grades.
* Responsive design for usability across devices.

== Testing Plan ==
{| class="wikitable"
! Test Type !! Details
|-
| Unit Tests || For mixin methods and average calculations.
|-
| Functional Tests || Using RSpec + Capybara to validate UI behavior.
|-
| Manual Testing || Validate layout, toggle functionality, and performance.
|}

== Metrics for Success ==
* Unified view is fully integrated and intuitive.
* UI loads efficiently and scales with data.
* Code coverage is maintained or improved.
* Previous feedback points are addressed.
* PR receives clean review with minimal rework.

== Team Information ==
'''Mentor:''' Mitesh Anil Agarwal

'''Team:'''
* Jap Ashokbhai Purohit - jpurohi@ncsu.edu
* Sharmeen Momin - smomin@ncsu.edu
* Prithish Samanta - psamant2@ncsu.edu

== References ==
* [https://github.com/expertiza/expertiza Expertiza Codebase]
* [https://guides.rubyonrails.org/action_view_overview.html Rails View Helpers]
* [https://github.com/flyerhzm/bullet Bullet Gem Documentation]

CSC/ECE 517 Spring 2025 - E2536. Improve assessment360 controller

2025-04-08T00:45:44Z

Psamant2: /* Team Information */

CSC/ECE 517 Spring 2025 - E2536. Improve assessment360 controller

2025-04-08T00:45:36Z

Psamant2: /* Team Information */

CSC/ECE 517 Spring 2025 - E2536. Improve assessment360 controller

2025-04-08T00:45:26Z

Psamant2: /* Team Information */

CSC/ECE 517 Spring 2025 - E2536. Improve assessment360 controller

2025-04-08T00:45:15Z

Psamant2: /* Team Information */

CSC/ECE 517 Spring 2025 - E2536. Improve assessment360 controller

2025-04-08T00:44:24Z

Psamant2: /* Project Overview */

CSC/ECE 517 Spring 2025 - E2536. Improve assessment360 controller

2025-04-08T00:43:58Z

Psamant2:

== Project Overview ==
'''Project Title:''' Improve assessment360 Controller

== Objective ==
The primary goal is to enhance the UI/UX and code quality of the <code>assessment360</code> controller. This involves:
* Merging the two existing views (<code>all_students_all_reviews</code> and <code>course_student_grade_summary</code>) into a single unified view.
* Improving the presentation and clarity of data (student grades, peer reviews).
* Refactoring logic for better separation of concerns and maintainability.
* Implementing feedback from the previous team.

== Current Implementation Summary ==
The <code>assessment360</code> controller exposes two main methods:
* <code>all_students_all_reviews</code>: Displays peer review scores per student.
* <code>course_student_grade_summary</code>: Displays projects and grades for each student.

'''Limitations noted in previous feedback:'''
* Separate views instead of a unified dashboard.
* Excessive decimal precision in grade averages.
* Some layout/design issues (e.g., narrow name column).
* Business logic within controllers (should be moved to mixins).
* Sparse code comments.

== Planned Enhancements ==

=== Functional Changes ===
{| class="wikitable"
! Feature !! Description
|-
| Unified View || Combine both views into a single HTML page that includes both project grades and review scores.
|-
| Column Selection || Allow users to toggle visible columns using checkboxes.
|-
| Exclude Unreviewed Assignments || Retain the functionality to exclude unreviewed assignments from averages.
|-
| Averages Precision || Limit decimal precision to 2 points for clarity.
|-
| Wider Name Column || Adjust layout to prioritize readability (e.g., wider name column than username).
|}

=== Code Refactor ===
{| class="wikitable"
! Task !! Reason
|-
| Move averaging logic to mixins or model concerns || Improve separation of concerns and reusability.
|-
| Commenting || Add meaningful comments for helper methods and business logic.
|-
| Query Optimization || Utilize the <code>bullet</code> gem to prevent N+1 queries where applicable.
|}

== UI/UX Design ==
The new unified view will feature:
* A tabular layout showing all relevant data.
* Sectioned headers for each student.
* Collapsible panels (if needed) for clarity.
* Visual cues for peer review vs. project grades.
* Responsive design for usability across devices.

== Testing Plan ==
{| class="wikitable"
! Test Type !! Details
|-
| Unit Tests || For mixin methods and average calculations.
|-
| Functional Tests || Using RSpec + Capybara to validate UI behavior.
|-
| Manual Testing || Validate layout, toggle functionality, and performance.
|}

== Metrics for Success ==
* Unified view is fully integrated and intuitive.
* UI loads efficiently and scales with data.
* Code coverage is maintained or improved.
* Previous feedback points are addressed.
* PR receives clean review with minimal rework.

== Team Information ==
* Mentor: Mitesh Anil Agarwal
* Team:
* Jap Ashokbhai Purohit - smomin@ncsu.edu
* Sharmeen Momin - smomin@ncsu.edu
* Prithish Samanta - psamant2@ncsu.edu

== References ==
* [https://github.com/expertiza/expertiza Expertiza Codebase]
* [https://guides.rubyonrails.org/action_view_overview.html Rails View Helpers]
* [https://github.com/flyerhzm/bullet Bullet Gem Documentation]

CSC/ECE 517 Fall 2024 - E2519. Implement view for results of bidding

2025-03-24T04:38:14Z

Psamant2: /* Our Changes */

== Introduction ==
Expertiza is an open-source platform that educational institutions use to create, assign, and manage assignments and peer assessments. To enhance its functionality, our team improved the existing implementation of the topic bidding results feature.

The original implementation ('''''E2459''''') attempted to address the issue where instructors could only monitor topic bidding by impersonating students, making it difficult to verify whether the bidding assignment algorithm correctly assigned teams to topics. However, the previous solution did not function as intended.

This project focuses on developing the bidding page again with a better view, enhancing usability, and ensuring better code maintainability. Key improvements making the user interface better, showing vital information that would help the user analyze the projected data easily, optimizing the topic bidding table layout for readability, adding info buttons for better context, improving test cases, and refactoring the code for efficiency.

With these enhancements, instructors and students will have a seamless experience navigating the topic bidding results, making the process more transparent, accessible, and easier to interpret. This project significantly improves the usability of the platform, empowering users with better tools for decision-making.

== Problem Statement ==
TODO: Problem Statement
The existing topic bidding results feature in Expertiza lacks usability and effectiveness, making it difficult for instructors to monitor and analyze the bidding process efficiently. The current implementation requires instructors to impersonate students to view bidding statuses, which is cumbersome and does not provide a clear overview of how topics are assigned. Additionally, the previous attempt (E2459) to address this issue failed to function as intended, leaving gaps in usability and functionality.

Key issues with the current system include:

1. Lack of visibility – Instructors cannot easily track topic allocations and bidding outcomes.

2. Poor data presentation – The information displayed is not structured in a way that facilitates easy analysis.

3. Limited context – Users do not receive sufficient guidance or explanations for the bidding process.

4. Code inefficiencies – The existing implementation lacks maintainability, making future enhancements difficult.

This project aims to come up with an entirely new design and improve the topic bidding results feature by addressing these challenges, ensuring a more user-friendly, informative, and efficient experience for both instructors and students.

== Objectives ==

The primary objective of this project is to enhance the topic bidding results feature in Expertiza by improving its usability, accessibility, and maintainability. Specifically, our goals include:

1. Improve User Interface & Experience – Redesign the bidding results page with a structured layout that presents information clearly and intuitively.

2. Enhance Data Visualization – Display essential bidding-related data in a format that is easy to interpret, allowing users to analyze assignments effectively.

3. Optimize Table Layout – Improve the readability of the topic bidding table to facilitate better decision-making.

4. Provide Contextual Information – Introduce info buttons and tooltips to help users understand the bidding process and related data.

5. Develop and Document Code for Maintainability – Enhance the efficiency and structure of the codebase to support future updates and scalability.

By achieving these objectives, this project aims to provide instructors and students with a seamless and transparent way to view and analyze topic bidding results, improving their overall experience on the platform.

== Steps To Run The Project ==

In order to run the application, one should have Node.js installed in their local.

In order to run the application, run the below commands.

1. npm install - this installs all dependencies listed in the package.json file for a Node.js project

2. npm start - This runs the app in the development mode.

== Our Changes ==
As part of our efforts to improve the topic bidding results feature in Expertiza, we introduced several key enhancements to enhance usability, visualization, and accessibility. The following changes were implemented:

# '''User Interface Enhancements'''
## Replaced the traditional table format with a card-based view for better readability and a more modern interface.[[File:BidsPage.png|800px]]
## Styled the card view with improved layouts, ensuring a more intuitive display of bidding details.
## Integrated modals to display detailed bid and team information upon clicking a card. [[File:BidsModel.png|900px]]
# '''Data Visualization Improvements'''
## Implemented bar graphs to visually represent bidding trends, allowing for easier analysis of topic popularity and bid distributions.[[File:BidsGraph.png|850px]]
## Styled the graph to ensure clear data representation and seamless integration with the user interface.[[File:Biddstable.png|850px]]
# '''Download Functionality'''
## Added a Download CSV button to allow users to export bidding results in CSV format for external analysis.[[File:DownloadCsvCodepng.png|850px]]
## Implemented a Download PDF button to generate a well-formatted PDF report of the bidding results.[[File:DownloadPdfCode.png|850px]]
# '''Navigation and Accessibility Enhancements''' :
##Introduced a direct link from the assignment details page to the bidding results, eliminating the need for manual navigation[[File:AssignmentPageForBidding.png|850px]]
# '''Code and Maintainability Improvements''' :
##Conducted unit testing and manual testing to ensure all implemented features functioned as intended and provided a seamless user experience.

These changes collectively enhance the usability and efficiency of the topic bidding results feature, making it easier for instructors and students to analyze bidding outcomes and make informed decisions.

== Testing ==

This document details the test suite for the View Bid functionality, which allows students to access bidding information for projects. The tests ensure that:

# Only users with the Student role can see and access the View Bid link in the navigation, while the instructors and the admin have to access the view bid page through a different method.
# The BiddingPage component renders correctly and displays project bidding data
# The role-based access controls are working properly

'''Test Framework and Structure'''

'''The tests are organized into three main files:'''
# BiddingPage.test.tsx: Unit tests for the BiddingPage component
# Header.test.tsx: Unit tests for the header component with focus on the View Bid link
# ViewBid.integration.test.tsx: Integration tests for View Bid functionality across components

'''BiddingPage Component Tests (src/pages/Bidding/BiddingPage.test.tsx)'''
These tests focus on the UI and functionality of the BiddingPage component.
# renders the page title correctly - Ensures that components like main heading "Assignment Bidding Summary by Priority" appears on the page without crashing
# renders all topic cards from the data - Verifies that all topics from the mock data are rendered as cards and their details are displayed correctly
# displays bid statistics in each card - Tests that each topic card displays the expected bidding statistics
# Verifies the total bids count is displayed - Verifies that the PDF download button is present in the modal

'''Header Component Tests (src/layout/Header.test.tsx)'''
These tests focus on the role-based visibility of the View Bid link in the header.
# Should show "View Bid" link for users with Student role
# Should not show "View Bid" link for users with Instructor and Admin role

'''Integration Tests (src/tests/ViewBid.integration.test.tsx)'''
These tests verify the interaction between components and role-based access controls.
# Non-student users should not see View Bid link
# Protected route redirects non-students trying to access bidding page directly

'''Steps to Run all tests'''
npm test
'''Run specific test files'''
npm test src/pages/Bidding/BiddingPage.test.tsx - Tests BiddingPage Components
[[File:BiddingPageTest.png|600px]]
npm test src/layout/Header.test.tsx - Header Component
[[File:HeaderPage.png|600px]]
npm test src/tests/ViewBid.integration.test.tsx - Performs Integration Tests
[[File:ViewBid.png|600px]]

== Opportunities for Additional Future Enhancements ==

There are several areas where the current implementation can be improved or extended in the future:

# '''Integrate Actual API Call:''' Currently, the data used is static. Integrating the frontend with the actual backend API will ensure real-time and dynamic data population.
# '''Implement RBAC Control for Download Functionality:''' To enhance security and maintain data privacy, Role-Based Access Control (RBAC) can be enforced on the PDF download feature. This ensures only authorized users can access sensitive information.
# '''Support Dynamic Priority Handling:''' At present, the system assumes exactly three priority levels. To make the implementation more robust, it should be refactored to handle any number of priority levels dynamically, based on the data received.

== Team ==

=== Mentors ===
* Mitesh Anil Agarwal
* Kartiki Bhandakkar

=== Members ===
* [https://github.com/jappurohit041 Jap Ashokbhai Purohit (Unity ID: jpurohi)]
* [https://github.com/prithishsamanta Prithish Samanta (Unity ID: psamant2)]
* [https://github.com/SharmeenMomin Sharmeen Momin (Unity ID: smomin)]

== Links ==

* '''Pull Request:''' [https://github.com/expertiza/reimplementation-front-end/pull/90 Frontend Reimplementation - PR #90]
Contains the code changes and discussion related to the implemented feature.

* '''Demo Video:''' [https://www.loom.com/share/e6fd5fb07ba64b208f1ecc93294491cb?sid=6d68e33c-28c7-4b83-ba81-8cdfab937443 Loom Recording]
Walkthrough of the functionality implemented in the PR.

* '''Requirement Document:''' [https://docs.google.com/document/d/1fVX5AytpMz0hns-1xnLshwHz94UW_aEXJI5VVdju1cc/edit?tab=t.0 Google Doc]
Outlines the requirements and scope for the feature.

== References ==

* [https://html2canvas.hertzen.com/ html2canvas] – A JavaScript library that allows you to take "screenshots" of webpages or parts of them, rendering HTML content to canvas.

* [https://github.com/parallax/jsPDF jsPDF] – A client-side JavaScript library used to generate PDF documents.

* [https://github.com/simonbengtsson/jsPDF-AutoTable jsPDF-AutoTable] – A plugin for jsPDF that enables generation of tables with support for styling, column spanning, and automatic page breaking.

CSC/ECE 517 Fall 2024 - E2519. Implement view for results of bidding

2025-03-24T04:37:57Z

Psamant2: /* Our Changes */

== Introduction ==
Expertiza is an open-source platform that educational institutions use to create, assign, and manage assignments and peer assessments. To enhance its functionality, our team improved the existing implementation of the topic bidding results feature.

The original implementation ('''''E2459''''') attempted to address the issue where instructors could only monitor topic bidding by impersonating students, making it difficult to verify whether the bidding assignment algorithm correctly assigned teams to topics. However, the previous solution did not function as intended.

This project focuses on developing the bidding page again with a better view, enhancing usability, and ensuring better code maintainability. Key improvements making the user interface better, showing vital information that would help the user analyze the projected data easily, optimizing the topic bidding table layout for readability, adding info buttons for better context, improving test cases, and refactoring the code for efficiency.

With these enhancements, instructors and students will have a seamless experience navigating the topic bidding results, making the process more transparent, accessible, and easier to interpret. This project significantly improves the usability of the platform, empowering users with better tools for decision-making.

== Problem Statement ==
TODO: Problem Statement
The existing topic bidding results feature in Expertiza lacks usability and effectiveness, making it difficult for instructors to monitor and analyze the bidding process efficiently. The current implementation requires instructors to impersonate students to view bidding statuses, which is cumbersome and does not provide a clear overview of how topics are assigned. Additionally, the previous attempt (E2459) to address this issue failed to function as intended, leaving gaps in usability and functionality.

Key issues with the current system include:

1. Lack of visibility – Instructors cannot easily track topic allocations and bidding outcomes.

2. Poor data presentation – The information displayed is not structured in a way that facilitates easy analysis.

3. Limited context – Users do not receive sufficient guidance or explanations for the bidding process.

4. Code inefficiencies – The existing implementation lacks maintainability, making future enhancements difficult.

This project aims to come up with an entirely new design and improve the topic bidding results feature by addressing these challenges, ensuring a more user-friendly, informative, and efficient experience for both instructors and students.

== Objectives ==

The primary objective of this project is to enhance the topic bidding results feature in Expertiza by improving its usability, accessibility, and maintainability. Specifically, our goals include:

1. Improve User Interface & Experience – Redesign the bidding results page with a structured layout that presents information clearly and intuitively.

2. Enhance Data Visualization – Display essential bidding-related data in a format that is easy to interpret, allowing users to analyze assignments effectively.

3. Optimize Table Layout – Improve the readability of the topic bidding table to facilitate better decision-making.

4. Provide Contextual Information – Introduce info buttons and tooltips to help users understand the bidding process and related data.

5. Develop and Document Code for Maintainability – Enhance the efficiency and structure of the codebase to support future updates and scalability.

By achieving these objectives, this project aims to provide instructors and students with a seamless and transparent way to view and analyze topic bidding results, improving their overall experience on the platform.

== Steps To Run The Project ==

In order to run the application, one should have Node.js installed in their local.

In order to run the application, run the below commands.

1. npm install - this installs all dependencies listed in the package.json file for a Node.js project

2. npm start - This runs the app in the development mode.

== Our Changes ==
As part of our efforts to improve the topic bidding results feature in Expertiza, we introduced several key enhancements to enhance usability, visualization, and accessibility. The following changes were implemented:

# '''User Interface Enhancements'''
## Replaced the traditional table format with a card-based view for better readability and a more modern interface.[[File:BidsPage.png|800px]]
## Styled the card view with improved layouts, ensuring a more intuitive display of bidding details.
## Integrated modals to display detailed bid and team information upon clicking a card. [[File:BidsModel.png|1000px]]
# '''Data Visualization Improvements'''
## Implemented bar graphs to visually represent bidding trends, allowing for easier analysis of topic popularity and bid distributions.[[File:BidsGraph.png|850px]]
## Styled the graph to ensure clear data representation and seamless integration with the user interface.[[File:Biddstable.png|850px]]
# '''Download Functionality'''
## Added a Download CSV button to allow users to export bidding results in CSV format for external analysis.[[File:DownloadCsvCodepng.png|850px]]
## Implemented a Download PDF button to generate a well-formatted PDF report of the bidding results.[[File:DownloadPdfCode.png|850px]]
# '''Navigation and Accessibility Enhancements''' :
##Introduced a direct link from the assignment details page to the bidding results, eliminating the need for manual navigation[[File:AssignmentPageForBidding.png|850px]]
# '''Code and Maintainability Improvements''' :
##Conducted unit testing and manual testing to ensure all implemented features functioned as intended and provided a seamless user experience.

These changes collectively enhance the usability and efficiency of the topic bidding results feature, making it easier for instructors and students to analyze bidding outcomes and make informed decisions.

== Testing ==

This document details the test suite for the View Bid functionality, which allows students to access bidding information for projects. The tests ensure that:

# Only users with the Student role can see and access the View Bid link in the navigation, while the instructors and the admin have to access the view bid page through a different method.
# The BiddingPage component renders correctly and displays project bidding data
# The role-based access controls are working properly

'''Test Framework and Structure'''

'''The tests are organized into three main files:'''
# BiddingPage.test.tsx: Unit tests for the BiddingPage component
# Header.test.tsx: Unit tests for the header component with focus on the View Bid link
# ViewBid.integration.test.tsx: Integration tests for View Bid functionality across components

'''BiddingPage Component Tests (src/pages/Bidding/BiddingPage.test.tsx)'''
These tests focus on the UI and functionality of the BiddingPage component.
# renders the page title correctly - Ensures that components like main heading "Assignment Bidding Summary by Priority" appears on the page without crashing
# renders all topic cards from the data - Verifies that all topics from the mock data are rendered as cards and their details are displayed correctly
# displays bid statistics in each card - Tests that each topic card displays the expected bidding statistics
# Verifies the total bids count is displayed - Verifies that the PDF download button is present in the modal

'''Header Component Tests (src/layout/Header.test.tsx)'''
These tests focus on the role-based visibility of the View Bid link in the header.
# Should show "View Bid" link for users with Student role
# Should not show "View Bid" link for users with Instructor and Admin role

'''Integration Tests (src/tests/ViewBid.integration.test.tsx)'''
These tests verify the interaction between components and role-based access controls.
# Non-student users should not see View Bid link
# Protected route redirects non-students trying to access bidding page directly

'''Steps to Run all tests'''
npm test
'''Run specific test files'''
npm test src/pages/Bidding/BiddingPage.test.tsx - Tests BiddingPage Components
[[File:BiddingPageTest.png|600px]]
npm test src/layout/Header.test.tsx - Header Component
[[File:HeaderPage.png|600px]]
npm test src/tests/ViewBid.integration.test.tsx - Performs Integration Tests
[[File:ViewBid.png|600px]]

== Opportunities for Additional Future Enhancements ==

There are several areas where the current implementation can be improved or extended in the future:

# '''Integrate Actual API Call:''' Currently, the data used is static. Integrating the frontend with the actual backend API will ensure real-time and dynamic data population.
# '''Implement RBAC Control for Download Functionality:''' To enhance security and maintain data privacy, Role-Based Access Control (RBAC) can be enforced on the PDF download feature. This ensures only authorized users can access sensitive information.
# '''Support Dynamic Priority Handling:''' At present, the system assumes exactly three priority levels. To make the implementation more robust, it should be refactored to handle any number of priority levels dynamically, based on the data received.

== Team ==

=== Mentors ===
* Mitesh Anil Agarwal
* Kartiki Bhandakkar

=== Members ===
* [https://github.com/jappurohit041 Jap Ashokbhai Purohit (Unity ID: jpurohi)]
* [https://github.com/prithishsamanta Prithish Samanta (Unity ID: psamant2)]
* [https://github.com/SharmeenMomin Sharmeen Momin (Unity ID: smomin)]

== Links ==

* '''Pull Request:''' [https://github.com/expertiza/reimplementation-front-end/pull/90 Frontend Reimplementation - PR #90]
Contains the code changes and discussion related to the implemented feature.

* '''Demo Video:''' [https://www.loom.com/share/e6fd5fb07ba64b208f1ecc93294491cb?sid=6d68e33c-28c7-4b83-ba81-8cdfab937443 Loom Recording]
Walkthrough of the functionality implemented in the PR.

* '''Requirement Document:''' [https://docs.google.com/document/d/1fVX5AytpMz0hns-1xnLshwHz94UW_aEXJI5VVdju1cc/edit?tab=t.0 Google Doc]
Outlines the requirements and scope for the feature.

== References ==

* [https://html2canvas.hertzen.com/ html2canvas] – A JavaScript library that allows you to take "screenshots" of webpages or parts of them, rendering HTML content to canvas.

* [https://github.com/parallax/jsPDF jsPDF] – A client-side JavaScript library used to generate PDF documents.

* [https://github.com/simonbengtsson/jsPDF-AutoTable jsPDF-AutoTable] – A plugin for jsPDF that enables generation of tables with support for styling, column spanning, and automatic page breaking.

CSC/ECE 517 Fall 2024 - E2519. Implement view for results of bidding

2025-03-24T04:37:41Z

Psamant2: /* Our Changes */

== Introduction ==
Expertiza is an open-source platform that educational institutions use to create, assign, and manage assignments and peer assessments. To enhance its functionality, our team improved the existing implementation of the topic bidding results feature.

The original implementation ('''''E2459''''') attempted to address the issue where instructors could only monitor topic bidding by impersonating students, making it difficult to verify whether the bidding assignment algorithm correctly assigned teams to topics. However, the previous solution did not function as intended.

This project focuses on developing the bidding page again with a better view, enhancing usability, and ensuring better code maintainability. Key improvements making the user interface better, showing vital information that would help the user analyze the projected data easily, optimizing the topic bidding table layout for readability, adding info buttons for better context, improving test cases, and refactoring the code for efficiency.

With these enhancements, instructors and students will have a seamless experience navigating the topic bidding results, making the process more transparent, accessible, and easier to interpret. This project significantly improves the usability of the platform, empowering users with better tools for decision-making.

== Problem Statement ==
TODO: Problem Statement
The existing topic bidding results feature in Expertiza lacks usability and effectiveness, making it difficult for instructors to monitor and analyze the bidding process efficiently. The current implementation requires instructors to impersonate students to view bidding statuses, which is cumbersome and does not provide a clear overview of how topics are assigned. Additionally, the previous attempt (E2459) to address this issue failed to function as intended, leaving gaps in usability and functionality.

Key issues with the current system include:

1. Lack of visibility – Instructors cannot easily track topic allocations and bidding outcomes.

2. Poor data presentation – The information displayed is not structured in a way that facilitates easy analysis.

3. Limited context – Users do not receive sufficient guidance or explanations for the bidding process.

4. Code inefficiencies – The existing implementation lacks maintainability, making future enhancements difficult.

This project aims to come up with an entirely new design and improve the topic bidding results feature by addressing these challenges, ensuring a more user-friendly, informative, and efficient experience for both instructors and students.

== Objectives ==

The primary objective of this project is to enhance the topic bidding results feature in Expertiza by improving its usability, accessibility, and maintainability. Specifically, our goals include:

1. Improve User Interface & Experience – Redesign the bidding results page with a structured layout that presents information clearly and intuitively.

2. Enhance Data Visualization – Display essential bidding-related data in a format that is easy to interpret, allowing users to analyze assignments effectively.

3. Optimize Table Layout – Improve the readability of the topic bidding table to facilitate better decision-making.

4. Provide Contextual Information – Introduce info buttons and tooltips to help users understand the bidding process and related data.

5. Develop and Document Code for Maintainability – Enhance the efficiency and structure of the codebase to support future updates and scalability.

By achieving these objectives, this project aims to provide instructors and students with a seamless and transparent way to view and analyze topic bidding results, improving their overall experience on the platform.

== Steps To Run The Project ==

In order to run the application, one should have Node.js installed in their local.

In order to run the application, run the below commands.

1. npm install - this installs all dependencies listed in the package.json file for a Node.js project

2. npm start - This runs the app in the development mode.

== Our Changes ==
As part of our efforts to improve the topic bidding results feature in Expertiza, we introduced several key enhancements to enhance usability, visualization, and accessibility. The following changes were implemented:

# '''User Interface Enhancements'''
## Replaced the traditional table format with a card-based view for better readability and a more modern interface.[[File:BidsPage.png|800px]]
## Styled the card view with improved layouts, ensuring a more intuitive display of bidding details.
## Integrated modals to display detailed bid and team information upon clicking a card. [[File:BidsModel.png|700px]]
# '''Data Visualization Improvements'''
## Implemented bar graphs to visually represent bidding trends, allowing for easier analysis of topic popularity and bid distributions.[[File:BidsGraph.png|850px]]
## Styled the graph to ensure clear data representation and seamless integration with the user interface.[[File:Biddstable.png|850px]]
# '''Download Functionality'''
## Added a Download CSV button to allow users to export bidding results in CSV format for external analysis.[[File:DownloadCsvCodepng.png|850px]]
## Implemented a Download PDF button to generate a well-formatted PDF report of the bidding results.[[File:DownloadPdfCode.png|850px]]
# '''Navigation and Accessibility Enhancements''' :
##Introduced a direct link from the assignment details page to the bidding results, eliminating the need for manual navigation[[File:AssignmentPageForBidding.png|850px]]
# '''Code and Maintainability Improvements''' :
##Conducted unit testing and manual testing to ensure all implemented features functioned as intended and provided a seamless user experience.

These changes collectively enhance the usability and efficiency of the topic bidding results feature, making it easier for instructors and students to analyze bidding outcomes and make informed decisions.

== Testing ==

This document details the test suite for the View Bid functionality, which allows students to access bidding information for projects. The tests ensure that:

# Only users with the Student role can see and access the View Bid link in the navigation, while the instructors and the admin have to access the view bid page through a different method.
# The BiddingPage component renders correctly and displays project bidding data
# The role-based access controls are working properly

'''Test Framework and Structure'''

'''The tests are organized into three main files:'''
# BiddingPage.test.tsx: Unit tests for the BiddingPage component
# Header.test.tsx: Unit tests for the header component with focus on the View Bid link
# ViewBid.integration.test.tsx: Integration tests for View Bid functionality across components

'''BiddingPage Component Tests (src/pages/Bidding/BiddingPage.test.tsx)'''
These tests focus on the UI and functionality of the BiddingPage component.
# renders the page title correctly - Ensures that components like main heading "Assignment Bidding Summary by Priority" appears on the page without crashing
# renders all topic cards from the data - Verifies that all topics from the mock data are rendered as cards and their details are displayed correctly
# displays bid statistics in each card - Tests that each topic card displays the expected bidding statistics
# Verifies the total bids count is displayed - Verifies that the PDF download button is present in the modal

'''Header Component Tests (src/layout/Header.test.tsx)'''
These tests focus on the role-based visibility of the View Bid link in the header.
# Should show "View Bid" link for users with Student role
# Should not show "View Bid" link for users with Instructor and Admin role

'''Integration Tests (src/tests/ViewBid.integration.test.tsx)'''
These tests verify the interaction between components and role-based access controls.
# Non-student users should not see View Bid link
# Protected route redirects non-students trying to access bidding page directly

'''Steps to Run all tests'''
npm test
'''Run specific test files'''
npm test src/pages/Bidding/BiddingPage.test.tsx - Tests BiddingPage Components
[[File:BiddingPageTest.png|600px]]
npm test src/layout/Header.test.tsx - Header Component
[[File:HeaderPage.png|600px]]
npm test src/tests/ViewBid.integration.test.tsx - Performs Integration Tests
[[File:ViewBid.png|600px]]

== Opportunities for Additional Future Enhancements ==

There are several areas where the current implementation can be improved or extended in the future:

# '''Integrate Actual API Call:''' Currently, the data used is static. Integrating the frontend with the actual backend API will ensure real-time and dynamic data population.
# '''Implement RBAC Control for Download Functionality:''' To enhance security and maintain data privacy, Role-Based Access Control (RBAC) can be enforced on the PDF download feature. This ensures only authorized users can access sensitive information.
# '''Support Dynamic Priority Handling:''' At present, the system assumes exactly three priority levels. To make the implementation more robust, it should be refactored to handle any number of priority levels dynamically, based on the data received.

== Team ==

=== Mentors ===
* Mitesh Anil Agarwal
* Kartiki Bhandakkar

=== Members ===
* [https://github.com/jappurohit041 Jap Ashokbhai Purohit (Unity ID: jpurohi)]
* [https://github.com/prithishsamanta Prithish Samanta (Unity ID: psamant2)]
* [https://github.com/SharmeenMomin Sharmeen Momin (Unity ID: smomin)]

== Links ==

* '''Pull Request:''' [https://github.com/expertiza/reimplementation-front-end/pull/90 Frontend Reimplementation - PR #90]
Contains the code changes and discussion related to the implemented feature.

* '''Demo Video:''' [https://www.loom.com/share/e6fd5fb07ba64b208f1ecc93294491cb?sid=6d68e33c-28c7-4b83-ba81-8cdfab937443 Loom Recording]
Walkthrough of the functionality implemented in the PR.

* '''Requirement Document:''' [https://docs.google.com/document/d/1fVX5AytpMz0hns-1xnLshwHz94UW_aEXJI5VVdju1cc/edit?tab=t.0 Google Doc]
Outlines the requirements and scope for the feature.

== References ==

* [https://html2canvas.hertzen.com/ html2canvas] – A JavaScript library that allows you to take "screenshots" of webpages or parts of them, rendering HTML content to canvas.

* [https://github.com/parallax/jsPDF jsPDF] – A client-side JavaScript library used to generate PDF documents.

* [https://github.com/simonbengtsson/jsPDF-AutoTable jsPDF-AutoTable] – A plugin for jsPDF that enables generation of tables with support for styling, column spanning, and automatic page breaking.

CSC/ECE 517 Fall 2024 - E2519. Implement view for results of bidding

2025-03-24T04:37:17Z

Psamant2: /* Our Changes */

== Introduction ==
Expertiza is an open-source platform that educational institutions use to create, assign, and manage assignments and peer assessments. To enhance its functionality, our team improved the existing implementation of the topic bidding results feature.

The original implementation ('''''E2459''''') attempted to address the issue where instructors could only monitor topic bidding by impersonating students, making it difficult to verify whether the bidding assignment algorithm correctly assigned teams to topics. However, the previous solution did not function as intended.

This project focuses on developing the bidding page again with a better view, enhancing usability, and ensuring better code maintainability. Key improvements making the user interface better, showing vital information that would help the user analyze the projected data easily, optimizing the topic bidding table layout for readability, adding info buttons for better context, improving test cases, and refactoring the code for efficiency.

With these enhancements, instructors and students will have a seamless experience navigating the topic bidding results, making the process more transparent, accessible, and easier to interpret. This project significantly improves the usability of the platform, empowering users with better tools for decision-making.

== Problem Statement ==
TODO: Problem Statement
The existing topic bidding results feature in Expertiza lacks usability and effectiveness, making it difficult for instructors to monitor and analyze the bidding process efficiently. The current implementation requires instructors to impersonate students to view bidding statuses, which is cumbersome and does not provide a clear overview of how topics are assigned. Additionally, the previous attempt (E2459) to address this issue failed to function as intended, leaving gaps in usability and functionality.

Key issues with the current system include:

1. Lack of visibility – Instructors cannot easily track topic allocations and bidding outcomes.

2. Poor data presentation – The information displayed is not structured in a way that facilitates easy analysis.

3. Limited context – Users do not receive sufficient guidance or explanations for the bidding process.

4. Code inefficiencies – The existing implementation lacks maintainability, making future enhancements difficult.

This project aims to come up with an entirely new design and improve the topic bidding results feature by addressing these challenges, ensuring a more user-friendly, informative, and efficient experience for both instructors and students.

== Objectives ==

The primary objective of this project is to enhance the topic bidding results feature in Expertiza by improving its usability, accessibility, and maintainability. Specifically, our goals include:

1. Improve User Interface & Experience – Redesign the bidding results page with a structured layout that presents information clearly and intuitively.

2. Enhance Data Visualization – Display essential bidding-related data in a format that is easy to interpret, allowing users to analyze assignments effectively.

3. Optimize Table Layout – Improve the readability of the topic bidding table to facilitate better decision-making.

4. Provide Contextual Information – Introduce info buttons and tooltips to help users understand the bidding process and related data.

5. Develop and Document Code for Maintainability – Enhance the efficiency and structure of the codebase to support future updates and scalability.

By achieving these objectives, this project aims to provide instructors and students with a seamless and transparent way to view and analyze topic bidding results, improving their overall experience on the platform.

== Steps To Run The Project ==

In order to run the application, one should have Node.js installed in their local.

In order to run the application, run the below commands.

1. npm install - this installs all dependencies listed in the package.json file for a Node.js project

2. npm start - This runs the app in the development mode.

== Our Changes ==
As part of our efforts to improve the topic bidding results feature in Expertiza, we introduced several key enhancements to enhance usability, visualization, and accessibility. The following changes were implemented:

# '''User Interface Enhancements'''
## Replaced the traditional table format with a card-based view for better readability and a more modern interface.[[File:BidsPage.png|800px]]
## Styled the card view with improved layouts, ensuring a more intuitive display of bidding details.
## Integrated modals to display detailed bid and team information upon clicking a card.
[[File:BidsModel.png|850px]]
# '''Data Visualization Improvements'''
## Implemented bar graphs to visually represent bidding trends, allowing for easier analysis of topic popularity and bid distributions.[[File:BidsGraph.png|850px]]
## Styled the graph to ensure clear data representation and seamless integration with the user interface.[[File:Biddstable.png|850px]]
# '''Download Functionality'''
## Added a Download CSV button to allow users to export bidding results in CSV format for external analysis.[[File:DownloadCsvCodepng.png|850px]]
## Implemented a Download PDF button to generate a well-formatted PDF report of the bidding results.[[File:DownloadPdfCode.png|850px]]
# '''Navigation and Accessibility Enhancements''' :
##Introduced a direct link from the assignment details page to the bidding results, eliminating the need for manual navigation[[File:AssignmentPageForBidding.png|850px]]
# '''Code and Maintainability Improvements''' :
##Conducted unit testing and manual testing to ensure all implemented features functioned as intended and provided a seamless user experience.

These changes collectively enhance the usability and efficiency of the topic bidding results feature, making it easier for instructors and students to analyze bidding outcomes and make informed decisions.

== Testing ==

This document details the test suite for the View Bid functionality, which allows students to access bidding information for projects. The tests ensure that:

# Only users with the Student role can see and access the View Bid link in the navigation, while the instructors and the admin have to access the view bid page through a different method.
# The BiddingPage component renders correctly and displays project bidding data
# The role-based access controls are working properly

'''Test Framework and Structure'''

'''The tests are organized into three main files:'''
# BiddingPage.test.tsx: Unit tests for the BiddingPage component
# Header.test.tsx: Unit tests for the header component with focus on the View Bid link
# ViewBid.integration.test.tsx: Integration tests for View Bid functionality across components

'''BiddingPage Component Tests (src/pages/Bidding/BiddingPage.test.tsx)'''
These tests focus on the UI and functionality of the BiddingPage component.
# renders the page title correctly - Ensures that components like main heading "Assignment Bidding Summary by Priority" appears on the page without crashing
# renders all topic cards from the data - Verifies that all topics from the mock data are rendered as cards and their details are displayed correctly
# displays bid statistics in each card - Tests that each topic card displays the expected bidding statistics
# Verifies the total bids count is displayed - Verifies that the PDF download button is present in the modal

'''Header Component Tests (src/layout/Header.test.tsx)'''
These tests focus on the role-based visibility of the View Bid link in the header.
# Should show "View Bid" link for users with Student role
# Should not show "View Bid" link for users with Instructor and Admin role

'''Integration Tests (src/tests/ViewBid.integration.test.tsx)'''
These tests verify the interaction between components and role-based access controls.
# Non-student users should not see View Bid link
# Protected route redirects non-students trying to access bidding page directly

'''Steps to Run all tests'''
npm test
'''Run specific test files'''
npm test src/pages/Bidding/BiddingPage.test.tsx - Tests BiddingPage Components
[[File:BiddingPageTest.png|600px]]
npm test src/layout/Header.test.tsx - Header Component
[[File:HeaderPage.png|600px]]
npm test src/tests/ViewBid.integration.test.tsx - Performs Integration Tests
[[File:ViewBid.png|600px]]

== Opportunities for Additional Future Enhancements ==

There are several areas where the current implementation can be improved or extended in the future:

# '''Integrate Actual API Call:''' Currently, the data used is static. Integrating the frontend with the actual backend API will ensure real-time and dynamic data population.
# '''Implement RBAC Control for Download Functionality:''' To enhance security and maintain data privacy, Role-Based Access Control (RBAC) can be enforced on the PDF download feature. This ensures only authorized users can access sensitive information.
# '''Support Dynamic Priority Handling:''' At present, the system assumes exactly three priority levels. To make the implementation more robust, it should be refactored to handle any number of priority levels dynamically, based on the data received.

== Team ==

=== Mentors ===
* Mitesh Anil Agarwal
* Kartiki Bhandakkar

=== Members ===
* [https://github.com/jappurohit041 Jap Ashokbhai Purohit (Unity ID: jpurohi)]
* [https://github.com/prithishsamanta Prithish Samanta (Unity ID: psamant2)]
* [https://github.com/SharmeenMomin Sharmeen Momin (Unity ID: smomin)]

== Links ==

* '''Pull Request:''' [https://github.com/expertiza/reimplementation-front-end/pull/90 Frontend Reimplementation - PR #90]
Contains the code changes and discussion related to the implemented feature.

* '''Demo Video:''' [https://www.loom.com/share/e6fd5fb07ba64b208f1ecc93294491cb?sid=6d68e33c-28c7-4b83-ba81-8cdfab937443 Loom Recording]
Walkthrough of the functionality implemented in the PR.

* '''Requirement Document:''' [https://docs.google.com/document/d/1fVX5AytpMz0hns-1xnLshwHz94UW_aEXJI5VVdju1cc/edit?tab=t.0 Google Doc]
Outlines the requirements and scope for the feature.

== References ==

* [https://html2canvas.hertzen.com/ html2canvas] – A JavaScript library that allows you to take "screenshots" of webpages or parts of them, rendering HTML content to canvas.

* [https://github.com/parallax/jsPDF jsPDF] – A client-side JavaScript library used to generate PDF documents.

* [https://github.com/simonbengtsson/jsPDF-AutoTable jsPDF-AutoTable] – A plugin for jsPDF that enables generation of tables with support for styling, column spanning, and automatic page breaking.

CSC/ECE 517 Fall 2024 - E2519. Implement view for results of bidding

2025-03-24T04:36:58Z

Psamant2: /* Our Changes */

== Introduction ==
Expertiza is an open-source platform that educational institutions use to create, assign, and manage assignments and peer assessments. To enhance its functionality, our team improved the existing implementation of the topic bidding results feature.

The original implementation ('''''E2459''''') attempted to address the issue where instructors could only monitor topic bidding by impersonating students, making it difficult to verify whether the bidding assignment algorithm correctly assigned teams to topics. However, the previous solution did not function as intended.

This project focuses on developing the bidding page again with a better view, enhancing usability, and ensuring better code maintainability. Key improvements making the user interface better, showing vital information that would help the user analyze the projected data easily, optimizing the topic bidding table layout for readability, adding info buttons for better context, improving test cases, and refactoring the code for efficiency.

With these enhancements, instructors and students will have a seamless experience navigating the topic bidding results, making the process more transparent, accessible, and easier to interpret. This project significantly improves the usability of the platform, empowering users with better tools for decision-making.

== Problem Statement ==
TODO: Problem Statement
The existing topic bidding results feature in Expertiza lacks usability and effectiveness, making it difficult for instructors to monitor and analyze the bidding process efficiently. The current implementation requires instructors to impersonate students to view bidding statuses, which is cumbersome and does not provide a clear overview of how topics are assigned. Additionally, the previous attempt (E2459) to address this issue failed to function as intended, leaving gaps in usability and functionality.

Key issues with the current system include:

1. Lack of visibility – Instructors cannot easily track topic allocations and bidding outcomes.

2. Poor data presentation – The information displayed is not structured in a way that facilitates easy analysis.

3. Limited context – Users do not receive sufficient guidance or explanations for the bidding process.

4. Code inefficiencies – The existing implementation lacks maintainability, making future enhancements difficult.

This project aims to come up with an entirely new design and improve the topic bidding results feature by addressing these challenges, ensuring a more user-friendly, informative, and efficient experience for both instructors and students.

== Objectives ==

The primary objective of this project is to enhance the topic bidding results feature in Expertiza by improving its usability, accessibility, and maintainability. Specifically, our goals include:

1. Improve User Interface & Experience – Redesign the bidding results page with a structured layout that presents information clearly and intuitively.

2. Enhance Data Visualization – Display essential bidding-related data in a format that is easy to interpret, allowing users to analyze assignments effectively.

3. Optimize Table Layout – Improve the readability of the topic bidding table to facilitate better decision-making.

4. Provide Contextual Information – Introduce info buttons and tooltips to help users understand the bidding process and related data.

5. Develop and Document Code for Maintainability – Enhance the efficiency and structure of the codebase to support future updates and scalability.

By achieving these objectives, this project aims to provide instructors and students with a seamless and transparent way to view and analyze topic bidding results, improving their overall experience on the platform.

== Steps To Run The Project ==

In order to run the application, one should have Node.js installed in their local.

In order to run the application, run the below commands.

1. npm install - this installs all dependencies listed in the package.json file for a Node.js project

2. npm start - This runs the app in the development mode.

== Our Changes ==
As part of our efforts to improve the topic bidding results feature in Expertiza, we introduced several key enhancements to enhance usability, visualization, and accessibility. The following changes were implemented:

# '''User Interface Enhancements'''
## Replaced the traditional table format with a card-based view for better readability and a more modern interface.[[File:BidsPage.png|800px]]
## Styled the card view with improved layouts, ensuring a more intuitive display of bidding details.
## Integrated modals to display detailed bid and team information upon clicking a card.[[File:BidsModel.png|850px]]
# '''Data Visualization Improvements'''
## Implemented bar graphs to visually represent bidding trends, allowing for easier analysis of topic popularity and bid distributions.[[File:BidsGraph.png|850px]]
## Styled the graph to ensure clear data representation and seamless integration with the user interface.[[File:Biddstable.png|850px]]
# '''Download Functionality'''
## Added a Download CSV button to allow users to export bidding results in CSV format for external analysis.[[File:DownloadCsvCodepng.png|850px]]
## Implemented a Download PDF button to generate a well-formatted PDF report of the bidding results.[[File:DownloadPdfCode.png|850px]]
# '''Navigation and Accessibility Enhancements''' :
##Introduced a direct link from the assignment details page to the bidding results, eliminating the need for manual navigation[[File:AssignmentPageForBidding.png|850px]]
# '''Code and Maintainability Improvements''' :
##Conducted unit testing and manual testing to ensure all implemented features functioned as intended and provided a seamless user experience.

These changes collectively enhance the usability and efficiency of the topic bidding results feature, making it easier for instructors and students to analyze bidding outcomes and make informed decisions.

== Testing ==

This document details the test suite for the View Bid functionality, which allows students to access bidding information for projects. The tests ensure that:

# Only users with the Student role can see and access the View Bid link in the navigation, while the instructors and the admin have to access the view bid page through a different method.
# The BiddingPage component renders correctly and displays project bidding data
# The role-based access controls are working properly

'''Test Framework and Structure'''

'''The tests are organized into three main files:'''
# BiddingPage.test.tsx: Unit tests for the BiddingPage component
# Header.test.tsx: Unit tests for the header component with focus on the View Bid link
# ViewBid.integration.test.tsx: Integration tests for View Bid functionality across components

'''BiddingPage Component Tests (src/pages/Bidding/BiddingPage.test.tsx)'''
These tests focus on the UI and functionality of the BiddingPage component.
# renders the page title correctly - Ensures that components like main heading "Assignment Bidding Summary by Priority" appears on the page without crashing
# renders all topic cards from the data - Verifies that all topics from the mock data are rendered as cards and their details are displayed correctly
# displays bid statistics in each card - Tests that each topic card displays the expected bidding statistics
# Verifies the total bids count is displayed - Verifies that the PDF download button is present in the modal

'''Header Component Tests (src/layout/Header.test.tsx)'''
These tests focus on the role-based visibility of the View Bid link in the header.
# Should show "View Bid" link for users with Student role
# Should not show "View Bid" link for users with Instructor and Admin role

'''Integration Tests (src/tests/ViewBid.integration.test.tsx)'''
These tests verify the interaction between components and role-based access controls.
# Non-student users should not see View Bid link
# Protected route redirects non-students trying to access bidding page directly

'''Steps to Run all tests'''
npm test
'''Run specific test files'''
npm test src/pages/Bidding/BiddingPage.test.tsx - Tests BiddingPage Components
[[File:BiddingPageTest.png|600px]]
npm test src/layout/Header.test.tsx - Header Component
[[File:HeaderPage.png|600px]]
npm test src/tests/ViewBid.integration.test.tsx - Performs Integration Tests
[[File:ViewBid.png|600px]]

== Opportunities for Additional Future Enhancements ==

There are several areas where the current implementation can be improved or extended in the future:

# '''Integrate Actual API Call:''' Currently, the data used is static. Integrating the frontend with the actual backend API will ensure real-time and dynamic data population.
# '''Implement RBAC Control for Download Functionality:''' To enhance security and maintain data privacy, Role-Based Access Control (RBAC) can be enforced on the PDF download feature. This ensures only authorized users can access sensitive information.
# '''Support Dynamic Priority Handling:''' At present, the system assumes exactly three priority levels. To make the implementation more robust, it should be refactored to handle any number of priority levels dynamically, based on the data received.

== Team ==

=== Mentors ===
* Mitesh Anil Agarwal
* Kartiki Bhandakkar

=== Members ===
* [https://github.com/jappurohit041 Jap Ashokbhai Purohit (Unity ID: jpurohi)]
* [https://github.com/prithishsamanta Prithish Samanta (Unity ID: psamant2)]
* [https://github.com/SharmeenMomin Sharmeen Momin (Unity ID: smomin)]

== Links ==

* '''Pull Request:''' [https://github.com/expertiza/reimplementation-front-end/pull/90 Frontend Reimplementation - PR #90]
Contains the code changes and discussion related to the implemented feature.

* '''Demo Video:''' [https://www.loom.com/share/e6fd5fb07ba64b208f1ecc93294491cb?sid=6d68e33c-28c7-4b83-ba81-8cdfab937443 Loom Recording]
Walkthrough of the functionality implemented in the PR.

* '''Requirement Document:''' [https://docs.google.com/document/d/1fVX5AytpMz0hns-1xnLshwHz94UW_aEXJI5VVdju1cc/edit?tab=t.0 Google Doc]
Outlines the requirements and scope for the feature.

== References ==

* [https://html2canvas.hertzen.com/ html2canvas] – A JavaScript library that allows you to take "screenshots" of webpages or parts of them, rendering HTML content to canvas.

* [https://github.com/parallax/jsPDF jsPDF] – A client-side JavaScript library used to generate PDF documents.

* [https://github.com/simonbengtsson/jsPDF-AutoTable jsPDF-AutoTable] – A plugin for jsPDF that enables generation of tables with support for styling, column spanning, and automatic page breaking.

CSC/ECE 517 Fall 2024 - E2519. Implement view for results of bidding

2025-03-24T04:36:16Z

Psamant2: /* Our Changes */

== Introduction ==
Expertiza is an open-source platform that educational institutions use to create, assign, and manage assignments and peer assessments. To enhance its functionality, our team improved the existing implementation of the topic bidding results feature.

The original implementation ('''''E2459''''') attempted to address the issue where instructors could only monitor topic bidding by impersonating students, making it difficult to verify whether the bidding assignment algorithm correctly assigned teams to topics. However, the previous solution did not function as intended.

This project focuses on developing the bidding page again with a better view, enhancing usability, and ensuring better code maintainability. Key improvements making the user interface better, showing vital information that would help the user analyze the projected data easily, optimizing the topic bidding table layout for readability, adding info buttons for better context, improving test cases, and refactoring the code for efficiency.

With these enhancements, instructors and students will have a seamless experience navigating the topic bidding results, making the process more transparent, accessible, and easier to interpret. This project significantly improves the usability of the platform, empowering users with better tools for decision-making.

== Problem Statement ==
TODO: Problem Statement
The existing topic bidding results feature in Expertiza lacks usability and effectiveness, making it difficult for instructors to monitor and analyze the bidding process efficiently. The current implementation requires instructors to impersonate students to view bidding statuses, which is cumbersome and does not provide a clear overview of how topics are assigned. Additionally, the previous attempt (E2459) to address this issue failed to function as intended, leaving gaps in usability and functionality.

Key issues with the current system include:

1. Lack of visibility – Instructors cannot easily track topic allocations and bidding outcomes.

2. Poor data presentation – The information displayed is not structured in a way that facilitates easy analysis.

3. Limited context – Users do not receive sufficient guidance or explanations for the bidding process.

4. Code inefficiencies – The existing implementation lacks maintainability, making future enhancements difficult.

This project aims to come up with an entirely new design and improve the topic bidding results feature by addressing these challenges, ensuring a more user-friendly, informative, and efficient experience for both instructors and students.

== Objectives ==

The primary objective of this project is to enhance the topic bidding results feature in Expertiza by improving its usability, accessibility, and maintainability. Specifically, our goals include:

1. Improve User Interface & Experience – Redesign the bidding results page with a structured layout that presents information clearly and intuitively.

2. Enhance Data Visualization – Display essential bidding-related data in a format that is easy to interpret, allowing users to analyze assignments effectively.

3. Optimize Table Layout – Improve the readability of the topic bidding table to facilitate better decision-making.

4. Provide Contextual Information – Introduce info buttons and tooltips to help users understand the bidding process and related data.

5. Develop and Document Code for Maintainability – Enhance the efficiency and structure of the codebase to support future updates and scalability.

By achieving these objectives, this project aims to provide instructors and students with a seamless and transparent way to view and analyze topic bidding results, improving their overall experience on the platform.

== Steps To Run The Project ==

In order to run the application, one should have Node.js installed in their local.

In order to run the application, run the below commands.

1. npm install - this installs all dependencies listed in the package.json file for a Node.js project

2. npm start - This runs the app in the development mode.

== Our Changes ==
As part of our efforts to improve the topic bidding results feature in Expertiza, we introduced several key enhancements to enhance usability, visualization, and accessibility. The following changes were implemented:

# '''User Interface Enhancements'''
## Replaced the traditional table format with a card-based view for better readability and a more modern interface.[[File:BidsPage.png|800px]]
## Styled the card view with improved layouts, ensuring a more intuitive display of bidding details.
## Integrated modals to display detailed bid and team information upon clicking a card. [[File:BidsModel.png|850px]]
# '''Data Visualization Improvements'''
## Implemented bar graphs to visually represent bidding trends, allowing for easier analysis of topic popularity and bid distributions.[[File:BidsGraph.png|850px]]
## Styled the graph to ensure clear data representation and seamless integration with the user interface.[[File:Biddstable.png|850px]]
# '''Download Functionality'''
## Added a Download CSV button to allow users to export bidding results in CSV format for external analysis.[[File:DownloadCsvCodepng.png|850px]]
## Implemented a Download PDF button to generate a well-formatted PDF report of the bidding results.[[File:DownloadPdfCode.png|850px]]
# '''Navigation and Accessibility Enhancements''' :
##Introduced a direct link from the assignment details page to the bidding results, eliminating the need for manual navigation[[File:AssignmentPageForBidding.png|850px]]
# '''Code and Maintainability Improvements''' :
##Conducted unit testing and manual testing to ensure all implemented features functioned as intended and provided a seamless user experience.

These changes collectively enhance the usability and efficiency of the topic bidding results feature, making it easier for instructors and students to analyze bidding outcomes and make informed decisions.

== Testing ==

This document details the test suite for the View Bid functionality, which allows students to access bidding information for projects. The tests ensure that:

# Only users with the Student role can see and access the View Bid link in the navigation, while the instructors and the admin have to access the view bid page through a different method.
# The BiddingPage component renders correctly and displays project bidding data
# The role-based access controls are working properly

'''Test Framework and Structure'''

'''The tests are organized into three main files:'''
# BiddingPage.test.tsx: Unit tests for the BiddingPage component
# Header.test.tsx: Unit tests for the header component with focus on the View Bid link
# ViewBid.integration.test.tsx: Integration tests for View Bid functionality across components

'''BiddingPage Component Tests (src/pages/Bidding/BiddingPage.test.tsx)'''
These tests focus on the UI and functionality of the BiddingPage component.
# renders the page title correctly - Ensures that components like main heading "Assignment Bidding Summary by Priority" appears on the page without crashing
# renders all topic cards from the data - Verifies that all topics from the mock data are rendered as cards and their details are displayed correctly
# displays bid statistics in each card - Tests that each topic card displays the expected bidding statistics
# Verifies the total bids count is displayed - Verifies that the PDF download button is present in the modal

'''Header Component Tests (src/layout/Header.test.tsx)'''
These tests focus on the role-based visibility of the View Bid link in the header.
# Should show "View Bid" link for users with Student role
# Should not show "View Bid" link for users with Instructor and Admin role

'''Integration Tests (src/tests/ViewBid.integration.test.tsx)'''
These tests verify the interaction between components and role-based access controls.
# Non-student users should not see View Bid link
# Protected route redirects non-students trying to access bidding page directly

'''Steps to Run all tests'''
npm test
'''Run specific test files'''
npm test src/pages/Bidding/BiddingPage.test.tsx - Tests BiddingPage Components
[[File:BiddingPageTest.png|600px]]
npm test src/layout/Header.test.tsx - Header Component
[[File:HeaderPage.png|600px]]
npm test src/tests/ViewBid.integration.test.tsx - Performs Integration Tests
[[File:ViewBid.png|600px]]

== Opportunities for Additional Future Enhancements ==

There are several areas where the current implementation can be improved or extended in the future:

# '''Integrate Actual API Call:''' Currently, the data used is static. Integrating the frontend with the actual backend API will ensure real-time and dynamic data population.
# '''Implement RBAC Control for Download Functionality:''' To enhance security and maintain data privacy, Role-Based Access Control (RBAC) can be enforced on the PDF download feature. This ensures only authorized users can access sensitive information.
# '''Support Dynamic Priority Handling:''' At present, the system assumes exactly three priority levels. To make the implementation more robust, it should be refactored to handle any number of priority levels dynamically, based on the data received.

== Team ==

=== Mentors ===
* Mitesh Anil Agarwal
* Kartiki Bhandakkar

=== Members ===
* [https://github.com/jappurohit041 Jap Ashokbhai Purohit (Unity ID: jpurohi)]
* [https://github.com/prithishsamanta Prithish Samanta (Unity ID: psamant2)]
* [https://github.com/SharmeenMomin Sharmeen Momin (Unity ID: smomin)]

== Links ==

* '''Pull Request:''' [https://github.com/expertiza/reimplementation-front-end/pull/90 Frontend Reimplementation - PR #90]
Contains the code changes and discussion related to the implemented feature.

* '''Demo Video:''' [https://www.loom.com/share/e6fd5fb07ba64b208f1ecc93294491cb?sid=6d68e33c-28c7-4b83-ba81-8cdfab937443 Loom Recording]
Walkthrough of the functionality implemented in the PR.

* '''Requirement Document:''' [https://docs.google.com/document/d/1fVX5AytpMz0hns-1xnLshwHz94UW_aEXJI5VVdju1cc/edit?tab=t.0 Google Doc]
Outlines the requirements and scope for the feature.

== References ==

* [https://html2canvas.hertzen.com/ html2canvas] – A JavaScript library that allows you to take "screenshots" of webpages or parts of them, rendering HTML content to canvas.

* [https://github.com/parallax/jsPDF jsPDF] – A client-side JavaScript library used to generate PDF documents.

* [https://github.com/simonbengtsson/jsPDF-AutoTable jsPDF-AutoTable] – A plugin for jsPDF that enables generation of tables with support for styling, column spanning, and automatic page breaking.

CSC/ECE 517 Fall 2024 - E2519. Implement view for results of bidding

2025-03-24T04:35:03Z

Psamant2: /* Testing */

== Introduction ==
Expertiza is an open-source platform that educational institutions use to create, assign, and manage assignments and peer assessments. To enhance its functionality, our team improved the existing implementation of the topic bidding results feature.

The original implementation ('''''E2459''''') attempted to address the issue where instructors could only monitor topic bidding by impersonating students, making it difficult to verify whether the bidding assignment algorithm correctly assigned teams to topics. However, the previous solution did not function as intended.

This project focuses on developing the bidding page again with a better view, enhancing usability, and ensuring better code maintainability. Key improvements making the user interface better, showing vital information that would help the user analyze the projected data easily, optimizing the topic bidding table layout for readability, adding info buttons for better context, improving test cases, and refactoring the code for efficiency.

With these enhancements, instructors and students will have a seamless experience navigating the topic bidding results, making the process more transparent, accessible, and easier to interpret. This project significantly improves the usability of the platform, empowering users with better tools for decision-making.

== Problem Statement ==
TODO: Problem Statement
The existing topic bidding results feature in Expertiza lacks usability and effectiveness, making it difficult for instructors to monitor and analyze the bidding process efficiently. The current implementation requires instructors to impersonate students to view bidding statuses, which is cumbersome and does not provide a clear overview of how topics are assigned. Additionally, the previous attempt (E2459) to address this issue failed to function as intended, leaving gaps in usability and functionality.

Key issues with the current system include:

1. Lack of visibility – Instructors cannot easily track topic allocations and bidding outcomes.

2. Poor data presentation – The information displayed is not structured in a way that facilitates easy analysis.

3. Limited context – Users do not receive sufficient guidance or explanations for the bidding process.

4. Code inefficiencies – The existing implementation lacks maintainability, making future enhancements difficult.

This project aims to come up with an entirely new design and improve the topic bidding results feature by addressing these challenges, ensuring a more user-friendly, informative, and efficient experience for both instructors and students.

== Objectives ==

The primary objective of this project is to enhance the topic bidding results feature in Expertiza by improving its usability, accessibility, and maintainability. Specifically, our goals include:

1. Improve User Interface & Experience – Redesign the bidding results page with a structured layout that presents information clearly and intuitively.

2. Enhance Data Visualization – Display essential bidding-related data in a format that is easy to interpret, allowing users to analyze assignments effectively.

3. Optimize Table Layout – Improve the readability of the topic bidding table to facilitate better decision-making.

4. Provide Contextual Information – Introduce info buttons and tooltips to help users understand the bidding process and related data.

5. Develop and Document Code for Maintainability – Enhance the efficiency and structure of the codebase to support future updates and scalability.

By achieving these objectives, this project aims to provide instructors and students with a seamless and transparent way to view and analyze topic bidding results, improving their overall experience on the platform.

== Steps To Run The Project ==

In order to run the application, one should have Node.js installed in their local.

In order to run the application, run the below commands.

1. npm install - this installs all dependencies listed in the package.json file for a Node.js project

2. npm start - This runs the app in the development mode.

== Our Changes ==
As part of our efforts to improve the topic bidding results feature in Expertiza, we introduced several key enhancements to enhance usability, visualization, and accessibility. The following changes were implemented:

# '''User Interface Enhancements'''
## Replaced the traditional table format with a card-based view for better readability and a more modern interface.[[File:BidsPage.png|850px]]
## Styled the card view with improved layouts, ensuring a more intuitive display of bidding details.
## Integrated modals to display detailed bid and team information upon clicking a card. [[File:BidsModel.png|850px]]
# '''Data Visualization Improvements'''
## Implemented bar graphs to visually represent bidding trends, allowing for easier analysis of topic popularity and bid distributions.[[File:BidsGraph.png|850px]]
## Styled the graph to ensure clear data representation and seamless integration with the user interface.[[File:Biddstable.png|850px]]
# '''Download Functionality'''
## Added a Download CSV button to allow users to export bidding results in CSV format for external analysis.[[File:DownloadCsvCodepng.png|850px]]
## Implemented a Download PDF button to generate a well-formatted PDF report of the bidding results.[[File:DownloadPdfCode.png|850px]]
# '''Navigation and Accessibility Enhancements''' :
##Introduced a direct link from the assignment details page to the bidding results, eliminating the need for manual navigation[[File:AssignmentPageForBidding.png|850px]]
# '''Code and Maintainability Improvements''' :
##Conducted unit testing and manual testing to ensure all implemented features functioned as intended and provided a seamless user experience.

These changes collectively enhance the usability and efficiency of the topic bidding results feature, making it easier for instructors and students to analyze bidding outcomes and make informed decisions.

== Testing ==

This document details the test suite for the View Bid functionality, which allows students to access bidding information for projects. The tests ensure that:

# Only users with the Student role can see and access the View Bid link in the navigation, while the instructors and the admin have to access the view bid page through a different method.
# The BiddingPage component renders correctly and displays project bidding data
# The role-based access controls are working properly

'''Test Framework and Structure'''

'''The tests are organized into three main files:'''
# BiddingPage.test.tsx: Unit tests for the BiddingPage component
# Header.test.tsx: Unit tests for the header component with focus on the View Bid link
# ViewBid.integration.test.tsx: Integration tests for View Bid functionality across components

'''BiddingPage Component Tests (src/pages/Bidding/BiddingPage.test.tsx)'''
These tests focus on the UI and functionality of the BiddingPage component.
# renders the page title correctly - Ensures that components like main heading "Assignment Bidding Summary by Priority" appears on the page without crashing
# renders all topic cards from the data - Verifies that all topics from the mock data are rendered as cards and their details are displayed correctly
# displays bid statistics in each card - Tests that each topic card displays the expected bidding statistics
# Verifies the total bids count is displayed - Verifies that the PDF download button is present in the modal

'''Header Component Tests (src/layout/Header.test.tsx)'''
These tests focus on the role-based visibility of the View Bid link in the header.
# Should show "View Bid" link for users with Student role
# Should not show "View Bid" link for users with Instructor and Admin role

'''Integration Tests (src/tests/ViewBid.integration.test.tsx)'''
These tests verify the interaction between components and role-based access controls.
# Non-student users should not see View Bid link
# Protected route redirects non-students trying to access bidding page directly

'''Steps to Run all tests'''
npm test
'''Run specific test files'''
npm test src/pages/Bidding/BiddingPage.test.tsx - Tests BiddingPage Components
[[File:BiddingPageTest.png|600px]]
npm test src/layout/Header.test.tsx - Header Component
[[File:HeaderPage.png|600px]]
npm test src/tests/ViewBid.integration.test.tsx - Performs Integration Tests
[[File:ViewBid.png|600px]]

== Opportunities for Additional Future Enhancements ==

There are several areas where the current implementation can be improved or extended in the future:

# '''Integrate Actual API Call:''' Currently, the data used is static. Integrating the frontend with the actual backend API will ensure real-time and dynamic data population.
# '''Implement RBAC Control for Download Functionality:''' To enhance security and maintain data privacy, Role-Based Access Control (RBAC) can be enforced on the PDF download feature. This ensures only authorized users can access sensitive information.
# '''Support Dynamic Priority Handling:''' At present, the system assumes exactly three priority levels. To make the implementation more robust, it should be refactored to handle any number of priority levels dynamically, based on the data received.

== Team ==

=== Mentors ===
* Mitesh Anil Agarwal
* Kartiki Bhandakkar

=== Members ===
* [https://github.com/jappurohit041 Jap Ashokbhai Purohit (Unity ID: jpurohi)]
* [https://github.com/prithishsamanta Prithish Samanta (Unity ID: psamant2)]
* [https://github.com/SharmeenMomin Sharmeen Momin (Unity ID: smomin)]

== Links ==

* '''Pull Request:''' [https://github.com/expertiza/reimplementation-front-end/pull/90 Frontend Reimplementation - PR #90]
Contains the code changes and discussion related to the implemented feature.

* '''Demo Video:''' [https://www.loom.com/share/e6fd5fb07ba64b208f1ecc93294491cb?sid=6d68e33c-28c7-4b83-ba81-8cdfab937443 Loom Recording]
Walkthrough of the functionality implemented in the PR.

* '''Requirement Document:''' [https://docs.google.com/document/d/1fVX5AytpMz0hns-1xnLshwHz94UW_aEXJI5VVdju1cc/edit?tab=t.0 Google Doc]
Outlines the requirements and scope for the feature.

== References ==

* [https://html2canvas.hertzen.com/ html2canvas] – A JavaScript library that allows you to take "screenshots" of webpages or parts of them, rendering HTML content to canvas.

* [https://github.com/parallax/jsPDF jsPDF] – A client-side JavaScript library used to generate PDF documents.

* [https://github.com/simonbengtsson/jsPDF-AutoTable jsPDF-AutoTable] – A plugin for jsPDF that enables generation of tables with support for styling, column spanning, and automatic page breaking.

File:ViewBid.png

2025-03-24T04:34:23Z

Psamant2:

CSC/ECE 517 Fall 2024 - E2519. Implement view for results of bidding

2025-03-24T04:34:09Z

Psamant2: /* Testing */

== Introduction ==
Expertiza is an open-source platform that educational institutions use to create, assign, and manage assignments and peer assessments. To enhance its functionality, our team improved the existing implementation of the topic bidding results feature.

The original implementation ('''''E2459''''') attempted to address the issue where instructors could only monitor topic bidding by impersonating students, making it difficult to verify whether the bidding assignment algorithm correctly assigned teams to topics. However, the previous solution did not function as intended.

This project focuses on developing the bidding page again with a better view, enhancing usability, and ensuring better code maintainability. Key improvements making the user interface better, showing vital information that would help the user analyze the projected data easily, optimizing the topic bidding table layout for readability, adding info buttons for better context, improving test cases, and refactoring the code for efficiency.

With these enhancements, instructors and students will have a seamless experience navigating the topic bidding results, making the process more transparent, accessible, and easier to interpret. This project significantly improves the usability of the platform, empowering users with better tools for decision-making.

== Problem Statement ==
TODO: Problem Statement
The existing topic bidding results feature in Expertiza lacks usability and effectiveness, making it difficult for instructors to monitor and analyze the bidding process efficiently. The current implementation requires instructors to impersonate students to view bidding statuses, which is cumbersome and does not provide a clear overview of how topics are assigned. Additionally, the previous attempt (E2459) to address this issue failed to function as intended, leaving gaps in usability and functionality.

Key issues with the current system include:

1. Lack of visibility – Instructors cannot easily track topic allocations and bidding outcomes.

2. Poor data presentation – The information displayed is not structured in a way that facilitates easy analysis.

3. Limited context – Users do not receive sufficient guidance or explanations for the bidding process.

4. Code inefficiencies – The existing implementation lacks maintainability, making future enhancements difficult.

This project aims to come up with an entirely new design and improve the topic bidding results feature by addressing these challenges, ensuring a more user-friendly, informative, and efficient experience for both instructors and students.

== Objectives ==

The primary objective of this project is to enhance the topic bidding results feature in Expertiza by improving its usability, accessibility, and maintainability. Specifically, our goals include:

1. Improve User Interface & Experience – Redesign the bidding results page with a structured layout that presents information clearly and intuitively.

2. Enhance Data Visualization – Display essential bidding-related data in a format that is easy to interpret, allowing users to analyze assignments effectively.

3. Optimize Table Layout – Improve the readability of the topic bidding table to facilitate better decision-making.

4. Provide Contextual Information – Introduce info buttons and tooltips to help users understand the bidding process and related data.

5. Develop and Document Code for Maintainability – Enhance the efficiency and structure of the codebase to support future updates and scalability.

By achieving these objectives, this project aims to provide instructors and students with a seamless and transparent way to view and analyze topic bidding results, improving their overall experience on the platform.

== Steps To Run The Project ==

In order to run the application, one should have Node.js installed in their local.

In order to run the application, run the below commands.

1. npm install - this installs all dependencies listed in the package.json file for a Node.js project

2. npm start - This runs the app in the development mode.

== Our Changes ==
As part of our efforts to improve the topic bidding results feature in Expertiza, we introduced several key enhancements to enhance usability, visualization, and accessibility. The following changes were implemented:

# '''User Interface Enhancements'''
## Replaced the traditional table format with a card-based view for better readability and a more modern interface.[[File:BidsPage.png|850px]]
## Styled the card view with improved layouts, ensuring a more intuitive display of bidding details.
## Integrated modals to display detailed bid and team information upon clicking a card. [[File:BidsModel.png|850px]]
# '''Data Visualization Improvements'''
## Implemented bar graphs to visually represent bidding trends, allowing for easier analysis of topic popularity and bid distributions.[[File:BidsGraph.png|850px]]
## Styled the graph to ensure clear data representation and seamless integration with the user interface.[[File:Biddstable.png|850px]]
# '''Download Functionality'''
## Added a Download CSV button to allow users to export bidding results in CSV format for external analysis.[[File:DownloadCsvCodepng.png|850px]]
## Implemented a Download PDF button to generate a well-formatted PDF report of the bidding results.[[File:DownloadPdfCode.png|850px]]
# '''Navigation and Accessibility Enhancements''' :
##Introduced a direct link from the assignment details page to the bidding results, eliminating the need for manual navigation[[File:AssignmentPageForBidding.png|850px]]
# '''Code and Maintainability Improvements''' :
##Conducted unit testing and manual testing to ensure all implemented features functioned as intended and provided a seamless user experience.

These changes collectively enhance the usability and efficiency of the topic bidding results feature, making it easier for instructors and students to analyze bidding outcomes and make informed decisions.

== Testing ==

This document details the test suite for the View Bid functionality, which allows students to access bidding information for projects. The tests ensure that:

# Only users with the Student role can see and access the View Bid link in the navigation, while the instructors and the admin have to access the view bid page through a different method.
# The BiddingPage component renders correctly and displays project bidding data
# The role-based access controls are working properly

'''Test Framework and Structure'''

'''The tests are organized into three main files:'''
# BiddingPage.test.tsx: Unit tests for the BiddingPage component
# Header.test.tsx: Unit tests for the header component with focus on the View Bid link
# ViewBid.integration.test.tsx: Integration tests for View Bid functionality across components

'''BiddingPage Component Tests (src/pages/Bidding/BiddingPage.test.tsx)'''
These tests focus on the UI and functionality of the BiddingPage component.
# renders the page title correctly - Ensures that components like main heading "Assignment Bidding Summary by Priority" appears on the page without crashing
# renders all topic cards from the data - Verifies that all topics from the mock data are rendered as cards and their details are displayed correctly
# displays bid statistics in each card - Tests that each topic card displays the expected bidding statistics
# Verifies the total bids count is displayed - Verifies that the PDF download button is present in the modal

'''Header Component Tests (src/layout/Header.test.tsx)'''
These tests focus on the role-based visibility of the View Bid link in the header.
# Should show "View Bid" link for users with Student role
# Should not show "View Bid" link for users with Instructor and Admin role

'''Integration Tests (src/tests/ViewBid.integration.test.tsx)'''
These tests verify the interaction between components and role-based access controls.
# Non-student users should not see View Bid link
# Protected route redirects non-students trying to access bidding page directly

'''Steps to Run all tests'''
npm test
'''Run specific test files'''
npm test src/pages/Bidding/BiddingPage.test.tsx - Tests BiddingPage Components
[[File:BiddingPageTest.png|600px]]
npm test src/layout/Header.test.tsx - Header Component
[[File:HeaderPage.png|thumb|600px]]
npm test src/tests/ViewBid.integration.test.tsx - Performs Integration Tests
[[File:ViewBid.png|thumb|600px]]

== Opportunities for Additional Future Enhancements ==

There are several areas where the current implementation can be improved or extended in the future:

# '''Integrate Actual API Call:''' Currently, the data used is static. Integrating the frontend with the actual backend API will ensure real-time and dynamic data population.
# '''Implement RBAC Control for Download Functionality:''' To enhance security and maintain data privacy, Role-Based Access Control (RBAC) can be enforced on the PDF download feature. This ensures only authorized users can access sensitive information.
# '''Support Dynamic Priority Handling:''' At present, the system assumes exactly three priority levels. To make the implementation more robust, it should be refactored to handle any number of priority levels dynamically, based on the data received.

== Team ==

=== Mentors ===
* Mitesh Anil Agarwal
* Kartiki Bhandakkar

=== Members ===
* [https://github.com/jappurohit041 Jap Ashokbhai Purohit (Unity ID: jpurohi)]
* [https://github.com/prithishsamanta Prithish Samanta (Unity ID: psamant2)]
* [https://github.com/SharmeenMomin Sharmeen Momin (Unity ID: smomin)]

== Links ==

* '''Pull Request:''' [https://github.com/expertiza/reimplementation-front-end/pull/90 Frontend Reimplementation - PR #90]
Contains the code changes and discussion related to the implemented feature.

* '''Demo Video:''' [https://www.loom.com/share/e6fd5fb07ba64b208f1ecc93294491cb?sid=6d68e33c-28c7-4b83-ba81-8cdfab937443 Loom Recording]
Walkthrough of the functionality implemented in the PR.

* '''Requirement Document:''' [https://docs.google.com/document/d/1fVX5AytpMz0hns-1xnLshwHz94UW_aEXJI5VVdju1cc/edit?tab=t.0 Google Doc]
Outlines the requirements and scope for the feature.

== References ==

* [https://html2canvas.hertzen.com/ html2canvas] – A JavaScript library that allows you to take "screenshots" of webpages or parts of them, rendering HTML content to canvas.

* [https://github.com/parallax/jsPDF jsPDF] – A client-side JavaScript library used to generate PDF documents.

* [https://github.com/simonbengtsson/jsPDF-AutoTable jsPDF-AutoTable] – A plugin for jsPDF that enables generation of tables with support for styling, column spanning, and automatic page breaking.