Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2025

2025-03-17T18:38:44Z

Magarwa3:

* [[CSC/ECE 517 Fall 2024 - E2508. Reimplement bidding-algorithm web service]]

CSC/ECE 517 Spring 2025

2025-03-17T18:38:36Z

Magarwa3:

* [[CSC/ECE 517 Fall 2024 - E2508. Reimplement bidding-algorithm web service]]
* [[CSC/ECE 517 Fall 2024 - E2505. Reimplement bidding-algorithm web service]]

CSC/ECE 517 Spring 2024 - E2444 Implement Frontend for the Review

2024-04-24T03:28:40Z

Magarwa3: /* reviewData.ts */

== Overview of Expertiza ==
Expertiza, constructed using Ruby on Rails, is an open-source learning management system that offers a diverse array of features. These include the ability to generate assignments, tests, assignment teams, courses, reviews for the assignments, etc. Notably, it excels in providing a comprehensive peer review system, fostering thorough feedback within teams and among group members. The central focus of the project revolves around enhancing the frontend components related to the Review. A specific challenge being tackled involves the reimplementation of the current non-Typescript Review Page to incorporate Typescript and React. Consequently, the team's task is to craft the User Interface for these components using React.js and Typescript.

== Introduction ==
The main objective of this project is to reimplement the front end for the Review view page within Expertiza.

== Problem Statement ==
The following tasks were required for the reimplementation :
#Frontend Reimplementation: Reimplement the frontend of the Review page in React.js and Typescript which is currently in Ruby.
#Seeding of Databse File There should be seeding of 1 file to simulate the review given by a user which will reflect in the Review UI page.
#Removal of Unused Elements: Remove any unused elements such as URLs, color legends, etc., to streamline the interface.
#Improve UI: We aim to improve user experience and interface efficiency by developing a refreshed front end using React JS and TypeScript.

=='''Project 4 - DESIGN DOC'''==

== Design Patterns ==
===Composite Design Pattern:===

By nesting and composing elements like Show-Review, Email etc and others, we can effectively design our Review component by utilising the Composite Design Pattern.

===DRY Principle:===

We want to reduce redundancy by using React's functionality to reuse pre-existing components like Show-Review and Email, in line with the DRY Principle.

=== Single Responsibility Principle (SRP) ===

<li>Each React component will have a single responsibility, such as displaying Reviews, managing file submissions, or handling email options.</li>
<li>Separate concerns such as data fetching, state management, and rendering to improve modularity and maintainability.</li>

===Provider Pattern:===

Our goal is to apply the Provider Pattern to React's Context API so that props can propagate naturally throughout the component hierarchy without requiring explicit prop drilling.

===Observer Pattern:===

Our goal is to take advantage of the Observer Pattern by using hooks like useEffect and useState along with React's Context API to manage component state and side effects efficiently.

===HOC Pattern:===

Routing for new pages can be made more efficient by using the Higher-Order Component pattern, or HOC Pattern. This entails creating functions that take an input component and provide a changed component with routing functionality.

===Mediator Pattern:===

Our goal is to apply the Mediator Pattern in light of the discrepancy between frontend requirements and backend data structures. With this method, we can easily change data as needed to ensure that it is consistent and compatible with the rest of our program.

=== Open/Closed Principle (OCP) ===

*Designing components to be open for extension by allowing for customization or configuration through props or context.
*Ensuring that components can be extended or modified without altering their core functionality by adhering to React's composition model.

== Use Cases ==

The following is a simple decision tree that can help summarize the various user stories that we absolutely must account for in our design. The first case is a user who reads the review and is satisfied, and takes no further action except for perhaps sharing their review publicly as a model. The second case is when there's an issue on the fault of the reviewer that the user notices, at which point they can press the email button to email the author of the review. Lastly, the user may be informed by a reviewer or discover on their own that something is wrong with their submission. If this happens, then the user may change the submissions saved in the system by removing unnecessary ones or uploading new files.

[[File:e2444_Use_cases.png | 700px| center]]
Figure 1: User story decision tree for Expertiza

== Existing Review Page ==
We identified several design issues with the existing review page. Most notably, there are many elements that are uncentered and completely unformatted. Spacing in between each element is inconsistent and some even have bullet points for no reason. It would also be nice if lists of links or files could be shown in a table instead of a list of checkboxes, as it makes actions related to these items more difficult for the user. Finally, some hyperlinks, particularly the toggle visibility ones, could be better implemented as buttons since they do not actually route the user anywhere.

[[File:Existing 2444.png | 1000px| center]]
Figure 2: Existing review page within Expertiza

[[File:e2444_Old_email.png | 1000px| center]]
Figure 3: Existing email page within Expertiza

==Design==
The following is our refactoring of the previous design. 
'''1.''' Several key elements are now centralized, and the link submission and the file submission areas are placed side-by-side to minimize whitespace while still maintaining readability. 
'''2.''' Key user actions were made into buttons, particularly visibility toggles, emailing the author, and sharing the review publicly. This was done to better grab the user's attention and to more clearly communicate the result of clicking the link by use of icons. 
'''3.''' "Email the Author" page was also stylized to incorporate central elements. 
'''4.''' The previous system of selecting a bullet-point list, and then clicking on a remove button was changed to simply having a trashcan icon next to every submission on the table, that way the user can simply press the icon corresponding to the submission they would like to remove. This action is dangerous, since it could potentially result in the user losing their work. For this reason, we also added a stylized confirmation screen that clearly communicates the exact action the user is about to take in the form of a warning. This is a good thing because it prevents potential future errors down the road. This warning system was also kept for the review sharing system since that could result in the exposing of sensitive information. 
'''5.''' We thought it would be a good idea to simplify the file-uploading experience for the user. The user sees the name of the file uploaded, the size of the file, and also the type of the file uploaded and does not have to go through a two-step select + upload process like before. 
'''6.''' In the new design, files are uploaded as they are selected but can be identified and removed quickly from the table. We thought this was an appropriate design choice because we saw no benefit to having to make the user press two buttons to perform what most would consider a single task. There are also minimal consequences for user error since they can immediately delete files that they did not mean to upload. 
'''7.''' Some changes we decided to keep were the color scheme and score reporting within the review table because we believe it should catch the attention of the user as soon as they navigate to the page. The circles provide good contrast from the other elements, and alongside the color make it quick to identify low scores on criteria that the user may want to give their attention to.

[[File:Screenshot 2024-04-23 at 10.37.18 PM.png | 1000px| center]]
Figure 4: Our new design of the review page

[[File:e2444_New_email.png | 1000px| center]]
Figure 5: Our new design of the email page

==Files Added / Changed ==

=== reviews.tsx ===
This is the main typescript file in which we have implemented all the changes. It contains the functionality as follows:
<li>Adding Files to the Reviews</li>
<li>Emailing the Author</li>
<li>Displaying the Reviews given by the people</li>
 
Enhancing the Design functionality of buttons and links have been integrated into this file.

[[File:2444-1.png | 800px| center]]

Figure 6: Changes in reviews.tsx

[[File:2444-2.png | 800px| center]]

Figure 7: Changes in reviews.tsx

[[File:2444-3.png | 800px| center]]

Figure 8: Changes in reviews.tsx

=== reviewData.ts ===
This is the transport stream file through which we are reading our reviews in the front-end page. We have seeded the reviews in this page and utilizing the"map" functionality in ReactJS to read the reviews from this file.

[[File:2444-4.png | 1000px| center]]
Figure 9: Changes in reviewData.ts

== Test Plan ==
Since the changes revolve around UI implementation, the features need to be manually checked on the web pages.

#Component Rendering: Ensure that all components from the original Ruby frontend are properly re-implemented in React.js and Typescript.
#Styling Consistency: Verify that the new front-end maintains consistent styling with the rest of the application.
#Functionality Testing: Test all interactive elements such as buttons, and input fields to ensure they work as expected.
#Responsive Design: Check the responsiveness of the new front-end on different screen sizes and devices.
#Show "Email Author" Link: Ensure that "Email Author" Link is there in the reimplemented React page so that the Review can be mailed to him/her.
#Seeding the Database Functionality: Ensure that the Reviews are correctly read from a sample Database by seeding it correctly.
#Interface Efficiency: Check if the new frontend enhances interface efficiency by being more intuitive and user-friendly.

The Results of our testing indicate that all of our components work correctly. Particularly, here are the features we have verified the following features:
<ol>
<li>The toggle visibility button for the submission table correctly toggles between show and hide, and appropriately makes the table contents visible and invisible.</li>
<li>The toggle visibility button for the review table correctly toggles between show and hide, and appropriately makes the table contents visible and invisible.</li>
<li>The email author button correctly navigates the user to the email author page.</li>
<li>The share review button correctly gives a warning, and will only run the handleShowReview() function if that warning is successfully confirmed.</li>
<li>The upload file button uploads the selected file and displays it on the file submission table below.</li>
<li>The trashcan icon next to a link will appropriately delete that link from the list of links, and visually update the table accordingly.</li>
<li>The trashcan icon next to a file will appropriately delete that file from the list of files, and visually update the table accordingly.</li>
<li>Our design is user friendly. This is verified by consulting all of the 12 Basic Principles of Graphic Design (https://www.zekagraphic.com/12-principles-of-graphic-design/).</li>
 
 

[[File:Warning.png | 1000px| center]]
Figure 10: Warning displayed when a user attempts to remove a submitted link
</ol>

== Important Links ==
* GitHub Repo: https://github.com/gwenmason125/reimplementation-front-end
* Pull Request: https://github.com/expertiza/reimplementation-front-end/pull/51

== Demo Video ==
You can watch this [https://www.youtube.com/watch?v=5dPeMEY6A_Y demo video] for a detailed demonstration of the changes we made in the UI.

== Team ==
=====Mentor=====
* '''Riya Gori'''

=====Members=====
* '''Mitesh Agarwal''' (unityid: magarwa3)
* '''Shubham Loya''' (unityid: ssloya)
* '''Gwen Mason''' (unityid: cpmason)

==References==

#[https://wiki-expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2022_-_E2233._Improving_search_facility_in_Expertiza Spring 2022 Design]
#[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2153._Improving_search_facility_in_Expertiza Fall 2021 Design]
#[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2020_-_E2079._Improve_Search_Facility_In_Expertiza Fall 2020 Design]
#[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2019_-_E1987._Improving_search_facility_in_Expertiza Fall 2019 Design]
#[https://github.com/expertiza/expertiza Expertiza on GitHub]

CSC/ECE 517 Spring 2024 - E2444 Implement Frontend for the Review

2024-04-24T03:26:48Z

Magarwa3:

== Overview of Expertiza ==
Expertiza, constructed using Ruby on Rails, is an open-source learning management system that offers a diverse array of features. These include the ability to generate assignments, tests, assignment teams, courses, reviews for the assignments, etc. Notably, it excels in providing a comprehensive peer review system, fostering thorough feedback within teams and among group members. The central focus of the project revolves around enhancing the frontend components related to the Review. A specific challenge being tackled involves the reimplementation of the current non-Typescript Review Page to incorporate Typescript and React. Consequently, the team's task is to craft the User Interface for these components using React.js and Typescript.

== Introduction ==
The main objective of this project is to reimplement the front end for the Review view page within Expertiza.

== Problem Statement ==
The following tasks were required for the reimplementation :
#Frontend Reimplementation: Reimplement the frontend of the Review page in React.js and Typescript which is currently in Ruby.
#Seeding of Databse File There should be seeding of 1 file to simulate the review given by a user which will reflect in the Review UI page.
#Removal of Unused Elements: Remove any unused elements such as URLs, color legends, etc., to streamline the interface.
#Improve UI: We aim to improve user experience and interface efficiency by developing a refreshed front end using React JS and TypeScript.

=='''Project 4 - DESIGN DOC'''==

== Design Patterns ==
===Composite Design Pattern:===

By nesting and composing elements like Show-Review, Email etc and others, we can effectively design our Review component by utilising the Composite Design Pattern.

===DRY Principle:===

We want to reduce redundancy by using React's functionality to reuse pre-existing components like Show-Review and Email, in line with the DRY Principle.

=== Single Responsibility Principle (SRP) ===

<li>Each React component will have a single responsibility, such as displaying Reviews, managing file submissions, or handling email options.</li>
<li>Separate concerns such as data fetching, state management, and rendering to improve modularity and maintainability.</li>

===Provider Pattern:===

Our goal is to apply the Provider Pattern to React's Context API so that props can propagate naturally throughout the component hierarchy without requiring explicit prop drilling.

===Observer Pattern:===

Our goal is to take advantage of the Observer Pattern by using hooks like useEffect and useState along with React's Context API to manage component state and side effects efficiently.

===HOC Pattern:===

Routing for new pages can be made more efficient by using the Higher-Order Component pattern, or HOC Pattern. This entails creating functions that take an input component and provide a changed component with routing functionality.

===Mediator Pattern:===

Our goal is to apply the Mediator Pattern in light of the discrepancy between frontend requirements and backend data structures. With this method, we can easily change data as needed to ensure that it is consistent and compatible with the rest of our program.

=== Open/Closed Principle (OCP) ===

*Designing components to be open for extension by allowing for customization or configuration through props or context.
*Ensuring that components can be extended or modified without altering their core functionality by adhering to React's composition model.

== Use Cases ==

The following is a simple decision tree that can help summarize the various user stories that we absolutely must account for in our design. The first case is a user who reads the review and is satisfied, and takes no further action except for perhaps sharing their review publicly as a model. The second case is when there's an issue on the fault of the reviewer that the user notices, at which point they can press the email button to email the author of the review. Lastly, the user may be informed by a reviewer or discover on their own that something is wrong with their submission. If this happens, then the user may change the submissions saved in the system by removing unnecessary ones or uploading new files.

[[File:e2444_Use_cases.png | 700px| center]]
Figure 1: User story decision tree for Expertiza

== Existing Review Page ==
We identified several design issues with the existing review page. Most notably, there are many elements that are uncentered and completely unformatted. Spacing in between each element is inconsistent and some even have bullet points for no reason. It would also be nice if lists of links or files could be shown in a table instead of a list of checkboxes, as it makes actions related to these items more difficult for the user. Finally, some hyperlinks, particularly the toggle visibility ones, could be better implemented as buttons since they do not actually route the user anywhere.

[[File:Existing 2444.png | 1000px| center]]
Figure 2: Existing review page within Expertiza

[[File:e2444_Old_email.png | 1000px| center]]
Figure 3: Existing email page within Expertiza

==Design==
The following is our refactoring of the previous design. 
'''1.''' Several key elements are now centralized, and the link submission and the file submission areas are placed side-by-side to minimize whitespace while still maintaining readability. 
'''2.''' Key user actions were made into buttons, particularly visibility toggles, emailing the author, and sharing the review publicly. This was done to better grab the user's attention and to more clearly communicate the result of clicking the link by use of icons. 
'''3.''' "Email the Author" page was also stylized to incorporate central elements. 
'''4.''' The previous system of selecting a bullet-point list, and then clicking on a remove button was changed to simply having a trashcan icon next to every submission on the table, that way the user can simply press the icon corresponding to the submission they would like to remove. This action is dangerous, since it could potentially result in the user losing their work. For this reason, we also added a stylized confirmation screen that clearly communicates the exact action the user is about to take in the form of a warning. This is a good thing because it prevents potential future errors down the road. This warning system was also kept for the review sharing system since that could result in the exposing of sensitive information. 
'''5.''' We thought it would be a good idea to simplify the file-uploading experience for the user. The user sees the name of the file uploaded, the size of the file, and also the type of the file uploaded and does not have to go through a two-step select + upload process like before. 
'''6.''' In the new design, files are uploaded as they are selected but can be identified and removed quickly from the table. We thought this was an appropriate design choice because we saw no benefit to having to make the user press two buttons to perform what most would consider a single task. There are also minimal consequences for user error since they can immediately delete files that they did not mean to upload. 
'''7.''' Some changes we decided to keep were the color scheme and score reporting within the review table because we believe it should catch the attention of the user as soon as they navigate to the page. The circles provide good contrast from the other elements, and alongside the color make it quick to identify low scores on criteria that the user may want to give their attention to.

[[File:Screenshot 2024-04-23 at 10.37.18 PM.png | 1000px| center]]
Figure 4: Our new design of the review page

[[File:e2444_New_email.png | 1000px| center]]
Figure 5: Our new design of the email page

==Files Added / Changed ==

=== reviews.tsx ===
This is the main typescript file in which we have implemented all the changes. It contains the functionality as follows:
<li>Adding Files to the Reviews</li>
<li>Emailing the Author</li>
<li>Displaying the Reviews given by the people</li>
 
Enhancing the Design functionality of buttons and links have been integrated into this file.

[[File:2444-1.png | 800px| center]]

Figure 6: Changes in reviews.tsx

[[File:2444-2.png | 800px| center]]

Figure 7: Changes in reviews.tsx

[[File:2444-3.png | 800px| center]]

Figure 8: Changes in reviews.tsx

=== reviewData.ts ===
This is the transport stream file through which we are reading our reviews in the front-end page. We have seeded the reviews in this page and utilizing the"map" functionality in ReactJS to read the reviews from this file.

[[File:2444-4.png | 1000px| center]]
Figure 9: Changes in reviews.tsx

== Test Plan ==
Since the changes revolve around UI implementation, the features need to be manually checked on the web pages.

#Component Rendering: Ensure that all components from the original Ruby frontend are properly re-implemented in React.js and Typescript.
#Styling Consistency: Verify that the new front-end maintains consistent styling with the rest of the application.
#Functionality Testing: Test all interactive elements such as buttons, and input fields to ensure they work as expected.
#Responsive Design: Check the responsiveness of the new front-end on different screen sizes and devices.
#Show "Email Author" Link: Ensure that "Email Author" Link is there in the reimplemented React page so that the Review can be mailed to him/her.
#Seeding the Database Functionality: Ensure that the Reviews are correctly read from a sample Database by seeding it correctly.
#Interface Efficiency: Check if the new frontend enhances interface efficiency by being more intuitive and user-friendly.

The Results of our testing indicate that all of our components work correctly. Particularly, here are the features we have verified the following features:
<ol>
<li>The toggle visibility button for the submission table correctly toggles between show and hide, and appropriately makes the table contents visible and invisible.</li>
<li>The toggle visibility button for the review table correctly toggles between show and hide, and appropriately makes the table contents visible and invisible.</li>
<li>The email author button correctly navigates the user to the email author page.</li>
<li>The share review button correctly gives a warning, and will only run the handleShowReview() function if that warning is successfully confirmed.</li>
<li>The upload file button uploads the selected file and displays it on the file submission table below.</li>
<li>The trashcan icon next to a link will appropriately delete that link from the list of links, and visually update the table accordingly.</li>
<li>The trashcan icon next to a file will appropriately delete that file from the list of files, and visually update the table accordingly.</li>
<li>Our design is user friendly. This is verified by consulting all of the 12 Basic Principles of Graphic Design (https://www.zekagraphic.com/12-principles-of-graphic-design/).</li>
 
 

[[File:Warning.png | 1000px| center]]
Figure 10: Warning displayed when a user attempts to remove a submitted link
</ol>

== Important Links ==
* GitHub Repo: https://github.com/gwenmason125/reimplementation-front-end
* Pull Request: https://github.com/expertiza/reimplementation-front-end/pull/51

== Demo Video ==
You can watch this [https://www.youtube.com/watch?v=5dPeMEY6A_Y demo video] for a detailed demonstration of the changes we made in the UI.

== Team ==
=====Mentor=====
* '''Riya Gori'''

=====Members=====
* '''Mitesh Agarwal''' (unityid: magarwa3)
* '''Shubham Loya''' (unityid: ssloya)
* '''Gwen Mason''' (unityid: cpmason)

==References==

#[https://wiki-expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2022_-_E2233._Improving_search_facility_in_Expertiza Spring 2022 Design]
#[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2153._Improving_search_facility_in_Expertiza Fall 2021 Design]
#[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2020_-_E2079._Improve_Search_Facility_In_Expertiza Fall 2020 Design]
#[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2019_-_E1987._Improving_search_facility_in_Expertiza Fall 2019 Design]
#[https://github.com/expertiza/expertiza Expertiza on GitHub]

File:2444-4.png

2024-04-24T03:24:21Z

Magarwa3:

File:2444-3.png

2024-04-24T03:21:22Z

Magarwa3:

File:2444-2.png

2024-04-24T03:20:49Z

Magarwa3:

File:2444-1.png

2024-04-24T03:19:45Z

Magarwa3:

CSC/ECE 517 Spring 2024 - E2444 Implement Frontend for the Review

2024-04-24T03:06:31Z

Magarwa3:

== Overview of Expertiza ==
Expertiza, constructed using Ruby on Rails, is an open-source learning management system that offers a diverse array of features. These include the ability to generate assignments, tests, assignment teams, courses, reviews for the assignments, etc. Notably, it excels in providing a comprehensive peer review system, fostering thorough feedback within teams and among group members. The central focus of the project revolves around enhancing the frontend components related to the Review. A specific challenge being tackled involves the reimplementation of the current non-Typescript Review Page to incorporate Typescript and React. Consequently, the team's task is to craft the User Interface for these components using React.js and Typescript.

== Introduction ==
The main objective of this project is to reimplement the front end for the Review view page within Expertiza.

== Problem Statement ==
The following tasks were required for the reimplementation :
#Frontend Reimplementation: Reimplement the frontend of the Review page in React.js and Typescript which is currently in Ruby.
#Seeding of Databse File There should be seeding of 1 file to simulate the review given by a user which will reflect in the Review UI page.
#Removal of Unused Elements: Remove any unused elements such as URLs, color legends, etc., to streamline the interface.
#Improve UI: We aim to improve user experience and interface efficiency by developing a refreshed front end using React JS and TypeScript.

=='''Project 4 - DESIGN DOC'''==

== Design Patterns ==
===Composite Design Pattern:===

By nesting and composing elements like Show-Review, Email etc and others, we can effectively design our Review component by utilising the Composite Design Pattern.

===DRY Principle:===

We want to reduce redundancy by using React's functionality to reuse pre-existing components like Show-Review and Email, in line with the DRY Principle.

=== Single Responsibility Principle (SRP) ===

<li>Each React component will have a single responsibility, such as displaying Reviews, managing file submissions, or handling email options.</li>
<li>Separate concerns such as data fetching, state management, and rendering to improve modularity and maintainability.</li>

===Provider Pattern:===

Our goal is to apply the Provider Pattern to React's Context API so that props can propagate naturally throughout the component hierarchy without requiring explicit prop drilling.

===Observer Pattern:===

Our goal is to take advantage of the Observer Pattern by using hooks like useEffect and useState along with React's Context API to manage component state and side effects efficiently.

===HOC Pattern:===

Routing for new pages can be made more efficient by using the Higher-Order Component pattern, or HOC Pattern. This entails creating functions that take an input component and provide a changed component with routing functionality.

===Mediator Pattern:===

Our goal is to apply the Mediator Pattern in light of the discrepancy between frontend requirements and backend data structures. With this method, we can easily change data as needed to ensure that it is consistent and compatible with the rest of our program.

=== Open/Closed Principle (OCP) ===

*Designing components to be open for extension by allowing for customization or configuration through props or context.
*Ensuring that components can be extended or modified without altering their core functionality by adhering to React's composition model.

== Use Cases ==

The following is a simple decision tree that can help summarize the various user stories that we absolutely must account for in our design. The first case is a user who reads the review and is satisfied, and takes no further action except for perhaps sharing their review publicly as a model. The second case is when there's an issue on the fault of the reviewer that the user notices, at which point they can press the email button to email the author of the review. Lastly, the user may be informed by a reviewer or discover on their own that something is wrong with their submission. If this happens, then the user may change the submissions saved in the system by removing unnecessary ones or uploading new files.

[[File:e2444_Use_cases.png | 700px| center]]
Figure 1: User story decision tree for Expertiza

== Existing Review Page ==
We identified several design issues with the existing review page. Most notably, there are many elements that are uncentered and completely unformatted. Spacing in between each element is inconsistent and some even have bullet points for no reason. It would also be nice if lists of links or files could be shown in a table instead of a list of checkboxes, as it makes actions related to these items more difficult for the user. Finally, some hyperlinks, particularly the toggle visibility ones, could be better implemented as buttons since they do not actually route the user anywhere.

[[File:Existing 2444.png | 1000px| center]]
Figure 2: Existing review page within Expertiza

[[File:e2444_Old_email.png | 1000px| center]]
Figure 3: Existing email page within Expertiza

==Design==
The following is our refactoring of the previous design. 
'''1.''' Several key elements are now centralized, and the link submission and the file submission areas are placed side-by-side to minimize whitespace while still maintaining readability. 
'''2.''' Key user actions were made into buttons, particularly visibility toggles, emailing the author, and sharing the review publicly. This was done to better grab the user's attention and to more clearly communicate the result of clicking the link by use of icons. 
'''3.''' "Email the Author" page was also stylized to incorporate central elements. 
'''4.''' The previous system of selecting a bullet-point list, and then clicking on a remove button was changed to simply having a trashcan icon next to every submission on the table, that way the user can simply press the icon corresponding to the submission they would like to remove. This action is dangerous, since it could potentially result in the user losing their work. For this reason, we also added a stylized confirmation screen that clearly communicates the exact action the user is about to take in the form of a warning. This is a good thing because it prevents potential future errors down the road. This warning system was also kept for the review sharing system since that could result in the exposing of sensitive information. 
'''5.''' We thought it would be a good idea to simplify the file-uploading experience for the user. The user sees the name of the file uploaded, the size of the file, and also the type of the file uploaded and does not have to go through a two-step select + upload process like before. 
'''6.''' In the new design, files are uploaded as they are selected but can be identified and removed quickly from the table. We thought this was an appropriate design choice because we saw no benefit to having to make the user press two buttons to perform what most would consider a single task. There are also minimal consequences for user error since they can immediately delete files that they did not mean to upload. 
'''7.''' Some changes we decided to keep were the color scheme and score reporting within the review table because we believe it should catch the attention of the user as soon as they navigate to the page. The circles provide good contrast from the other elements, and alongside the color make it quick to identify low scores on criteria that the user may want to give their attention to.

[[File:Screenshot 2024-04-23 at 10.37.18 PM.png | 1000px| center]]
Figure 4: Our new design of the review page

[[File:e2444_New_email.png | 1000px| center]]
Figure 5: Our new design of the email page

== Test Plan ==
Since the changes revolve around UI implementation, the features need to be manually checked on the web pages.

#Component Rendering: Ensure that all components from the original Ruby frontend are properly re-implemented in React.js and Typescript.
#Styling Consistency: Verify that the new front-end maintains consistent styling with the rest of the application.
#Functionality Testing: Test all interactive elements such as buttons, and input fields to ensure they work as expected.
#Responsive Design: Check the responsiveness of the new front-end on different screen sizes and devices.
#Show "Email Author" Link: Ensure that "Email Author" Link is there in the reimplemented React page so that the Review can be mailed to him/her.
#Seeding the Database Functionality: Ensure that the Reviews are correctly read from a sample Database by seeding it correctly.
#Interface Efficiency: Check if the new frontend enhances interface efficiency by being more intuitive and user-friendly.

The Results of our testing indicate that all of our components work correctly. Particularly, here are the features we have verified the following features:
<ol>
<li>The toggle visibility button for the submission table correctly toggles between show and hide, and appropriately makes the table contents visible and invisible.</li>
<li>The toggle visibility button for the review table correctly toggles between show and hide, and appropriately makes the table contents visible and invisible.</li>
<li>The email author button correctly navigates the user to the email author page.</li>
<li>The share review button correctly gives a warning, and will only run the handleShowReview() function if that warning is successfully confirmed.</li>
<li>The upload file button uploads the selected file and displays it on the file submission table below.</li>
<li>The trashcan icon next to a link will appropriately delete that link from the list of links, and visually update the table accordingly.</li>
<li>The trashcan icon next to a file will appropriately delete that file from the list of files, and visually update the table accordingly.</li>
<li>Our design is user friendly. This is verified by consulting all of the 12 Basic Principles of Graphic Design (https://www.zekagraphic.com/12-principles-of-graphic-design/).</li>

[[File:Warning.png | 1000px| center]]
Figure 6: Warning displayed when a user attempts to remove a submitted link
</ol>

== Important Links ==
* GitHub Repo: https://github.com/gwenmason125/reimplementation-front-end
* Pull Request: https://github.com/expertiza/reimplementation-front-end/pull/51

== Demo Video ==
You can watch this [https://www.youtube.com/watch?v=5dPeMEY6A_Y demo video] for a detailed demonstration of the changes we made in the UI.

== Team ==
=====Mentor=====
* '''Riya Gori'''

=====Members=====
* '''Mitesh Agarwal''' (unityid: magarwa3)
* '''Shubham Loya''' (unityid: ssloya)
* '''Gwen Mason''' (unityid: cpmason)

==References==

#[https://wiki-expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2022_-_E2233._Improving_search_facility_in_Expertiza Spring 2022 Design]
#[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2153._Improving_search_facility_in_Expertiza Fall 2021 Design]
#[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2020_-_E2079._Improve_Search_Facility_In_Expertiza Fall 2020 Design]
#[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2019_-_E1987._Improving_search_facility_in_Expertiza Fall 2019 Design]
#[https://github.com/expertiza/expertiza Expertiza on GitHub]

CSC/ECE 517 Spring 2024 - E2444 Implement Frontend for the Review

2024-04-24T02:56:51Z

Magarwa3:

== Overview of Expertiza ==
Expertiza, constructed using Ruby on Rails, is an open-source learning management system that offers a diverse array of features. These include the ability to generate assignments, tests, assignment teams, courses, reviews for the assignments, etc. Notably, it excels in providing a comprehensive peer review system, fostering thorough feedback within teams and among group members. The central focus of the project revolves around enhancing the frontend components related to the Review. A specific challenge being tackled involves the reimplementation of the current non-Typescript Review Page to incorporate Typescript and React. Consequently, the team's task is to craft the User Interface for these components using React.js and Typescript.

== Introduction ==
The main objective of this project is to reimplement the front end for the Review view page within Expertiza.

== Problem Statement ==
The following tasks were required for the reimplementation :
#Frontend Reimplementation: Reimplement the frontend of the Review page in React.js and Typescript which is currently in Ruby.
#Seeding of Databse File There should be seeding of 1 file to simulate the review given by a user which will reflect in the Review UI page.
#Removal of Unused Elements: Remove any unused elements such as URLs, color legends, etc., to streamline the interface.
#Improve UI: We aim to improve user experience and interface efficiency by developing a refreshed front end using React JS and TypeScript.

=='''Project 4 - DESIGN DOC'''==

== Design Patterns ==
===Composite Design Pattern:===

By nesting and composing elements like Show-Review, Email etc and others, we can effectively design our Review component by utilising the Composite Design Pattern.

===DRY Principle:===

We want to reduce redundancy by using React's functionality to reuse pre-existing components like Show-Review and Email, in line with the DRY Principle.

===Provider Pattern:===

Our goal is to apply the Provider Pattern to React's Context API so that props can propagate naturally throughout the component hierarchy without requiring explicit prop drilling.

===Observer Pattern:===

Our goal is to take advantage of the Observer Pattern by using hooks like useEffect and useState along with React's Context API to manage component state and side effects efficiently.

===HOC Pattern:===

Routing for new pages can be made more efficient by using the Higher-Order Component pattern, or HOC Pattern. This entails creating functions that take an input component and provide a changed component with routing functionality.

===Mediator Pattern:===

Our goal is to apply the Mediator Pattern in light of the discrepancy between frontend requirements and backend data structures. With this method, we can easily change data as needed to ensure that it is consistent and compatible with the rest of our program.

== Use Cases ==

The following is a simple decision tree that can help summarize the various user stories that we absolutely must account for in our design. The first case is a user who reads the review and is satisfied, and takes no further action except for perhaps sharing their review publicly as a model. The second case is when there's an issue on the fault of the reviewer that the user notices, at which point they can press the email button to email the author of the review. Lastly, the user may be informed by a reviewer or discover on their own that something is wrong with their submission. If this happens, then the user may change the submissions saved in the system by removing unnecessary ones or uploading new files.

[[File:e2444_Use_cases.png | 700px| center]]
Figure 1: User story decision tree for Expertiza

== Existing Review Page ==
We identified several design issues with the existing review page. Most notably, there are many elements that are uncentered and completely unformatted. Spacing in between each element is inconsistent and some even have bullet points for no reason. It would also be nice if lists of links or files could be shown in a table instead of a list of checkboxes, as it makes actions related to these items more difficult for the user. Finally, some hyperlinks, particularly the toggle visibility ones, could be better implemented as buttons since they do not actually route the user anywhere.

[[File:Existing 2444.png | 1000px| center]]
Figure 2: Existing review page within Expertiza

[[File:e2444_Old_email.png | 1000px| center]]
Figure 3: Existing email page within Expertiza

==Design==
The following is our refactoring of the previous design. 
'''1.''' Several key elements are now centralized, and the link submission and the file submission areas are placed side-by-side to minimize whitespace while still maintaining readability. 
'''2.''' Key user actions were made into buttons, particularly visibility toggles, emailing the author, and sharing the review publicly. This was done to better grab the user's attention and to more clearly communicate the result of clicking the link by use of icons. 
'''3.''' "Email the Author" page was also stylized to incorporate central elements. 
'''4.''' The previous system of selecting a bullet-point list, and then clicking on a remove button was changed to simply having a trashcan icon next to every submission on the table, that way the user can simply press the icon corresponding to the submission they would like to remove. This action is dangerous, since it could potentially result in the user losing their work. For this reason, we also added a stylized confirmation screen that clearly communicates the exact action the user is about to take in the form of a warning. This is a good thing because it prevents potential future errors down the road. This warning system was also kept for the review sharing system since that could result in the exposing of sensitive information. 
'''5.''' We thought it would be a good idea to simplify the file-uploading experience for the user. The user sees the name of the file uploaded, the size of the file, and also the type of the file uploaded and does not have to go through a two-step select + upload process like before. 
'''6.''' In the new design, files are uploaded as they are selected but can be identified and removed quickly from the table. We thought this was an appropriate design choice because we saw no benefit to having to make the user press two buttons to perform what most would consider a single task. There are also minimal consequences for user error since they can immediately delete files that they did not mean to upload. 
'''7.''' Some changes we decided to keep were the color scheme and score reporting within the review table because we believe it should catch the attention of the user as soon as they navigate to the page. The circles provide good contrast from the other elements, and alongside the color make it quick to identify low scores on criteria that the user may want to give their attention to.

[[File:Screenshot 2024-04-23 at 10.37.18 PM.png | 1000px| center]]
Figure 4: Our new design of the review page

[[File:e2444_New_email.png | 1000px| center]]
Figure 5: Our new design of the email page

== Test Plan ==
Since the changes revolve around UI implementation, the features need to be manually checked on the web pages.

#Component Rendering: Ensure that all components from the original Ruby frontend are properly re-implemented in React.js and Typescript.
#Styling Consistency: Verify that the new front-end maintains consistent styling with the rest of the application.
#Functionality Testing: Test all interactive elements such as buttons, and input fields to ensure they work as expected.
#Responsive Design: Check the responsiveness of the new front-end on different screen sizes and devices.
#Show "Email Author" Link: Ensure that "Email Author" Link is there in the reimplemented React page so that the Review can be mailed to him/her.
#Seeding the Database Functionality: Ensure that the Reviews are correctly read from a sample Database by seeding it correctly.
#Interface Efficiency: Check if the new frontend enhances interface efficiency by being more intuitive and user-friendly.

The Results of our testing indicate that all of our components work correctly. Particularly, here are the features we have verified the following features:
<ol>
<li>The toggle visibility button for the submission table correctly toggles between show and hide, and appropriately makes the table contents visible and invisible.</li>
<li>The toggle visibility button for the review table correctly toggles between show and hide, and appropriately makes the table contents visible and invisible.</li>
<li>The email author button correctly navigates the user to the email author page.</li>
<li>The share review button correctly gives a warning, and will only run the handleShowReview() function if that warning is successfully confirmed.</li>
<li>The upload file button uploads the selected file and displays it on the file submission table below.</li>
<li>The trashcan icon next to a link will appropriately delete that link from the list of links, and visually update the table accordingly.</li>
<li>The trashcan icon next to a file will appropriately delete that file from the list of files, and visually update the table accordingly.</li>
<li>Our design is user friendly. This is verified by consulting all of the 12 Basic Principles of Graphic Design (https://www.zekagraphic.com/12-principles-of-graphic-design/).</li>

[[File:Warning.png | 1000px| center]]
Figure 6: Warning displayed when a user attempts to remove a submitted link
</ol>

== Important Links ==
* GitHub Repo: https://github.com/gwenmason125/reimplementation-front-end
* Pull Request: https://github.com/expertiza/reimplementation-front-end/pull/51

== Demo Video ==
You can watch this [https://www.youtube.com/watch?v=5dPeMEY6A_Y demo video] for a detailed demonstration of the changes we made in the UI.

== Team ==
=====Mentor=====
* '''Riya Gori'''

=====Members=====
* '''Mitesh Agarwal''' (unityid: magarwa3)
* '''Shubham Loya''' (unityid: ssloya)
* '''Gwen Mason''' (unityid: cpmason)

==References==

#[https://wiki-expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2022_-_E2233._Improving_search_facility_in_Expertiza Spring 2022 Design]
#[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2153._Improving_search_facility_in_Expertiza Fall 2021 Design]
#[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2020_-_E2079._Improve_Search_Facility_In_Expertiza Fall 2020 Design]
#[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2019_-_E1987._Improving_search_facility_in_Expertiza Fall 2019 Design]
#[https://github.com/expertiza/expertiza Expertiza on GitHub]

File:Screenshot 2024-04-23 at 10.37.18 PM.png

2024-04-24T02:37:39Z

Magarwa3:

File:Existing 2444.png

2024-04-24T02:29:38Z

Magarwa3:

CSC/ECE 517 Spring 2024 - E2444 Implement Frontend for the Review

2024-04-09T02:15:40Z

Magarwa3:

CSC/ECE 517 Spring 2024 - E2444 Implement Frontend for the Review

2024-04-09T02:14:41Z

Magarwa3:

CSC/ECE 517 Spring 2024 - E2444 Implement Frontend for the Review

2024-04-08T22:16:07Z

Magarwa3:

File:Flowchart-draw.png

2024-04-08T22:11:38Z

Magarwa3: Magarwa3 uploaded a new version of File:Flowchart-draw.png

File:Flowchart-draw.png

2024-04-08T22:05:45Z

Magarwa3:

CSC/ECE 517 Spring 2024 - E2444 Implement Frontend for the Review

2024-04-08T21:55:13Z

Magarwa3:

File:Existing-UI.png

2024-04-08T21:29:04Z

Magarwa3:

CSC/ECE 517 Spring 2024 - E2444 Implement Frontend for the Review

2024-04-08T15:52:52Z

Magarwa3: Created page with "== Expertiza == Expertiza is an open-source learning management system built with Ruby on Rails as its core. Its features include creating tests and assignments, managing assignment teams and courses, and above all having a solid framework in place to facilitate peer reviews and group comments. The main objective of this project is to develop frontend React Components, with a particular focus on the Grades View page. The goal is to create a fully functional user interfac..."

== Expertiza ==
Expertiza is an open-source learning management system built with Ruby on Rails as its core. Its features include creating tests and assignments, managing assignment teams and courses, and above all having a solid framework in place to facilitate peer reviews and group comments. The main objective of this project is to develop frontend React Components, with a particular focus on the Grades View page. The goal is to create a fully functional user interface for these components using React.js and TypeScript.

== Introduction ==
The main objective of this project is to reimplement the front end for the grades view page within Expertiza.

== Problem Statement ==
The following tasks were required for the reimplementation :
#Frontend Reimplementation: Reimplement the frontend of the grades view page in React.js and Typescript which is currently in Ruby.
#Removal of Checkboxes for Word Count Remove checkboxes related to word count criteria (>10 words, >20 words).
#Enhanced "Show Submission" Button: The Show Button should reveal the submitted links and the submitted files.
#Removal of Unused Elements: Remove any unused elements such as URLs, color legends, etc., to streamline the interface. If any column isn’t present, entire columns shouldn’t show up like teammate review
#Include Heat Map: Heat map should be included in the grades view page.
#Improve UI: Our aim is to improve user experience and interface efficiency by developing a refreshed front end using React JS and TypeScript.

== Design Patterns ==
===Composite Design Pattern:===

By nesting and composing elements like Table, Modal, and others, we can effectively design our Course component by utilising the Composite Design Pattern.

===DRY Principle:===

We want to reduce redundancy by using React's functionality to reuse pre-existing components like Table and Modal, in line with the DRY Principle.

===Provider Pattern:===

Our goal is to apply the Provider Pattern to React's Context API so that props can propagate naturally throughout the component hierarchy without requiring explicit prop drilling.

===Observer Pattern:===

Our goal is to take advantage of the Observer Pattern by using hooks like useEffect and useState along with React's Context API to manage component state and side effects efficiently.

===HOC Pattern:===

Routing for new pages can be made more efficient by using the Higher-Order Component pattern, or HOC Pattern. This entails creating functions that take an input component and provide a changed component with routing functionality.

===Mediator Pattern:===

Our goal is to apply the Mediator Pattern in light of the discrepancy between frontend requirements and backend data structures. With this method, we can easily change data as needed to ensure that it is consistent and compatible with the rest of our program.

==Design==
The designs provided are for the existing Grades View Page, which has already been implemented. Our goal is to replicate these designs for the new components mentioned earlier in the project. This involves creating similar visual elements, layouts, and functionalities for these new components to maintain consistency and coherence across the application.

== Existing Grades View Page ==
[[File:Grades_View.png | 700px]] 

== Reimplementation To Be Done ==
Following is the Heat Map which is already implemented in the Expertiza. Our goal is to incorporate these changes into the current front end of the Expertiza and then start building our changes on it. 
[[File:heat_map.png | 700px]] 

== Test Plan ==
Since the changes revolve around UI implementation, the features need to be manually checked on the webpages..

#Component Rendering: Ensure that all components from the original Ruby frontend are properly re-implemented in React.js and Typescript.
#Styling Consistency: Verify that the new frontend maintains consistent styling with the rest of the application.
#Functionality Testing: Test all interactive elements such as buttons, dropdowns, and input fields to ensure they work as expected.
#Responsive Design: Check the responsiveness of the new frontend on different screen sizes and devices.
#"Show Submission" Button: Ensure that submitted links are displayed correctly, and they lead to the appropriate destinations when clicked. Verify that submitted files are listed correctly, and they can be downloaded or viewed as intended.
#Word Count Validation: Check if the word count validation is still functioning correctly without the checkboxes.
#Heat Map Integration and Functionality: Verify that the heat map is integrated correctly and accurately represents the scores of peer reviews received.
#Interface Efficiency: Check if the new frontend enhances interface efficiency by being more intuitive and user-friendly.

== Important Links ==
* GitHub repo [https://github.com/expertiza/reimplementation-front-end]
* Pull Request to be merged before starting this project [https://github.com/expertiza/reimplementation-front-end/pull/45]

== Team ==
=====Mentor=====
* Riya Gori

=====Members=====
* Mitesh Agarwal <magarwa3@ncsu.edu>
* Shubham Loya <ssloya@ncsu.edu>
* Chris Mason <cpmason@ncsu.edu>

CSC/ECE 517 Spring 2024

2024-04-08T15:50:56Z

Magarwa3:

* [[CSC/ECE 517 Spring 2024 - E2401 Implementing and testing import & export controllers]]
* [[CSC/ECE 517 Spring 2024 - E2405 Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Spring 2024 - E2407 Refactor review_mapping_controller.rb]]
* [[CSC/ECE 517 Spring 2024 - E2428 Replicate Roles and Institution UIs ReactJS]]
* [[CSC/ECE 517 Spring 2024 - E2429 Reimplement student_task list]]
* [[CSC/ECE 517 Spring 2024 - E2430 Reimplement student_task view]]
* [[CSC/ECE 517 Spring 2024 - E2410. View for Results of Bidding ]]
* [[CSC/ECE 517 Spring 2024 - E2414 Grading Audit Trail]]
* [[CSC/ECE 517 Spring 2024 - NTNX-1 : Extend NDB Operator to Support Postgres HA]]
* [[CSC/ECE 517 Spring 2024 - ‬NTNX-2‬‭ : Snapshot Functionality for provisioned databases]]
* [[CSC/ECE 517 Spring 2024 - E2411 : Fix "Back" link on “New Late Policy” page]]
* [[CSC/ECE 517 Spring 2024 - E2416. Reimplement the Question hierarchy]]
* [[CSC/ECE 517 Spring 2024 - E2420. Reimplement student_quizzes_controller]]
* [[CSC/ECE 517 Spring 2024 - E2424. Reimplement the Bookmarks Controller]]
* [[CSC/ECE 517 Spring 2024 - E2426. Create a UI for Assignment Edit page "Etc" tab in ReactJS]]
* [[CSC/ECE 517 Spring 2024 - E2417. Reimplement submitted content controller.rb]]
* [[CSC/ECE 517 Spring 2024 - E2425. Create a Courses user interface in ReactJS]]
* [[CSC/ECE 517 Spring 2024 - E2431. Reimplement grades/view_team]]
* [[CSC/ECE 517 Spring 2024 - E2404 Refactor student teams functionality]]
* [[CSC/ECE 517 Spring 2024 - E2406 Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management]]
* [[CSC/ECE 517 Spring 2024 - E2421. Reimplement impersonating users (within impersonate controller.rb)]]
* [[CSC/ECE 517 Spring 2024 - E2413. Testing - Answer Tagging]]
* [[CSC/ECE 517 Spring 2024 - E2412. Testing for hamer.rb]]
* [[CSC/ECE 517 Spring 2024 - E2427. UI for questionnaire.rb]]
* [[CSC/ECE 517 Spring 2024 - E2419. Reimplement duties controller.rb and badges controller.rb]]
* [[CSC/ECE 517 Spring 2024 - E2432. UI for Participants.rb]]
* [[CSC/ECE 517 Spring 2024 - G2402 Implement REST client, REST API, and Graphql API endpoint for repositories]]
* [[CSC/ECE 517 Spring 2024 - G2400 DevOp for GitHub Miner app]]
* [[CSC/ECE 517 Spring 2024 - E2439 Testing for view_translation_substitutor.rb]]
* [[CSC/ECE 517 Spring 2024 - E2443 Reimplement grades_controller]]
* [[CSC/ECE 517 Spring 2024 - E2434 Reimplement Frontend for the Grades view]]
* [[CSC/ECE 517 Spring 2024 - E2435 Implement Frontend for the My Profile]]
* [[CSC/ECE 517 Spring 2024 - E2446 Implement Front End for Student Task List]]
* [[CSC/ECE 517 Spring 2024 - E2444 Implement Frontend for the Review]]

CSC/ECE 517 Spring 2024 - E2427. UI for questionnaire.rb

2024-03-25T02:30:39Z

Magarwa3:

CSC/ECE 517 Spring 2024 - E2427. UI for questionnaire.rb

2024-03-25T01:35:03Z

Magarwa3: Created page with "== Overview of Expertiza == Expertiza, constructed using Ruby on Rails, is an open-source learning management system that offers a diverse array of features. These include the ability to generate assignments, tests, assignment teams, and courses. Notably, it excels in providing a comprehensive peer review system, fostering thorough feedback within teams and among group members. The central focus of the project revolves around enhancing the frontend components related to..."

File:Edit-survey.jpeg

2024-03-25T01:09:47Z

Magarwa3:

File:Delete-survey.jpeg

2024-03-25T01:09:31Z

Magarwa3:

File:New-survey.jpeg

2024-03-25T01:05:07Z

Magarwa3:

File:Sort.jpeg

2024-03-25T01:02:00Z

Magarwa3:

File:Search-bar.jpeg

2024-03-25T00:48:55Z

Magarwa3:

File:Delete-questionnarie.jpeg

2024-03-25T00:39:40Z

Magarwa3:

File:Edit-questionnarie.jpeg

2024-03-25T00:38:33Z

Magarwa3:

File:Questionnarie.jpeg

2024-03-25T00:34:40Z

Magarwa3:

File:Delete.jpeg

2024-03-25T00:33:53Z

Magarwa3: Magarwa3 uploaded a new version of File:Delete.jpeg

File:UI.jpeg

2024-03-25T00:19:57Z

Magarwa3:

CSC/ECE 517 Spring 2024

2024-03-24T22:03:14Z

Magarwa3:

* [[CSC/ECE 517 Spring 2024 - E2405 Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Spring 2024 - E2407 Refactor review_mapping_controller.rb]]
* [[CSC/ECE 517 Spring 2024 - E2428 Replicate Roles and Institution UIs ReactJS]]
* [[CSC/ECE 517 Spring 2024 - E2429 Reimplement student_task list]]
* [[CSC/ECE 517 Spring 2024 - E2414 Grading Audit Trail]]
* [[CSC/ECE 517 Spring 2024 - ‬NTNX-2‬‭ : Snapshot Functionality for provisioned databases]]
* [[CSC/ECE 517 Spring 2024 - E2411 : Fix "Back" link on “New Late Policy” page]]
* [[CSC/ECE 517 Spring 2024 - E2416. Reimplement the Question hierarchy]]
* [[CSC/ECE 517 Spring 2024 - E2420. Reimplement student_quizzes_controller]]
* [[CSC/ECE 517 Spring 2024 - E2424. Reimplement the Bookmarks Controller]]
* [[CSC/ECE 517 Spring 2024 - E2426. Create a UI for Assignment Edit page "Etc" tab in ReactJS]]
* [[CSC/ECE 517 Spring 2024 - E2417. Reimplement submitted content controller.rb]]
* [[CSC/ECE 517 Spring 2024 - E2425. Create a Courses user interface in ReactJS]]
* [[CSC/ECE 517 Spring 2024 - E2431. Reimplement grades/view_team]]
* [[CSC/ECE 517 Spring 2024 - E2404 Refactor student teams functionality]]
* [[CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management]]
* [[CSC/ECE 517 Spring 2024 - E2421. Reimplement impersonating users (within impersonate controller.rb)]]
* [[CSC/ECE 517 Spring 2024 - E2413. Testing - Answer Tagging]]
* [[CSC/ECE 517 Spring 2024 - E2412. Testing for hamer.rb]]
* [[CSC/ECE 517 Spring 2024 - E2427. UI for questionnaire.rb]]