CSC/ECE 517 Fall 2015 E1584 Send Feedback to Support: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
(Created page with "'''E1584. Send Feedback to Support''' This is the design document for the Feedback to Support feature of Expertiza. This goal of this ==Project== === Introduction to Expertiza...")
 
 
(128 intermediate revisions by the same user not shown)
Line 1: Line 1:
'''E1584. Send Feedback to Support'''
'''E1584. Send Feedback to Support'''


This is the design document for the Feedback to Support feature of Expertiza. This goal of this
This is the design document for the Feedback to Support feature of Expertiza.
==Project==


=== Introduction to Expertiza ===
=Introduction=
[http://expertiza.ncsu.edu/ Expertiza] is a peer review based system which provides an incremental class based learning together with the instructors and the peers. This project has been developed together by faculty and students using [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza handles assignment submissions, team formations, assignment reviews and grades, etc.
'''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. <ref>[https://github.com/expertiza/expertiza Expertiza on GitHub]</ref>


=== Purpose ===
== Problem Statement ==
During reviews, many times reviewers will be having questions about the submitted material and if it's a blocker there is no way that the reviewer can progress further with the review.  As a result, reviewers will end up submitting the empty or incomplete review.


=== Scope ===
The objective of this project is to allow Expertiza users to directly send their issues to Expertiza support team via a support form. Currently there is no support feature and the problems are passed on to the support team via instructors. The aim of this feature is faster resolution of the problems which are faced by the users. This feature should be available to all registered users of Expertiza. The users will be able to use it even when they are not logged in. Moreover, it should allow users to send screenshots of their issues. Apart from the feedback form, a view for the support team is also required. This view would contain a collective list of all the problems and the support person would be able to change the status of the problems.
This project is limited to an email based conversation for asking questions and answers. The reviewers would ask questions related to assignment submission doubts to which authors can respond. All this would be taken care as email responses using a link provided in the email. This project does not cater to any live interactive session with spontaneous back-to-back questions and responses.


Following tasks would be incorporated in the project:
== Design Specification and Mock Ups ==
* Provide a ‘TextArea’ input field on review forms, where any reviewer can type in their questions.
* Create a new button ‘Ask for Quick Help’ on the review forms.
* An email would be send to the author with the link where he can respond to the questions asked by the reviewers for their submitted work.
* Reviewers would be notified by an email when authors respond to the the questions.


== Design ==
=== User related specifications ===
* The link to '''Support''' should be present in the '''footer'''. This should help facilitate feedback from un-logged users.
[[File:user_view_support_option.png]]


=== Discussion of Resolution ===
* Clicking on "Contact Support" should open a '''new page''' rather than a pop-up or modal dialog box.


We will make the following modifications to implement the chat feature:- <br>
* The feedback form should consist of the following fields: '''Email''', '''Name''' (optional), '''Title''', '''Description''' (optional), '''Attachments''' (optional) and '''CAPTCHA'''.
[[File:user_view_support_form.png]]


*Create a new model which will help extract,store and validate data in the database table which contains information about the interaction between the author/s and reviewer.
* The feedback should go '''expertiza-support@lists.ncsu.edu'''.


*Edit the view which is used by the response controller to incorporate the text area input field on the review form where the reviewer can ask his/her initial query.
* Users should send feedback using their own email-ids. Thus, if a logged-in user opens the feedback form, then the user's email-id will be automatically filled (and which cannot be edited).


*Create a new controller which will contain methods to send emails to the author and reviewers as well as retrieve and display the chat history between the two.
* The title field should have a maximum of '''160 characters'''.


*Create a new view which will facilitate the author to respond to the queries asked by the reviewer. The reviewer can also use this view to ask any follow up questions.
* Users should should have the facility to upload '''only one file''' in their feedback.  


=== Mock-Ups ===
* The uploaded file should be either in '''.pdf or .png/.jpg''' format. Moreover, the extension list should not be hard-coded. A '''white-list''' of the extensions supported should be present in the database. 
The sample question box would look like:


[[File: ARSNMockup1.JPG]]
* The size of the uploaded file should '''not exceed 2MB'''.


An interface with the question would be displayed on opening a link from the email.
* To avoid attacks, the feedback form should contain a '''CAPTCHA'''.
The authors can reply the query which reviewers ask.


[[File: ARSNMockup2.JPG]]
* There should be a separate method that keeps a check on '''multiple requests'''. An algorithm should be implemented to add incremental delay between consecutive requests after three trials.


=== Design Patterns ===
* If the user is not logged-in, then the following '''error message''' should be displayed for invalid email-id: '''"Invalid email-id. Please provide email-id registered with Expertiza"'''.
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum


=== Database Design ===
=== Support team related specifications  ===
* The link to '''Feedback''' should be accessible only to support people.


[[File:DatabaseTable.jpg]]
* The feedback page should contain a list of all the issues in a '''table format'''.
[[File:support_view_feedback.png]]


The above figure shows the schema of a new table which will be created in Expertiza to store relevant information about the chat. It contains the following attributes:
* Each feedback can be categorized into the following states:
* id: This attribute is auto-generated by rails when we create a table and is auto incremented with each record. It is also the primary key of our table.
** '''New''' - when a new feedback is generated by the user and not yet handled by any support person.  
* assignment_id: Stores the ID of the assignment for which the interaction between author and reviewer is taking place.
** '''In Progress''' - when a support person has viewed the feedback and started working on it.
* reviewer_id: Stores the ID of the reviewer who asks the questions.
** '''Completed''' - when a support person has solved the issue in the feedback.
* team_id: Stores the ID of the team to which the topic belongs.
** '''Invalid''' - when the feedback is not relevant to Expertiza.
* type_flag: Flag which is used to indicate if the particular tuple contains a question or answer. It can take two values, 'Q' for question and 'A' for answer.
* content: Stores the question asked by the reviewer or the response given by the author/s depending on the value of the type flag.


Records for a particular interaction can be identified by using a combination of assignment_id, reviewer_id and team_id.
* When a state is changed, the user may get notified through email.


=== Use Cases ===
* Support must have the facility to '''configure feedback settings'''. This includes mentioning support email-id, file extension while-list, Max number of attachments allowed, Max size of each attachment, Types of feedback states, and other settings for multiple requests.  
'''Name:''' Send a question to the author/s about their work.<br>
[[File:feedback_configuration_display_form.png]]
'''Actor:''' Reviewer. <br>
'''Description:''' The reviewer enters his question in the text area which is provided and clicks on the "Ask question" button which is provided as shown in the mock up. On clicking this button an email is sent to the author/s along which a link to answer the question.<br>
<br>
'''Name:''' Answer the question which has been asked by the reviewer.<br>
'''Actor:''' Author/s<br>
'''Description:''' The author/s click on the link received in their email and are redirected to a page where they can answer the question. Once they submit the answer, an email is sent to the reviewer notifying him/her that their question has been answered.<br>


=== Proposed Tests ===
=== Other Specifications ===
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum
* Currently, the attachment extension white-list and types of states of the feedback will be stored as '''comma separated values''' in the database.


== Implementation ==
= Implementation =
== Tables and Schema ==


'''Files created/modified:-'''
*feedbacks
::*id - primary key
::*user_email - contains the email of register user.
::*title - contains the title of the feedback.
::*description - contains the description of the feedback.
::*status - stores the current status of the feedback.


*Create a new model chat_feedback.rb
*feedback_attachments - stores feedback attachments in binary form
::*id - primary key
::*feedback_id - contains primary key of the feedback
::*filename - contains the filename of the feedback attachment
::*content_type - contains type and extension of the attachment like application/pdf or image/png.
::*data - contains the contents of the attachment in binary form


*Create a new controller review_interactions_controller.rb
*feedback_attachment_settings
::*id - primary key
::*file_type - contains the allowed extensions of the attachments like application/pdf or image/png.


*Create new views as discussed in the design.
*feedback_settings
::*id - primary key
::*support_mail - contains the email id of the where the feedback is submitted.
::*max_attachments - contains the maximum number of attachments allowed.
::*max_attachment_size - contains maximum size of attachments in kb.
::*wrong_retries - number of retires allowed before the system starts blocking the user.
::*wait_duration - number of minutes the user is blocked after attempting the specified wrong retires.
::*wait_duration_increment - number of minutes incremented in the wait duration after every wrong attempt made after attempting the specified wrong retries.
::*support_team - list of emails(comma separated) who can view/edit the user feedbacks.


*Modify view expertiza/app/views/response/response.html.erb to incorporate text box and corresponding submit button.
*feedback_statuses
::*id - primary key
::*status - contains possible states of the feedback like new, in progress, completed etc.


'''Flow:-'''
== Models ==
*feedback.rb - Model to store feedback. It also validates the presence of email and title field.
*feedback_attachment.rb - Model to store feedback attachments. Function '''attachment_type_validation''' validates file type and '''uploaded_file''' reads the data into binary format.
*feedback_attachment_settings.rb - Model to store '''file_type''' of the attachment allowed in the database.
*feedback_settings.rb - Model to store the feedback settings.
*feedback_status.rb - Model to store list of '''status''' of the feedback in the database.


*The reviewer enters his question in the text area provided and clicks on the "Ask Question" button.
== Controllers ==
*On clicking this button the appropriate method is called in review_interactions_controller.rb which sends an email to all the authors of the topic indicating that a question has been asked about their work. The email contains a link which when clicked on will redirect the author to the appropriate view where he/she can answer the question.
*On answering the question, the reviewer receives an email indicating that his question has been answered. It also contains a link which redirects the reviewer to the appropriate view where the answer will be displayed.
*This view also contains the chat history between the author/s and the reviewer for the entire duration of the interaction.


== Suggestions for Future Improvements ==
*feedbacks_controller.rb - controller handles the following feedback related functions
::*'''index''' - displays list of all feedbacks in tabular format
::*'''show''' - display feedback based on id
::*'''download_feedback_attachment''' - facilitates downloading the uploaded attachment
::*'''new''' - creates new feedback form
::*'''edit''' - allows support to change the feedback status
::*'''verify_captcha''' - function to verify whether the CAPTCHA is entered correctly
::*'''create''' - creates new feedback
::*'''wrong_retries_calculator''' - calculates the number of wrong attempts and the wait duration if the wrong attempts exceed the threshold value
::*'''send_support_email''' - sends feedback details to support via email
::*'''create_attachment''' - saves an attachment in the database with feedback_id as a foreign key
::*'''update''' - facilitates status change
::*'''destroy''' - deletes a feedback entry


* This can be extended to a live interactive author-reviewer anonymous chat session inside the Expertiza reviews window.
*feedback_settings_controller.rb
* A purging script can be developed which will clear all the interaction records every semester.
::*'''index''' - to display current feedback settings, attachment settings and status settings
::*'''new''' - renders new settings page
::*'''add_attachment_type''' - function to save new attachment type
::*'''add_status''' - function to save new feedback status
::*'''create''' - function to save only feedback settings
::*'''update''' - function to facilitate change in feedback settings
::*'''destroy''' - function to destroy feedback settings
::*'''delete_attachment_type''' - function to delete existing attachment type
::*'''delete_status''' - function to delete existing feedback status
::*'''set_file_types''' - function to fetch attachment settings and status settings


==Resources==
== Views ==


* Expertiza Github repository<ref>Expertiza Github repository https://github.com/expertiza/expertiza</ref>
*feedbacks
::*_form.html.erb - partial for new feedback form
::*edit.html.erb - view for editing status of the feedback
::*index.html.erb - displays list of feedbacks in tabular form
::*show.html.erb - form to display a single feedback


==References==
*feedback_settings
::*_add_file_type.html.erb - partial for adding new file extension
::*_add_status.html.erb - partial for adding new feedback status
::*_form.html.erb - partial for editing feedback settings
::*edit.html.erb - contains form, add_file_type, and add_status partial
::*index.html.erb - displays only feedback settings in tabular form
::*new.html.erb - contains form to enter new feedback settings
::*show.html.erb - display only feedback settings
 
= Testing =
== Gems ==
* gem 'capybara'
* gem 'factory_girl_rails'
* gem 'database_cleaner'
 
== Factories ==
* feedback_testing.rb - It contains factories for feeedback_settings, feedback_attachment_settings and user
 
== Features ==
* feedback_submission.rb - It contains Capybara with Rspec scenarios for feedback submission by unlogged user.
 
== Spec ==
* rails_helper.rb - contains code foe database cleaner to truncate user, feedback_settings and feedback_attachment_settings tables after the tests
 
== Test result ==
[[File:test_result.png]]
 
= Screenshots =
 
* Homepage with "Report An Error"
[[File:expertiza_homepage.png]]
 
* Feedback form
[[File:expertiza_feedback_form.png]]
 
* View Feedbacks Link in the footer
[[File:expertiza_view_feedback.png]]
 
* List of all feedbacks
[[File:expertiza_feedback_list.png]]
 
* Edit feedback settings
[[File:expertiza_feedback_setting.png]]
`
 
=References=
<references/>
<references/>
== External Sources ==
* [https://github.com/ambethia/recaptcha/ Recaptcha in Ruby]

Latest revision as of 16:47, 16 December 2015

E1584. Send Feedback to Support

This is the design document for the Feedback to Support feature of Expertiza.

Introduction

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. <ref>Expertiza on GitHub</ref>

Problem Statement

The objective of this project is to allow Expertiza users to directly send their issues to Expertiza support team via a support form. Currently there is no support feature and the problems are passed on to the support team via instructors. The aim of this feature is faster resolution of the problems which are faced by the users. This feature should be available to all registered users of Expertiza. The users will be able to use it even when they are not logged in. Moreover, it should allow users to send screenshots of their issues. Apart from the feedback form, a view for the support team is also required. This view would contain a collective list of all the problems and the support person would be able to change the status of the problems.

Design Specification and Mock Ups

User related specifications

  • The link to Support should be present in the footer. This should help facilitate feedback from un-logged users.

  • Clicking on "Contact Support" should open a new page rather than a pop-up or modal dialog box.
  • The feedback form should consist of the following fields: Email, Name (optional), Title, Description (optional), Attachments (optional) and CAPTCHA.

  • The feedback should go expertiza-support@lists.ncsu.edu.
  • Users should send feedback using their own email-ids. Thus, if a logged-in user opens the feedback form, then the user's email-id will be automatically filled (and which cannot be edited).
  • The title field should have a maximum of 160 characters.
  • Users should should have the facility to upload only one file in their feedback.
  • The uploaded file should be either in .pdf or .png/.jpg format. Moreover, the extension list should not be hard-coded. A white-list of the extensions supported should be present in the database.
  • The size of the uploaded file should not exceed 2MB.
  • To avoid attacks, the feedback form should contain a CAPTCHA.
  • There should be a separate method that keeps a check on multiple requests. An algorithm should be implemented to add incremental delay between consecutive requests after three trials.
  • If the user is not logged-in, then the following error message should be displayed for invalid email-id: "Invalid email-id. Please provide email-id registered with Expertiza".

Support team related specifications

  • The link to Feedback should be accessible only to support people.
  • The feedback page should contain a list of all the issues in a table format.

  • Each feedback can be categorized into the following states:
    • New - when a new feedback is generated by the user and not yet handled by any support person.
    • In Progress - when a support person has viewed the feedback and started working on it.
    • Completed - when a support person has solved the issue in the feedback.
    • Invalid - when the feedback is not relevant to Expertiza.
  • When a state is changed, the user may get notified through email.
  • Support must have the facility to configure feedback settings. This includes mentioning support email-id, file extension while-list, Max number of attachments allowed, Max size of each attachment, Types of feedback states, and other settings for multiple requests.

Other Specifications

  • Currently, the attachment extension white-list and types of states of the feedback will be stored as comma separated values in the database.

Implementation

Tables and Schema

  • feedbacks
  • id - primary key
  • user_email - contains the email of register user.
  • title - contains the title of the feedback.
  • description - contains the description of the feedback.
  • status - stores the current status of the feedback.
  • feedback_attachments - stores feedback attachments in binary form
  • id - primary key
  • feedback_id - contains primary key of the feedback
  • filename - contains the filename of the feedback attachment
  • content_type - contains type and extension of the attachment like application/pdf or image/png.
  • data - contains the contents of the attachment in binary form
  • feedback_attachment_settings
  • id - primary key
  • file_type - contains the allowed extensions of the attachments like application/pdf or image/png.
  • feedback_settings
  • id - primary key
  • support_mail - contains the email id of the where the feedback is submitted.
  • max_attachments - contains the maximum number of attachments allowed.
  • max_attachment_size - contains maximum size of attachments in kb.
  • wrong_retries - number of retires allowed before the system starts blocking the user.
  • wait_duration - number of minutes the user is blocked after attempting the specified wrong retires.
  • wait_duration_increment - number of minutes incremented in the wait duration after every wrong attempt made after attempting the specified wrong retries.
  • support_team - list of emails(comma separated) who can view/edit the user feedbacks.
  • feedback_statuses
  • id - primary key
  • status - contains possible states of the feedback like new, in progress, completed etc.

Models

  • feedback.rb - Model to store feedback. It also validates the presence of email and title field.
  • feedback_attachment.rb - Model to store feedback attachments. Function attachment_type_validation validates file type and uploaded_file reads the data into binary format.
  • feedback_attachment_settings.rb - Model to store file_type of the attachment allowed in the database.
  • feedback_settings.rb - Model to store the feedback settings.
  • feedback_status.rb - Model to store list of status of the feedback in the database.

Controllers

  • feedbacks_controller.rb - controller handles the following feedback related functions
  • index - displays list of all feedbacks in tabular format
  • show - display feedback based on id
  • download_feedback_attachment - facilitates downloading the uploaded attachment
  • new - creates new feedback form
  • edit - allows support to change the feedback status
  • verify_captcha - function to verify whether the CAPTCHA is entered correctly
  • create - creates new feedback
  • wrong_retries_calculator - calculates the number of wrong attempts and the wait duration if the wrong attempts exceed the threshold value
  • send_support_email - sends feedback details to support via email
  • create_attachment - saves an attachment in the database with feedback_id as a foreign key
  • update - facilitates status change
  • destroy - deletes a feedback entry
  • feedback_settings_controller.rb
  • index - to display current feedback settings, attachment settings and status settings
  • new - renders new settings page
  • add_attachment_type - function to save new attachment type
  • add_status - function to save new feedback status
  • create - function to save only feedback settings
  • update - function to facilitate change in feedback settings
  • destroy - function to destroy feedback settings
  • delete_attachment_type - function to delete existing attachment type
  • delete_status - function to delete existing feedback status
  • set_file_types - function to fetch attachment settings and status settings

Views

  • feedbacks
  • _form.html.erb - partial for new feedback form
  • edit.html.erb - view for editing status of the feedback
  • index.html.erb - displays list of feedbacks in tabular form
  • show.html.erb - form to display a single feedback
  • feedback_settings
  • _add_file_type.html.erb - partial for adding new file extension
  • _add_status.html.erb - partial for adding new feedback status
  • _form.html.erb - partial for editing feedback settings
  • edit.html.erb - contains form, add_file_type, and add_status partial
  • index.html.erb - displays only feedback settings in tabular form
  • new.html.erb - contains form to enter new feedback settings
  • show.html.erb - display only feedback settings

Testing

Gems

  • gem 'capybara'
  • gem 'factory_girl_rails'
  • gem 'database_cleaner'

Factories

  • feedback_testing.rb - It contains factories for feeedback_settings, feedback_attachment_settings and user

Features

  • feedback_submission.rb - It contains Capybara with Rspec scenarios for feedback submission by unlogged user.

Spec

  • rails_helper.rb - contains code foe database cleaner to truncate user, feedback_settings and feedback_attachment_settings tables after the tests

Test result

Screenshots

  • Homepage with "Report An Error"

  • Feedback form

  • View Feedbacks Link in the footer

  • List of all feedbacks

  • Edit feedback settings

`

References

<references/>

External Sources

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2015_E1584_Send_Feedback_to_Support&oldid=100587"