Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2018 E1815: Improvements to review grader

2018-04-28T22:52:01Z

Bjyounce: /* Optional additional improvements */

Improvements to Review Grader

__TOC__
== Abstract ==
In this design doc, since it's clearer to explain how we are going to improve the UI design by proposing each idea with the corresponding design's current image, we aren't going to separate problems from goals because you, as a reader, will need to scroll up and down to match problems to their corresponding goals.

== Introduction ==
Expertiza is a web application that is widely used by 2 types of users: students and instructors. When a user is logged-in as an instructor, and would like to see a review report on an assignment to review a grader, he/she could reach the page via Manage > Assignments and clicking on the “'''View review report'''” icon. The page would look somewhat like this:

[[File:Rev_report2018.png]]

To get a summary review report performed by a particular student, an instructor can get to the page from the review report by clicking “'''summary'''” in the row for that student. The page would look like this one:

[[File:Summary_report2018.png]]

== Problem Statement ==

This project is focused primarily on making various improvements to the Review Report and Review Summary pages, described in detail in the previous section. Each of these pages, while functional, suffer from many UI issues which make the pages more difficult to use for instructors. That is, information which would be useful to instructors is missing in several cases. In others, large amounts of unnecessary information is present, cluttering the site. Additionally, both pages suffer from structural and design issues which, again, waste instructor time.

Finally, the Review Report page sometimes mis-categorizes students who have not updated their reviews of others, even though the project under review has not changed! This could cause students to be deducted points unfairly. By adding a new way of highlighting this special case to instructors, review grades can be assigned more fairly.

== File Changes ==
* app/helpers/review_mapping_helper.rb for Add metrics charts
* app/views/popup/view_review_scores_popup.html.erb
* app/views/review_mapping/_review_report.html.erb
* app/assets/stylesheets/table_sorter.scss
* app/helpers/review_mapping_helper.rb
* app/views/popup/team_users_pop_up.html.haml
* config/application.rb

== Review Report Page==

=== Add metrics charts ===

Presently, this page contains a 'metrics' column, presently displaying the average review volume for a given user in text form. This method of displaying data can be difficult to interpret, and even more difficult to compare at a glance, or to notice trends. Additionally, plans for expanding the metrics column to include more data would worsen this issue if it remained in its current state.

[[File:Metrics2018.png]]

====Solution====
=====Files=====
* app/helpers/review_mapping_helper.rb

This project will replace the text in this column with easy to read bar or line graphs, which will be color-coded or otherwise made very simple and easy to read. These graphs will display the data clearly and concisely, mitigating these issues. This concise display will allow for easier comparison of data, easier interpretation of data, and will allow for more metrics to be added without simply overcrowding the page with text.

First of all, we calculate the average volume in each round and the overall average volume of all rounds.
[[File:chart_data_organize.png]]

Next, we organize all the data and their corresponding label array for the chart drawing method later.

[[File:chart_data_array.png]]

Finally, we apply an extension called chartjs-ror to help us draw horizontal bar charts. Most of the codes in this method relate to the configuration setting of the chart.
[[File:metric_chart_config_code.png]]

[[File:metric_chart_config_code1.png]]

The result of our improvement doesn't have its value explicitly showed because we want to save more space and let the chart be simpler to read. Yet, you can let your mouse points the bar, then the value will show up as seen in the figures below.

[[File:chart_no_value.png]]

[[File:metric_chart_value.png]]

=== Update alternating background color if sorted ===

In order to make the large table which dominates this page easier to read, each row has an alternating background color (between white and a yellow-green). Although this helps tremendously with readability, the alternating background colors do not update when the table is sorted. That is, if any of the sort functions are used, the background colors move with the associated rows, effectively shuffling the colors of each row. This, in fact, harms the readability of the page, and creates false groupings of visually similar rows.

[[File:AlterColors2018.png]]

Review Report sorted by metrics:

[[File:SortByMetr2018.png]]

====Solution====
=====Files=====
* app/views/review_mapping/_review_report.html.erb
* app/assets/stylesheets/table_sorter.scss

Fixing the alternating background color involved removing the existing backgrounding mechanism in _review_report.html.erb and applying the "zebra" widget to the existing java tablesorter table. 
[[File:Alt_background.PNG]] 
Defining the colors for odd and even rows was just a style fix in the table_sorter.scss file. 
[[File:Alt_background_css.PNG]] 

Both of these changes yields a table that updates the backgrounds of each element appropriately, even when the table is sorted. 
[[File:Table_alt_bg.PNG]] 

=== Add new color to Team reviewed ===

On this page, the names of teams reviewed are color-coded, to make it easier for instructors to see common issues.
For example, if a student has not completed a review for a team in every round, the team name is colored red. If a student has completed a review for a team either in every round or not, and has not received a grade, the team name is colored blue. A brown-colored team name indicates that the review grade has been assigned. However, the current color coding scheme assigns a blue color to a team name as long as there is A review. Thus, there is no distinction between the cases when a team's work has been reviewed in the previous round, but the team has not resubmitted their work in the following round, and if the team has resubmitted a work in a round, but there is no review in that round. That is, students may be marked explicitly as having done no work when they have nothing to review in the latest round. Thus, the plan is to add new colors to refactor the case of assigning blue color to team names.

[[File:TeamReviewed2018.png]]

====Solution====
=====Files=====
* app/views/review_mapping/_review_report.html.erb
* app/helpers/review_mapping_helper.rb
* config/application.rb
* app/assets/stylesheets/redbox.scss

Once again, if a student originally completed a review during the first round, but did not update it, AND the project under review has not been changed since the initial review, the reviewer should not be penalized. Reviewers who meet these criteria will be given a green color, otherwise, purple color.

To make new colors assignment work, firstly, we needed to define both new colors in app/assets/stylesheets/redbox.scss:

<pre>
#green a{
color: #00aa00;
}
#green{
height:auto;
}

#purple a{
color: #FF00FF;
}

#purple{
height:auto;
}
</pre>

The actual implementation of refining new logic of color assignment and its supporting methods was added to app/helpers/review_mapping_helper.rb. For this project we had to extend the logic of Response.exists?(map_id: response_map.id) condition:

- assign 'blue' to team reviewed only if the review grade is not assigned, and there is a review for each round;

- assign 'purple' if a team submitted their work within a round, but a student did not review it within that round, or if the team submitted a link in the previous round, and the link was updated within the following round;

- assign 'green' if there is no work to review within a round, or if the team submitted a link in the previous round, and the link was NOT updated within the following round;

Right now the method supports only wiki links, and can return their last-modified date. In the future, it can be extended to support github links.

<pre>
if Response.exists?(map_id: response_map.id)
if !response_map.try(:reviewer).try(:review_grade).nil?
'brown'
elsif response_for_each_round?(response_map)
'blue'
else
color = []
(1..@assignment.num_review_rounds).each do |round|
if submitted_within_round?(round, response_map, assignment_created, assignment_due_dates)
color.push 'purple'
else
link = submitted_hyperlink(round, response_map, assignment_created, assignment_due_dates)
if link.nil? or (link !~ /https*:\/\/wiki(.*)/) # can be extended for github links in future
color.push 'green'
else
link_updated_at = get_link_updated_at(link)
color.push link_updated_since_last?(round, assignment_due_dates, link_updated_at) ? 'purple' : 'green'
end
end
end
color[-1]
end
else
'red'
end
</pre>

The rest of new methods definitions, such as:
* response_for_each_round?
* submitted_within_round?
* submitted_hyperlink
* get_link_updated_at
* link_updated_since_last?
can be found in app/helpers/review_mapping_helper.rb.

To support the mechanism of getting last-modified header, we had to add "require 'net/https'" to config/application.rb.

The following screen-shot represents a case when a team submitted their work within a round, but a student did not review it within that round:

[[File:Review_wasnt_subm.png]]

This screen-shot represents a case when a team submitted a link in the last round, and the link was NOT updated within the next round. Thus, to avoid penalizing a student for no submitted review, the team name is assigned green color:

[[File:No_work_to_review.png]]

To reflect new color assignments, we updated the legend from app/views/review_mapping/_review_report.html.erb:

<pre>
 **In "Team reviewed" column, text in red indicates that the review is not yet completed;
text in blue indicates that the review grade is not assigned or updated;
text in brown indicates that the review grade has been assigned;
text in green indicates that there is no work to review;
text in purple indicates that there is no review for a team's work
</pre>

This is the updated legend:

[[File:New_legend.png]]

== Review Summary page ==

=== Header ===

[[File:NoHeader_2018.png]]

* collapse (fix whitespace where possible)
* add reviewers name to easily tell who's review you are looking at, as well as course and assignment this relates to
* fix round capitalization and add space between word round and the round number

==== Solution ====
* Most changes were front end, made to the view_review_scores_popup

[[File:HeaderScreenshot01.png]]

=== Questions should span the entire row ===

[[File:Question_Span.png]]

* Add colspan attribute which would allow the question to span the entire column which would then allow the name column to be smaller and the comment column to be larger.

==== Solution ====

* As mentioned, adding the colspan=3 attribute allowed the question to span the entire column. This was a purely client-side change.

[[File:Question_Span_Sol.png]]

=== Checkbox questions ===

[[File:Check_Question.png]]

* Replace individual team members name with just the team name
* Delete the comments column since comments aren't allowed in these types of questions
* Questions should be in a column that spans the width of the table.
* The team names that the reviewer reviewed should be in the following row separated into columns.
* The index in the table will have a check if the question was answered with a check and an X if answered otherwise. Each team will be represented as a column with its answer, check or X image, underneath.
====Solution====
=====Files=====
* app/views/popup/view_review_scores_popup.html.erb
Fixing this involved mostly html changes. Representing the team names instead of individual names was simply using the team attribute instead of the individual's name. Having questions span the entire table involved adding colspan attributes where necessary. Deleting the comments column for as well as representing each team and their answers in columns involved nesting a table into the existing table based on the question type. Representing the checkbox questions as pictures of a check and an X was as easy as showing an image based on the type of questions. 
[[File:CB_Code.PNG]] 
All of the above changes resulted in a checkbox section that looks like this: 
[[File:CB_Table.PNG]] 

=== Additional comments spanning ===

[[File:AdditionalComments.png]]

* Additional comments should span across all of the columns to save vertical space

==== Solution ====

* Several front-end changes result in a cleaner Additional Comments section which saves additional space by adding the Reviewer to a new column

[[File:AdditionalComments_Sol.png]]

=== CSS / Style improvements to review scores ===
* Add addition colors for reviews that didn't do a second(third,forth,etc) round review. In other words if the review hasn't changed from the previous round, color that review(er) a different color so instructors don't have to open the review and see that it hasn't changed.

== Test Plan ==
This project would be manually tested since it's all about UI improvement. To show that it's fully tested, we will record the manual tests for each goal we plan to achieve and of course, it will include audio and video. The video would be posted on Youtube so that it's easy for everyone to watch.

== Optional additional improvements ==

=== User Report Page ===
Another piece of low hanging fruit that we decided to tackle was the User report page, which shows the response for an individual review instead of the summary of all of the reviews done. You get to this page by clicking on a team name in the "Team Reviewed" column of the Review Report table(shown above). The edits made on this page where reflective of the edits made on the summary page to enure consistent styles between the two different types of reviewing reviews.
====Solution====
=====Files=====
* app/views/popup/team_users_pop_up.html.haml
The fixes to this page involved adding colspan's and adjusting what is displayed in score column based on whether the question is a checkbox question or not. 
[[File:User_popup_code.PNG]] 
The changes to the code above leads to a following table: 
[[File:User_popup_table.PNG]] 

----

== References ==

* [https://github.com/bawagne2/expertiza Our project Git Repo]

File:AdditionalComments Sol.png

2018-04-28T22:50:59Z

Bjyounce:

CSC/ECE 517 Spring 2018 E1815: Improvements to review grader

2018-04-28T22:50:37Z

Bjyounce: /* Additional comments spanning */

Improvements to Review Grader

__TOC__
== Abstract ==
In this design doc, since it's clearer to explain how we are going to improve the UI design by proposing each idea with the corresponding design's current image, we aren't going to separate problems from goals because you, as a reader, will need to scroll up and down to match problems to their corresponding goals.

== Introduction ==
Expertiza is a web application that is widely used by 2 types of users: students and instructors. When a user is logged-in as an instructor, and would like to see a review report on an assignment to review a grader, he/she could reach the page via Manage > Assignments and clicking on the “'''View review report'''” icon. The page would look somewhat like this:

[[File:Rev_report2018.png]]

To get a summary review report performed by a particular student, an instructor can get to the page from the review report by clicking “'''summary'''” in the row for that student. The page would look like this one:

[[File:Summary_report2018.png]]

== Problem Statement ==

This project is focused primarily on making various improvements to the Review Report and Review Summary pages, described in detail in the previous section. Each of these pages, while functional, suffer from many UI issues which make the pages more difficult to use for instructors. That is, information which would be useful to instructors is missing in several cases. In others, large amounts of unnecessary information is present, cluttering the site. Additionally, both pages suffer from structural and design issues which, again, waste instructor time.

Finally, the Review Report page sometimes mis-categorizes students who have not updated their reviews of others, even though the project under review has not changed! This could cause students to be deducted points unfairly. By adding a new way of highlighting this special case to instructors, review grades can be assigned more fairly.

== File Changes ==
* app/helpers/review_mapping_helper.rb for Add metrics charts
* app/views/popup/view_review_scores_popup.html.erb
* app/views/review_mapping/_review_report.html.erb
* app/assets/stylesheets/table_sorter.scss
* app/helpers/review_mapping_helper.rb
* app/views/popup/team_users_pop_up.html.haml
* config/application.rb

== Review Report Page==

=== Add metrics charts ===

Presently, this page contains a 'metrics' column, presently displaying the average review volume for a given user in text form. This method of displaying data can be difficult to interpret, and even more difficult to compare at a glance, or to notice trends. Additionally, plans for expanding the metrics column to include more data would worsen this issue if it remained in its current state.

[[File:Metrics2018.png]]

====Solution====
=====Files=====
* app/helpers/review_mapping_helper.rb

This project will replace the text in this column with easy to read bar or line graphs, which will be color-coded or otherwise made very simple and easy to read. These graphs will display the data clearly and concisely, mitigating these issues. This concise display will allow for easier comparison of data, easier interpretation of data, and will allow for more metrics to be added without simply overcrowding the page with text.

First of all, we calculate the average volume in each round and the overall average volume of all rounds.
[[File:chart_data_organize.png]]

Next, we organize all the data and their corresponding label array for the chart drawing method later.

[[File:chart_data_array.png]]

Finally, we apply an extension called chartjs-ror to help us draw horizontal bar charts. Most of the codes in this method relate to the configuration setting of the chart.
[[File:metric_chart_config_code.png]]

[[File:metric_chart_config_code1.png]]

The result of our improvement doesn't have its value explicitly showed because we want to save more space and let the chart be simpler to read. Yet, you can let your mouse points the bar, then the value will show up as seen in the figures below.

[[File:chart_no_value.png]]

[[File:metric_chart_value.png]]

=== Update alternating background color if sorted ===

In order to make the large table which dominates this page easier to read, each row has an alternating background color (between white and a yellow-green). Although this helps tremendously with readability, the alternating background colors do not update when the table is sorted. That is, if any of the sort functions are used, the background colors move with the associated rows, effectively shuffling the colors of each row. This, in fact, harms the readability of the page, and creates false groupings of visually similar rows.

[[File:AlterColors2018.png]]

Review Report sorted by metrics:

[[File:SortByMetr2018.png]]

====Solution====
=====Files=====
* app/views/review_mapping/_review_report.html.erb
* app/assets/stylesheets/table_sorter.scss

Fixing the alternating background color involved removing the existing backgrounding mechanism in _review_report.html.erb and applying the "zebra" widget to the existing java tablesorter table. 
[[File:Alt_background.PNG]] 
Defining the colors for odd and even rows was just a style fix in the table_sorter.scss file. 
[[File:Alt_background_css.PNG]] 

Both of these changes yields a table that updates the backgrounds of each element appropriately, even when the table is sorted. 
[[File:Table_alt_bg.PNG]] 

=== Add new color to Team reviewed ===

On this page, the names of teams reviewed are color-coded, to make it easier for instructors to see common issues.
For example, if a student has not completed a review for a team in every round, the team name is colored red. If a student has completed a review for a team either in every round or not, and has not received a grade, the team name is colored blue. A brown-colored team name indicates that the review grade has been assigned. However, the current color coding scheme assigns a blue color to a team name as long as there is A review. Thus, there is no distinction between the cases when a team's work has been reviewed in the previous round, but the team has not resubmitted their work in the following round, and if the team has resubmitted a work in a round, but there is no review in that round. That is, students may be marked explicitly as having done no work when they have nothing to review in the latest round. Thus, the plan is to add new colors to refactor the case of assigning blue color to team names.

[[File:TeamReviewed2018.png]]

====Solution====
=====Files=====
* app/views/review_mapping/_review_report.html.erb
* app/helpers/review_mapping_helper.rb
* config/application.rb
* app/assets/stylesheets/redbox.scss

Once again, if a student originally completed a review during the first round, but did not update it, AND the project under review has not been changed since the initial review, the reviewer should not be penalized. Reviewers who meet these criteria will be given a green color, otherwise, purple color.

To make new colors assignment work, firstly, we needed to define both new colors in app/assets/stylesheets/redbox.scss:

<pre>
#green a{
color: #00aa00;
}
#green{
height:auto;
}

#purple a{
color: #FF00FF;
}

#purple{
height:auto;
}
</pre>

The actual implementation of refining new logic of color assignment and its supporting methods was added to app/helpers/review_mapping_helper.rb. For this project we had to extend the logic of Response.exists?(map_id: response_map.id) condition:

- assign 'blue' to team reviewed only if the review grade is not assigned, and there is a review for each round;

- assign 'purple' if a team submitted their work within a round, but a student did not review it within that round, or if the team submitted a link in the previous round, and the link was updated within the following round;

- assign 'green' if there is no work to review within a round, or if the team submitted a link in the previous round, and the link was NOT updated within the following round;

Right now the method supports only wiki links, and can return their last-modified date. In the future, it can be extended to support github links.

<pre>
if Response.exists?(map_id: response_map.id)
if !response_map.try(:reviewer).try(:review_grade).nil?
'brown'
elsif response_for_each_round?(response_map)
'blue'
else
color = []
(1..@assignment.num_review_rounds).each do |round|
if submitted_within_round?(round, response_map, assignment_created, assignment_due_dates)
color.push 'purple'
else
link = submitted_hyperlink(round, response_map, assignment_created, assignment_due_dates)
if link.nil? or (link !~ /https*:\/\/wiki(.*)/) # can be extended for github links in future
color.push 'green'
else
link_updated_at = get_link_updated_at(link)
color.push link_updated_since_last?(round, assignment_due_dates, link_updated_at) ? 'purple' : 'green'
end
end
end
color[-1]
end
else
'red'
end
</pre>

The rest of new methods definitions, such as:
* response_for_each_round?
* submitted_within_round?
* submitted_hyperlink
* get_link_updated_at
* link_updated_since_last?
can be found in app/helpers/review_mapping_helper.rb.

To support the mechanism of getting last-modified header, we had to add "require 'net/https'" to config/application.rb.

The following screen-shot represents a case when a team submitted their work within a round, but a student did not review it within that round:

[[File:Review_wasnt_subm.png]]

This screen-shot represents a case when a team submitted a link in the last round, and the link was NOT updated within the next round. Thus, to avoid penalizing a student for no submitted review, the team name is assigned green color:

[[File:No_work_to_review.png]]

To reflect new color assignments, we updated the legend from app/views/review_mapping/_review_report.html.erb:

<pre>
 **In "Team reviewed" column, text in red indicates that the review is not yet completed;
text in blue indicates that the review grade is not assigned or updated;
text in brown indicates that the review grade has been assigned;
text in green indicates that there is no work to review;
text in purple indicates that there is no review for a team's work
</pre>

This is the updated legend:

[[File:New_legend.png]]

== Review Summary page ==

=== Header ===

[[File:NoHeader_2018.png]]

* collapse (fix whitespace where possible)
* add reviewers name to easily tell who's review you are looking at, as well as course and assignment this relates to
* fix round capitalization and add space between word round and the round number

==== Solution ====
* Most changes were front end, made to the view_review_scores_popup

[[File:HeaderScreenshot01.png]]

=== Questions should span the entire row ===

[[File:Question_Span.png]]

* Add colspan attribute which would allow the question to span the entire column which would then allow the name column to be smaller and the comment column to be larger.

==== Solution ====

* As mentioned, adding the colspan=3 attribute allowed the question to span the entire column. This was a purely client-side change.

[[File:Question_Span_Sol.png]]

=== Checkbox questions ===

[[File:Check_Question.png]]

* Replace individual team members name with just the team name
* Delete the comments column since comments aren't allowed in these types of questions
* Questions should be in a column that spans the width of the table.
* The team names that the reviewer reviewed should be in the following row separated into columns.
* The index in the table will have a check if the question was answered with a check and an X if answered otherwise. Each team will be represented as a column with its answer, check or X image, underneath.
====Solution====
=====Files=====
* app/views/popup/view_review_scores_popup.html.erb
Fixing this involved mostly html changes. Representing the team names instead of individual names was simply using the team attribute instead of the individual's name. Having questions span the entire table involved adding colspan attributes where necessary. Deleting the comments column for as well as representing each team and their answers in columns involved nesting a table into the existing table based on the question type. Representing the checkbox questions as pictures of a check and an X was as easy as showing an image based on the type of questions. 
[[File:CB_Code.PNG]] 
All of the above changes resulted in a checkbox section that looks like this: 
[[File:CB_Table.PNG]] 

=== Additional comments spanning ===

[[File:AdditionalComments.png]]

* Additional comments should span across all of the columns to save vertical space

==== Solution ====

* Several front-end changes result in a cleaner Additional Comments section which saves additional space by adding the Reviewer to a new column

[[File:AdditionalComments_Sol.png]]

=== CSS / Style improvements to review scores ===
* Add addition colors for reviews that didn't do a second(third,forth,etc) round review. In other words if the review hasn't changed from the previous round, color that review(er) a different color so instructors don't have to open the review and see that it hasn't changed.

== Test Plan ==
This project would be manually tested since it's all about UI improvement. To show that it's fully tested, we will record the manual tests for each goal we plan to achieve and of course, it will include audio and video. The video would be posted on Youtube so that it's easy for everyone to watch.

== Optional additional improvements ==

=== Review Report page - sort by other metrics ===

Ideally, this page would have an option to allow instructors to sort by any metric. Presently, only one metric is shown, but adding more has been planned for the future. This may require the addition of a drop-down to allow the selection of what metric to sort by. However this is implemented, it may not add too much complexity to the page.

=== User Report Page ===
Another piece of low hanging fruit that we decided to tackle was the User report page, which shows the response for an individual review instead of the summary of all of the reviews done. You get to this page by clicking on a team name in the "Team Reviewed" column of the Review Report table(shown above). The edits made on this page where reflective of the edits made on the summary page to enure consistent styles between the two different types of reviewing reviews.
====Solution====
=====Files=====
* app/views/popup/team_users_pop_up.html.haml
The fixes to this page involved adding colspan's and adjusting what is displayed in score column based on whether the question is a checkbox question or not. 
[[File:User_popup_code.PNG]] 
The changes to the code above leads to a following table: 
[[File:User_popup_table.PNG]] 

=== Review Summary page - Interpret HTML ===
Presently, users may enter HTML code to style their comments and reviews. However, this is currently not displayed properly. For example, HTML tags will themselves be displayed. The addition of a gem or potentially configuration changes will be needed to ensure this HTML will be properly displayed. Any implementation of this task should follow the DRY principle - that is, the implementation should be able to be re-used in all other pages where user-entered HTMl should be displayed

----

== References ==

* [https://github.com/bawagne2/expertiza Our project Git Repo]

File:Question Span Sol.png

2018-04-28T22:48:10Z

Bjyounce:

CSC/ECE 517 Spring 2018 E1815: Improvements to review grader

2018-04-28T22:47:43Z

Bjyounce: /* Questions should span the entire row */

Improvements to Review Grader

__TOC__
== Abstract ==
In this design doc, since it's clearer to explain how we are going to improve the UI design by proposing each idea with the corresponding design's current image, we aren't going to separate problems from goals because you, as a reader, will need to scroll up and down to match problems to their corresponding goals.

== Introduction ==
Expertiza is a web application that is widely used by 2 types of users: students and instructors. When a user is logged-in as an instructor, and would like to see a review report on an assignment to review a grader, he/she could reach the page via Manage > Assignments and clicking on the “'''View review report'''” icon. The page would look somewhat like this:

[[File:Rev_report2018.png]]

To get a summary review report performed by a particular student, an instructor can get to the page from the review report by clicking “'''summary'''” in the row for that student. The page would look like this one:

[[File:Summary_report2018.png]]

== Problem Statement ==

This project is focused primarily on making various improvements to the Review Report and Review Summary pages, described in detail in the previous section. Each of these pages, while functional, suffer from many UI issues which make the pages more difficult to use for instructors. That is, information which would be useful to instructors is missing in several cases. In others, large amounts of unnecessary information is present, cluttering the site. Additionally, both pages suffer from structural and design issues which, again, waste instructor time.

Finally, the Review Report page sometimes mis-categorizes students who have not updated their reviews of others, even though the project under review has not changed! This could cause students to be deducted points unfairly. By adding a new way of highlighting this special case to instructors, review grades can be assigned more fairly.

== File Changes ==
* app/helpers/review_mapping_helper.rb for Add metrics charts
* app/views/popup/view_review_scores_popup.html.erb
* app/views/review_mapping/_review_report.html.erb
* app/assets/stylesheets/table_sorter.scss
* app/helpers/review_mapping_helper.rb
* app/views/popup/team_users_pop_up.html.haml
* config/application.rb

== Review Report Page==

=== Add metrics charts ===

Presently, this page contains a 'metrics' column, presently displaying the average review volume for a given user in text form. This method of displaying data can be difficult to interpret, and even more difficult to compare at a glance, or to notice trends. Additionally, plans for expanding the metrics column to include more data would worsen this issue if it remained in its current state.

[[File:Metrics2018.png]]

====Solution====
=====Files=====
* app/helpers/review_mapping_helper.rb

This project will replace the text in this column with easy to read bar or line graphs, which will be color-coded or otherwise made very simple and easy to read. These graphs will display the data clearly and concisely, mitigating these issues. This concise display will allow for easier comparison of data, easier interpretation of data, and will allow for more metrics to be added without simply overcrowding the page with text.

First of all, we calculate the average volume in each round and the overall average volume of all rounds.
[[File:chart_data_organize.png]]

Next, we organize all the data and their corresponding label array for the chart drawing method later.

[[File:chart_data_array.png]]

Finally, we apply an extension called chartjs-ror to help us draw horizontal bar charts. Most of the codes in this method relate to the configuration setting of the chart.
[[File:metric_chart_config_code.png]]

[[File:metric_chart_config_code1.png]]

The result of our improvement doesn't have its value explicitly showed because we want to save more space and let the chart be simpler to read. Yet, you can let your mouse points the bar, then the value will show up as seen in the figures below.

[[File:chart_no_value.png]]

[[File:metric_chart_value.png]]

=== Update alternating background color if sorted ===

In order to make the large table which dominates this page easier to read, each row has an alternating background color (between white and a yellow-green). Although this helps tremendously with readability, the alternating background colors do not update when the table is sorted. That is, if any of the sort functions are used, the background colors move with the associated rows, effectively shuffling the colors of each row. This, in fact, harms the readability of the page, and creates false groupings of visually similar rows.

[[File:AlterColors2018.png]]

Review Report sorted by metrics:

[[File:SortByMetr2018.png]]

====Solution====
=====Files=====
* app/views/review_mapping/_review_report.html.erb
* app/assets/stylesheets/table_sorter.scss

Fixing the alternating background color involved removing the existing backgrounding mechanism in _review_report.html.erb and applying the "zebra" widget to the existing java tablesorter table. 
[[File:Alt_background.PNG]] 
Defining the colors for odd and even rows was just a style fix in the table_sorter.scss file. 
[[File:Alt_background_css.PNG]] 

Both of these changes yields a table that updates the backgrounds of each element appropriately, even when the table is sorted. 
[[File:Table_alt_bg.PNG]] 

=== Add new color to Team reviewed ===

On this page, the names of teams reviewed are color-coded, to make it easier for instructors to see common issues.
For example, if a student has not completed a review for a team in every round, the team name is colored red. If a student has completed a review for a team either in every round or not, and has not received a grade, the team name is colored blue. A brown-colored team name indicates that the review grade has been assigned. However, the current color coding scheme assigns a blue color to a team name as long as there is A review. Thus, there is no distinction between the cases when a team's work has been reviewed in the previous round, but the team has not resubmitted their work in the following round, and if the team has resubmitted a work in a round, but there is no review in that round. That is, students may be marked explicitly as having done no work when they have nothing to review in the latest round. Thus, the plan is to add new colors to refactor the case of assigning blue color to team names.

[[File:TeamReviewed2018.png]]

====Solution====
=====Files=====
* app/views/review_mapping/_review_report.html.erb
* app/helpers/review_mapping_helper.rb
* config/application.rb
* app/assets/stylesheets/redbox.scss

Once again, if a student originally completed a review during the first round, but did not update it, AND the project under review has not been changed since the initial review, the reviewer should not be penalized. Reviewers who meet these criteria will be given a green color, otherwise, purple color.

To make new colors assignment work, firstly, we needed to define both new colors in app/assets/stylesheets/redbox.scss:

<pre>
#green a{
color: #00aa00;
}
#green{
height:auto;
}

#purple a{
color: #FF00FF;
}

#purple{
height:auto;
}
</pre>

The actual implementation of refining new logic of color assignment and its supporting methods was added to app/helpers/review_mapping_helper.rb. For this project we had to extend the logic of Response.exists?(map_id: response_map.id) condition:

- assign 'blue' to team reviewed only if the review grade is not assigned, and there is a review for each round;

- assign 'purple' if a team submitted their work within a round, but a student did not review it within that round, or if the team submitted a link in the previous round, and the link was updated within the following round;

- assign 'green' if there is no work to review within a round, or if the team submitted a link in the previous round, and the link was NOT updated within the following round;

Right now the method supports only wiki links, and can return their last-modified date. In the future, it can be extended to support github links.

<pre>
if Response.exists?(map_id: response_map.id)
if !response_map.try(:reviewer).try(:review_grade).nil?
'brown'
elsif response_for_each_round?(response_map)
'blue'
else
color = []
(1..@assignment.num_review_rounds).each do |round|
if submitted_within_round?(round, response_map, assignment_created, assignment_due_dates)
color.push 'purple'
else
link = submitted_hyperlink(round, response_map, assignment_created, assignment_due_dates)
if link.nil? or (link !~ /https*:\/\/wiki(.*)/) # can be extended for github links in future
color.push 'green'
else
link_updated_at = get_link_updated_at(link)
color.push link_updated_since_last?(round, assignment_due_dates, link_updated_at) ? 'purple' : 'green'
end
end
end
color[-1]
end
else
'red'
end
</pre>

The rest of new methods definitions, such as:
* response_for_each_round?
* submitted_within_round?
* submitted_hyperlink
* get_link_updated_at
* link_updated_since_last?
can be found in app/helpers/review_mapping_helper.rb.

To support the mechanism of getting last-modified header, we had to add "require 'net/https'" to config/application.rb.

The following screen-shot represents a case when a team submitted their work within a round, but a student did not review it within that round:

[[File:Review_wasnt_subm.png]]

This screen-shot represents a case when a team submitted a link in the last round, and the link was NOT updated within the next round. Thus, to avoid penalizing a student for no submitted review, the team name is assigned green color:

[[File:No_work_to_review.png]]

To reflect new color assignments, we updated the legend from app/views/review_mapping/_review_report.html.erb:

<pre>
 **In "Team reviewed" column, text in red indicates that the review is not yet completed;
text in blue indicates that the review grade is not assigned or updated;
text in brown indicates that the review grade has been assigned;
text in green indicates that there is no work to review;
text in purple indicates that there is no review for a team's work
</pre>

This is the updated legend:

[[File:New_legend.png]]

== Review Summary page ==

=== Header ===

[[File:NoHeader_2018.png]]

* collapse (fix whitespace where possible)
* add reviewers name to easily tell who's review you are looking at, as well as course and assignment this relates to
* fix round capitalization and add space between word round and the round number

==== Solution ====
* Most changes were front end, made to the view_review_scores_popup

[[File:HeaderScreenshot01.png]]

=== Questions should span the entire row ===

[[File:Question_Span.png]]

* Add colspan attribute which would allow the question to span the entire column which would then allow the name column to be smaller and the comment column to be larger.

==== Solution ====

* As mentioned, adding the colspan=3 attribute allowed the question to span the entire column. This was a purely client-side change.

[[File:Question_Span_Sol.png]]

=== Checkbox questions ===

[[File:Check_Question.png]]

* Replace individual team members name with just the team name
* Delete the comments column since comments aren't allowed in these types of questions
* Questions should be in a column that spans the width of the table.
* The team names that the reviewer reviewed should be in the following row separated into columns.
* The index in the table will have a check if the question was answered with a check and an X if answered otherwise. Each team will be represented as a column with its answer, check or X image, underneath.
====Solution====
=====Files=====
* app/views/popup/view_review_scores_popup.html.erb
Fixing this involved mostly html changes. Representing the team names instead of individual names was simply using the team attribute instead of the individual's name. Having questions span the entire table involved adding colspan attributes where necessary. Deleting the comments column for as well as representing each team and their answers in columns involved nesting a table into the existing table based on the question type. Representing the checkbox questions as pictures of a check and an X was as easy as showing an image based on the type of questions. 
[[File:CB_Code.PNG]] 
All of the above changes resulted in a checkbox section that looks like this: 
[[File:CB_Table.PNG]] 

=== Additional comments spanning ===

[[File:AdditionalComments.png]]

* Additional comments should span across all of the columns to save vertical space

=== CSS / Style improvements to review scores ===
* Add addition colors for reviews that didn't do a second(third,forth,etc) round review. In other words if the review hasn't changed from the previous round, color that review(er) a different color so instructors don't have to open the review and see that it hasn't changed.

== Test Plan ==
This project would be manually tested since it's all about UI improvement. To show that it's fully tested, we will record the manual tests for each goal we plan to achieve and of course, it will include audio and video. The video would be posted on Youtube so that it's easy for everyone to watch.

== Optional additional improvements ==

=== Review Report page - sort by other metrics ===

Ideally, this page would have an option to allow instructors to sort by any metric. Presently, only one metric is shown, but adding more has been planned for the future. This may require the addition of a drop-down to allow the selection of what metric to sort by. However this is implemented, it may not add too much complexity to the page.

=== User Report Page ===
Another piece of low hanging fruit that we decided to tackle was the User report page, which shows the response for an individual review instead of the summary of all of the reviews done. You get to this page by clicking on a team name in the "Team Reviewed" column of the Review Report table(shown above). The edits made on this page where reflective of the edits made on the summary page to enure consistent styles between the two different types of reviewing reviews.
====Solution====
=====Files=====
* app/views/popup/team_users_pop_up.html.haml
The fixes to this page involved adding colspan's and adjusting what is displayed in score column based on whether the question is a checkbox question or not. 
[[File:User_popup_code.PNG]] 
The changes to the code above leads to a following table: 
[[File:User_popup_table.PNG]] 

=== Review Summary page - Interpret HTML ===
Presently, users may enter HTML code to style their comments and reviews. However, this is currently not displayed properly. For example, HTML tags will themselves be displayed. The addition of a gem or potentially configuration changes will be needed to ensure this HTML will be properly displayed. Any implementation of this task should follow the DRY principle - that is, the implementation should be able to be re-used in all other pages where user-entered HTMl should be displayed

----

== References ==

* [https://github.com/bawagne2/expertiza Our project Git Repo]

File:HeaderScreenshot01.png

2018-04-28T22:42:39Z

Bjyounce: uploaded a new version of "File:HeaderScreenshot01.png"

File:HeaderScreenshot01.png

2018-04-28T22:42:02Z

Bjyounce:

CSC/ECE 517 Spring 2018 E1815: Improvements to review grader

2018-04-28T22:41:07Z

Bjyounce: /* Review Summary page */

Improvements to Review Grader

__TOC__
== Abstract ==
In this design doc, since it's clearer to explain how we are going to improve the UI design by proposing each idea with the corresponding design's current image, we aren't going to separate problems from goals because you, as a reader, will need to scroll up and down to match problems to their corresponding goals.

== Introduction ==
Expertiza is a web application that is widely used by 2 types of users: students and instructors. When a user is logged-in as an instructor, and would like to see a review report on an assignment to review a grader, he/she could reach the page via Manage > Assignments and clicking on the “'''View review report'''” icon. The page would look somewhat like this:

[[File:Rev_report2018.png]]

To get a summary review report performed by a particular student, an instructor can get to the page from the review report by clicking “'''summary'''” in the row for that student. The page would look like this one:

[[File:Summary_report2018.png]]

== Problem Statement ==

This project is focused primarily on making various improvements to the Review Report and Review Summary pages, described in detail in the previous section. Each of these pages, while functional, suffer from many UI issues which make the pages more difficult to use for instructors. That is, information which would be useful to instructors is missing in several cases. In others, large amounts of unnecessary information is present, cluttering the site. Additionally, both pages suffer from structural and design issues which, again, waste instructor time.

Finally, the Review Report page sometimes mis-categorizes students who have not updated their reviews of others, even though the project under review has not changed! This could cause students to be deducted points unfairly. By adding a new way of highlighting this special case to instructors, review grades can be assigned more fairly.

== File Changes ==
* app/helpers/review_mapping_helper.rb for Add metrics charts
* app/views/popup/view_review_scores_popup.html.erb
* app/views/review_mapping/_review_report.html.erb
* app/assets/stylesheets/table_sorter.scss
* app/helpers/review_mapping_helper.rb
* app/views/popup/team_users_pop_up.html.haml
* config/application.rb

== Review Report Page==

=== Add metrics charts ===

Presently, this page contains a 'metrics' column, presently displaying the average review volume for a given user in text form. This method of displaying data can be difficult to interpret, and even more difficult to compare at a glance, or to notice trends. Additionally, plans for expanding the metrics column to include more data would worsen this issue if it remained in its current state.

[[File:Metrics2018.png]]

====Solution====
=====Files=====
* app/helpers/review_mapping_helper.rb

This project will replace the text in this column with easy to read bar or line graphs, which will be color-coded or otherwise made very simple and easy to read. These graphs will display the data clearly and concisely, mitigating these issues. This concise display will allow for easier comparison of data, easier interpretation of data, and will allow for more metrics to be added without simply overcrowding the page with text.

First of all, we calculate the average volume in each round and the overall average volume of all rounds.
[[File:chart_data_organize.png]]

Next, we organize all the data and their corresponding label array for the chart drawing method later.

[[File:chart_data_array.png]]

Finally, we apply an extension called chartjs-ror to help us draw horizontal bar charts. Most of the codes in this method relate to the configuration setting of the chart.
[[File:metric_chart_config_code.png]]

[[File:metric_chart_config_code1.png]]

The result of our improvement doesn't have its value explicitly showed because we want to save more space and let the chart be simpler to read. Yet, you can let your mouse points the bar, then the value will show up as seen in the figures below.

[[File:chart_no_value.png]]

[[File:metric_chart_value.png]]

=== Update alternating background color if sorted ===

In order to make the large table which dominates this page easier to read, each row has an alternating background color (between white and a yellow-green). Although this helps tremendously with readability, the alternating background colors do not update when the table is sorted. That is, if any of the sort functions are used, the background colors move with the associated rows, effectively shuffling the colors of each row. This, in fact, harms the readability of the page, and creates false groupings of visually similar rows.

[[File:AlterColors2018.png]]

Review Report sorted by metrics:

[[File:SortByMetr2018.png]]

====Solution====
=====Files=====
* app/views/review_mapping/_review_report.html.erb
* app/assets/stylesheets/table_sorter.scss

Fixing the alternating background color involved removing the existing backgrounding mechanism in _review_report.html.erb and applying the "zebra" widget to the existing java tablesorter table. 
[[File:Alt_background.PNG]] 
Defining the colors for odd and even rows was just a style fix in the table_sorter.scss file. 
[[File:Alt_background_css.PNG]] 

Both of these changes yields a table that updates the backgrounds of each element appropriately, even when the table is sorted. 
[[File:Table_alt_bg.PNG]] 

=== Add new color to Team reviewed ===

On this page, the names of teams reviewed are color-coded, to make it easier for instructors to see common issues.
For example, if a student has not completed a review for a team in every round, the team name is colored red. If a student has completed a review for a team either in every round or not, and has not received a grade, the team name is colored blue. A brown-colored team name indicates that the review grade has been assigned. However, the current color coding scheme assigns a blue color to a team name as long as there is A review. Thus, there is no distinction between the cases when a team's work has been reviewed in the previous round, but the team has not resubmitted their work in the following round, and if the team has resubmitted a work in a round, but there is no review in that round. That is, students may be marked explicitly as having done no work when they have nothing to review in the latest round. Thus, the plan is to add new colors to refactor the case of assigning blue color to team names.

[[File:TeamReviewed2018.png]]

====Solution====
=====Files=====
* app/views/review_mapping/_review_report.html.erb
* app/helpers/review_mapping_helper.rb
* config/application.rb
* app/assets/stylesheets/redbox.scss

Once again, if a student originally completed a review during the first round, but did not update it, AND the project under review has not been changed since the initial review, the reviewer should not be penalized. Reviewers who meet these criteria will be given a green color, otherwise, purple color.

To make new colors assignment work, firstly, we needed to define both new colors in app/assets/stylesheets/redbox.scss:

<pre>
#green a{
color: #00aa00;
}
#green{
height:auto;
}

#purple a{
color: #FF00FF;
}

#purple{
height:auto;
}
</pre>

The actual implementation of refining new logic of color assignment and its supporting methods was added to app/helpers/review_mapping_helper.rb. For this project we had to extend the logic of Response.exists?(map_id: response_map.id) condition:

- assign 'blue' to team reviewed only if the review grade is not assigned, and there is a review for each round;

- assign 'purple' if a team submitted their work within a round, but a student did not review it within that round, or if the team submitted a link in the previous round, and the link was updated within the following round;

- assign 'green' if there is no work to review within a round, or if the team submitted a link in the previous round, and the link was NOT updated within the following round;

Right now the method supports only wiki links, and can return their last-modified date. In the future, it can be extended to support github links.

<pre>
if Response.exists?(map_id: response_map.id)
if !response_map.try(:reviewer).try(:review_grade).nil?
'brown'
elsif response_for_each_round?(response_map)
'blue'
else
color = []
(1..@assignment.num_review_rounds).each do |round|
if submitted_within_round?(round, response_map, assignment_created, assignment_due_dates)
color.push 'purple'
else
link = submitted_hyperlink(round, response_map, assignment_created, assignment_due_dates)
if link.nil? or (link !~ /https*:\/\/wiki(.*)/) # can be extended for github links in future
color.push 'green'
else
link_updated_at = get_link_updated_at(link)
color.push link_updated_since_last?(round, assignment_due_dates, link_updated_at) ? 'purple' : 'green'
end
end
end
color[-1]
end
else
'red'
end
</pre>

The rest of new methods definitions, such as:
* response_for_each_round?
* submitted_within_round?
* submitted_hyperlink
* get_link_updated_at
* link_updated_since_last?
can be found in app/helpers/review_mapping_helper.rb.

To support the mechanism of getting last-modified header, we had to add "require 'net/https'" to config/application.rb.

The following screen-shot represents a case when a team submitted their work within a round, but a student did not review it within that round:

[[File:Review_wasnt_subm.png]]

This screen-shot represents a case when a team submitted a link in the last round, and the link was NOT updated within the next round. Thus, to avoid penalizing a student for no submitted review, the team name is assigned green color:

[[File:No_work_to_review.png]]

To reflect new color assignments, we updated the legend from app/views/review_mapping/_review_report.html.erb:

<pre>
 **In "Team reviewed" column, text in red indicates that the review is not yet completed;
text in blue indicates that the review grade is not assigned or updated;
text in brown indicates that the review grade has been assigned;
text in green indicates that there is no work to review;
text in purple indicates that there is no review for a team's work
</pre>

This is the updated legend:

[[File:New_legend.png]]

== Review Summary page ==

=== Header ===

[[File:NoHeader_2018.png]]

* collapse (fix whitespace where possible)
* add reviewers name to easily tell who's review you are looking at, as well as course and assignment this relates to
* fix round capitalization and add space between word round and the round number

==== Solution ====
* Most changes were front end, made to the view_review_scores_popup

[[File:HeaderScreenshot01.png]]

=== Questions should span the entire row ===

[[File:Question_Span.png]]

* Add colspan attribute which would allow the question to span the entire column which would then allow the name column to be smaller and the comment column to be larger.

=== Checkbox questions ===

[[File:Check_Question.png]]

* Replace individual team members name with just the team name
* Delete the comments column since comments aren't allowed in these types of questions
* Questions should be in a column that spans the width of the table.
* The team names that the reviewer reviewed should be in the following row separated into columns.
* The index in the table will have a check if the question was answered with a check and an X if answered otherwise. Each team will be represented as a column with its answer, check or X image, underneath.
====Solution====
=====Files=====
* app/views/popup/view_review_scores_popup.html.erb
Fixing this involved mostly html changes. Representing the team names instead of individual names was simply using the team attribute instead of the individual's name. Having questions span the entire table involved adding colspan attributes where necessary. Deleting the comments column for as well as representing each team and their answers in columns involved nesting a table into the existing table based on the question type. Representing the checkbox questions as pictures of a check and an X was as easy as showing an image based on the type of questions. 
[[File:CB_Code.PNG]] 
All of the above changes resulted in a checkbox section that looks like this: 
[[File:CB_Table.PNG]] 

=== Additional comments spanning ===

[[File:AdditionalComments.png]]

* Additional comments should span across all of the columns to save vertical space

=== CSS / Style improvements to review scores ===
* Add addition colors for reviews that didn't do a second(third,forth,etc) round review. In other words if the review hasn't changed from the previous round, color that review(er) a different color so instructors don't have to open the review and see that it hasn't changed.

== Test Plan ==
This project would be manually tested since it's all about UI improvement. To show that it's fully tested, we will record the manual tests for each goal we plan to achieve and of course, it will include audio and video. The video would be posted on Youtube so that it's easy for everyone to watch.

== Optional additional improvements ==

=== Review Report page - sort by other metrics ===

Ideally, this page would have an option to allow instructors to sort by any metric. Presently, only one metric is shown, but adding more has been planned for the future. This may require the addition of a drop-down to allow the selection of what metric to sort by. However this is implemented, it may not add too much complexity to the page.

=== User Report Page ===
Another piece of low hanging fruit that we decided to tackle was the User report page, which shows the response for an individual review instead of the summary of all of the reviews done. You get to this page by clicking on a team name in the "Team Reviewed" column of the Review Report table(shown above). The edits made on this page where reflective of the edits made on the summary page to enure consistent styles between the two different types of reviewing reviews.
====Solution====
=====Files=====
* app/views/popup/team_users_pop_up.html.haml
The fixes to this page involved adding colspan's and adjusting what is displayed in score column based on whether the question is a checkbox question or not. 
[[File:User_popup_code.PNG]] 
The changes to the code above leads to a following table: 
[[File:User_popup_table.PNG]] 

=== Review Summary page - Interpret HTML ===
Presently, users may enter HTML code to style their comments and reviews. However, this is currently not displayed properly. For example, HTML tags will themselves be displayed. The addition of a gem or potentially configuration changes will be needed to ensure this HTML will be properly displayed. Any implementation of this task should follow the DRY principle - that is, the implementation should be able to be re-used in all other pages where user-entered HTMl should be displayed

----

== References ==

* [https://github.com/bawagne2/expertiza Our project Git Repo]

CSC/ECE 517 Spring 2018 E1815: Improvements to review grader

2018-04-06T14:34:49Z

Bjyounce: /* CSS / Style improvements to review scores */

Improvements to Review Grader

__TOC__

== Introduction ==
Expertiza is a web application that is widely used by 2 types of users: students and instructors. When a user is logged-in as an instructor, and would like to see a review report on an assignment to review a grader, he/she could reach the page via Manage > Assignments and clicking on the “'''View review report'''” icon. The page would look somewhat like this:

[[File:Rev_report2018.png]]

To get a summary review report performed by a particular student, an instructor can get to the page from the review report by clicking “'''summary'''” in the row for that student. The page would look like this one:

[[File:Summary_report2018.png]]

== Problem Statement ==

This project is focused primarily on making various improvements to the Review Report and Review Summary pages, described in detail in the previous section. Each of these pages, while functional, suffer from many UI issues which make the pages more difficult to use for instructors. That is, information which would be useful to instructors is missing in several cases. In others, large amounts of unnecessary information is present, cluttering the site. Additionally, both pages suffer from structural and design issues which, again, waste instructor time.

Finally, the Review Report page sometimes mis-categorizes students who have not updated their reviews of others, even though the project under review has not changed! This could cause students to be deducted points unfairly. By adding a new way of highlighting this special case to instructors, review grades can be assigned more fairly.

== Review Report Page==

=== Add metrics charts ===

Presently, this page contains a 'metrics' column, presently displaying the average review volume for a given user in text form. This method of displaying data can be difficult to interpret, and even more difficult to compare at a glance, or to notice trends. Additionally, plans for expanding the metrics column to include more data would worsen this issue if it remained in its current state.

[[File:Metrics2018.png]]

This project will replace the text in this column with easy to read bar or line graphs, which will be color-coded or otherwise made very simple and easy to read. These graphs will display the data clearly and concisely, mitigating these issues. This concise display will allow for easier comparison of data, easier interpretation of data, and will allow for more metrics to be added without simply overcrowding the page with text.

=== Update alternating background color if sorted ===

In order to make the large table which dominates this page easier to read, each row has an alternating background color (between white and a yellow-green). Although this helps tremendously with readability, the alternating background colors do not update when the table is sorted. That is, if any of the sort functions are used, the background colors move with the associated rows, effectively shuffling the colors of each row. This, in fact, harms the readability of the page, and creates false groupings of visually similar rows.

This project will attempt to maintain the alternating background colors, even if the content of the table has been re-organized due to sorting.

=== Add new color to reviewers ===

On this page, the names of student peer reviewers are often color-coded, to make it easier for instructors to see common issues. For example, reviewers who have not submitted a review may be colored red, and reviewers who have not received a grade may be colored blue. However, as mentioned earlier, the current color coding scheme will assign a red color to students who have not updated their review of others projects, even when that project has not changed. That is, students may be marked explicitly as having done no work, when there was no work to do!

As part of this project, we will add a new color-code for students in this case. Once again, if a student originally completed a review during the first round, but did not update it, AND the project under review has not been changed since the initial review, the reviewer should not be penalized. Reviewers who meet these criteria will be given a new color, potentially green.

== Review Summary page ==

=== Header ===
* collapse (fix whitespace where possible)
* add reviewers name to easily tell who's review you are looking at

=== Questions should span the entire row ===
* Add colspan attribute which would allow the question to span the entire column which would then allow the name column to be smaller and the comment column to be larger.

=== Checkbox questions ===
* Replace individual team members name with just the team name
* Delete the comments column since comments aren't allowed in these types of questions
* Questions should be in the leftmost column and the team names that the reviewer reviewed should be in the following columns. The index in the table will have a check if the question was answered with a check and an X if answered otherwise.

=== Additional comments spanning ===
* Additional comments should span across all of the columns to save vertical space

=== CSS / Style improvements to review scores ===
* Add addition colors for reviews that didn't do a second(third,forth,etc) round review. In other words if the review hasn't changed from the previous round, color that review(er) a different color so instructors don't have to open the review and see that it hasn't changed.

== Optional additional improvements ==

=== Review Report page - sort by other metrics ===

Ideally, this page would have an option to allow instructors to sort by any metric. Presently, only one metric is shown, but adding more has been planned for the future. This may require the addition of a dropdown to allow the selection of what metric to sort by. However this is implemented, it may not add too much complexity to the page.

=== Review Summary page - Interpret HTML ===
Presently, users may enter HTML code to style their comments and reviews. However, this is currently not displayed properly. For example, HTML tags will themselves be displayed. The addition of a gem or potentially configuration changes will be needed to ensure this HTML will be properly displayed. Any implementation of this task should follow the DRY principle - that is, the implementation should be able to be re-used in all other pages where user-entered HTMl should be displayed

----

CSC/ECE 517 Spring 2018 E1815: Improvements to review grader

2018-04-06T14:34:17Z

Bjyounce: /* Review Summary page */

Improvements to Review Grader

__TOC__

== Introduction ==
Expertiza is a web application that is widely used by 2 types of users: students and instructors. When a user is logged-in as an instructor, and would like to see a review report on an assignment to review a grader, he/she could reach the page via Manage > Assignments and clicking on the “'''View review report'''” icon. The page would look somewhat like this:

[[File:Rev_report2018.png]]

To get a summary review report performed by a particular student, an instructor can get to the page from the review report by clicking “'''summary'''” in the row for that student. The page would look like this one:

[[File:Summary_report2018.png]]

== Problem Statement ==

This project is focused primarily on making various improvements to the Review Report and Review Summary pages, described in detail in the previous section. Each of these pages, while functional, suffer from many UI issues which make the pages more difficult to use for instructors. That is, information which would be useful to instructors is missing in several cases. In others, large amounts of unnecessary information is present, cluttering the site. Additionally, both pages suffer from structural and design issues which, again, waste instructor time.

Finally, the Review Report page sometimes mis-categorizes students who have not updated their reviews of others, even though the project under review has not changed! This could cause students to be deducted points unfairly. By adding a new way of highlighting this special case to instructors, review grades can be assigned more fairly.

== Review Report Page==

=== Add metrics charts ===

Presently, this page contains a 'metrics' column, presently displaying the average review volume for a given user in text form. This method of displaying data can be difficult to interpret, and even more difficult to compare at a glance, or to notice trends. Additionally, plans for expanding the metrics column to include more data would worsen this issue if it remained in its current state.

[[File:Metrics2018.png]]

This project will replace the text in this column with easy to read bar or line graphs, which will be color-coded or otherwise made very simple and easy to read. These graphs will display the data clearly and concisely, mitigating these issues. This concise display will allow for easier comparison of data, easier interpretation of data, and will allow for more metrics to be added without simply overcrowding the page with text.

=== Update alternating background color if sorted ===

In order to make the large table which dominates this page easier to read, each row has an alternating background color (between white and a yellow-green). Although this helps tremendously with readability, the alternating background colors do not update when the table is sorted. That is, if any of the sort functions are used, the background colors move with the associated rows, effectively shuffling the colors of each row. This, in fact, harms the readability of the page, and creates false groupings of visually similar rows.

This project will attempt to maintain the alternating background colors, even if the content of the table has been re-organized due to sorting.

=== Add new color to reviewers ===

On this page, the names of student peer reviewers are often color-coded, to make it easier for instructors to see common issues. For example, reviewers who have not submitted a review may be colored red, and reviewers who have not received a grade may be colored blue. However, as mentioned earlier, the current color coding scheme will assign a red color to students who have not updated their review of others projects, even when that project has not changed. That is, students may be marked explicitly as having done no work, when there was no work to do!

As part of this project, we will add a new color-code for students in this case. Once again, if a student originally completed a review during the first round, but did not update it, AND the project under review has not been changed since the initial review, the reviewer should not be penalized. Reviewers who meet these criteria will be given a new color, potentially green.

== Review Summary page ==

=== Header ===
* collapse (fix whitespace where possible)
* add reviewers name to easily tell who's review you are looking at

=== Questions should span the entire row ===
* Add colspan attribute which would allow the question to span the entire column which would then allow the name column to be smaller and the comment column to be larger.

=== Checkbox questions ===
* Replace individual team members name with just the team name
* Delete the comments column since comments aren't allowed in these types of questions
* Questions should be in the leftmost column and the team names that the reviewer reviewed should be in the following columns. The index in the table will have a check if the question was answered with a check and an X if answered otherwise.

=== Additional comments spanning ===
* Additional comments should span across all of the columns to save vertical space

=== CSS / Style improvements to review scores ===
* Add addition colors for reviews that didn't do a second(third,forth,etc) round review. In other words if the review hasn't changed from
the previous round, color that review(er) a different color so instructors don't have to open the review and see that it hasn't
changed.

== Optional additional improvements ==

=== Review Report page - sort by other metrics ===

Ideally, this page would have an option to allow instructors to sort by any metric. Presently, only one metric is shown, but adding more has been planned for the future. This may require the addition of a dropdown to allow the selection of what metric to sort by. However this is implemented, it may not add too much complexity to the page.

=== Review Summary page - Interpret HTML ===
Presently, users may enter HTML code to style their comments and reviews. However, this is currently not displayed properly. For example, HTML tags will themselves be displayed. The addition of a gem or potentially configuration changes will be needed to ensure this HTML will be properly displayed. Any implementation of this task should follow the DRY principle - that is, the implementation should be able to be re-used in all other pages where user-entered HTMl should be displayed

----

CSC/ECE 517 Spring 2018 E1815: Improvements to review grader

2018-04-06T14:33:15Z

Bjyounce:

Improvements to Review Grader

__TOC__

== Introduction ==
Expertiza is a web application that is widely used by 2 types of users: students and instructors. When a user is logged-in as an instructor, and would like to see a review report on an assignment to review a grader, he/she could reach the page via Manage > Assignments and clicking on the “'''View review report'''” icon. The page would look somewhat like this:

[[File:Rev_report2018.png]]

To get a summary review report performed by a particular student, an instructor can get to the page from the review report by clicking “'''summary'''” in the row for that student. The page would look like this one:

[[File:Summary_report2018.png]]

== Problem Statement ==

This project is focused primarily on making various improvements to the Review Report and Review Summary pages, described in detail in the previous section. Each of these pages, while functional, suffer from many UI issues which make the pages more difficult to use for instructors. That is, information which would be useful to instructors is missing in several cases. In others, large amounts of unnecessary information is present, cluttering the site. Additionally, both pages suffer from structural and design issues which, again, waste instructor time.

Finally, the Review Report page sometimes mis-categorizes students who have not updated their reviews of others, even though the project under review has not changed! This could cause students to be deducted points unfairly. By adding a new way of highlighting this special case to instructors, review grades can be assigned more fairly.

== Review Report Page==

=== Add metrics charts ===

Presently, this page contains a 'metrics' column, presently displaying the average review volume for a given user in text form. This method of displaying data can be difficult to interpret, and even more difficult to compare at a glance, or to notice trends. Additionally, plans for expanding the metrics column to include more data would worsen this issue if it remained in its current state.

[[File:Metrics2018.png]]

This project will replace the text in this column with easy to read bar or line graphs, which will be color-coded or otherwise made very simple and easy to read. These graphs will display the data clearly and concisely, mitigating these issues. This concise display will allow for easier comparison of data, easier interpretation of data, and will allow for more metrics to be added without simply overcrowding the page with text.

=== Update alternating background color if sorted ===

In order to make the large table which dominates this page easier to read, each row has an alternating background color (between white and a yellow-green). Although this helps tremendously with readability, the alternating background colors do not update when the table is sorted. That is, if any of the sort functions are used, the background colors move with the associated rows, effectively shuffling the colors of each row. This, in fact, harms the readability of the page, and creates false groupings of visually similar rows.

This project will attempt to maintain the alternating background colors, even if the content of the table has been re-organized due to sorting.

=== Add new color to reviewers ===

On this page, the names of student peer reviewers are often color-coded, to make it easier for instructors to see common issues. For example, reviewers who have not submitted a review may be colored red, and reviewers who have not received a grade may be colored blue. However, as mentioned earlier, the current color coding scheme will assign a red color to students who have not updated their review of others projects, even when that project has not changed. That is, students may be marked explicitly as having done no work, when there was no work to do!

As part of this project, we will add a new color-code for students in this case. Once again, if a student originally completed a review during the first round, but did not update it, AND the project under review has not been changed since the initial review, the reviewer should not be penalized. Reviewers who meet these criteria will be given a new color, potentially green.

== Review Summary page ==

=== Header ===
* collapse (fix whitespace where possible)
* add reviewers name to easily tell who's review you are looking at

=== Questions should span the entire row ===
* Add colspan attribute which would allow the question to span the entire column which would then allow the name
column to be smaller and the comment column to be larger.

=== Checkbox questions ===
* Replace individual team members name with just the team name
* Delete the comments column since comments aren't allowed in these types of questions
* Questions should be in the leftmost column and the team names that the reviewer reviewed should be in the following columns.
The index in the table will have a check if the question was answered with a check and an X if answered otherwise.

=== Additional comments spanning ===
* Additional comments should span across all of the columns to save vertical space

=== CSS / Style improvements to review scores ===
* Add addition colors for reviews that didn't do a second(third,forth,etc) round review. In other words if the review hasn't changed from
the previous round, color that review(er) a different color so instructors don't have to open the review and see that it hasn't
changed.

== Optional additional improvements ==

=== Review Report page - sort by other metrics ===

Ideally, this page would have an option to allow instructors to sort by any metric. Presently, only one metric is shown, but adding more has been planned for the future. This may require the addition of a dropdown to allow the selection of what metric to sort by. However this is implemented, it may not add too much complexity to the page.

=== Review Summary page - Interpret HTML ===
Presently, users may enter HTML code to style their comments and reviews. However, this is currently not displayed properly. For example, HTML tags will themselves be displayed. The addition of a gem or potentially configuration changes will be needed to ensure this HTML will be properly displayed. Any implementation of this task should follow the DRY principle - that is, the implementation should be able to be re-used in all other pages where user-entered HTMl should be displayed

----

CSC/ECE 517 Spring 2018 E1815: Improvements to review grader

2018-04-05T13:18:53Z

Bjyounce:

Improvements to Review Grader

__TOC__

== Introduction ==
Expertiza is a web application that is widely used by 2 types of users: students and instructors. When a user is logged-in as an instructor, and would like to see a review report on an assignment to review a grader, he/she could reach the page via Manage > Assignments and clicking on the “'''View review report'''” icon. The page would look somewhat like this:

[[File:Rev_report2018.png]]

To get a summary review report performed by a particular student, an instructor can get to the page from the review report by clicking “'''summary'''” in the row for that student. The page would look like this one:

[[File:Summary_report2018.png]]

== Problem Statement ==

This project is focused primarily on making various improvements to the Review Report and Review Summary pages, described in detail in the previous section. Each of these pages, while functional, suffer from many UI issues which make the pages more difficult to use for instructors. That is, information which would be useful to instructors is missing in several cases. In others, large amounts of unnecessary information is present, cluttering the site. Additionally, both pages suffer from structural and design issues which, again, waste instructor time.

Finally, the Review Report page sometimes mis-categorizes students who have not updated their reviews of others, even though the project under review has not changed! This could cause students to be deducted points unfairly. By adding a new way of highlighting this special case to instructors, review grades can be assigned more fairly.

== Review Report Page==

=== Add metrics charts ===

Presently, this page contains a 'metrics' column, presently displaying the average review volume for a given user in text form. This method of displaying data can be difficult to interpret, and even more difficult to compare at a glance, or to notice trends. Additionally, plans for expanding the metrics column to include more data would worsen this issue if it remained in its current state.

This project will replace the text in this column with easy to read bar or line graphs, which will be color-coded or otherwise made very simple and easy to read. These graphs will display the data clearly and concisely, mitigating these issues. This concise display will allow for easier comparison of data, easier interpretation of data, and will allow for more metrics to be added without simply overcrowding the page with text.

=== Update alternating background color if sorted ===

In order to make the large table which dominates this page easier to read, each row has an alternating background color (between white and a yellow-green). Although this helps tremendously with readability, the alternating background colors do not update when the table is sorted. That is, if any of the sort functions are used, the background colors move with the associated rows, effectively shuffling the colors of each row. This, in fact, harms the readability of the page, and creates false groupings of visually similar rows.

This project will attempt to maintain the alternating background colors, even if the content of the table has been re-organized due to sorting.

=== Add new color to reviewers ===

On this page, the names of student peer reviewers are often color-coded, to make it easier for instructors to see common issues. For example, reviewers who have not submitted a review may be colored red, and reviewers who have not received a grade may be colored blue. However, as mentioned earlier, the current color coding scheme will assign a red color to students who have not updated their review of others projects, even when that project has not changed. That is, students may be marked explicitly as having done no work, when there was no work to do!

As part of this project, we will add a new color-code for students in this case. Once again, if a student originally completed a review during the first round, but did not update it, AND the project under review has not been changed since the initial review, the reviewer should not be penalized. Reviewers who meet these criteria will be given a new color, potentially green.

== Review Summary page ==

* Header - collapse (fix whitespace where possible)

* Add more information such as the reviewer’s name.

* Checkbox questions

* Replace all team members names with just team name

* Comments aren’t allowed, delete that column

* Columns per team, question on left

* Additional comments spanning

* CSS / Style improvements to review scores

== Optional additional improvements ===

=== Review Report page - sort by other metrics ===

=== Review Summary page - Interpret HTML ===
----

CSC/ECE 517 Spring 2018 E1815: Improvements to review grader

2018-04-05T13:07:55Z

Bjyounce:

CSC/ECE 517 Spring 2018 E1815: Improvements to review grader

2018-04-05T13:01:32Z

Bjyounce:

CSC/ECE 517 Spring 2018 - E1800: Add past-due assignments to task list

2018-04-02T23:00:48Z

Bjyounce: /* Refactored student_task_controller.rb */

== About Expertiza ==
Expertiza is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). It is used in select courses at NC State and by professors at several other colleges and universities. -- Expertiza project

== Project E1800 Overview ==
For the E1800 project, a course project for CSC 517 at NCSU during the Spring of 2018, certain improvements were made to the Expertiza system. Primarily, the goal of this project was to add past-due assignments to the student task list. The full list of tasks (the original task list with modifications from instructor feedback) is:

* Issue #80: Add past-due assignments to task list (on Student Task page).
* Highlight with specific colors current and next due dates (on Student Task page).
* Check for correction in due dates of assignments
* On the Student Task page, separate the list of 'teamed with' students from the current tasks box.
* Show required action on: every student has to review others work and give feedback.
* Write all the required tests before implementing/refactoring the methods in the above mentioned classes.

Some Additional tasks accomplished by our team are:

* Added pagination to past-due assignments on task list
* Made various UI enhancements to the student_tasks page, specifically regarding the layout of elements.
* Refactored student_task_controller.rb

== Files modified ==
student_task_controller.erb 
list.html.erb 
student_task_helper.rb

== New files ==
will_paginate_array_fix.rb

== Adding past-due assignments to task page ==
Currently, the student task list consists of one list of all assignments that are and have been assigned to the student regardless of their due date. Now a separate table exists for assignments that are past due. This table is sorted to show the most recent past due assignments at the top of the table. The table that used to be all student tasks is now assignments that are currently due. This table is sorted by due date to show assignments that are due the soonest at the top of the table.

This change mostly involved changes to the student_task_controller.rb and list.html.erb files. A helper function was also added to the student_task_helper.rb file to break a string into multiple lines, even in the middle of a word, if it contains a word that is very long.

In the student_task_controller.rb, a separate instance variable was created to contain only student tasks that are past due and sorted by date. The existing instance variable was recycled to contain all of the student tasks that are still currently due.

In the list.html.erb file a new table was created to hold all of the past assignments. Both the current assignments and past assignments tables are also individually paginated if there are more than 10 of either.

To create the ability for the will_paginate gem to add pagination based on an array the will_paginate_array_fix.rb file was added to the initializers folder.

[[File:PastDueAssignments.PNG]]

== Highlighting current and next due dates ==
Currently, all of the tasks in the table have a white background regardless of when the task is due. To make it more apparent when due dates are approaching, each row will now highlight green, yellow, orange, or red depending on how many days out the assignment is due.

This change involved adding a function to the student_task_helper.rb file as well as a change in list.html.erb.

The change in student_task_helper.rb was a function that receives a due_date in Time format, converts it to DateTime then does a subtraction to DateTime.now to get how many days until the due date. Based on the result the function will return a string containing a color that will be the background of an individual row in the current assignments table.

[[File:backgrounding.PNG]]

== Separate Teamed-with list from task list ==
Currently, the current tasks list, as well as students you have worked with, exist in the same box. This looks cluttered, so they have been separated to be their own boxes.

This change involved editing list.html.erb.

The information about students you have worked with was moved out of the existing "taskbox" div tag and into its own "taskbox" div tag to separate it.

[[File:StudentsTeamedWith.PNG]]

== Show required action for reviews ==

Presently, the required actions list does not show entries for review tasks. That is, the list only displays tasks that have yet to be started. Therefore, once an assignment has been submitted, additional required actions such as reviews do not appear. In order to solve this problem, a few lines of code were added to student_task_controller.rb. This code retrieved all active student tasks, and adds tasks which both are in the review phase and for which the student has yet to submit a review to the required task list.

In addition, a bit of creative discretion was used and an icon was added to draw the user towards the Review link when it is active. This can be seen in the capture below. The current assignments will show all assignments that are not completed, and if the assignment is in the review phase, it will display a small warning icon indicating action needs to be taken. The screenshot below demonstrates this on the "Unknown" stage, since, because of the afromentioned issues with testing, an assignment in the review phase could not be created for testing purposes. However, the logic is in the view, and is a simple string compare, so if the stage is in Review, the icon will show up.

[[File:oss_expertiza_1.png]]

== Separating current and past task lists ==
As mentioned in the “Adding past-due assignments to task page” task, the primary assignment list on the student_task page has been updated. In our new version, the list separates tasks that have been completed from ongoing tasks. This both improves the page aesthetically as well as draws attention to ongoing tasks. Previously, these were often buried underneath many past tasks which were already completed.

== Added pagination of past-due assignments ==
Another task completed which enhances the usability of the student_task page is adding pagination to current and past assignments. Specifically, If there are more than 10 past or current assignments due, each table will individually paginate. Meaning you could be on page 2 of current assignments but also page 4 of past assignments. This makes the lists easier to read and parse for users with many tasks.

== Refactored student_task_controller.rb ==
Prior to this project, the Code Coverage report displayed many warnings for student_task_controller.rb. Primarily, these warnings were clear signs of excessively high complexity within methods. In several cases, the cyclomatic complexity of methods was too high. In others, the perceived complexity or assignment branch condition size was too great. In order to fix as many of these issues as possible, the class was refactored. In some cases, several comments within methods were used in order to divide one method into logical pieces, a clear code smell. In order to fix many of these issues, the "Extract Method" refactor was used. That is, methods were split into more logical, easier to read and follow pieces. Several other refactoring methods were utilized to make this file easier to understand, as it does perform many separate logical tasks.

For example, the method <code>view</code> was flagged in Code Climate with the message: <code>Assignment Branch Condition size for view is too high. [24.62/15]</code>. In order to correct this, the original method:

<code>
def view
StudentTask.from_participant_id params[:id]
@participant = AssignmentParticipant.find(params[:id])
@can_submit = @participant.can_submit
@can_review = @participant.can_review
@can_take_quiz = @participant.can_take_quiz
@authorization = Participant.get_authorization(@can_submit, @can_review, @can_take_quiz)
@team = @participant.team
denied unless current_user_id?(@participant.user_id)
@assignment = @participant.assignment
@can_provide_suggestions = @assignment.allow_suggestions
@topic_id = SignedUpTeam.topic_id(@assignment.id, @participant.user_id)
@topics = SignUpTopic.where(assignment_id: @assignment.id)
# Timeline feature
@timeline_list = StudentTask.get_timeline_data(@assignment, @participant, @team)
end
</code>

was refactored using the 'extract method' refactor, leading to the following, where <code>init_participant</code>, <code>init_assignment</code>, and <code>init_timeline</code> are separate, short, methods.

<code>
def view
StudentTask.from_participant_id params[:id]
init_participant
denied unless current_user_id?(@participant.user_id)
init_assignment
init_timeline
end
</code>

== Test Plan ==

As this documentation shows, much of our changes and features involved solely the view. Testing for this revolved around simply ensuring that the view changed as per the various conditions defined. For example, the coloration of due dates could be tested by navigating the site as a dev user, and making sure that if an assignment stage is due in more than ten days, then the row should be green. Likewise, if a stage is due in a day, the row should be red. For view-based features, this method of navigating the site and ensuring '''if X, then Y should be Z''' is the best way to test, since the view's final product, in the end, is a visual result.

However, refactoring was conducted and so RSpec tests were written those instances.

File:Oss expertiza 1.png

2018-04-02T22:43:35Z

Bjyounce: uploaded a new version of "File:Oss expertiza 1.png"

File:StudentsTeamedWith.PNG

2018-04-02T22:41:09Z

Bjyounce: uploaded a new version of "File:StudentsTeamedWith.PNG"

File:Backgrounding.PNG

2018-04-02T22:40:13Z

Bjyounce: uploaded a new version of "File:Backgrounding.PNG"

File:Backgrounding.PNG

2018-04-02T22:39:18Z

Bjyounce: uploaded a new version of "File:Backgrounding.PNG"

File:PastDueAssignments.PNG

2018-04-02T22:38:34Z

Bjyounce: uploaded a new version of "File:PastDueAssignments.PNG"

File:PastDueAssignments.PNG

2018-04-02T22:36:29Z

Bjyounce: uploaded a new version of "File:PastDueAssignments.PNG"

CSC/ECE 517 Spring 2018 - E1800: Add past-due assignments to task list

2018-04-02T22:29:51Z

Bjyounce: /* Added pagination of past-due assignments */

== About Expertiza ==
Expertiza is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). It is used in select courses at NC State and by professors at several other colleges and universities. -- Expertiza project

== Project E1800 Overview ==
For the E1800 project, a course project for CSC 517 at NCSU during the Spring of 2018, certain improvements were made to the Expertiza system. Primarily, the goal of this project was to add past-due assignments to the student task list. The full list of tasks (the original task list with modifications from instructor feedback) is:

* Issue #80: Add past-due assignments to task list (on Student Task page).
* Highlight with specific colors current and next due dates (on Student Task page).
* Check for correction in due dates of assignments
* On the Student Task page, separate the list of 'teamed with' students from the current tasks box.
* Show required action on: every student has to review others work and give feedback.
* Write all the required tests before implementing/refactoring the methods in the above mentioned classes.

Some Additional tasks accomplished by our team are:

* Added pagination to past-due assignments on task list
* Made various UI enhancements to the student_tasks page, specifically regarding the layout of elements.
* Refactored student_task_controller.rb

== Files modified ==
student_task_controller.erb 
list.html.erb 
student_task_helper.rb

== New files ==
will_paginate_array_fix.rb

== Adding past-due assignments to task page ==
Currently, the student task list consists of one list of all assignments that are and have been assigned to the student regardless of their due date. Now a separate table exists for assignments that are past due. This table is sorted to show the most recent past due assignments at the top of the table. The table that used to be all student tasks is now assignments that are currently due. This table is sorted by due date to show assignments that are due the soonest at the top of the table.

This change mostly involved changes to the student_task_controller.rb and list.html.erb files. A helper function was also added to the student_task_helper.rb file to break a string into multiple lines, even in the middle of a word, if it contains a word that is very long.

In the student_task_controller.rb, a separate instance variable was created to contain only student tasks that are past due and sorted by date. The existing instance variable was recycled to contain all of the student tasks that are still currently due.

In the list.html.erb file a new table was created to hold all of the past assignments. Both the current assignments and past assignments tables are also individually paginated if there are more than 10 of either.

To create the ability for the will_paginate gem to add pagination based on an array the will_paginate_array_fix.rb file was added to the initializers folder.

[[File:PastDueAssignments.PNG]]

== Highlighting current and next due dates ==
Currently, all of the tasks in the table have a white background regardless of when the task is due. To make it more apparent when due dates are approaching, each row will now highlight green, yellow, orange, or red depending on how many days out the assignment is due.

This change involved adding a function to the student_task_helper.rb file as well as a change in list.html.erb.

The change in student_task_helper.rb was a function that receives a due_date in Time format, converts it to DateTime then does a subtraction to DateTime.now to get how many days until the due date. Based on the result the function will return a string containing a color that will be the background of an individual row in the current assignments table.

[[File:backgrounding.PNG]]

== Separate Teamed-with list from task list ==
Currently, the current tasks list, as well as students you have worked with, exist in the same box. This looks cluttered, so they have been separated to be their own boxes.

This change involved editing list.html.erb.

The information about students you have worked with was moved out of the existing "taskbox" div tag and into its own "taskbox" div tag to separate it.

[[File:StudentsTeamedWith.PNG]]

== Show required action for reviews ==

Presently, the required actions list does not show entries for review tasks. That is, the list only displays tasks that have yet to be started. Therefore, once an assignment has been submitted, additional required actions such as reviews do not appear. In order to solve this problem, a few lines of code were added to student_task_controller.rb. This code retrieved all active student tasks, and adds tasks which both are in the review phase and for which the student has yet to submit a review to the required task list.

In addition, a bit of creative discretion was used and an icon was added to draw the user towards the Review link when it is active. This can be seen in the capture below. The current assignments will show all assignments that are not completed, and if the assignment is in the review phase, it will display a small warning icon indicating action needs to be taken. The screenshot below demonstrates this on the "Unknown" stage, since, because of the afromentioned issues with testing, an assignment in the review phase could not be created for testing purposes. However, the logic is in the view, and is a simple string compare, so if the stage is in Review, the icon will show up.

[[File:oss_expertiza_1.png]]

== Separating current and past task lists ==
As mentioned in the “Adding past-due assignments to task page” task, the primary assignment list on the student_task page has been updated. In our new version, the list separates tasks that have been completed from ongoing tasks. This both improves the page aesthetically as well as draws attention to ongoing tasks. Previously, these were often buried underneath many past tasks which were already completed.

== Added pagination of past-due assignments ==
Another task completed which enhances the usability of the student_task page is adding pagination to current and past assignments. Specifically, If there are more than 10 past or current assignments due, each table will individually paginate. Meaning you could be on page 2 of current assignments but also page 4 of past assignments. This makes the lists easier to read and parse for users with many tasks.

== Refactored student_task_controller.rb ==
Prior to this project, the Code Coverage report displayed many warnings for student_task_controller.rb. Primarily, these warnings were clear signs of excessively high complexity within methods. In several cases, the cyclomatic complexity of methods was too high. In others, the perceived complexity or assignment branch condition size was too great. In order to fix as many of these issues as possible, the class was refactored. In some cases, several comments within methods were used in order to divide one method into logical pieces, a clear code smell. In order to fix many of these issues, the "Extract Method" refactor was used. That is, methods were split into more logical, easier to read and follow pieces. Several other refactoring methods were utilized to make this file easier to understand, as it does perform many separate logical tasks.

== Test Plan ==

As this documentation shows, much of our changes and features involved solely the view. Testing for this revolved around simply ensuring that the view changed as per the various conditions defined. For example, the coloration of due dates could be tested by navigating the site as a dev user, and making sure that if an assignment stage is due in more than ten days, then the row should be green. Likewise, if a stage is due in a day, the row should be red. For view-based features, this method of navigating the site and ensuring '''if X, then Y should be Z''' is the best way to test, since the view's final product, in the end, is a visual result.

However, refactoring was conducted and so RSpec tests were written those instances.

CSC/ECE 517 Spring 2018 - E1800: Add past-due assignments to task list

2018-04-02T22:28:47Z

Bjyounce: /* Adding past-due assignments to task page */

== About Expertiza ==
Expertiza is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). It is used in select courses at NC State and by professors at several other colleges and universities. -- Expertiza project

== Project E1800 Overview ==
For the E1800 project, a course project for CSC 517 at NCSU during the Spring of 2018, certain improvements were made to the Expertiza system. Primarily, the goal of this project was to add past-due assignments to the student task list. The full list of tasks (the original task list with modifications from instructor feedback) is:

* Issue #80: Add past-due assignments to task list (on Student Task page).
* Highlight with specific colors current and next due dates (on Student Task page).
* Check for correction in due dates of assignments
* On the Student Task page, separate the list of 'teamed with' students from the current tasks box.
* Show required action on: every student has to review others work and give feedback.
* Write all the required tests before implementing/refactoring the methods in the above mentioned classes.

Some Additional tasks accomplished by our team are:

* Added pagination to past-due assignments on task list
* Made various UI enhancements to the student_tasks page, specifically regarding the layout of elements.
* Refactored student_task_controller.rb

== Files modified ==
student_task_controller.erb 
list.html.erb 
student_task_helper.rb

== New files ==
will_paginate_array_fix.rb

== Adding past-due assignments to task page ==
Currently, the student task list consists of one list of all assignments that are and have been assigned to the student regardless of their due date. Now a separate table exists for assignments that are past due. This table is sorted to show the most recent past due assignments at the top of the table. The table that used to be all student tasks is now assignments that are currently due. This table is sorted by due date to show assignments that are due the soonest at the top of the table.

This change mostly involved changes to the student_task_controller.rb and list.html.erb files. A helper function was also added to the student_task_helper.rb file to break a string into multiple lines, even in the middle of a word, if it contains a word that is very long.

In the student_task_controller.rb, a separate instance variable was created to contain only student tasks that are past due and sorted by date. The existing instance variable was recycled to contain all of the student tasks that are still currently due.

In the list.html.erb file a new table was created to hold all of the past assignments. Both the current assignments and past assignments tables are also individually paginated if there are more than 10 of either.

To create the ability for the will_paginate gem to add pagination based on an array the will_paginate_array_fix.rb file was added to the initializers folder.

[[File:PastDueAssignments.PNG]]

== Highlighting current and next due dates ==
Currently, all of the tasks in the table have a white background regardless of when the task is due. To make it more apparent when due dates are approaching, each row will now highlight green, yellow, orange, or red depending on how many days out the assignment is due.

This change involved adding a function to the student_task_helper.rb file as well as a change in list.html.erb.

The change in student_task_helper.rb was a function that receives a due_date in Time format, converts it to DateTime then does a subtraction to DateTime.now to get how many days until the due date. Based on the result the function will return a string containing a color that will be the background of an individual row in the current assignments table.

[[File:backgrounding.PNG]]

== Separate Teamed-with list from task list ==
Currently, the current tasks list, as well as students you have worked with, exist in the same box. This looks cluttered, so they have been separated to be their own boxes.

This change involved editing list.html.erb.

The information about students you have worked with was moved out of the existing "taskbox" div tag and into its own "taskbox" div tag to separate it.

[[File:StudentsTeamedWith.PNG]]

== Show required action for reviews ==

Presently, the required actions list does not show entries for review tasks. That is, the list only displays tasks that have yet to be started. Therefore, once an assignment has been submitted, additional required actions such as reviews do not appear. In order to solve this problem, a few lines of code were added to student_task_controller.rb. This code retrieved all active student tasks, and adds tasks which both are in the review phase and for which the student has yet to submit a review to the required task list.

In addition, a bit of creative discretion was used and an icon was added to draw the user towards the Review link when it is active. This can be seen in the capture below. The current assignments will show all assignments that are not completed, and if the assignment is in the review phase, it will display a small warning icon indicating action needs to be taken. The screenshot below demonstrates this on the "Unknown" stage, since, because of the afromentioned issues with testing, an assignment in the review phase could not be created for testing purposes. However, the logic is in the view, and is a simple string compare, so if the stage is in Review, the icon will show up.

[[File:oss_expertiza_1.png]]

== Separating current and past task lists ==
As mentioned in the “Adding past-due assignments to task page” task, the primary assignment list on the student_task page has been updated. In our new version, the list separates tasks that have been completed from ongoing tasks. This both improves the page aesthetically as well as draws attention to ongoing tasks. Previously, these were often buried underneath many past tasks which were already completed.

== Added pagination of past-due assignments ==
Another task completed which enhances the usability of the student_task page is adding pagination to current and past assignments. Specifically, If there are more than 10 past or current assignments due, each table will individually paginate. Meaning you could be on page 2 of current assignments but also page 4 of past assignments. This makes the lists easier to read and parse for users with many tasks.

=== Refactored student_task_controller.rb ===
Prior to this project, the Code Coverage report displayed many warnings for student_task_controller.rb. Primarily, these warnings were clear signs of excessively high complexity within methods. In several cases, the cyclomatic complexity of methods was too high. In others, the perceived complexity or assignment branch condition size was too great. In order to fix as many of these issues as possible, the class was refactored. In some cases, several comments within methods were used in order to divide one method into logical pieces, a clear code smell. In order to fix many of these issues, the "Extract Method" refactor was used. That is, methods were split into more logical, easier to read and follow pieces. Several other refactoring methods were utilized to make this file easier to understand, as it does perform many separate logical tasks.

== Test Plan ==

As this documentation shows, much of our changes and features involved solely the view. Testing for this revolved around simply ensuring that the view changed as per the various conditions defined. For example, the coloration of due dates could be tested by navigating the site as a dev user, and making sure that if an assignment stage is due in more than ten days, then the row should be green. Likewise, if a stage is due in a day, the row should be red. For view-based features, this method of navigating the site and ensuring '''if X, then Y should be Z''' is the best way to test, since the view's final product, in the end, is a visual result.

However, refactoring was conducted and so RSpec tests were written those instances.

CSC/ECE 517 Spring 2018 - E1800: Add past-due assignments to task list

2018-04-02T22:28:21Z

Bjyounce: /* Adding past-due assignments to task page */

== About Expertiza ==
Expertiza is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). It is used in select courses at NC State and by professors at several other colleges and universities. -- Expertiza project

== Project E1800 Overview ==
For the E1800 project, a course project for CSC 517 at NCSU during the Spring of 2018, certain improvements were made to the Expertiza system. Primarily, the goal of this project was to add past-due assignments to the student task list. The full list of tasks (the original task list with modifications from instructor feedback) is:

* Issue #80: Add past-due assignments to task list (on Student Task page).
* Highlight with specific colors current and next due dates (on Student Task page).
* Check for correction in due dates of assignments
* On the Student Task page, separate the list of 'teamed with' students from the current tasks box.
* Show required action on: every student has to review others work and give feedback.
* Write all the required tests before implementing/refactoring the methods in the above mentioned classes.

Some Additional tasks accomplished by our team are:

* Added pagination to past-due assignments on task list
* Made various UI enhancements to the student_tasks page, specifically regarding the layout of elements.
* Refactored student_task_controller.rb

== Files modified ==
student_task_controller.erb 
list.html.erb 
student_task_helper.rb

== New files ==
will_paginate_array_fix.rb

== Adding past-due assignments to task page ==
Currently, the student task list consists of one list of all assignments that are and have been assigned to the student regardless of their due date. Now a separate table exists for assignments that are past due. This table is sorted to show the most recent past due assignments at the top of the table. The table that used to be all student tasks is now assignments that are currently due. This table is sorted by due date to show assignments that are due the soonest at the top of the table.

This change mostly involved changes to the student_task_controller.rb and list.html.erb files. A helper function was also added to the student_task_helper.rb file to break a string into multiple lines, even in the middle of a word, if it contains a word that is very long.

In the student_task_controller.rb, a separate instance variable was created to contain only student tasks that are past due and sorted by date. The existing instance variable was recycled to contain all of the student tasks that are still currently due.

In the list.html.erb file a new table was created to hold all of the past assignments. Both the current assignments and past assignments tables are also individually paginated if there are more than 10 of either.

To create the ability for the will_paginate gem to add pagination based on an array the will_paginate_array_fix.rb file was added to the initializers folder.

[[File:PastDueAssignments.PNG|x200px]]

== Highlighting current and next due dates ==
Currently, all of the tasks in the table have a white background regardless of when the task is due. To make it more apparent when due dates are approaching, each row will now highlight green, yellow, orange, or red depending on how many days out the assignment is due.

This change involved adding a function to the student_task_helper.rb file as well as a change in list.html.erb.

The change in student_task_helper.rb was a function that receives a due_date in Time format, converts it to DateTime then does a subtraction to DateTime.now to get how many days until the due date. Based on the result the function will return a string containing a color that will be the background of an individual row in the current assignments table.

[[File:backgrounding.PNG]]

== Separate Teamed-with list from task list ==
Currently, the current tasks list, as well as students you have worked with, exist in the same box. This looks cluttered, so they have been separated to be their own boxes.

This change involved editing list.html.erb.

The information about students you have worked with was moved out of the existing "taskbox" div tag and into its own "taskbox" div tag to separate it.

[[File:StudentsTeamedWith.PNG]]

== Show required action for reviews ==

Presently, the required actions list does not show entries for review tasks. That is, the list only displays tasks that have yet to be started. Therefore, once an assignment has been submitted, additional required actions such as reviews do not appear. In order to solve this problem, a few lines of code were added to student_task_controller.rb. This code retrieved all active student tasks, and adds tasks which both are in the review phase and for which the student has yet to submit a review to the required task list.

In addition, a bit of creative discretion was used and an icon was added to draw the user towards the Review link when it is active. This can be seen in the capture below. The current assignments will show all assignments that are not completed, and if the assignment is in the review phase, it will display a small warning icon indicating action needs to be taken. The screenshot below demonstrates this on the "Unknown" stage, since, because of the afromentioned issues with testing, an assignment in the review phase could not be created for testing purposes. However, the logic is in the view, and is a simple string compare, so if the stage is in Review, the icon will show up.

[[File:oss_expertiza_1.png]]

== Separating current and past task lists ==
As mentioned in the “Adding past-due assignments to task page” task, the primary assignment list on the student_task page has been updated. In our new version, the list separates tasks that have been completed from ongoing tasks. This both improves the page aesthetically as well as draws attention to ongoing tasks. Previously, these were often buried underneath many past tasks which were already completed.

== Added pagination of past-due assignments ==
Another task completed which enhances the usability of the student_task page is adding pagination to current and past assignments. Specifically, If there are more than 10 past or current assignments due, each table will individually paginate. Meaning you could be on page 2 of current assignments but also page 4 of past assignments. This makes the lists easier to read and parse for users with many tasks.

=== Refactored student_task_controller.rb ===
Prior to this project, the Code Coverage report displayed many warnings for student_task_controller.rb. Primarily, these warnings were clear signs of excessively high complexity within methods. In several cases, the cyclomatic complexity of methods was too high. In others, the perceived complexity or assignment branch condition size was too great. In order to fix as many of these issues as possible, the class was refactored. In some cases, several comments within methods were used in order to divide one method into logical pieces, a clear code smell. In order to fix many of these issues, the "Extract Method" refactor was used. That is, methods were split into more logical, easier to read and follow pieces. Several other refactoring methods were utilized to make this file easier to understand, as it does perform many separate logical tasks.

== Test Plan ==

As this documentation shows, much of our changes and features involved solely the view. Testing for this revolved around simply ensuring that the view changed as per the various conditions defined. For example, the coloration of due dates could be tested by navigating the site as a dev user, and making sure that if an assignment stage is due in more than ten days, then the row should be green. Likewise, if a stage is due in a day, the row should be red. For view-based features, this method of navigating the site and ensuring '''if X, then Y should be Z''' is the best way to test, since the view's final product, in the end, is a visual result.

However, refactoring was conducted and so RSpec tests were written those instances.

CSC/ECE 517 Spring 2018 - E1800: Add past-due assignments to task list

2018-03-30T15:07:30Z

Bjyounce:

== About Expertiza ==
Expertiza is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). It is used in select courses at NC State and by professors at several other colleges and universities. -- Expertiza project

== Project E1800 Overview ==
For the E1800 project, a course project for CSC 517 at NCSU during the Spring of 2018, certain improvements were made to the Expertiza system. Primarily, the goal of this project was to add past-due assignments to the student task list. The full list of tasks (the original task list with modifications from instructor feedback) is:

* Issue #80: Add past-due assignments to task list (on Student Task page).
* Highlight with specific colors current and next due dates (on Student Task page).
* Check for correction in due dates of assignments
* On the Student Task page, separate the list of 'teamed with' students from the current tasks box.
* Show required action on: every student has to review others work and give feedback.
* Write all the required tests before implementing/refactoring the methods in the above mentioned classes.

Some Additional tasks accomplished by our team are:

* Added pagination to past-due assignments on task list
* Made various UI enhancements to the student_tasks page, specifically regarding the layout of elements.
* Refactored student_task_controller.rb

== Adding past-due assignments to task page ==
Currently, the student task list consists of one list of all assignments that are and have been assigned to the student regardless of their due date. Now a separate table exists for assignments that are past due. This table is sorted to show the most recent past due assignments at the top of the table. The table that used to be all student tasks is now assignments that are currently due. This table is sorted by due date to show assignments that are due the soonest at the top of the table.

This change mostly involved changes to the student_task_controller.rb and list.html.erb files. A helper function was also added to the student_task_helper.rb file to break a string into multiple lines, even in the middle of a word, if it contains a word that is very long.

In the student_task_controller.rb, a separate instance variable was created to contain only student tasks that are past due and sorted by date. The existing instance variable was recycled to contain all of the student tasks that are still currently due.

In the list.html.erb file a new table was created to hold all of the past assignments. Both the current assignments and past assignments tables are also individually paginated if there are more than 10 of either.

To create the ability for the will_paginate gem to add pagination based on an array the will_paginate_array_fix.rb file was added to the initializers folder.

[[File:PastDueAssignments.PNG]]

== Highlighting current and next due dates ==
Currently, all of the tasks in the table have a white background regardless of when the task is due. To make it more apparent when due dates are approaching, each row will now highlight green, yellow, orange, or red depending on how many days out the assignment is due.

This change involved adding a function to the student_task_helper.rb file as well as a change in list.html.erb.

The change in student_task_helper.rb was a function that receives a due_date in Time format, converts it to DateTime then does a subtraction to DateTime.now to get how many days until the due date. Based on the result the function will return a string containing a color that will be the background of an individual row in the current assignments table.

[[File:backgrounding.PNG]]

== Separate Teamed-with list from task list ==
Currently, the current tasks list, as well as students you have worked with, exist in the same box. This looks cluttered, so they have been separated to be their own boxes.

This change involved editing list.html.erb.

The information about students you have worked with was moved out of the existing "taskbox" div tag and into its own "taskbox" div tag to separate it.

[[File:StudentsTeamedWith.PNG]]

== Show required action for reviews ==

Presently, the required actions list does not show entries for review tasks. That is, the list only displays tasks that have yet to be started. Therefore, once an assignment has been submitted, additional required actions such as reviews do not appear. In order to solve this problem, a few lines of code were added to student_task_controller.rb. This code retrieved all active student tasks, and adds tasks which both are in the review phase and for which the student has yet to submit a review to the required task list.

In addition, a bit of creative discretion was used and an icon was added to draw the user towards the Review link when it is active. This can be seen in the capture below. The current assignments will show all assignments that are not completed, and if the assignment is in the review phase, it will display a small warning icon indicating action needs to be taken. The screenshot below demonstrates this on the "Unknown" stage, since, because of the afromentioned issues with testing, an assignment in the review phase could not be created for testing purposes. However, the logic is in the view, and is a simple string compare, so if the stage is in Review, the icon will show up.

[[File:oss_expertiza_1.png]]

== Separating current and past task lists ==
As mentioned in the “Adding past-due assignments to task page” task, the primary assignment list on the student_task page has been updated. In our new version, the list separates tasks that have been completed from ongoing tasks. This both improves the page aesthetically as well as draws attention to ongoing tasks. Previously, these were often buried underneath many past tasks which were already completed.

== Added pagination of past-due assignments ==
Another task completed which enhances the usability of the student_task page is adding pagination to current and past assignments. Specifically, If there are more than 10 past or current assignments due, each table will individually paginate. Meaning you could be on page 2 of current assignments but also page 4 of past assignments. This makes the lists easier to read and parse for users with many tasks.

=== Refactored student_task_controller.rb ===
Prior to this project, the Code Coverage report displayed many warnings for student_task_controller.rb. Primarily, these warnings were clear signs of excessively high complexity within methods. In several cases, the cyclomatic complexity of methods was too high. In others, the perceived complexity or assignment branch condition size was too great. In order to fix as many of these issues as possible, the class was refactored. In some cases, several comments within methods were used in order to divide one method into logical pieces, a clear code smell. In order to fix many of these issues, the "Extract Method" refactor was used. That is, methods were split into more logical, easier to read and follow pieces. Several other refactoring methods were utilized to make this file easier to understand, as it does perform many separate logical tasks.

File:Oss expertiza 1.png

2018-03-30T14:55:32Z

Bjyounce:

CSC/ECE 517 Spring 2018 - E1800: Add past-due assignments to task list

2018-03-30T14:53:45Z

Bjyounce:

CSC/ECE 517 Spring 2018 - E1800: Add past-due assignments to task list

2018-03-26T23:04:43Z

Bjyounce:

CSC/ECE 517 Spring 2018 - E1800: Add past-due assignments to task list

2018-03-26T23:04:14Z

Bjyounce: /* Project E1800 Overview */

MainPage

2018-03-26T23:03:36Z

Bjyounce: /* Course-Specific Topics */

==Expertiza==
* [[Expertiza documentation]]

==Course-Specific Topics==

* [[CSC/ECE 517 Summer 2008]]
* [[CSC/ECE 517 Fall 2010]]
* [[CSC/ECE 517 Fall 2011]]
* [[CSC/ECE 517 Fall 2012]]
* [[CSC/ECE 517 Fall 2013]]
* [[CSC/ECE 517 Fall 2014]]
* [[CSC/ECE 517 Fall 2015]]
* [[CSC/ECE 517 Fall 2016]]
* [[CSC/ECE 517 Spring 2014]]
* [[CSC/ECE 517 Spring 2015]]
* [[CSC/ECE 517 Spring 2016]]
* [[CSC/ECE 517 Spring 2017]]
* [[CSC/ECE 517 Fall 2017]]
* [[CSC/ECE 517 Spring 2018- Project Juniper:Bookmark Enhancements]]
* [[CSC/ECE 517 Spring 2018- Project E1803: Introducing a Student View for Instructors]]
* [[CSC/ECE 517 Spring 2018- Project E1804: OSS project Yellow: Topic management]]
* [[CSC/ECE 517 Spring 2018- Project E1808: Refactor review_mapping_controller.rb]]
* [[CSC/ECE 517 Spring 2018- Project M1802: 2D Canvas Rendering]]
* [[CSC/ECE 517 Spring 2018 - E1800: Add past-due assignments to task list]]
* [[CSC 456 Spring 2011|CSC 456 Spring 2012]]
* [[ECE 633]]
* [[KCU]]
* [[Progress reports]]

==Application Behavior==
* [[Grading]]

==Metaprogramming==
* [[CSC/ECE_517_Spring_2013/ch1b_1k_hf|Lecture on Metaprogramming]]

==Development==

''Expertiza now has a Java dependency, so the machine you are using to develop Expertiza on should have the JVM installed.''

* [[Setting Up a Development Machine]]
* [[Creating a Linux Development Environment for Expertiza - Installation Guide]]
* [[Using git and github for projects]]
* [[Using heroku to deploy your projects]]
* [[How to Begin a Project from the Current Expertiza Repository]]
* [[Git]]
* [[How to Change a User's Password on a Development Machine]]
* [[Debugging Rails]]
* [http://rajanalwan.com/ui_guidelines/ Design Template]

==Production==
* [[Deploying to Production]]
* [[Downloading Production Data]]
* [[Accessing the Production Server]]

==Testing==
* [[Using Cucumber with Expertiza]]
* [[Rails Testing Overview]]
* [[Expertiza Continuous Integration]]

==References==
* [[Object-Oriented Design and Programming]]

File:StudentsTeamedWith.PNG

2018-03-26T22:55:17Z

Bjyounce:

File:PastDueAssignments.PNG

2018-03-26T22:54:41Z

Bjyounce:

CSC/ECE 517 Spring 2018 - E1800: Add past-due assignments to task list

2018-03-26T22:54:21Z

Bjyounce: Created page with " == About Expertiza == Expertiza is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). It is used in select courses at..."