iSchool Peer Feedback Tool

Features

We spent the first semester creating a list of MVP requirements, a project charter, and discussing our plans for design, development, and the final implementation. Through many iterations, we decided on the following requirements:

• Develop a user role management system, allowing users to select and assign roles. Presently, there are two distinct roles for forms:
  • Creator: Creators possess the capability to generate customized feedback forms and access responses. They have the right to say who gets to see their forms and how it gets grouped (e.g., the different teams in ISTE 500 or different groups for faculty review).
  • Responder: Responders are solely tasked with completing the assigned feedback forms.
  • Super Admin: The Super Admin is in charge of assigning the Creators.
• Enable Creators to design and customize feedback forms according to specific requirements, granting them the flexibility to tailor forms to the unique needs of different projects or assessments.
• Ensure Responders can efficiently and effectively provide feedback by streamlining the form-filling process.
• Implement functionality to export form responses in CSV (Comma-Separated Values) format, facilitating seamless data transfer and analysis across various platforms and applications.
• Ensure the anonymity of responses to foster candid and unbiased feedback. Implement robust mechanisms to anonymize responses effectively, safeguarding the confidentiality and integrity of feedback data throughout the process. The creator of the form should be the only one who can see the respondents.

Screens

Shibboleth Login

Users can securely log in using Shibboleth, similar to RIT's own login system.

Creating a Form

One of the hardest parts of this project was making it work for both faculty reviews and in-class student reviews. The tool had to be flexible enough to handle both situations and use language that reflected that. We create a system of "Groups", "Teams", and "Users" to effectively capture both use cases.

At the second-highest level of power, behind only admins, creators can make new forms, edit existing forms and assigned teams/users, and view individual and aggregated submission data. Creators can be also be responders on forms.

Only users in the same team can submit responses for each other. This can be seen later on in the "Responding To Forms" section.

An important feature is the ability to add multiple creators and set their permissions individually. This way, multiple people can see data, edit forms, and edit assigned teams / users. In some cases, we didn't want every creator to have access to all of these features. This also applies to the initial creator, who, on the honor system, might need to remove some of their own abilities on a particular form.

Start and end dates determine when the form becomes available to responders and if it can be edited (forms cannot be edited after they open, to protect submission data tables).

Admin Page

Admins are able to delegate roles to users and have a dedicated page viewable only to them. This was in response to a need for user management that wouldn't require backend skills / knowledge, as the admin wouldn't necessarily be a technically-savy individual.

Form States

Forms have appropriate states depending on a form's status (Complete Form, Completed, Not Yet Available, Passed Deadline).

Responding To Forms

Users who are assigned to a form can respond if it's available (which happens when it's past the creator-set start date). Once all submissions are made, a message confirms to the user that they've completed this form and the dashboard view reflects this (by setting the form to a "Completed" status and stopping any further actions).