CSC/ECE 517 Spring 2022 - E2245: View for results of bidding: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
 
(107 intermediate revisions by 3 users not shown)
Line 1: Line 1:
CSC/ECE 517 Spring 2022 - E2245: View for results of bidding
'''CSC/ECE 517 Spring 2022 - E2245: View for results of bidding
 
'''
== Problem Statement ==  
== Problem Statement ==  


When topics are opened up for bidding, students can see how “hot” each topic is by the color it has on their topic list.  However, instructors have no way to view the bidding process except by impersonating students.  Furthermore, when the bidding assignment algorithm is run, there is no way to verify that it did in fact assign teams to topics they had chosen.
When students sign up for topics, they are presented with a system to bid on their favorite topics. This process is allowed for both individual students as well as teams. As a result, many students will first sign up for topics, which can reduce the number of teams that get their first pick, and result in long waitlists. A bidding algorithms has been developed to give as many groups as possible their first choice. As this is an NP-complete problem, the algorithm has to use heuristics to guess efficiently. There needs to be a way for instructors to easily view and compare the results of the bidding algorithms to get a quantitative sense of their effectiveness.
This project is to create a field for instructors on the topic list that shows how many teams have bid for each project. Depending on how you implement it, you might or might not set up the topics to change color.  Since topic lines in the topic list potentially have several fields, including partner advertisements, take care that (1) the #-of-bids field is not displayed except for projects that use bidding for topics, and (2) the field is as narrow as feasible.
Also, there should be a way to see how many teams have made each topic their #1 bid, #2 bid, etc. And for any team, there should be a way to show all of its bids. There should still be a way to see the bids after the bidding-assignment algorithm has been run, so that it can be checked to see if it did a reasonable job of assigning teams to topics. I do not want to tell you how to organize the display, but please give it some thought and discuss it with me, so that we can come up with a highly usable interface


== Project Goal ==  
== Project Goal ==  
This project aims to solve this issue by giving clear and concise feedback of the algorithms in topics list in the assignment. However, since topics in the table potentially have several fields, care must be taken not to overcrowd the table with information. There are several different UI/UX approaches to display this information, and the chosen one should:
* Maximize useful information at a glance, while minimizing clutter
* Fit into the flow of the topic page
* Allow further information to be obtained if requested
* Not be visible if bidding is not used


Develop a trigger that: <br>
Some other miscellaneous goals of this project are to:
# Is activated when any team has been formed that has k members, where k is greater than 50% of the maximum team capacity <br>
* Remove topic fields from view if they are not applicable
#* ex. max members = 4, trigger activated when the team size reaches 3
* Refactor code as needed
# Assign a mentor to the team. Mentors should be evenly assigned to teams, so a good strategy is to assign the mentor who has the fewest teams to mentor so far.
* Increase test coverage as appropriate
# Notify the mentor via email that they are now assigned to a specific team, and provide the email addresses of the team members.
# Possibly notify the team members that they have been assigned the mentor with contact information.


== Previous Work ==  
== Previous Work ==  
=== Design Pattern ===


Since the trigger they implemented would need multiple handlers and each of the responses in different actions, they decided to use Chain of Responsibility as the design pattern. Chain of Responsibility is a behavioural design pattern that lets you pass requests along a chain of handlers. Upon receiving a request, each handler decides either to process the request or to pass it to the next handler in the chain.
=== Current User Cases ===
The reason to take this approach is we have a certain question which needs to be answered, based on the answer the flow moves. It follows a sequence which follows this behaviour pattern well.  
 
Below is the use case diagram that depicts the existing use cases that associated to the topics bidding features of the application. Notice that in order to check some bidding information for a topic/project, the Instructor has to impersonate a student.
 
[[File:old-usecases.png|800px|Old user cases]]
 
=== Current Work Flow Diagram ===
 
As an Instructor, the user after, being authenticated, needs to go to the Assignments >> Topics view to create the topics/projects and then once the bidding started, needs to impersonate a student to partially (at very minimal level) get the bidding process information
 
[[File:Old-flow.png|600px|Old user cases]]
 
== Strategy to implement our plan to improve previous Works ==
 
=== Change in Use Cases ===
 
[[File:new-usecases.png|800px|Old user cases]]
 
'''Student''': This actor is responsible for submitting and deleting bids for topics while the topic selection period is open for an assignment which uses the new lottery topic selection mechanism. <br>
 
'''Instructor''': This actor is responsible for updating an assignment to use the new lottery topic selection as well as closing the bidding period and beginning the automatic topic selection. Instructor is also able to view the progress details of bids without having to impersonate students
 
=== UI design ===
 
The existing view with very limited information about the bidding process
 
'''Before''':
 
[[File:before-bidding.png|1200px|Popup prototype]]
 
 
With this proposed new view, the Instructor can gain a more complete view of the whole bidding process in one place.


=== Work Flow Diagram ===
'''Proposed UI'''


[[File:Design-popup1.png|200px|Popup prototype]]
[[File:after-bidding.png|1200px|Popup prototype]]


== Improvement on the Previous Work ==
=== Change in Work Flow Diagram ===
=== Change in Work Flow Diagram ===


Controllers:
With the new flow and implementation, the Instructor now can have all (complete) information he/she needs in one place at the Topics list/details view instead of having to impersonate a student to get even some minimal, un-completed piece of information about the bidding.
*app/controllers/submission_records_controller.rb
 
[[File:new-flow.png|600px|Old user cases]]
 
=== Class Diagram ===
 
[[File:class-diagram.png|1000px|Class diagram]]
 
 
=== Track our works for transparency, collaboration and productivity  ===
 
We've been working collaboratively to deliver this project as a team, by using Github Project feature to assign, track and collaborate our tasks. We've created an accompanying github project for this purpose, link can be found [https://github.com/dnguyenv/final-e2245/projects/1 here]
 
[[File:E2245-project-tasks.png|1200px|project tasks]]
 
=== Code changes ===
 
From preliminary research, we believed we would need to add and modify, refactor code from almost all layers of the features (including Controllers, Models, Views but we end up decided to focus on delivering the feature with minimum code changes and regression tests, so majority of our code changes are on Views layer. Following are the changes we made (We also added links to our Github commits for each change so that the reviewers can link directly to github for more in-depth inspection/review)
 
 
'''New Files added:'''
 
*[https://github.com/expertiza/expertiza/pull/2392/files#diff-5df8b9300332120367b2b5930ef57a17907270e3705e7ed90e0f5f825f335449 app/views/sign_up_sheet/_total_bids.html.erb]
 
[[File:total-bids.png|1200px|Total bids]]
 
*[https://github.com/expertiza/expertiza/pull/2392/files#diff-5df8b9300332120367b2b5930ef57a17907270e3705e7ed90e0f5f825f335449 app/views/sign_up_sheet/_total_1_2_bids.html.erb]


[[File:total-1-2-bids.png|1200px|1-2 bids]]


Models:
'''Files changed:'''
*app/models/assignment_team.rb


<br>
'''View:'''
Views:
*app/views/student_task/view
<br>


Rspec:
*[https://github.com/expertiza/expertiza/pull/2392/files#diff-5df8b9300332120367b2b5930ef57a17907270e3705e7ed90e0f5f825f335449 app/views/sign_up_sheet/_add_signup_topics.html.erb]
*spec/features/staggered_deadline_spec.rb
<br>


''' I. Refactor Code to follow good coding practices''' <br>
[[File:add-signup-topics.png|1200px|Add Signup Topics]]
Example:<br>
1. Rename method names more meaningfully and intuitive.
2. Reduce the number of conditional statements checking for mentor.
3. Rename variable names to reduce confusion like changing lowest_team_no to lowest_number_of_teams.
4. Make the code DRYer


*[https://github.com/expertiza/expertiza/pull/2392/files#diff-5df8b9300332120367b2b5930ef57a17907270e3705e7ed90e0f5f825f335449 app/views/sign_up_sheet/_table_header.html.erb]


'''II. Correct Previous Design''' <br>
[[File:table-header.png|1200px|Add Signup Topics]]


1. Remove mentors from being included in a team's number of members count.<br>
*[https://github.com/expertiza/expertiza/pull/2392/files#diff-5df8b9300332120367b2b5930ef57a17907270e3705e7ed90e0f5f825f335449 app/views/sign_up_sheet/_table_line.html.erb]


2. Change the View to make mentor separate from the team. <br>
[[File:table-line.png|1200px|Add Signup Topics]]
'''BEFORE''' <br>


'''AFTER''' <br>
'''Helper:'''


*[https://github.com/expertiza/expertiza/pull/2392/files#diff-5df8b9300332120367b2b5930ef57a17907270e3705e7ed90e0f5f825f335449 app/helpers/sign_up_sheet_helper.rb]


3. Change the conditional statement that checks if a mentor has to be added to the team. (The strength of the team has to be greater than 50% of the team size).
[[File:e2245-signup-sheet-helper.png|1200px|Add Signup Topics]]


4. Fix the SUBMIT button issue during role selection
'''Test:'''


''' III. Code placed in the wrong locations to be moved to the desired locations.''' <br>
*[https://github.com/expertiza/expertiza/pull/2392/files#diff-5df8b9300332120367b2b5930ef57a17907270e3705e7ed90e0f5f825f335449 spec/helpers/sign_up_sheet_helper_spec.rb]
Example:<br>
 
# The email code moved to the email module.
[[File:e2245-helper-testcase.png|1200px|Add Signup Topics]]
# Code written in team file moved to the assignment team file.
 
 
'''Configuration:'''
 
*config/locales/en_US.yml


== Functionalities added ==
== Functionalities added ==
   
   
* The mentor should be able to check submissions of his team.<br>
# [https://drive.google.com/file/d/1uSPnL0S0E2VqvTidk534pcv-2rX4dBtN/view?usp=sharing Here is the link to our recorded demo of the feature]
This is a new functionality, where a mentor when logged in , would be able to view all the teams assigned under him for an assignment, when he clicks view and manage teams. Additionally the respective teams submissions and submission histories could be viewed by the mentor (if and only a submission is available).Existing functions and classes were reused.
# The instructor should be able to see how many teams have bid for each topic without having to impersonate students<br>
 
Here is the screenshot of real app running that shows what the Instructor will see in Assignment >> Topic view:


[[File:assignment-topics.png|1200px|Assignment Topics View]]


== Testing ==
== Testing ==
# Some existing test cases have been modified, which have been reverted. <br>
# Run and pass the existing RSpec Tests. <br>
# Test the UI for the deployed project.<br>


== UI Testing ==
=== Manual UI testing for the deployed project. ===
Part 1: <br>
 
* Login as the instructor6 <br>
==== UI Testing ====
'''Instructor View''' <br>
* username: instructor6 <br>
* password: password <br>
 
'''Student View'''  <br>
* username: student575 <br>
* password: password <br>
 
==== View total bids for a topic ====
# Log into expertiza as Instructor
# Go to Assignments >> Topics page/tab
# Execute this query against the application database to get the total number of bids for each topic for a particular assignment: SELECT topic_id as topic_id, COUNT(b.topic_id) as count FROM sign_up_topics t JOIN bids b ON t.id = b.topic_id WHERE t.assignment_id = 834 GROUP BY t.id
# Once the Topics page shows up, verify the bidding details (total number of bids) for each Topic on the table
 
Example:
 
<pre>
 
mysql> SELECT topic_id as topic_id, COUNT(b.topic_id) as count FROM sign_up_topics t JOIN bids b ON t.id = b.topic_id WHERE t.assignment_id = 834 GROUP BY t.id;
+----------+-------+
| topic_id | count |
+----------+-------+
|    3918 |    29 |
|    3919 |    14 |
|    3920 |    12 |
|    3921 |    29 |
|    3922 |    19 |
|    3923 |    13 |
|    3924 |    14 |
|    3925 |    15 |
|    3926 |    11 |
|    3927 |    10 |
|    3928 |    9 |
|    3929 |    6 |
|    3930 |    7 |
|    3931 |    8 |
|    3932 |    5 |
|    3933 |    7 |
|    3934 |    17 |
|    3935 |    12 |
|    3936 |    4 |
|    3937 |    19 |
|    3938 |    10 |
+----------+-------+
21 rows in set (0.00 sec)
 
</pre>
 
==== View total of #1 bids for a topic ====
# Log into expertiza as Instructor
# Go to Assignments >> Topics page/tab
# Execute this query against the application database to get the total number of bids for each topic for a particular topic: select * from bids where priority = 1 and topic_id=3918;
# Once the Topics page shows up, verify the bidding details (total number of #1 bids) for each Topic on the table
 
Example:
 
<pre>
 
mysql> select count(*) from bids where priority = 1 and topic_id=3918;
+----------+
| count(*) |
+----------+
|      10 |
+----------+
1 row in set (0.00 sec)


Part 2:  <br>
</pre>
* Login as student575 (added to the program by the instructor) <br>


==== View total of #2 bids for a topic ====
# Log into expertiza as Instructor
# Go to Assignments >> Topics page/tab
# Execute this query against the application database to get the total number of bids for each topic for a particular topic: select * from bids where priority = 2 and topic_id=3918;
# Once the Topics page shows up, verify the bidding details (total number of # 2 bids) for each Topic on the table


Example:
<pre>
mysql> select count(*) from bids where priority = 2 and topic_id=3921;
+----------+
| count(*) |
+----------+
|        6 |
+----------+
1 row in set (0.00 sec)
</pre>
==== Test case for sign_up_sheet_helper ====
<pre>
  describe '#get_team_bids' do
    before(:each) do
      @assignment1 = create(:assignment, name: 'final 1', directory_path: 'final_1')
      @topic1 = create(:topic, assignment: @assignment1)
      @assignment2 = create(:assignment, name: 'final 2', directory_path: 'final_2')
      @topic2 = create(:topic, assignment: @assignment2)
      @participant1 = create(:participant, assignment: @assignment1)
    end
    it 'The get_team_bids method return an empty string' do
      out_string = helper.get_team_bids(@topic1, [@participant1])
      expect(out_string).to be_nil
    end
    it 'The get_team_bids method should throw an exception' do
      expect { helper.get_team_bids(@topic1, @assignment1, nil) }.to raise_exception(ArgumentError)
    end
  end 
</pre>


== Future Work ==
== Future Work ==
* If a mentor is removed from an assignment, reassignment of mentor has to be done. (edge-case)
 
* Rspec for email functionality needs to be implemented.
Because of the time constraints, we could only implement that much of features and would like to layout some potential future works need to be done:
 
# More testing for edge-cases
# Add automatic test for UIs


==Team Roster ==
==Team Roster ==
Mentor: Ed Gehringer - efg@ncsu.edu
*Duy Nguyen - dvnguye3@ncsu.edu <br>
*Duy Nguyen - dvnguye3@ncsu.edu <br>
*Kwon HyeokJun - khyeokj@ncsu.edu <br>
*Kwon HyeokJun - khyeokj@ncsu.edu <br>
*Shawn S - ssaleki@ncsu.edu <br>
*Shawn Salekin - ssaleki@ncsu.edu <br>
*David Glymph - dwglymph@ncsu.edu <br>
*David Glymph - dwglymph@ncsu.edu <br>
Mentor: Ed Gehringer - efg@ncsu.edu


== Reference ==
== Reference ==
[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2019_-_E1994._Mentor_management_for_assignments_without_topics Previous Work]
#[https://docs.google.com/document/d/1tyWX8njxDLvYpN7wJf5hjA6lnWbzQRP9vUKGxxRjRzo/edit?pli=1#heading=h.5cgh9aixuut7 Previous works]
#[https://github.com/dnguyenv/expertiza/tree/beta Team code repo]
#[https://github.com/expertiza/expertiza/tree/beta Upstream code repo]

Latest revision as of 02:54, 29 April 2022

CSC/ECE 517 Spring 2022 - E2245: View for results of bidding

Problem Statement

When students sign up for topics, they are presented with a system to bid on their favorite topics. This process is allowed for both individual students as well as teams. As a result, many students will first sign up for topics, which can reduce the number of teams that get their first pick, and result in long waitlists. A bidding algorithms has been developed to give as many groups as possible their first choice. As this is an NP-complete problem, the algorithm has to use heuristics to guess efficiently. There needs to be a way for instructors to easily view and compare the results of the bidding algorithms to get a quantitative sense of their effectiveness.

Project Goal

This project aims to solve this issue by giving clear and concise feedback of the algorithms in topics list in the assignment. However, since topics in the table potentially have several fields, care must be taken not to overcrowd the table with information. There are several different UI/UX approaches to display this information, and the chosen one should:

  • Maximize useful information at a glance, while minimizing clutter
  • Fit into the flow of the topic page
  • Allow further information to be obtained if requested
  • Not be visible if bidding is not used

Some other miscellaneous goals of this project are to:

  • Remove topic fields from view if they are not applicable
  • Refactor code as needed
  • Increase test coverage as appropriate

Previous Work

Current User Cases

Below is the use case diagram that depicts the existing use cases that associated to the topics bidding features of the application. Notice that in order to check some bidding information for a topic/project, the Instructor has to impersonate a student.

Old user cases

Current Work Flow Diagram

As an Instructor, the user after, being authenticated, needs to go to the Assignments >> Topics view to create the topics/projects and then once the bidding started, needs to impersonate a student to partially (at very minimal level) get the bidding process information

Old user cases

Strategy to implement our plan to improve previous Works

Change in Use Cases

Old user cases

Student: This actor is responsible for submitting and deleting bids for topics while the topic selection period is open for an assignment which uses the new lottery topic selection mechanism.

Instructor: This actor is responsible for updating an assignment to use the new lottery topic selection as well as closing the bidding period and beginning the automatic topic selection. Instructor is also able to view the progress details of bids without having to impersonate students

UI design

The existing view with very limited information about the bidding process

Before:

Popup prototype


With this proposed new view, the Instructor can gain a more complete view of the whole bidding process in one place.

Proposed UI

Popup prototype

Change in Work Flow Diagram

With the new flow and implementation, the Instructor now can have all (complete) information he/she needs in one place at the Topics list/details view instead of having to impersonate a student to get even some minimal, un-completed piece of information about the bidding.

Old user cases

Class Diagram

Class diagram


Track our works for transparency, collaboration and productivity

We've been working collaboratively to deliver this project as a team, by using Github Project feature to assign, track and collaborate our tasks. We've created an accompanying github project for this purpose, link can be found here

project tasks

Code changes

From preliminary research, we believed we would need to add and modify, refactor code from almost all layers of the features (including Controllers, Models, Views but we end up decided to focus on delivering the feature with minimum code changes and regression tests, so majority of our code changes are on Views layer. Following are the changes we made (We also added links to our Github commits for each change so that the reviewers can link directly to github for more in-depth inspection/review)


New Files added:

Total bids

1-2 bids

Files changed:

View:

Add Signup Topics

Add Signup Topics

Add Signup Topics

Helper:

Add Signup Topics

Test:

Add Signup Topics


Configuration:

  • config/locales/en_US.yml

Functionalities added

  1. Here is the link to our recorded demo of the feature
  2. The instructor should be able to see how many teams have bid for each topic without having to impersonate students

Here is the screenshot of real app running that shows what the Instructor will see in Assignment >> Topic view:

Assignment Topics View

Testing

Manual UI testing for the deployed project.

UI Testing

Instructor View

  • username: instructor6
  • password: password

Student View

  • username: student575
  • password: password

View total bids for a topic

  1. Log into expertiza as Instructor
  2. Go to Assignments >> Topics page/tab
  3. Execute this query against the application database to get the total number of bids for each topic for a particular assignment: SELECT topic_id as topic_id, COUNT(b.topic_id) as count FROM sign_up_topics t JOIN bids b ON t.id = b.topic_id WHERE t.assignment_id = 834 GROUP BY t.id
  4. Once the Topics page shows up, verify the bidding details (total number of bids) for each Topic on the table

Example:


mysql> SELECT topic_id as topic_id, COUNT(b.topic_id) as count FROM sign_up_topics t JOIN bids b ON t.id = b.topic_id WHERE t.assignment_id = 834 GROUP BY t.id;
+----------+-------+
| topic_id | count |
+----------+-------+
|     3918 |    29 |
|     3919 |    14 |
|     3920 |    12 |
|     3921 |    29 |
|     3922 |    19 |
|     3923 |    13 |
|     3924 |    14 |
|     3925 |    15 |
|     3926 |    11 |
|     3927 |    10 |
|     3928 |     9 |
|     3929 |     6 |
|     3930 |     7 |
|     3931 |     8 |
|     3932 |     5 |
|     3933 |     7 |
|     3934 |    17 |
|     3935 |    12 |
|     3936 |     4 |
|     3937 |    19 |
|     3938 |    10 |
+----------+-------+
21 rows in set (0.00 sec)

View total of #1 bids for a topic

  1. Log into expertiza as Instructor
  2. Go to Assignments >> Topics page/tab
  3. Execute this query against the application database to get the total number of bids for each topic for a particular topic: select * from bids where priority = 1 and topic_id=3918;
  4. Once the Topics page shows up, verify the bidding details (total number of #1 bids) for each Topic on the table

Example:


mysql> select count(*) from bids where priority = 1 and topic_id=3918;
+----------+
| count(*) |
+----------+
|       10 |
+----------+
1 row in set (0.00 sec)

View total of #2 bids for a topic

  1. Log into expertiza as Instructor
  2. Go to Assignments >> Topics page/tab
  3. Execute this query against the application database to get the total number of bids for each topic for a particular topic: select * from bids where priority = 2 and topic_id=3918;
  4. Once the Topics page shows up, verify the bidding details (total number of # 2 bids) for each Topic on the table

Example:


mysql> select count(*) from bids where priority = 2 and topic_id=3921;
+----------+
| count(*) |
+----------+
|        6 |
+----------+
1 row in set (0.00 sec)

Test case for sign_up_sheet_helper


  describe '#get_team_bids' do
    before(:each) do
      @assignment1 = create(:assignment, name: 'final 1', directory_path: 'final_1')
      @topic1 = create(:topic, assignment: @assignment1)
      @assignment2 = create(:assignment, name: 'final 2', directory_path: 'final_2')
      @topic2 = create(:topic, assignment: @assignment2)
      @participant1 = create(:participant, assignment: @assignment1)
    end

    it 'The get_team_bids method return an empty string' do
      out_string = helper.get_team_bids(@topic1, [@participant1])
      expect(out_string).to be_nil
    end

    it 'The get_team_bids method should throw an exception' do
      expect { helper.get_team_bids(@topic1, @assignment1, nil) }.to raise_exception(ArgumentError)
    end
  end  

Future Work

Because of the time constraints, we could only implement that much of features and would like to layout some potential future works need to be done:

  1. More testing for edge-cases
  2. Add automatic test for UIs

Team Roster

Mentor: Ed Gehringer - efg@ncsu.edu

  • Duy Nguyen - dvnguye3@ncsu.edu
  • Kwon HyeokJun - khyeokj@ncsu.edu
  • Shawn Salekin - ssaleki@ncsu.edu
  • David Glymph - dwglymph@ncsu.edu

Reference

  1. Previous works
  2. Team code repo
  3. Upstream code repo